sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
kgk has joined #bitcoin-wizards
arowser has quit [Read error: Connection reset by peer]
kgk has quit [Ping timeout: 260 seconds]
arowser has joined #bitcoin-wizards
sparetire_ has quit [Read error: Connection reset by peer]
melvster has quit [Ping timeout: 240 seconds]
sparetire_ has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
pozitrono has quit [Ping timeout: 255 seconds]
Tiraspol has quit [Remote host closed the connection]
frankenmint has joined #bitcoin-wizards
Tiraspol has joined #bitcoin-wizards
PaulCapestany has quit [Quit: .]
PaulCapestany has joined #bitcoin-wizards
frankenmint has quit [Remote host closed the connection]
mrkent has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
CodeShark has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
CodeShark_ has joined #bitcoin-wizards
CodeShark has quit [Read error: Connection reset by peer]
alferz has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence_ has joined #bitcoin-wizards
Quanttek has quit [Ping timeout: 250 seconds]
Burrito has quit [Quit: Leaving]
Ylbam has quit [Quit: Connection closed for inactivity]
dEBRUYNE has quit [Ping timeout: 265 seconds]
frankenmint has joined #bitcoin-wizards
bassguitarman has quit [Remote host closed the connection]
artifexd has quit [Remote host closed the connection]
wpalczynski has quit [Remote host closed the connection]
mikolalysenko has quit [Remote host closed the connection]
runeks has quit [Remote host closed the connection]
adams__ has quit [Remote host closed the connection]
c-cex-yuriy has quit [Remote host closed the connection]
kumavis has quit [Remote host closed the connection]
<yoleaux>
how many qubits to break RSA-2048? "Current estimates range from tens of millions to a billion physical qubits." http://eprint.iacr.org/2015/1075.pdf (@veorq)
<nsh>
seems off to me, but what do i know...
davec has quit [Read error: Connection reset by peer]
<nsh>
i suppose time-space tradeoffs don't work the same in quantum algorithms because of the difference in nature of intermediary state
davec has joined #bitcoin-wizards
<nsh>
(superpositions cannot be an output used an an input to another subcalculation, unlike in classical algorithmics)
<nsh>
*as an
<nsh>
s/superpositions/correlations/
Keefe has quit [Ping timeout: 240 seconds]
atgreen has quit [Ping timeout: 240 seconds]
Keefe has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
damethos has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
jojva has joined #bitcoin-wizards
kgk has joined #bitcoin-wizards
kgk has quit [Ping timeout: 260 seconds]
matsjj has quit [Read error: Connection reset by peer]
ThomasV has quit [Ping timeout: 246 seconds]
matsjj has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
mjerr has quit [Ping timeout: 265 seconds]
ThomasV has joined #bitcoin-wizards
Piper-Off is now known as Monthrect
<kanzure>
gavinandresen: "disappointed you don't mention the tradeoff at "the other end of the bathtub" -- Key-holder versus Validator decentralization balance"
<kanzure>
gavinandresen: just to clarify, do you mean "the number of transactions that key-holders make" or do you mean "the absolute number of key-holders"?
nessence has joined #bitcoin-wizards
frankenm_ has quit [Remote host closed the connection]
<kanzure>
anyone can get a private key, and anyone can be given BTC; you can even argue for complex child-pays-for-parent schemes. if you have a private key that is assigned BTC through a complex series of lightning network transactions, does that count towards "key-holder decentralization" even if not yet committed? (note that the working assumption is lightning network commitment transaction did indeed get into the blockchain somewhere)
nessence has quit [Client Quit]
TBI has joined #bitcoin-wizards
Monthrect is now known as Piper-Off
<kanzure>
and also, if there's a bunch of merge-mined sidechains that store BTC-pegged amounts, where transaction fees are possibly lower, accessible via lightning network payment routing, would that count as "key-holder decentralization" or no...? not sure what your preferences are with these definitions and boundaries.
TBI_ has quit [Ping timeout: 250 seconds]
ThomasV has quit [Ping timeout: 265 seconds]
mjerr has joined #bitcoin-wizards
kyuupichan has joined #bitcoin-wizards
atgreen has joined #bitcoin-wizards
<kanzure>
"I'd like to take a second to submit a new argument in favor of transaction fees. I suspect the other arguments are much stronger and more comprehensive, but here's a new one. All transactions have priority; they indicate some transfer that you have preferred rather than some other transaction. There is an opportunity cost to every single transaction that anyone makes for any reason. The real transaction fee that a user is willing to ...
<kanzure>
... pay must be non-zero. There may be scenarios where most reasonable transaction fees are sub-satoshi amounts, but still some non-zero amount, even 1/1000th of a satoshi BTC. (At some point you hit limits to where tracking a billionth of a satoshi has negative economic value, even though the amount is still positive, but I haven't looked at what that amount actually is, I doubt it's 1 satoshi BTC exactly at the moment!)."
<kanzure>
unconfirmed transactions are sadly a liquidity lock of some kind, and anything that can mitigate or minimize the effects of liquidity lock are v. good (lightning qualifies)
mjerr has quit [Ping timeout: 264 seconds]
<Taek>
conversation about oracles vs arbiters:
<Taek>
<amiller_> for arbiter vs oracle
<Taek>
<amiller_> oracle is kind of an abstract thing used in computer science, it kind of refers to an over idealized thing
<Taek>
<amiller_> i reject the use of 'oracle' as it is in cryptocurrency
<Taek>
<amiller_> in cryptocurrency it usually means an actual trusted party, that is there in the actual thing!
<Taek>
<amiller_> so we chose arbiter as a specific role
<Taek>
<amiller_> parties filling the role of arbiter are subject to incentives and possible corruptions same as other parties
<Taek>
<amiller_> so... a little bit pedantic and grumpy
<Taek>
<Taek> yeah iirc 'Oracles' are traditionally infallible
<kanzure>
"escrowacle"
<kanzure>
besides the size of the transaction backlog itself existing outside of consensus, you cannot rely on unconfirmed transaction presence in backlog to figure out user priorities, because zero-fee unconfirmed transactions could be generated by anyone for any reason (even malicious miners that are trying to DOS the network, or other malcontents, who knows)- you must select by fee. this is quite similar to the other kinds of sybil resistance ...
<kanzure>
... in bitcoin.
damethos has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
grubles has joined #bitcoin-wizards
copumpkin has joined #bitcoin-wizards
jojva has quit [Ping timeout: 240 seconds]
Doge_Funnie has joined #bitcoin-wizards
kgk has joined #bitcoin-wizards
kgk has quit [Ping timeout: 260 seconds]
c0rw|zZz is now known as c0rw1n
bedeho has joined #bitcoin-wizards
frankenmint has quit [Remote host closed the connection]
frankenmint has joined #bitcoin-wizards
trippysalmon has joined #bitcoin-wizards
frankenmint has quit [Ping timeout: 244 seconds]
c0rw1n has quit []
c0rw1n has joined #bitcoin-wizards
Dizzle has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
Yoghur114 has joined #bitcoin-wizards
Yoghur114 has quit [Read error: No route to host]
pozitrono has quit [Ping timeout: 260 seconds]
copumpkin has quit [Read error: Connection reset by peer]
copumpkin has joined #bitcoin-wizards
alferz has quit [Ping timeout: 244 seconds]
Yoghur114 has joined #bitcoin-wizards
cluckj has joined #bitcoin-wizards
Emcy has quit [Read error: Connection reset by peer]
pozitron has joined #bitcoin-wizards
alferz has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Emcy has joined #bitcoin-wizards
hashtag_ has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 252 seconds]
matsjj has quit [Remote host closed the connection]
the`doctor has joined #bitcoin-wizards
alferz has quit [Ping timeout: 244 seconds]
kgk has joined #bitcoin-wizards
the`doct1r has joined #bitcoin-wizards
kgk has quit [Ping timeout: 260 seconds]
the`doctor has quit [Ping timeout: 244 seconds]
alferz has joined #bitcoin-wizards
the`doct1r has quit [Ping timeout: 240 seconds]
the`doctor has joined #bitcoin-wizards
onetime has joined #bitcoin-wizards
mjerr has joined #bitcoin-wizards
hdbuck has joined #bitcoin-wizards
the`doctor has quit [Ping timeout: 260 seconds]
the`doctor has joined #bitcoin-wizards
mjerr has quit [Ping timeout: 252 seconds]
rusty has joined #bitcoin-wizards
jojva has joined #bitcoin-wizards
the`doctor has quit [Quit: Lost terminal]
<rusty>
Luke-Jr: Do you have a draft for SW? I'm trying to figure out exactly what the benefits are, and I haven't had coffee yet this morning.
mjerr has joined #bitcoin-wizards
<sipa>
rusty: i'm working on a segregated witness implementation
prosodyvVC is now known as prosodyvVerreabC
<sipa>
benefits: prunability of signatures (you don't need to download them if you're not going to verify them), opt-in solving of malleability (though it require all non-confirmed inputs to be SW), increased scale (because old consensus rules do not count the witness data as part of blocks)
<gmaxwell>
The specific construction we've been working on also carries some other benefits, e.g. radically simplifying script soft-forks (my making it easier to make new things soft-fork safe).
pozitron has quit [Ping timeout: 250 seconds]
<sipa>
and being P2SH compatible
<rusty>
sipa: the prunability is nice, though UTXO set commitment offers a more finegrained solution. Malleability is a win. But scale argument seems disingenous: most arguments are about bandwidth, not how hard it is to remove the 1MB limit.
<gmaxwell>
and it has the above benefits (e.g. the elimination of malleability) without imposing long term costs like increasing the utxo set size by 20%.
<sipa>
rusty: IMHO utxo commitments are completely orthogonal
matsjj has joined #bitcoin-wizards
<rusty>
sipa: yes, but if you're interested in partial validation, they're much more powerful.
<gmaxwell>
rusty: To the extent that bandwidth is about catch up and not tip, it answers that.
<sipa>
rusty: it would be coupled with a new rule that counts the witness size as part of the block size still
<sipa>
rusty: or whatever the cost limit becomes
<sipa>
but it can offer a discount
<gmaxwell>
rusty: not if the desired result is continued validation moving forward, and so far the runtime costs have not been addressed. (e.g. the naieve contstruction for utxo commitments is a 10++ fold IO cost in validation, which now dominates validation costs already)
<gmaxwell>
(the not if is a response to 'utxo commitments are much more powerful')
<rusty>
gmaxwell: are you suggesting you'd race to the tip then go back downloading witness for old blocks? That's the only way I can see a bw saving?
<gmaxwell>
An additional benefit is that SPV proofs of transaction membership are ~1/3rd the size for SW transactions.
<gmaxwell>
rusty: Yes, you can sync immediate and then handle back validation on whatever time scale you want (including not performing it, or performing it only probablistically, sufficiently far in the past)
matsjj has quit [Ping timeout: 240 seconds]
<rusty>
gmaxwell: am not convinced on SPV proof size? It's the 12 32-byte SHAs that dominate?
<rusty>
And where is the "real" output script stored in the softfork variant? Do I need a separate SPV proof for that?
<gmaxwell>
rusty: Exact figures depends on the size of the transaction and how many you're revealing at a time. The transaction itself is 1/3rd the size on typical transactions.
<gmaxwell>
rusty: the outputs are where they've always been.
<rusty>
gmaxwell: that seems odd to me (the outputs in the tx). Why not separate them too?
<gmaxwell>
You mean the signatures? In the construction we're using you can choose which tree you traverse to get either transactions or transactions+witnesses. In the soft-fork case that commitment is in the coinbase txn, but will propose moving the commitment to the top of the tree in a bitcoinj compatible hardfork as well.
<gmaxwell>
rusty: ... because they're the actual functional action of the transaction!
<sipa>
rusty: the outputs contain the actual redeemscript or a hash of it... the redeemscript can move to the scriptSig (P2SH) or to the witness itself
smk has joined #bitcoin-wizards
<rusty>
gmaxwell: OK, I guess P2SH has kind of done that separate already.
<sipa>
you need the transaction data to commit to the output scripts... directly or indirectly
* rusty
repeats what sipa said.
<rusty>
sipa: OK, so you have added new seg-p2sh opcode/patttern?
<sipa>
rusty: i'm just experimenting now, but that's the idea, yes
<gmaxwell>
Which is backwards compatible with the existing p2sh addresses too.
<rusty>
gmaxwell: I'm confused on that one (backwards compatible). If you give me a P2Sh address today, doesn't that imply you I shouldn't use a seg-p2sh on it tomorrow?
<rusty>
s/you I/I/
<gmaxwell>
rusty: you put a segwitness call in the p2sh redeemscript, then the only thing in the transaction signature is the p2sh redeemscript.
<gmaxwell>
It lets people immediately begin using SW without anyone else having to accept a new address type.
<rusty>
gmaxwell: ah, nice.
<gmaxwell>
(since we know for history that address types take a long time to deploy due to chicken and egg problems)
<rusty>
gmaxwell: OK, so you said it simplifies soft fork deployment. That's not obvious to me, can you unpack that a little?
<gmaxwell>
rusty: segwittness 'redeemscripts' will begin with a version identifer byte. If it's unknown to you, it means return true.
<sipa>
rusty: basically, we introduce a new language "witness-enabled script", which consists of a 1-byte version number (which can by 0 + actual script, and input taken from witness; or can be 1 + hash of script, and script + input taken from witness)
<sipa>
rusty: when the version number is something unknown, it is anyone can spend
<gmaxwell>
The 1-byteness isn't limiting, since e.g. 0xfd, 0xfe, 0xff can be later defined as 2,3,4 byte non-overlapping IDs.
<sipa>
or turned into bitvectors even
CodeShark has joined #bitcoin-wizards
<gmaxwell>
The result is that new features added using a new version number would not be required to themselves be soft-fork safe (e.g. the way that CLTV cannot modify the stack), since older nodes will simply ignore pubkey entirely.
<rusty>
gmaxwell: ah, that's kind of orthogonal, but I appreciate taking the opportunity presented.
<gmaxwell>
yea, it's orthrgonal, but it was a good oppturnity, and I hoped that it would avoid any furhter pressure to stuff in additional changes given the opportunity.
<gmaxwell>
Basically it takes the oppturnity given now and preserves it.
<gmaxwell>
otherwise there is a pressure to do MAST, and schnorr-checksig and ... all at once, which would be unmanagable.
<gmaxwell>
Thats what I meant above though by "the specific construction"-- not something fundimental to SFSW but its cheap and easy to pick that up now, so we do.