Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 15119 bytes --]

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-lists@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
>
>

[-- Attachment #2: Type: text/html, Size: 19888 bytes --]