>From me to you ...this proposal doesn't lock in anything. We could just merge it with some small pushback - allow segwit to activate in Aug, then "upgrade" the hard fork to be "spoonet in 18 months" instead.
On Fri, Mar 31, 2017 at 11:03 PM, Samson Mow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A compromise for the sake of compromise doesn't merit technical > discussions. There are no benefits to be gained from a 2MB hard-fork at > this time and it would impose an unnecessary cost to the ecosystem for > testing and implementation. > > On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <lf-li...@mattcorallo.com> >> wrote: >> >>> Hey Sergio, >>> >>> You appear to have ignored the last two years of Bitcoin hardfork >>> research and understanding, recycling instead BIP 102 from 2015. There >>> are many proposals which have pushed the state of hard fork research >>> much further since then, and you may wish to read some of the posts on >>> this mailing list listed at https://bitcoinhardforkresearch.github.io/ >>> and make further edits based on what you learn. >> >> >> I've read every proposal that was published in the last two years and the >> choice for NOT implementing any of the super cool research you cite is >> intentional. >> >> We're in a deadlock and it seems we can't go forward adding more >> functionality to segwit without the community approval (which include >> miners). This is obvious to me.Then we have to go back. >> >> If this last resort solution is merged, we could go back to discuss >> improvements with the >> >> Your goal of "avoid >>> technical changes" appears to not have any basis outside of perceived >>> compromise for compromise sake, only making such a hardfork riskier >>> instead. >>> >>> You're are totally correct. It's a compromise for the compromise sake. I >> couldn't have expressed it more clearly. However the only "riskier" element >> is the hard forking date. We can move the date forward. >> >> >>> At a minimum, in terms of pure technical changes, you should probably >>> consider (probably among others): >>> >> a) Utilizing the "hard fork signaling bit" in the nVersion of the block. >>> >> >> This I could consider, as it requires probably a single line of code. >> Which BIP specifies this? >> >> >>> b) Either limiting non-SegWit transactions in some way to fix the n**2 >>> sighash and FindAndDelete runtime and memory usage issues or fix them by >>> utilizing the new sighash type which many wallets and projects have >>> already implemented for SegWit in the spending of non-SegWit outputs. >>> >> >> The Seghash problem has already been addressed by limiting the maximum >> size of a transaction to 1 Mb. >> The FindAndDelete problem has already been solved by the Core Developers, >> so we don't have to worry about it anymore. >> >> >>> c) Your really should have replay protection in any HF. >> >> >> We could add a simple protection, although if we reach community >> consensus and 95% of hashing power, does we really need to? Can the old >> chain still be alive? >> If more people ask for replay protection, I will merge Spoonet scheme or >> develop the minimum possible replay protection (a simple signaling bit in >> transaction version) >> >> >>> d) You may wish to consider the possibility of tweaking the witness >>> discount and possibly discounting other parts of the input - SegWit went >>> a long ways towards making removal of elements from the UTXO set cheaper >>> than adding them, but didn't quite get there, you should probably finish >>> that job. This also provides additional tuneable parameters to allow you >>> to increase the block size while not having a blowup in the worst-case >>> block size. >>> >> >> That is an interesting economic change and would be out of the scope of >> segwit2mb. >> >> >>> e) Additional commitments at the top of the merkle root - both for >>> SegWit transactions and as additional space for merged mining and other >>> commitments which we may wish to add in the future, this should likely >>> be implemented an "additional header" ala Johnson Lau's Spoonnet >>> proposal. >>> >>> That is an interesting technical improvement that is out of the scope of >> segwit2mb. >> We can keep discussing spoonet while we merge segwit2mb, as spoonnet >> includes most of technical innovations. >> >> >>> Additionally, I think your parameters here pose very significant risk to >>> the Bitcoin ecosystem broadly. >>> >>> a) Activating a hard fork with less than 18/24 months (and even then...) >>> from a fully-audited and supported release of full node software to >>> activation date poses significant risks to many large software projects >>> and users. I've repeatedly received feedback from various folks that a >>> year or more is likely required in any hard fork to limit this risk, and >>> limited pushback on that given the large increase which SegWit provides >>> itself buying a ton of time. >>> >>> The feedback I received is slightly different from your feedback. Many >> company CTOs have expressed that one year for a Bitcoin hard-fork was >> period they could schedule a secure upgrade. >> >> >> >>> b) Having a significant discontinuity in block size increase only serves >>> to confuse and mislead users and businesses, forcing them to rapidly >>> adapt to a Bitcoin which changed overnight both by hardforking, and by >>> fees changing suddenly. Instead, having the hard fork activate technical >>> changes, and then slowly increasing the block size over the following >>> several years keeps things nice and continuous and also keeps us from >>> having to revisit ye old blocksize debate again six months after >>> activation. >>> >>> This is something worth considering. There is the old Pieter BIP103 >> proposal has good parameters (17.7% per year). >> >> c) You should likely consider the effect of the many technological >>> innovations coming down the pipe in the coming months. Technologies like >>> Lightning, TumbleBit, and even your own RootStock could significantly >>> reduce fee pressure as transactions move to much faster and more >>> featureful systems. >>> >>> RSK sidechain team would have to take very tough decisions if Bitcoin >> splits, as RSK platform cannot be pegged to two different cryptocurrencies. >> We could launch two platforms, but RSK value proposition is "supporting the >> advance of Bitcoin, the cryptocurrecy with highest network effect". You >> understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to >> be the cryptocurrencies with higher volume/market cap/network effect. >> >> Therefore all RSK people that I talked too would prefer to avoid a split >> at all cost, reather that to be the winners of the scaling war. >> >> >> >>> On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >Hi everyone, >>> > >>> >Segwit2Mb is the project to merge into Bitcoin a minimal patch that >>> >aims to >>> >untangle the current conflict between different political positions >>> >regarding segwit activation vs. an increase of the on-chain blockchain >>> >space through a standard block size increase. It is not a new solution, >>> >but >>> >it should be seen more as a least common denominator. >>> > >>> >Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB >>> >block >>> >size hard-fork activated ONLY if segwit activates (95% of miners >>> >signaling), but at a fixed future date. >>> > >>> >The sole objective of this proposal is to re-unite the Bitcoin >>> >community >>> >and avoid a cryptocurrency split. Segwit2Mb does not aim to be best >>> >possible technical solution to solve Bitcoin technical limitations. >>> >However, this proposal does not imply a compromise to the future >>> >scalability or decentralization of Bitcoin, as a small increase in >>> >block >>> >size has been proven by several core and non-core developers not to >>> >affect >>> >Bitcoin value propositions. >>> > >>> >In the worst case, a 2X block size increase has much lower economic >>> >impact >>> >than the last bitcoin halving (<10%), which succeeded without problem. >>> > >>> >On the other side, Segwit2Mb primary goal is to be minimalistic: in >>> >this >>> >patch some choices have been made to reduce the number of lines >>> >modified in >>> >the current Bitcoin Core state (master branch), instead of implementing >>> >the >>> >most elegant solution. This is because I want to reduce the time it >>> >takes >>> >for core programmers and reviewers to check the correctness of the >>> >code, >>> >and to report and correct bugs. >>> > >>> >The patch was built by forking the master branch of Bitcoin Core, >>> >mixing a >>> >few lines of code from Jeff Garzik's BIP102, and defining a second >>> >versionbits activation bit (bit 2) for the combined activation. >>> > >>> >The combined activation of segwit and 2Mb hard-fork nVersion bit is 2 >>> >(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS). >>> > >>> >This means that segwit can still be activated without the 2MB hard-fork >>> >by >>> >signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT). >>> > >>> >The tentative lock-in and hard-fork dates are the following: >>> > >>> >Bit 2 signaling StartTime = 1493424000; // April 29th, 2017 >>> > >>> >Bit 2 signaling Timeout = 1503964800; // August 29th, 2017 >>> > >>> >HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT >>> > >>> > >>> >The hard-fork is conditional to 95% of the hashing power has approved >>> >the >>> >segwit2mb soft-fork and the segwit soft-fork has been activated (which >>> >should occur 2016 blocks after its lock-in time) >>> > >>> >For more information on how soft-forks are signaled and activated, see >>> >https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki >>> > >>> >This means that segwit would be activated before 2Mb: this is >>> >inevitable, >>> >as versionbits have been designed to have fixed activation periods and >>> >thresholds for all bits. Making segwit and 2Mb fork activate together >>> >at a >>> >delayed date would have required a major re-write of this code, which >>> >would >>> >contradict the premise of creating a minimalistic patch. However, once >>> >segwit is activated, the hard-fork is unavoidable. >>> > >>> >Although I have coded a first version of the segwit2mb patch (which >>> >modifies 120 lines of code, and adds 220 lines of testing code), I >>> >would >>> >prefer to wait to publish the source code until more comments have been >>> >received from the community. >>> > >>> >To prevent worsening block verification time because of the O(N^2) >>> >hashing >>> >problem, the simple restriction that transactions cannot be larger than >>> >1Mb >>> >has been kept. Therefore the worse-case of block verification time has >>> >only >>> >doubled. >>> > >>> >Regarding the hard-fork activation date, I want to give enough time to >>> >all >>> >active economic nodes to upgrade. As of Fri Mar 31 2017, >>> >https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%) >>> >have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can >>> >be >>> >used to identify economic active nodes, because in the 0.12 release >>> >dynamic >>> >fees were introduced, and currently no Bitcoin automatic payment system >>> >can >>> >operate without automatic discovery of the current fee rate. A pre-0.12 >>> >would require constant manual intervention. >>> >Therefore I conclude that no more than 91% of the network nodes >>> >reported by >>> >bitnodes are active economic nodes. >>> > >>> >As Bitcoin Core 0.12 was released on February 2016, the time for this >>> >91% >>> >to upgrade has been around one year (under a moderate pressure of >>> >operational problems with unconfirmed transactions). >>> >Therefore we can expect a similar or lower time to upgrade for a >>> >hard-fork, >>> >after developers have discussed and approved the patch, and it has been >>> >reviewed and merged and 95% of the hashing power has signaled for it >>> >(the >>> >pressure not to upgrade being a complete halt of the operations). >>> >However I >>> >suggest that we discuss the hard-fork date and delay it if there is a >>> >real >>> >need to. >>> > >>> >Currently time works against the Bitcoin community, and so is delaying >>> >a >>> >compromise solution. Most of the community agree that halting the >>> >innovation for several years is a very bad option. >>> > >>> >After the comments collected by the community, a BIP will be written >>> >describing the resulting proposal details. >>> > >>> >If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should >>> >be >>> >updated to a Segwit2Mb enabled node to prevent them to be forked-away >>> >in a >>> >chain with almost no hashing-power. >>> > >>> >The proof of concept patch was made for Bitcoin Core but should be >>> >easily >>> >ported to other Bitcoin protocol implementations that already support >>> >versionbits. Lightweight (SPV) wallets should not be affected as they >>> >generally do not check the block size. >>> > >>> >I personally want to see the Lightning Network in action this year, use >>> >the >>> >non-malleability features in segwit, see the community discussing other >>> >exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains >>> >and >>> >MAST. >>> > >>> >I want to see miners, developers and industry side-by-side pushing >>> >Bitcoin >>> >forward, to increase the value of Bitcoin and prevent high transaction >>> >fees >>> >to put out of business use-cases that could have high positive social >>> >impact. >>> > >>> >I believe in the strength of a unified Bitcoin community. If you're a >>> >developer, please give your opinion, suggest changes, audit it, and >>> >take a >>> >stand with me to unlock the current Bitcoin deadlock. >>> > >>> >Contributions to the segwit2mb project are welcomed and awaited. The >>> >only >>> >limitation is to stick to the principle that the patch should be as >>> >simple >>> >to audit as possible. As an example, I wouldn't feel confident if the >>> >patch >>> >modified more than ~150 lines of code. >>> > >>> >Improvements unrelated to a 2 Mb increase or segwit, as beneficial as >>> >it >>> >may be to Bitcoin, should not be part of segwit2Mb. >>> > >>> >This proposal should not prevent other consensus proposals to be >>> >simultaneously merged: segwit2mb is a last resort solution in case we >>> >can >>> >not reach consensus on anything better. >>> > >>> >Again, the proposal is only a starting point: community feedback is >>> >expected and welcomed. >>> > >>> >Regards, >>> >Sergio Demian Lerner >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
