rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2015-12-08 📝 Original message:On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the > coinbase is messy and will just complicate consensus-critical code (as > opposed to making the right side of the merkle tree in block.version=5 > blocks the segwitness data). It's nearly complexity-costless to put it in the coinbase transaction. Exploring the costs is one of the reasons why this was implemented first. We already have consensus critical enforcement there, the height, which has almost never been problematic. (A popular block explorer recently misimplemented the var-int decode and suffered an outage). And most but not all prior commitment proposals have suggested the same or similar. The exact location is not that critical, however, and we do have several soft-fork compatible options. > It will also make any segwitness fraud proofs significantly larger (merkle > path versus merkle path to coinbase transactions, plus ENTIRE coinbase > transaction, which might be quite large, plus merkle path up to root). Yes, it will make them larger by log2() the number of transaction in a block which is-- say-- 448 bytes. With the coinbase transaction thats another couple kilobytes, I think this is negligible. >From a risk reduction perspective, I think it is much preferable to perform the primary change in a backwards compatible manner, and pick up the data reorganization in a hardfork if anyone even cares. I think thats generally a nice cadence to split up risks that way; and avoid controversy. > We also need to fix the O(n^2) sighash problem as an additional BIP for ANY > blocksize increase. The witness data is never an input to sighash, so no, I don't agree that this holds for "any" increase. > Segwitness will make the current bottleneck (block propagation) a little > worse in the short term, because of the extra fraud-proof data. Benefits > well worth the costs. The fraud proof data is deterministic, full nodes could skip sending it between each other, if anyone cared; but the overhead is pretty tiny in any case. > I think a barrier to quickly getting consensus might be a fundamental > difference of opinion on this: > "Even without them I believe we’ll be in an acceptable position with > respect to capacity in the near term" > > The heaviest users of the Bitcoin network (businesses who generate tens of > thousands of transactions per day on behalf of their customers) would > strongly disgree; the current state of affairs is NOT acceptable to them. My message lays out a plan for several different complementary capacity advances; it's not referring to the current situation-- though the current capacity situation is no emergency. I believe it already reflects the emerging consensus in the Bitcoin Core project; in terms of the overall approach and philosophy, if not every specific technical detail. It's not a forever plan, but a pragmatic one that understand that the future is uncertain no matter what we do; one that trusts that we'll respond to whatever contingencies surprise us on the road to success.