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