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

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

[Sergio Demian Lerner]

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

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

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

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

[Matt Corallo]

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. It seems your goal of
"avoid any technical changes" doesn't have any foundation aside from a
perceived compromise for compromise sake, only making for fork riskier
in the process.

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.
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.
c) Your replay protection isn't really ideal - XXX. The clever fix from
Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
be spent with SegWit's sighash provides this all in one go.
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.
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.

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.

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.

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.

Commitments to aggressive hard fork parameters now may leave miners
without much revenue as far out as the next halving (which current
transaction growth trends are indicating we'd just only barely reach 2MB
of transaction volume, let alone if you consider the effects of users
moving to systems which provide more features for Bitcoin transactions).
This could lead to a precipitous drop in hashrate as miners are no
longer sufficiently compensated.

Remember that the "hashpower required to secure bitcoin" is determined
as a percentage of total Bitcoins transacted on-chain in each block, so
as subsidy goes down, miners need to be paid with fees, not just price
increases. Even if we were OK with hashpower going down compared to the
value it is securing, betting the security of Bitcoin on its price
rising exponentially to match decreasing subsidy does not strike me as a
particularly inspiring tradeoff.

There aren't many great technical solutions to some of these issues, as
far as I'm aware, but it's something that needs to be incredibly
carefully considered before betting the continued security of Bitcoin on
exponential on-chain growth, something which we have historically never
seen.

Matt


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

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

[praxeology_guy]

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

Sergio Demian Lerner: Please confirm that you understand that:

The current SegWit being proposed comes bundled with an effective 2MB block size increase.

Are you proposing the remove this bundled policy change, and then have a different BIP that increases the block size? Not quite clear if you understand what the current proposal is.

Cheers,
Praxeology

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

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

[Sergio Demian Lerner]

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

Praxelogy_guy,
Yes I understand that segwit2mb represents a "potential" 4Mb block size
increase.
But Segwit does not immediately lead to 2 Mb blocks, but can only achieve
close to a 2Mb increase if all Bitcoin wallets switch to segwit, which will
take a couple of years.
Therefore I don't expect transactions per block to quadruple from one day
to another.


On Fri, Mar 31, 2017 at 6:22 PM, praxeology_guy <
praxeology_guy@protonmail.com> wrote:

> Sergio Demian Lerner: Please confirm that you understand that:
>
> The current SegWit being proposed comes bundled with an effective 2MB
> block size increase.
>
> Are you proposing the remove this bundled policy change, and then have a
> different BIP that increases the block size?  Not quite clear if you
> understand what the current proposal is.
>
> Cheers,
> Praxeology
>

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

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

[Matt Corallo]

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. 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.

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.
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.
c) Your really should have replay protection in any HF. The clever fix from
Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
be spent with SegWit's sighash provides this all in one go.
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.
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.

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.

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.

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.

Commitments to aggressive hard fork parameters now may leave miners
without much revenue as far out as the next halving (which current
transaction growth trends are indicating we'd just only barely reach 2MB
of transaction volume, let alone if you consider the effects of users
moving to systems which provide more features for Bitcoin transactions).
This could lead to a precipitous drop in hashrate as miners are no
longer sufficiently compensated.

Remember that the "hashpower required to secure bitcoin" is determined
as a percentage of total Bitcoins transacted on-chain in each block, so
as subsidy goes down, miners need to be paid with fees, not just price
increases. Even if we were OK with hashpower going down compared to the
value it is securing, betting the security of Bitcoin on its price
rising exponentially to match decreasing subsidy does not strike me as a
particularly inspiring tradeoff.

There aren't many great technical solutions to some of these issues, as
far as I'm aware, but it's something that needs to be incredibly
carefully considered before betting the continued security of Bitcoin on
exponential on-chain growth, something which we have historically never
seen.

Matt


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

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

[Sergio Demian Lerner]

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

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
>

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

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

[Samson Mow]

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

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

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

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

[Sergio Demian Lerner]

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

Even if the proposal involves a political compromise, any change to the
code must be technically evaluated.
The patch was made to require the least possible time for auditing. I'm
talking about reviewing 120 lines of code (not counting comments or
space) which 30 of them are changes to constants. A core programmer audited
it in less than one hour.

Also you're risking the unique opportunity to see segwit activated for
what?
Maybe we can reach a similar agreement for segwit activation in two years.
That's will be too late. The remaining cryptocurrency ecosystem do move
forward.



On Sat, Apr 1, 2017 at 12:03 AM, Samson Mow <samson.mow@gmail.com> 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
>>
>>
>

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

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

[Erik Aronesty]

[-- 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 --]

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

[Jared Lee Richardson]

> Remember that the "hashpower required to secure bitcoin" is determined
> as a percentage of total Bitcoins transacted on-chain in each block

Can you explain this statement a little better?  What do you mean by
that?  What does the total bitcoins transacted have to do with
hashpower required?

On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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. 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.
>
> 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.
> 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.
> c) Your really should have replay protection in any HF. The clever fix from
> Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
> be spent with SegWit's sighash provides this all in one go.
> 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.
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Commitments to aggressive hard fork parameters now may leave miners
> without much revenue as far out as the next halving (which current
> transaction growth trends are indicating we'd just only barely reach 2MB
> of transaction volume, let alone if you consider the effects of users
> moving to systems which provide more features for Bitcoin transactions).
> This could lead to a precipitous drop in hashrate as miners are no
> longer sufficiently compensated.
>
> Remember that the "hashpower required to secure bitcoin" is determined
> as a percentage of total Bitcoins transacted on-chain in each block, so
> as subsidy goes down, miners need to be paid with fees, not just price
> increases. Even if we were OK with hashpower going down compared to the
> value it is securing, betting the security of Bitcoin on its price
> rising exponentially to match decreasing subsidy does not strike me as a
> particularly inspiring tradeoff.
>
> There aren't many great technical solutions to some of these issues, as
> far as I'm aware, but it's something that needs to be incredibly
> carefully considered before betting the continued security of Bitcoin on
> exponential on-chain growth, something which we have historically never
> seen.
>
> Matt
>
>
> 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

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

[Sergio Demian Lerner]

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

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.

The Segwit2Mb patch can be found here:
https://github.com/SergioDemianLerner/bitcoin/commits/master

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.


regards


On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <jaredr26@gmail.com>
wrote:

> > Remember that the "hashpower required to secure bitcoin" is determined
> > as a percentage of total Bitcoins transacted on-chain in each block
>
> Can you explain this statement a little better?  What do you mean by
> that?  What does the total bitcoins transacted have to do with
> hashpower required?
>
> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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. 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.
> >
> > 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.
> > 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.
> > c) Your really should have replay protection in any HF. The clever fix
> from
> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
> > be spent with SegWit's sighash provides this all in one go.
> > 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.
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Commitments to aggressive hard fork parameters now may leave miners
> > without much revenue as far out as the next halving (which current
> > transaction growth trends are indicating we'd just only barely reach 2MB
> > of transaction volume, let alone if you consider the effects of users
> > moving to systems which provide more features for Bitcoin transactions).
> > This could lead to a precipitous drop in hashrate as miners are no
> > longer sufficiently compensated.
> >
> > Remember that the "hashpower required to secure bitcoin" is determined
> > as a percentage of total Bitcoins transacted on-chain in each block, so
> > as subsidy goes down, miners need to be paid with fees, not just price
> > increases. Even if we were OK with hashpower going down compared to the
> > value it is securing, betting the security of Bitcoin on its price
> > rising exponentially to match decreasing subsidy does not strike me as a
> > particularly inspiring tradeoff.
> >
> > There aren't many great technical solutions to some of these issues, as
> > far as I'm aware, but it's something that needs to be incredibly
> > carefully considered before betting the continued security of Bitcoin on
> > exponential on-chain growth, something which we have historically never
> > seen.
> >
> > Matt
> >
> >
> > 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
>

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

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

[Jorge Timón]

Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
MAX_BLOCK2_BASE_SIZE.
Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
mb weight to 8 mb weight.

I would also use the hardfork bit (sign bit in block.nNersion) as matt comments.

> 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 segwit is controversial the way it is (I still don't understand why
despite having insistently asking to users and miners who claim to
oppose it), adding more consensus rule changes won't make it any less
controversial. If anything, it would be removing consensus rule
changes, not adding them that could make it less controversial.

By no means I want to dissuade you from working on this bip proposal,
but I really don't see how it helps getting out of the deadlock at
all.


On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
> The Segwit2Mb patch can be found here:
> https://github.com/SergioDemianLerner/bitcoin/commits/master
>
> 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.
>
>
> regards
>
>
>
> On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <jaredr26@gmail.com>
> wrote:
>>
>> > Remember that the "hashpower required to secure bitcoin" is determined
>> > as a percentage of total Bitcoins transacted on-chain in each block
>>
>> Can you explain this statement a little better?  What do you mean by
>> that?  What does the total bitcoins transacted have to do with
>> hashpower required?
>>
>>
>> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> 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. 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.
>> >
>> > 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.
>> > 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.
>> > c) Your really should have replay protection in any HF. The clever fix
>> > from
>> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
>> > be spent with SegWit's sighash provides this all in one go.
>> > 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.
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > Commitments to aggressive hard fork parameters now may leave miners
>> > without much revenue as far out as the next halving (which current
>> > transaction growth trends are indicating we'd just only barely reach 2MB
>> > of transaction volume, let alone if you consider the effects of users
>> > moving to systems which provide more features for Bitcoin transactions).
>> > This could lead to a precipitous drop in hashrate as miners are no
>> > longer sufficiently compensated.
>> >
>> > Remember that the "hashpower required to secure bitcoin" is determined
>> > as a percentage of total Bitcoins transacted on-chain in each block, so
>> > as subsidy goes down, miners need to be paid with fees, not just price
>> > increases. Even if we were OK with hashpower going down compared to the
>> > value it is securing, betting the security of Bitcoin on its price
>> > rising exponentially to match decreasing subsidy does not strike me as a
>> > particularly inspiring tradeoff.
>> >
>> > There aren't many great technical solutions to some of these issues, as
>> > far as I'm aware, but it's something that needs to be incredibly
>> > carefully considered before betting the continued security of Bitcoin on
>> > exponential on-chain growth, something which we have historically never
>> > seen.
>> >
>> > Matt
>> >
>> >
>> > 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
>

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

[Natanael]

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

Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:

Segwit replaces the 1 mb size limit with a weight limit of 4 mb.


That would make it a hardfork, not a softfork, if done exactly as you say.

Segwit only separates out signature data. The 1 MB limit remains, but would
now only cover the contents of the transaction scripts. With segwit that
means we have two (2) size limits, not one. This is important to remember.
Even with segwit + MAST for large complex scripts, there's still going to
be a very low limit to the total number of possible transactions per block.
And not all transactions will get the same space savings.

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

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

[Jorge Timón]

On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail.com> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org>:
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember.
> Even with segwit + MAST for large complex scripts, there's still going to be
> a very low limit to the total number of possible transactions per block. And
> not all transactions will get the same space savings.

No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit. The weight is also the only notion of cost miners need
to consider when comparing txs by feerate (fee per cost, before segwit
tx_fee/tx_size, post-segwit tx_fee/tx_weight).
This is important to remember, because having 2 separated limits or
costs would make block creation and relay policies much harder to
implement.

Therefore a hardfork after segwit can just increase the weight limit
and completely forget about the pre-segwit 1 mb size limit.

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

[Natanael]

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

Den 1 apr. 2017 16:07 skrev "Jorge Timón" <jtimon@jtimon.cc>:

On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail.com> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org>:
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but
would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember.
> Even with segwit + MAST for large complex scripts, there's still going to
be
> a very low limit to the total number of possible transactions per block.
And
> not all transactions will get the same space savings.

No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit.


https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size

Huh, that's odd. It really does still count raw blockchain data blocksize.

It just uses a ratio between how many units each byte is worth for block
data vs signature data, plus a cap to define the maximum. So the current
max is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x
= 4 MB. That just means you replaced the two limits with one limit and a
ratio.

A hardfork increasing the size would likely have the ratio modified too.
With exactly the same effect as if it was two limits...

Either way, there's still going to be non-segwit nodes for ages.

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

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

[Jorge Timón]

On Sat, Apr 1, 2017 at 5:34 PM, Natanael <natanael.l@gmail.com> wrote:
> Den 1 apr. 2017 16:07 skrev "Jorge Timón" <jtimon@jtimon.cc>:
> On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail.com> wrote:
>> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
>> <bitcoin-dev@lists.linuxfoundation.org>:
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>> That would make it a hardfork, not a softfork, if done exactly as you say.
> No, because of the way the weight is calculated, it is impossible to
> create a block that old nodes would perceive as bigger than 1 mb
> without also violating the weight limit.
> After segwit activation, nodes supporting segwit don't need to
> validate the 1 mb size limit anymore as long as they validate the
> weight limit.
>
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
>
> Huh, that's odd. It really does still count raw blockchain data blocksize.

It's not odd, it's just counter-intuitive. How can "< 4 mb weight" be
a more restrictive rule than "< 1 mb size"? Well, it is, that's why
segwit's size increase is a softfork.
It is not that hard once you look at the actual weight formula:
segregated_sigs_sise + (other_size * 4) < 4 "mb"

It is impossible to produce to produce a block that violates the 1 mb
size limit but doesn't violate the 4 mb weight limit too.
There can be block that are < 1 mb size but 20 mb in weight, but those
are invalid according to the new 4 mb weight rule.
At the same time, any block that violates the < 1 mb rule for old
nodes will be invalid not only to old nodes but also to any node
validating the new 4mb rule. This is not by chance but a design choice
for any block size increase within segwit to remain a softfork, which
is what can be deployed faster.

One extreme example would be any 1 mb block today. 1 "mb" of a block
today times 4 is 4 mb, so it complies with the new 4 mb weight rule.
The opposite extreme example would be 4 mb of signatures and 0 mb of
"other data", but this example is not really possible in practice
because signatures need some tx to be part of to be part of the block
itself.
The most extreme examples I have seen on testnet are 3.7 mb blocks,
but those don't represent the average usage today (whenever you read
this).

One common misunderstanding is that users who aren't using payment
channels (that includes lightning but also other smart contracts) or
users that aren't using mutlisig can't enjoy the so called "discount":
there's no reasonable argument for rejecting the "discount" on your
own transactions once/if segwit gets activated.

I would prefer to call the absence of "discount" *penalization*.
Signatures are unreasonable penalized pre-segwit, and there's more
things that remain unreasonably penalized with respect to their
influence on the current utxo after segwit. But signatures are by far
the biggest in data space and validation time, and the most important
unreasonable yet unintended penalization pre-segwit.

> It just uses a ratio between how many units each byte is worth for block
> data vs signature data, plus a cap to define the maximum. So the current max
> is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x = 4
> MB. That just means you replaced the two limits with one limit and a ratio.

Exactly, once one maximum limit is defined, no need for two limits.
But the current max is 1 mb size, not 4 mb weight until/unless segwit
is activated.
Some people complain about 4 mb weight not being as much as 4 mb size,
and that is correct, but both are bigger than 1 mb size.

> A hardfork increasing the size would likely have the ratio modified too.

If the single ratio needs to be modified, it can be modified now
before any rule changes are activated, no need to change the consensus
rules more than needed.

> With exactly the same effect as if it was two limits...

If you don't see any disadvantage on having one single limit if/when
segwit gets activated, I don't see the point of maintaining two
limits, but if you're happy to maintain the branch with the redundant
one you may get my ack: I don't see any disadvantage on checking the
same thing twice besides performance,

> Either way, there's still going to be non-segwit nodes for ages.

That's precisely why it's good segwit has been designed to be backward
compatible as a bip9 softfork.

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

[Natanael]

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

My point, if you missed it, is that there's a mathematical equivalence
between using two limits (and calculating the ratio) vs using one limit and
a ratio. The output is fully identical. The only difference is the order of
operations. Saying there's no blocksize limit with this is pretty
meaningless, because you're just saying you're using an abstraction that
doesn't make the limit visible.

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

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

[Jorge Timón]

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

Just saying that we can talk in terms of weight alone after segwit. 8 mb
weight is much more clear than 2 mb size to me. 2 mb size seems to
obfuscate the actual new limit with the proposed hf, which simply 8 mb
weight.

On 2 Apr 2017 12:03 pm, "Natanael" <natanael.l@gmail.com> wrote:

> My point, if you missed it, is that there's a mathematical equivalence
> between using two limits (and calculating the ratio) vs using one limit and
> a ratio. The output is fully identical. The only difference is the order of
> operations. Saying there's no blocksize limit with this is pretty
> meaningless, because you're just saying you're using an abstraction that
> doesn't make the limit visible.
>

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

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

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 17164 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 Sat, Apr 1, 2017 at 8:33 AM, Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
> MAX_BLOCK2_BASE_SIZE.
> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
> mb weight to 8 mb weight.
>
> I would also use the hardfork bit (sign bit in block.nNersion) as matt
> comments.
>
> > 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 segwit is controversial the way it is (I still don't understand why
> despite having insistently asking to users and miners who claim to
> oppose it), adding more consensus rule changes won't make it any less
> controversial. If anything, it would be removing consensus rule
> changes, not adding them that could make it less controversial.
>
> By no means I want to dissuade you from working on this bip proposal,
> but I really don't see how it helps getting out of the deadlock at
> all.
>
>
> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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.
> >
> > The Segwit2Mb patch can be found here:
> > https://github.com/SergioDemianLerner/bitcoin/commits/master
> >
> > 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.
> >
> >
> > regards
> >
> >
> >
> > On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <jaredr26@gmail.com
> >
> > wrote:
> >>
> >> > Remember that the "hashpower required to secure bitcoin" is determined
> >> > as a percentage of total Bitcoins transacted on-chain in each block
> >>
> >> Can you explain this statement a little better?  What do you mean by
> >> that?  What does the total bitcoins transacted have to do with
> >> hashpower required?
> >>
> >>
> >> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> 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. 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.
> >> >
> >> > 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.
> >> > 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.
> >> > c) Your really should have replay protection in any HF. The clever fix
> >> > from
> >> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
> >> > be spent with SegWit's sighash provides this all in one go.
> >> > 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.
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > Commitments to aggressive hard fork parameters now may leave miners
> >> > without much revenue as far out as the next halving (which current
> >> > transaction growth trends are indicating we'd just only barely reach
> 2MB
> >> > of transaction volume, let alone if you consider the effects of users
> >> > moving to systems which provide more features for Bitcoin
> transactions).
> >> > This could lead to a precipitous drop in hashrate as miners are no
> >> > longer sufficiently compensated.
> >> >
> >> > Remember that the "hashpower required to secure bitcoin" is determined
> >> > as a percentage of total Bitcoins transacted on-chain in each block,
> so
> >> > as subsidy goes down, miners need to be paid with fees, not just price
> >> > increases. Even if we were OK with hashpower going down compared to
> the
> >> > value it is securing, betting the security of Bitcoin on its price
> >> > rising exponentially to match decreasing subsidy does not strike me
> as a
> >> > particularly inspiring tradeoff.
> >> >
> >> > There aren't many great technical solutions to some of these issues,
> as
> >> > far as I'm aware, but it's something that needs to be incredibly
> >> > carefully considered before betting the continued security of Bitcoin
> on
> >> > exponential on-chain growth, something which we have historically
> never
> >> > seen.
> >> >
> >> > Matt
> >> >
> >> >
> >> > 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
>

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

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

[Sergio Demian Lerner]

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

By "upgrade"  the HF you mean activate 2X and then spoonet 18 months later
or do not activate the 2x HF at all?





On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 Sat, Apr 1, 2017 at 8:33 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
>> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
>> MAX_BLOCK2_BASE_SIZE.
>> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
>> mb weight to 8 mb weight.
>>
>> I would also use the hardfork bit (sign bit in block.nNersion) as matt
>> comments.
>>
>> > 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 segwit is controversial the way it is (I still don't understand why
>> despite having insistently asking to users and miners who claim to
>> oppose it), adding more consensus rule changes won't make it any less
>> controversial. If anything, it would be removing consensus rule
>> changes, not adding them that could make it less controversial.
>>
>> By no means I want to dissuade you from working on this bip proposal,
>> but I really don't see how it helps getting out of the deadlock at
>> all.
>>
>>
>> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > 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.
>> >
>> > The Segwit2Mb patch can be found here:
>> > https://github.com/SergioDemianLerner/bitcoin/commits/master
>> >
>> > 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.
>> >
>> >
>> > regards
>> >
>> >
>> >
>> > On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <
>> jaredr26@gmail.com>
>> > wrote:
>> >>
>> >> > Remember that the "hashpower required to secure bitcoin" is
>> determined
>> >> > as a percentage of total Bitcoins transacted on-chain in each block
>> >>
>> >> Can you explain this statement a little better?  What do you mean by
>> >> that?  What does the total bitcoins transacted have to do with
>> >> hashpower required?
>> >>
>> >>
>> >> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org> 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://bitcoinhardforkresearc
>> h.github.io/
>> >> > and make further edits based on what you learn. 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.
>> >> >
>> >> > 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.
>> >> > 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.
>> >> > c) Your really should have replay protection in any HF. The clever
>> fix
>> >> > from
>> >> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs
>> to
>> >> > be spent with SegWit's sighash provides this all in one go.
>> >> > 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.
>> >> > 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.
>> >> >
>> >> > 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.
>> >> >
>> >> > 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.
>> >> >
>> >> > 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.
>> >> >
>> >> > Commitments to aggressive hard fork parameters now may leave miners
>> >> > without much revenue as far out as the next halving (which current
>> >> > transaction growth trends are indicating we'd just only barely reach
>> 2MB
>> >> > of transaction volume, let alone if you consider the effects of users
>> >> > moving to systems which provide more features for Bitcoin
>> transactions).
>> >> > This could lead to a precipitous drop in hashrate as miners are no
>> >> > longer sufficiently compensated.
>> >> >
>> >> > Remember that the "hashpower required to secure bitcoin" is
>> determined
>> >> > as a percentage of total Bitcoins transacted on-chain in each block,
>> so
>> >> > as subsidy goes down, miners need to be paid with fees, not just
>> price
>> >> > increases. Even if we were OK with hashpower going down compared to
>> the
>> >> > value it is securing, betting the security of Bitcoin on its price
>> >> > rising exponentially to match decreasing subsidy does not strike me
>> as a
>> >> > particularly inspiring tradeoff.
>> >> >
>> >> > There aren't many great technical solutions to some of these issues,
>> as
>> >> > far as I'm aware, but it's something that needs to be incredibly
>> >> > carefully considered before betting the continued security of
>> Bitcoin on
>> >> > exponential on-chain growth, something which we have historically
>> never
>> >> > seen.
>> >> >
>> >> > Matt
>> >> >
>> >> >
>> >> > 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
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

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

[Erik Aronesty]

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

What I mean is that spoonet and other HF improvements, and a slower
timeline needs to be folded in ...before the HF activation date - to make
it far more likely that the community adopts the whole proposal and the
chain doesn't fragment.

If you try to push a 2mb with no safety checks and nothing else improved -
nothing will happen.

Take a quick look at the COOP proposal...it gets us to 4mb blocks in 4
years....gradually, no massive fee swings.


On Fri, Jun 2, 2017 at 5:51 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

> By "upgrade"  the HF you mean activate 2X and then spoonet 18 months later
> or do not activate the 2x HF at all?
>
>
>
>
>
> On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 Sat, Apr 1, 2017 at 8:33 AM, Jorge Timón via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
>>> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
>>> MAX_BLOCK2_BASE_SIZE.
>>> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
>>> mb weight to 8 mb weight.
>>>
>>> I would also use the hardfork bit (sign bit in block.nNersion) as matt
>>> comments.
>>>
>>> > 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 segwit is controversial the way it is (I still don't understand why
>>> despite having insistently asking to users and miners who claim to
>>> oppose it), adding more consensus rule changes won't make it any less
>>> controversial. If anything, it would be removing consensus rule
>>> changes, not adding them that could make it less controversial.
>>>
>>> By no means I want to dissuade you from working on this bip proposal,
>>> but I really don't see how it helps getting out of the deadlock at
>>> all.
>>>
>>>
>>> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > 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.
>>> >
>>> > The Segwit2Mb patch can be found here:
>>> > https://github.com/SergioDemianLerner/bitcoin/commits/master
>>> >
>>> > 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.
>>> >
>>> >
>>> > regards
>>> >
>>> >
>>> >
>>> > On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <
>>> jaredr26@gmail.com>
>>> > wrote:
>>> >>
>>> >> > Remember that the "hashpower required to secure bitcoin" is
>>> determined
>>> >> > as a percentage of total Bitcoins transacted on-chain in each block
>>> >>
>>> >> Can you explain this statement a little better?  What do you mean by
>>> >> that?  What does the total bitcoins transacted have to do with
>>> >> hashpower required?
>>> >>
>>> >>
>>> >> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
>>> >> <bitcoin-dev@lists.linuxfoundation.org> 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://bitcoinhardforkresearc
>>> h.github.io/
>>> >> > and make further edits based on what you learn. 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.
>>> >> >
>>> >> > 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.
>>> >> > 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.
>>> >> > c) Your really should have replay protection in any HF. The clever
>>> fix
>>> >> > from
>>> >> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs
>>> to
>>> >> > be spent with SegWit's sighash provides this all in one go.
>>> >> > 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.
>>> >> > 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.
>>> >> >
>>> >> > 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.
>>> >> >
>>> >> > 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.
>>> >> >
>>> >> > 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.
>>> >> >
>>> >> > Commitments to aggressive hard fork parameters now may leave miners
>>> >> > without much revenue as far out as the next halving (which current
>>> >> > transaction growth trends are indicating we'd just only barely
>>> reach 2MB
>>> >> > of transaction volume, let alone if you consider the effects of
>>> users
>>> >> > moving to systems which provide more features for Bitcoin
>>> transactions).
>>> >> > This could lead to a precipitous drop in hashrate as miners are no
>>> >> > longer sufficiently compensated.
>>> >> >
>>> >> > Remember that the "hashpower required to secure bitcoin" is
>>> determined
>>> >> > as a percentage of total Bitcoins transacted on-chain in each
>>> block, so
>>> >> > as subsidy goes down, miners need to be paid with fees, not just
>>> price
>>> >> > increases. Even if we were OK with hashpower going down compared to
>>> the
>>> >> > value it is securing, betting the security of Bitcoin on its price
>>> >> > rising exponentially to match decreasing subsidy does not strike me
>>> as a
>>> >> > particularly inspiring tradeoff.
>>> >> >
>>> >> > There aren't many great technical solutions to some of these
>>> issues, as
>>> >> > far as I'm aware, but it's something that needs to be incredibly
>>> >> > carefully considered before betting the continued security of
>>> Bitcoin on
>>> >> > exponential on-chain growth, something which we have historically
>>> never
>>> >> > seen.
>>> >> >
>>> >> > Matt
>>> >> >
>>> >> >
>>> >> > 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
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

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

[Oliver Petruzel]

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

>>>Take a quick look at the COOP proposal...it gets us to 4mb blocks in 4
years....gradually, no massive fee swings.<<<

How is that captured in the COOP BIP? I can see Luke's 2MB cap referenced
in the BIP, but I don't see anything in the text that would indicate a
gradual increase of any sort.

As someone who has previously written a BIP draft to accomplish a gradual
increase with SegWit, I'd be very interested in seeing what approach
they've chosen.

Ollie

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

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

[Oliver Petruzel]

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

>>2.1MB capacity in August via segwit, with 4MB weight, and 4.2MB capacity
in December with 8MB<<

I'm not sure how many people to not of the draft BIP I submitted to the
list in early April. It was essentially a combination of Gavin's BIP 109,
Adam's 2-4-8 idea, and something I added to SegWit that I call "Discount
Governing."

It basically takes the idea of gradual increases one step farther: a
gradual increase of both the Total weight and SegWit discount rate over a
period of X years (a schedule of Flag Day + X blocks increases).

Would this be something that some in the dev community might consider
if/when SegWit is combined with a block increase?

Original draft here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
2017-April/013984.html

Ollie

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

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

[Btc Drak]

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

On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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)
>

Miners signalling they have upgraded by flipping a bit in the nVersion
field has little relevance in a hard fork. If 100% of the hash power
indicates they are running this proposal, but the nodes don't upgrade, what
will happen?

For the record, I actually talk a lot about hard forks with various
developers and am very interested in the research that Johnson in
particular is pioneering. However, I have failed to understand your point
about 95% miner signalling in relation to a hard fork, so I am eagerly
awaiting your explanation.

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

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

[Erik Aronesty]

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

I personally appreciate the minimal changes, and often encourage
development to be done this way - when it needs to be released quickly.
But does this need to be released quickly?

- maybe the proposal should be renamed segwit 8mb and be discussed solely
in terms of block weights.

- a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.

- miners who currently object to segwit while pretending to like larger
blocks will find some excuse to object to this too.

- Given the challenges miners seem to have in flipping bits, I expect any
fork that requires 95pct hash power to be vaporware.

On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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)
>>
>
> Miners signalling they have upgraded by flipping a bit in the nVersion
> field has little relevance in a hard fork. If 100% of the hash power
> indicates they are running this proposal, but the nodes don't upgrade, what
> will happen?
>
> For the record, I actually talk a lot about hard forks with various
> developers and am very interested in the research that Johnson in
> particular is pioneering. However, I have failed to understand your point
> about 95% miner signalling in relation to a hard fork, so I am eagerly
> awaiting your explanation.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

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

[Sergio Demian Lerner]

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

Responding between lines...

On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty <earonesty@gmail.com> wrote:

> I personally appreciate the minimal changes, and often encourage
> development to be done this way - when it needs to be released quickly.
> But does this need to be released quickly?
>
>
Segwit2mb is a last resort option. It does not need to be released quickly.
Not at all. It just needs to be there in case no other option is chosen. I
put tentative dates. We can move them.


> - maybe the proposal should be renamed segwit 8mb and be discussed solely
> in terms of block weights.
>

The name does not matter much. The name means joining segwit with a 2Mb
hard-fork. It's a grammatical name.

I also disagree with the idea that segwit2mb is a 8mb increase. As stated
by in the Bitcon.org website [1] and backed up by scientific research, “a
block filled with standard single-signature P2PKH transactions would be
about 1.6MB and a block filled with 2-of-2 multisignature transactions
would be about 2.0MB.”. As standard blocks are a combination between P2PKH,
and 2-of-3 multisignatures, the actual average segwit block size will be
close to 2.0MB.

Because Segwit2Mb doubles the maximum size of a block, the average block
size for a block filed with average transactions is 4.0Mb.

[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-size

I can explain in a following e-mail why creating 8Mb blocks on purpose is
generally is an irrational choice. And in the case where it could provide
an economic benefit, adding parallel block validation to Core nullifies any
adversary advantage.



> a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.

You and me may never know the reasons why these operators (or many many of
other users) prefer to increase the block-size. I suppose it has to do high
the high current transaction fees as compared to less than a year ago.
Anyway consensus can only be achieved if one understands the others may
have reasons that do not match ours.

Last, if this proposal is rejected by any side, then we'll definitively
learn that side is not looking for any consensual resolution of the
conflict.


> - miners who currently object to segwit while pretending to like larger
> blocks will find some excuse to object to this too.
>
>
If they do, we'll get a lot of public, verifiable information from that
fact. The cost to include this patch is low compared with the benefit it
can bring and the information we can gather in case one of the sides
rejects it.

However, I've received positive feedback from them until now.


> - Given the challenges miners seem to have in flipping bits, I expect any
> fork that requires 95pct hash power to be vaporware.
>

Then we'll learn a lot about hard-forks, the limits of miner "voting" and
the quorums we can expect.

Regards,
Sergio.


>
> On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, what
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your point
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

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

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

[Sergio Demian Lerner]

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

The 95% miner signaling is important to prevent two Bitcoin forks, such as
what happened with Ethereum HF and Ethereum Classic.

Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
just 95% miner support will initially (for 2016 blocks) be 5% slower (an
average block every 10 minutes and 30 seconds). The transaction capacity of
the new Bitcoin protocol is reduced only 5%.
However the chain with 5% if the hashing power not only has a 20x capacity
reduction, but confirms transactions in 20x more time. So the mempool will
grow 400 times. It must be noted that fees increased 10x from the moment
blocks were half full, to the moment blocks became saturated. I'm sure no
Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
fees to use such a slow and insecure network.

So a 6-block confirmation will take 20 hours in the original chain and the
original chain will be in this almost useless slow state for an average of
2016 blocks, or 280 days.
If the original blockchain hard-forks to re-adjust the difficulty, then it
will just represent an alt-coin having 5% of Bitcoin community, and it
can't affect Bitcoin (the segwit2mb fork).


On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak@gmail.com> wrote:

> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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)
>>
>
> Miners signalling they have upgraded by flipping a bit in the nVersion
> field has little relevance in a hard fork. If 100% of the hash power
> indicates they are running this proposal, but the nodes don't upgrade, what
> will happen?
>
> For the record, I actually talk a lot about hard forks with various
> developers and am very interested in the research that Johnson in
> particular is pioneering. However, I have failed to understand your point
> about 95% miner signalling in relation to a hard fork, so I am eagerly
> awaiting your explanation.
>

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

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

[Sergio Demian Lerner]

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

Ups. My mistake:  the mempool will not grow 400 times, the is no square
there.
I will initially grow 20 times. Multiplied by the number of times a
transaction may need to be replaced with one with higher fees. Maybe 50
times, but not 400.



On Thu, Apr 6, 2017 at 5:42 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

> The 95% miner signaling is important to prevent two Bitcoin forks, such as
> what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
> just 95% miner support will initially (for 2016 blocks) be 5% slower (an
> average block every 10 minutes and 30 seconds). The transaction capacity of
> the new Bitcoin protocol is reduced only 5%.
> However the chain with 5% if the hashing power not only has a 20x capacity
> reduction, but confirms transactions in 20x more time. So the mempool will
> grow 400 times. It must be noted that fees increased 10x from the moment
> blocks were half full, to the moment blocks became saturated. I'm sure no
> Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
> fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and the
> original chain will be in this almost useless slow state for an average of
> 2016 blocks, or 280 days.
> If the original blockchain hard-forks to re-adjust the difficulty, then it
> will just represent an alt-coin having 5% of Bitcoin community, and it
> can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak@gmail.com> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, what
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your point
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>
>

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

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

[Aymeric Vitte]

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

Not sure to get how you are answering the question

>  If the original blockchain hard-forks to re-adjust the difficulty,
then it will just represent an alt-coin having 5% of Bitcoin community,
and it can't affect Bitcoin (the segwit2mb fork).

destroys the whole thing

Because if the nodes don't upgrade and just implement the patch to
adjust the difficulty, what happens? You get a 95% mining power chain
with "no" nodes and a 5% one with "all" the nodes

I really don't get in all those discussions why the nodes are always
disconsidered compared to the miners, ie why they seem to be of zero
importance and are supposed to obey whatever you ask them

And apparently the trend is not going to revert if we look at the
priority features sent in the asicboost thread where motivating and
scaling full nodes is still something you need very powerful glasses to
see coming


Le 06/04/2017 à 22:42, Sergio Demian Lerner via bitcoin-dev a écrit :
> The 95% miner signaling is important to prevent two Bitcoin forks,
> such as what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that
> has just 95% miner support will initially (for 2016 blocks) be 5%
> slower (an average block every 10 minutes and 30 seconds). The
> transaction capacity of the new Bitcoin protocol is reduced only 5%. 
> However the chain with 5% if the hashing power not only has a 20x
> capacity reduction, but confirms transactions in 20x more time. So the
> mempool will grow 400 times. It must be noted that fees increased 10x
> from the moment blocks were half full, to the moment blocks became
> saturated. I'm sure no Bitcoin (pre-fork) user will be willing to pay
> 100x times the transaction fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and
> the original chain will be in this almost useless slow state for an
> average of 2016 blocks, or 280 days. 
> If the original blockchain hard-forks to re-adjust the difficulty,
> then it will just represent an alt-coin having 5% of Bitcoin
> community, and it can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak@gmail.com
> <mailto:btcdrak@gmail.com>> wrote:
>
>     On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via
>     bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>         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)
>
>
>     Miners signalling they have upgraded by flipping a bit in the
>     nVersion field has little relevance in a hard fork. If 100% of the
>     hash power indicates they are running this proposal, but the nodes
>     don't upgrade, what will happen?
>
>     For the record, I actually talk a lot about hard forks with
>     various developers and am very interested in the research that
>     Johnson in particular is pioneering. However, I have failed to
>     understand your point about 95% miner signalling in relation to a
>     hard fork, so I am eagerly awaiting your explanation.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


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

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

[R E Broadley]

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

Miner signalling is not enough to avoid two forks - as has been proven in
the past (e.g. when miners signaled they were fully validating blocks when
there we in fact only validating headers). To really protect against two
forks happening, the code needs to detect this happening (i.e. monitor the
other fork) and if it's clear that the signalling was dishonest, then it
needs to abort, IMHO.

On Thu, Apr 6, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The 95% miner signaling is important to prevent two Bitcoin forks, such as
> what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
> just 95% miner support will initially (for 2016 blocks) be 5% slower (an
> average block every 10 minutes and 30 seconds). The transaction capacity of
> the new Bitcoin protocol is reduced only 5%.
> However the chain with 5% if the hashing power not only has a 20x capacity
> reduction, but confirms transactions in 20x more time. So the mempool will
> grow 400 times. It must be noted that fees increased 10x from the moment
> blocks were half full, to the moment blocks became saturated. I'm sure no
> Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
> fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and the
> original chain will be in this almost useless slow state for an average of
> 2016 blocks, or 280 days.
> If the original blockchain hard-forks to re-adjust the difficulty, then it
> will just represent an alt-coin having 5% of Bitcoin community, and it
> can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak@gmail.com> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, what
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your point
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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