<div dir="ltr"><span id="gmail-docs-internal-guid-bd0849f2-2951-1446-7678-92328ee5daec">Some people have asked me for the current implementation of this patch to review. I remind you that the current patch does not implement the hard-fork signaling, as requested by Matt.</span><br><br><div>The Segwit2Mb patch can be found here:<br><a href="https://github.com/SergioDemianLerner/bitcoin/commits/master">https://github.com/SergioDemianLerner/bitcoin/commits/master</a></div><div><br></div><div><span id="gmail-docs-internal-guid-bd0849f2-2952-d768-c012-cb490870313d"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline">For now, the segwit2mb repo has a single test file using the old internal blockchain building method (test/block_size_tests.cpp). This must be replaced soon with a better external test using the bitcoin/qa/rpc-tests tests, which I will begin to work on now after I collect all comments from the community.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline"><br></span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline">regards</span></p><div><br></div></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <span dir="ltr"><<a href="mailto:jaredr26@gmail.com" target="_blank">jaredr26@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Remember that the "hashpower required to secure bitcoin" is determined<br>
> as a percentage of total Bitcoins transacted on-chain in each block<br>
<br>
</span>Can you explain this statement a little better? What do you mean by<br>
that? What does the total bitcoins transacted have to do with<br>
hashpower required?<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev<br>
<<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
> Hey Sergio,<br>
><br>
> You appear to have ignored the last two years of Bitcoin hardfork<br>
> research and understanding, recycling instead BIP 102 from 2015. There<br>
> are many proposals which have pushed the state of hard fork research<br>
> much further since then, and you may wish to read some of the posts on<br>
> this mailing list listed at <a href="https://bitcoinhardforkresearch.github.io/" rel="noreferrer" target="_blank">https://<wbr>bitcoinhardforkresearch.<wbr>github.io/</a><br>
> and make further edits based on what you learn. Your goal of "avoid<br>
> technical changes" appears to not have any basis outside of perceived<br>
> compromise for compromise sake, only making such a hardfork riskier<br>
> instead.<br>
><br>
> At a minimum, in terms of pure technical changes, you should probably<br>
> consider (probably among others):<br>
><br>
> a) Utilizing the "hard fork signaling bit" in the nVersion of the block.<br>
> b) Either limiting non-SegWit transactions in some way to fix the n**2<br>
> sighash and FindAndDelete runtime and memory usage issues or fix them by<br>
> utilizing the new sighash type which many wallets and projects have<br>
> already implemented for SegWit in the spending of non-SegWit outputs.<br>
> c) Your really should have replay protection in any HF. The clever fix from<br>
> Spoonnet for poor scaling of optionally allowing non-SegWit outputs to<br>
> be spent with SegWit's sighash provides this all in one go.<br>
> d) You may wish to consider the possibility of tweaking the witness<br>
> discount and possibly discounting other parts of the input - SegWit went<br>
> a long ways towards making removal of elements from the UTXO set cheaper<br>
> than adding them, but didn't quite get there, you should probably finish<br>
> that job. This also provides additional tuneable parameters to allow you<br>
> to increase the block size while not having a blowup in the worst-case<br>
> block size.<br>
> e) Additional commitments at the top of the merkle root - both for<br>
> SegWit transactions and as additional space for merged mining and other<br>
> commitments which we may wish to add in the future, this should likely<br>
> be implemented an "additional header" ala Johnson Lau's Spoonnet proposal.<br>
><br>
> Additionally, I think your parameters here pose very significant risk to<br>
> the Bitcoin ecosystem broadly.<br>
><br>
> a) Activating a hard fork with less than 18/24 months (and even then...)<br>
> from a fully-audited and supported release of full node software to<br>
> activation date poses significant risks to many large software projects<br>
> and users. I've repeatedly received feedback from various folks that a<br>
> year or more is likely required in any hard fork to limit this risk, and<br>
> limited pushback on that given the large increase which SegWit provides<br>
> itself buying a ton of time.<br>
><br>
> b) Having a significant discontinuity in block size increase only serves<br>
> to confuse and mislead users and businesses, forcing them to rapidly<br>
> adapt to a Bitcoin which changed overnight both by hardforking, and by<br>
> fees changing suddenly. Instead, having the hard fork activate technical<br>
> changes, and then slowly increasing the block size over the following<br>
> several years keeps things nice and continuous and also keeps us from<br>
> having to revisit ye old blocksize debate again six months after activation.<br>
><br>
> c) You should likely consider the effect of the many technological<br>
> innovations coming down the pipe in the coming months. Technologies like<br>
> Lightning, TumbleBit, and even your own RootStock could significantly<br>
> reduce fee pressure as transactions move to much faster and more<br>
> featureful systems.<br>
><br>
> Commitments to aggressive hard fork parameters now may leave miners<br>
> without much revenue as far out as the next halving (which current<br>
> transaction growth trends are indicating we'd just only barely reach 2MB<br>
> of transaction volume, let alone if you consider the effects of users<br>
> moving to systems which provide more features for Bitcoin transactions).<br>
> This could lead to a precipitous drop in hashrate as miners are no<br>
> longer sufficiently compensated.<br>
><br>
> Remember that the "hashpower required to secure bitcoin" is determined<br>
> as a percentage of total Bitcoins transacted on-chain in each block, so<br>
> as subsidy goes down, miners need to be paid with fees, not just price<br>
> increases. Even if we were OK with hashpower going down compared to the<br>
> value it is securing, betting the security of Bitcoin on its price<br>
> rising exponentially to match decreasing subsidy does not strike me as a<br>
> particularly inspiring tradeoff.<br>
><br>
> There aren't many great technical solutions to some of these issues, as<br>
> far as I'm aware, but it's something that needs to be incredibly<br>
> carefully considered before betting the continued security of Bitcoin on<br>
> exponential on-chain growth, something which we have historically never<br>
> seen.<br>
><br>
> Matt<br>
><br>
><br>
> On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>Hi everyone,<br>
>><br>
>>Segwit2Mb is the project to merge into Bitcoin a minimal patch that<br>
>>aims to<br>
>>untangle the current conflict between different political positions<br>
>>regarding segwit activation vs. an increase of the on-chain blockchain<br>
>>space through a standard block size increase. It is not a new solution,<br>
>>but<br>
>>it should be seen more as a least common denominator.<br>
>><br>
>>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB<br>
>>block<br>
>>size hard-fork activated ONLY if segwit activates (95% of miners<br>
>>signaling), but at a fixed future date.<br>
>><br>
>>The sole objective of this proposal is to re-unite the Bitcoin<br>
>>community<br>
>>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best<br>
>>possible technical solution to solve Bitcoin technical limitations.<br>
>>However, this proposal does not imply a compromise to the future<br>
>>scalability or decentralization of Bitcoin, as a small increase in<br>
>>block<br>
>>size has been proven by several core and non-core developers not to<br>
>>affect<br>
>>Bitcoin value propositions.<br>
>><br>
>>In the worst case, a 2X block size increase has much lower economic<br>
>>impact<br>
>>than the last bitcoin halving (<10%), which succeeded without problem.<br>
>><br>
>>On the other side, Segwit2Mb primary goal is to be minimalistic: in<br>
>>this<br>
>>patch some choices have been made to reduce the number of lines<br>
>>modified in<br>
>>the current Bitcoin Core state (master branch), instead of implementing<br>
>>the<br>
>>most elegant solution. This is because I want to reduce the time it<br>
>>takes<br>
>>for core programmers and reviewers to check the correctness of the<br>
>>code,<br>
>>and to report and correct bugs.<br>
>><br>
>>The patch was built by forking the master branch of Bitcoin Core,<br>
>>mixing a<br>
>>few lines of code from Jeff Garzik's BIP102, and defining a second<br>
>>versionbits activation bit (bit 2) for the combined activation.<br>
>><br>
>>The combined activation of segwit and 2Mb hard-fork nVersion bit is 2<br>
>>(DEPLOYMENT_SEGWIT_AND_2MB_<wbr>BLOCKS).<br>
>><br>
>>This means that segwit can still be activated without the 2MB hard-fork<br>
>>by<br>
>>signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).<br>
>><br>
>>The tentative lock-in and hard-fork dates are the following:<br>
>><br>
>>Bit 2 signaling StartTime = 1493424000; // April 29th, 2017<br>
>><br>
>>Bit 2 signaling Timeout = 1503964800; // August 29th, 2017<br>
>><br>
>>HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT<br>
>><br>
>><br>
>>The hard-fork is conditional to 95% of the hashing power has approved<br>
>>the<br>
>>segwit2mb soft-fork and the segwit soft-fork has been activated (which<br>
>>should occur 2016 blocks after its lock-in time)<br>
>><br>
>>For more information on how soft-forks are signaled and activated, see<br>
>><a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="noreferrer" target="_blank">https://github.com/bitcoin/<wbr>bips/blob/master/bip-0009.<wbr>mediawiki</a><br>
>><br>
>>This means that segwit would be activated before 2Mb: this is<br>
>>inevitable,<br>
>>as versionbits have been designed to have fixed activation periods and<br>
>>thresholds for all bits. Making segwit and 2Mb fork activate together<br>
>>at a<br>
>>delayed date would have required a major re-write of this code, which<br>
>>would<br>
>>contradict the premise of creating a minimalistic patch. However, once<br>
>>segwit is activated, the hard-fork is unavoidable.<br>
>><br>
>>Although I have coded a first version of the segwit2mb patch (which<br>
>>modifies 120 lines of code, and adds 220 lines of testing code), I<br>
>>would<br>
>>prefer to wait to publish the source code until more comments have been<br>
>>received from the community.<br>
>><br>
>>To prevent worsening block verification time because of the O(N^2)<br>
>>hashing<br>
>>problem, the simple restriction that transactions cannot be larger than<br>
>>1Mb<br>
>>has been kept. Therefore the worse-case of block verification time has<br>
>>only<br>
>>doubled.<br>
>><br>
>>Regarding the hard-fork activation date, I want to give enough time to<br>
>>all<br>
>>active economic nodes to upgrade. As of Fri Mar 31 2017,<br>
>><a href="https://bitnodes.21.co/nodes/" rel="noreferrer" target="_blank">https://bitnodes.21.co/<wbr>nodes/</a> reports that 6332 out of 6955 nodes (91%)<br>
>>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can<br>
>>be<br>
>>used to identify economic active nodes, because in the 0.12 release<br>
>>dynamic<br>
>>fees were introduced, and currently no Bitcoin automatic payment system<br>
>>can<br>
>>operate without automatic discovery of the current fee rate. A pre-0.12<br>
>>would require constant manual intervention.<br>
>>Therefore I conclude that no more than 91% of the network nodes<br>
>>reported by<br>
>>bitnodes are active economic nodes.<br>
>><br>
>>As Bitcoin Core 0.12 was released on February 2016, the time for this<br>
>>91%<br>
>>to upgrade has been around one year (under a moderate pressure of<br>
>>operational problems with unconfirmed transactions).<br>
>>Therefore we can expect a similar or lower time to upgrade for a<br>
>>hard-fork,<br>
>>after developers have discussed and approved the patch, and it has been<br>
>>reviewed and merged and 95% of the hashing power has signaled for it<br>
>>(the<br>
>>pressure not to upgrade being a complete halt of the operations).<br>
>>However I<br>
>>suggest that we discuss the hard-fork date and delay it if there is a<br>
>>real<br>
>>need to.<br>
>><br>
>>Currently time works against the Bitcoin community, and so is delaying<br>
>>a<br>
>>compromise solution. Most of the community agree that halting the<br>
>>innovation for several years is a very bad option.<br>
>><br>
>>After the comments collected by the community, a BIP will be written<br>
>>describing the resulting proposal details.<br>
>><br>
>>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should<br>
>>be<br>
>>updated to a Segwit2Mb enabled node to prevent them to be forked-away<br>
>>in a<br>
>>chain with almost no hashing-power.<br>
>><br>
>>The proof of concept patch was made for Bitcoin Core but should be<br>
>>easily<br>
>>ported to other Bitcoin protocol implementations that already support<br>
>>versionbits. Lightweight (SPV) wallets should not be affected as they<br>
>>generally do not check the block size.<br>
>><br>
>>I personally want to see the Lightning Network in action this year, use<br>
>>the<br>
>>non-malleability features in segwit, see the community discussing other<br>
>>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains<br>
>>and<br>
>>MAST.<br>
>><br>
>>I want to see miners, developers and industry side-by-side pushing<br>
>>Bitcoin<br>
>>forward, to increase the value of Bitcoin and prevent high transaction<br>
>>fees<br>
>>to put out of business use-cases that could have high positive social<br>
>>impact.<br>
>><br>
>>I believe in the strength of a unified Bitcoin community. If you're a<br>
>>developer, please give your opinion, suggest changes, audit it, and<br>
>>take a<br>
>>stand with me to unlock the current Bitcoin deadlock.<br>
>><br>
>>Contributions to the segwit2mb project are welcomed and awaited. The<br>
>>only<br>
>>limitation is to stick to the principle that the patch should be as<br>
>>simple<br>
>>to audit as possible. As an example, I wouldn't feel confident if the<br>
>>patch<br>
>>modified more than ~150 lines of code.<br>
>><br>
>>Improvements unrelated to a 2 Mb increase or segwit, as beneficial as<br>
>>it<br>
>>may be to Bitcoin, should not be part of segwit2Mb.<br>
>><br>
>>This proposal should not prevent other consensus proposals to be<br>
>>simultaneously merged: segwit2mb is a last resort solution in case we<br>
>>can<br>
>>not reach consensus on anything better.<br>
>><br>
>>Again, the proposal is only a starting point: community feedback is<br>
>>expected and welcomed.<br>
>><br>
>>Regards,<br>
>>Sergio Demian Lerner<br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>