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
brg444 has quit [Quit: brg444]
AlineGomes has joined #bitcoin-wizards
Bitcoinego has joined #bitcoin-wizards
Bitcoinego has quit [Client Quit]
kenshi84 has joined #bitcoin-wizards
Davasny has quit [Remote host closed the connection]
PRab has quit [Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]]
brg444 has joined #bitcoin-wizards
kenshi84 has quit [Read error: Connection reset by peer]
kenshi84 has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 258 seconds]
priidu has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
abpa has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wasi has joined #bitcoin-wizards
CrazyLoaf has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Quit: WeeChat 0.4.2]
belcher has quit [*.net *.split]
worstadmin has quit [*.net *.split]
kumavis has quit [*.net *.split]
yokwe has quit [*.net *.split]
SirJacket has quit [*.net *.split]
superkuh has quit [*.net *.split]
Myagui has quit [*.net *.split]
Eliel has quit [*.net *.split]
Lightsword has quit [*.net *.split]
nanotube has quit [*.net *.split]
aspect_ has quit [*.net *.split]
midnightmagic has quit [*.net *.split]
jonasschnelli has quit [*.net *.split]
dEBRUYNE has quit [*.net *.split]
ryan-c has quit [*.net *.split]
ithicad has quit [*.net *.split]
Raccoon has quit [*.net *.split]
Muis has quit [*.net *.split]
catcow has quit [*.net *.split]
eragmus has quit [*.net *.split]
cannedprimates has quit [*.net *.split]
gielbier has quit [*.net *.split]
nickler has quit [*.net *.split]
wallet42 has quit [*.net *.split]
yorick has quit [*.net *.split]
runeks has quit [*.net *.split]
venzen has quit [*.net *.split]
prosody has quit [*.net *.split]
nsh has quit [*.net *.split]
CryptoTraderClub has quit [*.net *.split]
kisspunch has quit [*.net *.split]
thom_ has quit [*.net *.split]
mappum has quit [*.net *.split]
stevenroose has quit [*.net *.split]
gwillen has quit [*.net *.split]
GreenIsMyPepper has quit [*.net *.split]
musalbas has quit [*.net *.split]
[Derek] has quit [*.net *.split]
CodeShark has quit [*.net *.split]
Eliel_ has joined #bitcoin-wizards
Guest28451 has quit [*.net *.split]
dEBRUYNE_ has joined #bitcoin-wizards
ryan-c has joined #bitcoin-wizards
gwollon has joined #bitcoin-wizards
Myagui has joined #bitcoin-wizards
thom has joined #bitcoin-wizards
coup_de_shitlord has joined #bitcoin-wizards
yorick has joined #bitcoin-wizards
nickler has joined #bitcoin-wizards
ithicad has joined #bitcoin-wizards
gielbier has joined #bitcoin-wizards
superkuh has joined #bitcoin-wizards
GreenIsMyPepper has joined #bitcoin-wizards
kisspunch has joined #bitcoin-wizards
superkuh has quit [Changing host]
superkuh has joined #bitcoin-wizards
yorick has joined #bitcoin-wizards
yorick has quit [Changing host]
jonasschnelli has joined #bitcoin-wizards
venzen has joined #bitcoin-wizards
musalbas has joined #bitcoin-wizards
dEBRUYNE_ is now known as dEBRUYNE
dEBRUYNE is now known as Guest78794
Guest78794 has quit [Changing host]
Guest78794 has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
Lightsword has joined #bitcoin-wizards
stevenroose has joined #bitcoin-wizards
Raccoon has joined #bitcoin-wizards
qpm has quit [Ping timeout: 272 seconds]
midnightmagic has joined #bitcoin-wizards
nsh- has joined #bitcoin-wizards
worstadmin has joined #bitcoin-wizards
nanotube has joined #bitcoin-wizards
gwollon is now known as gwillen
SirJacket has joined #bitcoin-wizards
kumavis has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
yokwe has joined #bitcoin-wizards
CodeShark has joined #bitcoin-wizards
prosody has joined #bitcoin-wizards
prosody has quit [Excess Flood]
prosody has joined #bitcoin-wizards
Muis has joined #bitcoin-wizards
aspect_ has joined #bitcoin-wizards
qpm has joined #bitcoin-wizards
runeks has joined #bitcoin-wizards
catcow has joined #bitcoin-wizards
alferz has joined #bitcoin-wizards
eragmus has joined #bitcoin-wizards
mappum has joined #bitcoin-wizards
cannedprimates has joined #bitcoin-wizards
CryptoTraderClub has joined #bitcoin-wizards
Raccoon has quit [Quit: -]
Raccoon has joined #bitcoin-wizards
T3rry has left #bitcoin-wizards ["Leaving"]
abpa has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
c0rw1n has quit [Quit: Leaving]
c0rw1n has joined #bitcoin-wizards
alferz has quit [Ping timeout: 244 seconds]
Guest78794 is now known as dEBRUYNE
alferz has joined #bitcoin-wizards
priidu has quit [Ping timeout: 256 seconds]
aeternity has quit [Read error: Connection reset by peer]
Giszmo has quit [Quit: Leaving.]
Transisto2 has joined #bitcoin-wizards
gsdgdfs has quit [Ping timeout: 246 seconds]
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kenshi84_ has quit [Remote host closed the connection]
kenshi84 has quit [Ping timeout: 240 seconds]
chjj has joined #bitcoin-wizards
windsok has joined #bitcoin-wizards
kenshi84 has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
jannes has joined #bitcoin-wizards
sausage_factory has quit [Ping timeout: 272 seconds]
so has joined #bitcoin-wizards
kenshi84_ has joined #bitcoin-wizards
kenshi8__ has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 248 seconds]
kenshi84_ has quit [Ping timeout: 240 seconds]
laurentmt has joined #bitcoin-wizards
kenshi8__ has quit [Remote host closed the connection]
laurentmt has quit [Quit: laurentmt]
[Derek] has joined #bitcoin-wizards
[Derek] is now known as Guest9651
blackwraith has quit [Read error: Connection reset by peer]
blackwraith has joined #bitcoin-wizards
CrazyLoaf has quit [Quit: Connection closed for inactivity]
Giszmo has joined #bitcoin-wizards
Raccoon is now known as raccoon
raccoon is now known as Raccoontemp
Raccoontemp is now known as raccoon
Guest9651 is now known as [Derek]
[Derek] has quit [Changing host]
[Derek] has joined #bitcoin-wizards
windsok has quit [Ping timeout: 255 seconds]
Uglux has joined #bitcoin-wizards
Uglux has joined #bitcoin-wizards
Uglux has quit [Changing host]
NewLiberty_ has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 240 seconds]
<adam3us>
stevenroose smaller transactoins from combining signatures using schnorr signature aggregation. basically you can have a 2 of 2 sig that is the size of a 1 sig (the bare sig part) same for n of n. just using that across your own inputs saves +- 33% and joining across others in the block (a big coinjoin of the block) may get to +- 50% transaction size saving. so very roughly 3MB - 4MB worth of transactoins in a 2MB segwit block once the
<adam3us>
schnorr signature aggregatoin follow on softfork is done.
<adam3us>
(very rough percentages)
paveljanik has quit [Quit: Leaving]
windsok has joined #bitcoin-wizards
<Eliel_>
adam3us: I was under the impression that schnorr signature aggregation kind of cancels out the extra space segwit provides. Is there a way around that?
saintromuald has joined #bitcoin-wizards
<gmaxwell>
wha? no.
<gmaxwell>
Eliel_: the reduction is in witness data, so it doesn't have as much impact as if it were non-witness data; but it still has a significant impact.
mountaingoat has quit [Ping timeout: 265 seconds]
<gmaxwell>
(Also, Adam's figures are a bit high-- I think based on my post where I used data from some recent blocks that turned out to be a little better than average for aggregation results for some reason.)
<Eliel_>
gmaxwell: Yes, that's what I mean. It can potentially eliminate almost all witness data per block, which means the extra space from segwit might end up almost completely unused, which would mean the effective limit in terms of bytes is still around a megabyte.
<Eliel_>
although, that megabyte will be able to much more transactions than before.
<gmaxwell>
Eliel_: ah you have a misaprehension about how segwit works.
<gmaxwell>
(I think)
<Eliel_>
you have me interested :)
<gmaxwell>
or perhaps not. Segwit doesn't create a seperate "extra space", it just replaces the size limit with a weight limit where the witness data costs less weight per byte. With aggregation the witness data will still contain public keys, which are ~half the size of the signatures.
<Eliel_>
oh ok, so I was at least overestimating the reduction in witness data from signature aggregation
<gmaxwell>
it sounded like you were thinking that there were two seperately limited areas, but nah one limit. A typical content max size segwit block has about 600k of non-witness data. so that gives some impression about how much more room there is for non-witness data that you could get from shrinking the witness data further.
mountaingoat has joined #bitcoin-wizards
<Eliel_>
Strange, I'm a bit uncertain if my thinking would fall under that misconception or not. I did, to some degree, consider them separately, but ... the correct interpretation doesn't seem to lead to any major changes in how I think about it.
airbreather has quit [Read error: Connection reset by peer]
airbreather has joined #bitcoin-wizards
<gmaxwell>
yea, that was why I went to perhaps not. It sounded like you were thinking of two groups but the conclusion you reached wasn't really impacted by it-- though I didn't realize that until I'd started typing.
<Eliel_>
maybe it was just that I hadn't done any "hands on" thinking about how segwit works with actual blocks and since they're usually spoken of as separate, it was kind of pushing my thinking that way too, even if my intution about it still somehow worked.
<stevenroose>
adam3us, yeah I know about sig aggregation, I just forgot that witness data was still counting towards the block size limit, just weighted down
<stevenroose>
adam3us, gmaxwell, the weight factor or 0.25 for witness data, is it arbitrary?
<adam3us>
well Eliel_ in one sense maybe you are right. weight formula is base+1/4*witness < 1MB if the witness data becomes 1/2 the size then it's base+1/4*1/2*witness < 1MB effectively
<stevenroose>
adam3us, that's not "cancel out", that just makes the improvement from schnorr less significant. but it's still an improvement
<adam3us>
and if we back of envelope that base=33% and witness 66% and assuming full coin join then it goes from
<Eliel_>
yes, blocks get smaller, but you can still fit more transactions in them.
<Eliel_>
Mostly, I'm wondering if there's much point to segwit's witness discount if it mostly ends up unused as a result of schnorr signatures.
<adam3us>
if you solve that with no aggregation you get 2MB of transactions
<adam3us>
and if you solve with full aggregation you get 2.6MB but sending "worth" of 4.3MB of transactoins
<Eliel_>
anyway, it's probably best to talk about this in unoptimized block equivalent numbers. as in, how much space would a 1MB block with full signature aggregation take, if it was built according to the current rules.
<gmaxwell>
stevenroose: the exact value is somewhat arbritary, there is a tradeoff of worst case attack surface, utxo bloat vs byte bloat. A weight of 1 is _heavily_ weighed towards utxo bloat. There are dimishing improvements in the opposing metric at the extremes. E.g. 20% increases the worst case byte bloat a lot, without helping utxo bloat that much. Middleground comes from the ratio of the data sizes
<gmaxwell>
for typical transactions. 25% perhaps on the higher end of that tradeoff, but with aggregation it's probably about right on. (It's also, coupled with tx compaction about what the typical compaction gains give).
<gmaxwell>
the idea of using "size" as a measure of capacity is just foolish.
<gmaxwell>
:)
<adam3us>
and with own input aggregation you get maybe 2.4MB of dat but equivalent to 3.6MB
<adam3us>
however these data points are all very back of envelope and based on some stats gmax had that are at a high point.
<adam3us>
so i was calling it 3Mb and 4MB equivalent
<gmaxwell>
and leads to absuridty like someone complaining that segwit makes the sizes less consistent and people authoring transactions need consistency, ... when, in fact, segwit makes the number of transactions (well, #txin+#txout) _more_ consistent and less at the whim of transaction mix.
<adam3us>
but it does suggest we need to get away from talking about blocksize. it reminds of the amd vs intel days when amd was trouncing intel at lower clock rates and advertising CPUs with "cpu ghz equivalent to what it would take to get same perf with intel" the so called PR (performance rating)
<adam3us>
we may need to think about transactions/block or transactions/day in terms of throughput
<Eliel_>
yeah, it's not the best metric, but it's the only one most people have any way to relate to anything currently.
<adam3us>
and also there's lots of wastage in what people are doing. really need "useful
<adam3us>
tx/day which could maybe go up 25-50% just by people stopping doing some dumb things and optimising a bit.
mountaingoat has quit [Ping timeout: 248 seconds]
<gmaxwell>
well there is tx/day and then there is payments/day or something, e.g. people that make long chains of unconfirmed transactions instead of using send many.. That is N payments in N transactions currently, but could be N payments in 1.1 transaction.
pro has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
pro has quit [Read error: Connection reset by peer]
pro has joined #bitcoin-wizards
<adam3us>
stevenroose the weight factor is designed to balance two things, making utxo creation closer in cost to utxo consumption, so that defragging becomes more cost neutral. as is other than somewhat altruistic change selection algos in wallets, it's short term rational to create dust, and split coins even when you have coins to combine of suitable value. defragging costs you money, creating dust is discounted. the weighting tries to correct
<adam3us>
that
<stevenroose>
yeah I understand, but the number 4
<stevenroose>
has there been some research or discussion on the number
<stevenroose>
or was 4 just Pieter's magic number that everyone accepted? :)
<adam3us>
stevenroose other thing is adversarial worst case block and effective size. if weighting was 1/10 worst case would be 10MB, and if weighting was 1/3 usable space would go down because of the formula base+1/3*witness < 1MB
<adam3us>
stevenroose i think gmaxwell has the view that if you graph it it is about the turning point of the graph of break even.
<stevenroose>
hmm
<adam3us>
there were quite strong design constraints around it too though. 1/2 or 1/3 gets disappointing scale increase, and 1/5 or 1/6 starts to get above the 4MB safety limit that people had empirically measured for orphans.
mountaingoat has joined #bitcoin-wizards
<stevenroose>
ok, that makes sense
<adam3us>
so it was a fortuitous confluence of design space. i think people figured well we barely have a choice here so lets not knock ourselves out modelling the optimal param. also the optimal params are grey... it depends on what pattern of multisigs are used. and that pattern changes over time. and maybe interacts with the better weighting too... people would actively like to use multisig for security but may be holding off due to cost etc.
<adam3us>
eg there's schnorr aggregation which changes it again, and then coinjoin + schnorr aggregation, and mast, and lightning changing typical transactions etc.
<stevenroose>
well, another option would not have been to start using weighing in the block size
<stevenroose>
i.e. have a base size limit and a witness size limit
<adam3us>
there was some next gen discussion about more targetted cost metrics, but it was deemed too complex to do at the same time, watch this presentation by n1ckler
<adam3us>
yeah i was hung up on that too because in principle you can get more space out of it. however the issue is the knapsack problem. it's a multidimensional optimisation problem for whcih the wallet has no information to drive packing. (he doesnt know what the average transaction split between witness and base is)
<adam3us>
i couldnt see a way to solve that conveniently, and sipa and gmaxwell looked at it a lot more carefully than i did and i think basically decided it's not usefully possible.
<stevenroose>
adam3us, are you Adam from Blockstream, btw?
<adam3us>
yes.
<stevenroose>
on a totally different note, I sometimes think it's sad that a lot of these protocol discussions happen in the github repo of the satoshi client
<stevenroose>
there should be a place for protocol discussion separate from an implementation
<stevenroose>
currently, when referring to a protocol rule decision, people link to the commit that implements it
<stevenroose>
instead of an RFC-like thing
<gmaxwell>
stevenroose: uh no
<stevenroose>
except for BIPS, but there are far more decisions made
<gmaxwell>
What consensus rules are you talking about that aren't in BIPs made any time in the last couple years?
<stevenroose>
I can't name them specifically, but I've been browsing through the btcd code a lot recently, and they often argument certain things by referring to commits in bitcoin core
<gmaxwell>
thats also because they slavishly copy the design and implementation details from bitcoin core.
<gmaxwell>
that doesn't mean it has anything to do with the consensus.
<stevenroose>
true
<stevenroose>
I didn't really take note on what references were strictly consensus rules
<gmaxwell>
AFAIK, nothing goes into core that is a normative protocol change with impact on consensus without a BIP.
<stevenroose>
hmm
<stevenroose>
ok, didn't know tat
<stevenroose>
that*
<stevenroose>
that's good to hear, though, thanks for pointing that out
berndj has joined #bitcoin-wizards
<stevenroose>
I really value the existence of alternative implementations
<gmaxwell>
If you encounter something that got missed at any point, please bring it up.
<stevenroose>
you don't wanna go the path of Ripple where only a handful of people know the code and so no one has the ability to fork against certain decisions :p not that bitcoin is nowhere near that at this point, luckily
<stevenroose>
anywhere*
<gmaxwell>
that isn't a property of multiple implementations, however. It's a property of collaboration, peer review, etc.
hashtagg has quit [Read error: Connection reset by peer]
BashCo has quit []
laurentmt has joined #bitcoin-wizards
s4z has joined #bitcoin-wizards
hashtag_ has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 246 seconds]
<gmaxwell>
stevenroose: about the witness factor, here is an explination: https://people.xiph.org/~greg/temp/bloat_tradeoff.png x is the witness factor. The red line shows the ratio of the worst case block size to the block size for a block full of 2 in 3 out transactions, the green line shows the ratio of utxo bytes for a worst case utxo filling block vs a utxo bytes of a typical block using 2 in 3 out t
<gmaxwell>
xn. I admit some graft-craft there in choosing 2,3 which happens to put the tying point right at 0.25. :P 1,2 - 2,1 put it anywhere between .2 and .3 --- and the exact crossover is subjective because utxo cost and block storage costs are not equally 'expensive' but depend on user tolerances, hardware arch, etc. The key point is that the derivitive of the red line is a -1/x^2 like curve, that
<gmaxwell>
has a knee right at .2, so a witness factor smaller that that has an increasingly large bloat effect while only linear capacity and utxo bloat mitigation.
BashCo has joined #bitcoin-wizards
<gmaxwell>
probably anywhere between .2 and .3 would have been fine, .25 is in the middle. There are a bunch of parameters in Bitcoin where the exact figure doesn't really matter, but it's more or less in the middle of a sensible range, and setting far outside of that range would work less well or not at all.
Creative89 has joined #bitcoin-wizards
<gmaxwell>
of all the designs that have been discussed that tried to do something about the utxo bad incentives, segwit had the important property of having only a single parameter which had a naturally constrained range of sensible values.
Creative89 has left #bitcoin-wizards [#bitcoin-wizards]
Chris_Stewart_5 has joined #bitcoin-wizards
abbysmith has joined #bitcoin-wizards
abbysmith has left #bitcoin-wizards ["Leaving"]
Guyver2 has joined #bitcoin-wizards
BCBot_ has quit [Remote host closed the connection]
laurentmt has quit [Quit: laurentmt]
BCBot has joined #bitcoin-wizards
BCBot has quit [Remote host closed the connection]
BCBot has joined #bitcoin-wizards
Uglux has quit [Quit: Leaving]
uiuc-slack1 has joined #bitcoin-wizards
uiuc-slack has quit [Remote host closed the connection]
kristofferR has joined #bitcoin-wizards
Alina-malina has quit [Excess Flood]
priidu has quit [Remote host closed the connection]
Alina-malina has joined #bitcoin-wizards
Alina-malina has quit [Changing host]
Alina-malina has joined #bitcoin-wizards
blackwraith has quit [Ping timeout: 246 seconds]
Aranjedeath has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 248 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 245 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
buckowski has quit [Excess Flood]
buckowski has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
brg444 has quit [Read error: No route to host]
brg444 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 255 seconds]
roconnor has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
<roconnor>
Currently the 6 confirmation thing is convention that people are not obligated to follow; it isn't part of the protocol. The equivalent safety number in the protocol is 100.
<adam3us>
which was about the problems on reorg of backwards compatible payouts from an extension block from xtx to regular tx, as collated into a anyonecanspend non-standard but valid after mined one special utxo tx per block by miners.
<adam3us>
a challenge being if someone spends from that output and then the special utxo output txid changes, the transaction needs to be redone with the new txid.
<adam3us>
(which will happen on reorg)
<kanzure>
(channeling luke-jr for a second) backwards-compatibility of an extension block upgrade would require the extension block to obey existing bandwidth limitations
<kanzure>
anyway, reorgs changing the transaction set of recent blocks is a problem for many things not just extension blocks...
<adam3us>
it is arguably similar to oiRBF jl2012 "1. I submit a tx; 2. it gets mined but I don't know; 3. I submit a RBF; 4. re-org happened and the RBF got mined"
<adam3us>
well other than coinbase outputs (which have 100 block maturity protection) i think other transactions tend to remain valid once valid, modulo reorgs, double-spends across reorgs and oiRBF across reorgs
<kanzure>
[i thought it was agreed that your behavior for peg in/peg out needs to have a long wait period for confirmations
Starduster_ is now known as Starduster
<adam3us>
this is an extension block though, it is being enforced by regular miners, not some merge mine loosely coupled thing without full validation.
<kanzure>
it's still basically a peg though, right? to get coins out of the extension lock, you use the anyonecanspend mechanisms, but otherwise the transactions "live" in the extension block.
<kanzure>
*extension block
<luke-jr>
adam3us: it must also be enforced by every full node
<kanzure>
do i get points for correctly predicting luke-jr's message?
<luke-jr>
kanzure: incorrectly*?
<jl2012>
that's true for every softfork even a simple one like BIP34
<kanzure>
luke-jr: your objection to extension blocks has been that every full node needs to get the extra data (hence you can't actually add to the bandwidth requirements without breaking hte network anyway)
<kanzure>
adam3us: perhaps it would be helpful to specify what sort of data structure you're thinking about for an extension block. unlike segwit it's not just a set of witnesses, it's entire tx right?
<luke-jr>
every case an extension block makes sense, so does a hardfork.
<jl2012>
wait.....that'd be a problem for segwit too...
WungFu has joined #bitcoin-wizards
<adam3us>
kanzure they're not really suspended as such, they are just controlled by miners on an anyone can spend for backwards compatible payout and payin.
<adam3us>
kanzure a commitment to another instance of a bitcoin block. like segwit but with xtx's in it.
<jl2012>
luke-jr: if 1. you don't want to require lite nodes to upgrade; 2. you don't want to require all full nodes to upgrade; and 3. you want a bigger block, then the _only_ option is ext-block
<kanzure>
jl2012: it erodes the security properties if full nodes can't follow along anyway due to all the extra size. the full nodes must see everything.
<luke-jr>
jl2012: all full nodes must upgrade for an ext-block
<luke-jr>
also for any softfork
<kanzure>
no reason to have a commitment to something you're incapable of tracking
<adam3us>
its arguably a little more opt-in than a soft-hardfork at the same overall size.
<jl2012>
luke-jr: then why bother doing softforks?
brg444 has quit [Read error: Connection reset by peer]
<luke-jr>
jl2012: so the former-full nodes aren't left vulnerable.
<adam3us>
(or a simple HF which has a variety of risks)
<jl2012>
kanzure: how about witness commitment.....
brg444 has joined #bitcoin-wizards
<kanzure>
jl2012: yes, segwit is in fact a capacity increase :)
WungFu has quit [Remote host closed the connection]
<jl2012>
luke-jr: ok I change my statement: if 1. you don't want to require lite nodes to upgrade; 2. you don't want to leave former full nodes vulnerable; and 3. you want a bigger block, then the _only_ option is ext-block
<adam3us>
i think if you posit the same overall size combined block via simple-HF, soft-HF, or ext-block the scale cost arguments are almost the same. I think soft-HF is maybe most coercive. then simple HF then ext-block. and ext-block might be the safest from upgrade perspective and the least painful in terms of not forcing upgrades.
<luke-jr>
#1 is never a goal IMO
<adam3us>
a soft-HF isnt actually very soft.
<jl2012>
1. you don't want to leave former lite nodes vulnerable
<jl2012>
you may going to say.... lite nodes are always vulnerable? :P
<luke-jr>
jl2012: then you do a SHF
<kanzure>
if you are a low capacity full node (bandwidth limited), upgrading to a soft-fork that tells you about an extension block commitment isn't very helpful if you can't actually follow the extension block (in terms of capacity)
<adam3us>
luke-jr xblock maybe offers an easier opt-out mechanism than soft-HF. in a soft-HF you have to bootstrap a new chain. in an xblock you just decline to accept xtx's or accept them only after an extended period (1000 blocks)
<luke-jr>
adam3us: no, that isn't opt-out
<adam3us>
its less not opt-out than SHF
<luke-jr>
yes it is
<luke-jr>
you might not even be aware it's happening
paveljanik has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
WungFu has joined #bitcoin-wizards
<jl2012>
luke-jr: ok, you win
b-itcoinssg has quit [Quit: Connection closed for inactivity]
<adam3us>
if the size is the same i think views have shifted over time quite a bit. due to ETH HF disasters, and evil-fork somehow becoming more acceptable. and segwit is a kind of ext-block itself ...
<kanzure>
high-capacity extension block is, from the point of view of bandwidth-limited full nodes, basically a transition to "yo trust the miners" security model
<adam3us>
on the miner side for example i think an xblock is slightly better than a SHF or HF because you could solo mine the main block and pool mine the extblock proposal.
<kanzure>
(and if you are OK with that security model then there's a lot of stuff other than gigantic extension blocks that you could do)
<adam3us>
similar for fullnodes you could receive all of the main block and have fraud proofs for the ext block, or sharded verification
<luke-jr>
adam3us: except fraud proofs aren't possible
<jl2012>
kanzure: I think eventually we will migrate to a probabilistic validation. Even your smartphone could validate 0.01% of the blockchain
<adam3us>
this would be true i think of most things. even sidechains. a GB ext block, SHF, sidechain .. it's all a failure mode
wasi has quit [Quit: Leaving]
<jl2012>
why fraud proofs aren't possible?
<kanzure>
(also: small miners are bandwidth limited and will have trouble with infinitely large extension blocks)
<kanzure>
adam3us: to be fair, most sidechains have been said to be a different security model anyway, sooo that's correct and expected
<jl2012>
kanzure: no one is talking about infinitely large block here
<kanzure>
i am being facetious about infinitely, sorry :)
<adam3us>
jl2012 he explained it to me once. he has a point there is an assumption that a mined block reveals the transactions. but it doesnt have to be so, they could not reveal all, and some merkle paths may not even exist.
<luke-jr>
jl2012: because they assume blocks are well-formed
<adam3us>
(it assumes miners are well behaved enough not to do that and orphan such blocks)
<adam3us>
but lets talk about the incremental case. eg imagine we do weak blocks, compact blocks is working well, bandwidth si good, miners decentralise quite a bit, and people consider decide 6MB blocks. now how do we do it.
<adam3us>
argument is ext-block is maybe the best method to do so.
<kanzure>
adam3us: i have proposed a structure for blocks where there's a single merkle root (32 bytes) and then a list of pubkeys and an aggregated signature. miners can put anything into the merkle tree. miners give inclusion proofs to the spenders before the block is completed. spenders sign in aggregate over the merkle root value to signal that they received their inclusion proofs. in this sc...
<luke-jr>
btw, segwit actually breaks one more case of fraud-proofs that is possible right now
<kanzure>
...heme, the block contents are only the merkle root and the list of pubkeys. taek calculated this is about 4x scalability over current situation i think?
<luke-jr>
right now, you can prove the block size limit is violated with 32 bytes per transaction in the block, but you can't do the same for block weight
jannes has quit [Quit: Leaving]
<jl2012>
why only 32 bytes?
<kanzure>
some hash, the point is it's a constant size number of bytes
<kanzure>
i described the scheme here //gnusha.org/bitcoin-wizards/2016-12-11.log
<jl2012>
why only 32-bytes/tx needed to proof oversize?
<luke-jr>
jl2012: SHA256 hashes include the size of the data in the final 64 bits
<jl2012>
i don't get it. It's some hash magic?
<luke-jr>
jl2012: step 1 of SHA256 is to append the data with padding, the final 64-bits of which is the size of the data
kristofferR has joined #bitcoin-wizards
<luke-jr>
might actually be 64 bytes, not 32
<luke-jr>
midstate + final block
<luke-jr>
jl2012: basically every SHA256 hash commits to the size
<jl2012>
oh, I don't know that
<adam3us>
so how could one fix this xtx-tx reorg problem within soft-fork to make a reasonable experience for non-upgraded clients?
<jl2012>
but in that case, you could still do it because witness size = full size - base size. Just the proof size is doubled
<jl2012>
luke-jr: anyway, the most broken thing right now is unable to proof spending of non-existing UTXO. That requires all txids in the history to proof
<kanzure>
adam3us: wait long confirmations?
s4z has quit [Remote host closed the connection]
WungFu has quit [Ping timeout: 272 seconds]
<kanzure>
*wait for long confirmation periods
WungFu has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
<adam3us>
yeah that's a bad experience however
<luke-jr>
jl2012: hmm, I suppose
<jl2012>
luke-jr: but your point is, if a miner decides to withhold part of a block, and other miners are happy to build on top of the incomplete block, there is no way to proof?