<unnamed>

Public Key

npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2d

Profile Code

nprofile1qqs83jkavkae3let2zhgyhapqq6j6lcs9eq7ch926tjd96v7qr0389qprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv67he5a

Publishing to

relay.snort.social

Last Notes

2023-06-07 20:02:35 CEST

- reply

📅 Original date posted:2017-06-07
📝 Original message:I think even 55% would probably work out fine simply due to incentive
structures, once signalling is over 51% it's then clear to miners that
non-signalling blocks will be orphaned and the rest will rapidly
update to splitprotection/BIP148. The purpose of this BIP is to reduce
chain split risk for BIP148 since it's looking like BIP148 is going to
be run by a non-insignificant percentage of the economy at a minimum.
On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <contact at taoeffect.com> wrote:
> See thread on replay attacks for why activating regardless of threshold is a
> bad idea [1].
>
> BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
> difficult for miners to hold together in opposition to Core. It gives Core
> more leverage in negotiations.
>
> If they don't activate with 80%, Core can release another BIP to reduce it
> to 75%.
>
> Each threshold reduction makes it both more likely to succeed, but also
> increases the likelihood of harm to the ecosystem.
>
> Cheers,
> Greg
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1 at gmail.com>
> wrote:
>
> This is a BIP8 style soft fork so mandatory signalling will be active
> after Aug 1st regardless.
>
> On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com> wrote:
>
> What is the probability that a 65% threshold is too low and can allow a
> "surprise miner attack", whereby miners are kept offline before the
> deadline, and brought online immediately after, creating potential havoc?
>
> (Nit: "simple majority" usually refers to >50%, I think, might cause
> confusion.)
>
> -Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Due to the proposed calendar(https://segwit2x.github.io/) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using BIP91 I would like to propose another
> option that miners can use to prevent a chain split ahead of the Aug
> 1st BIP148 activation date.
>
> The splitprotection soft fork is essentially BIP91 but using BIP8
> instead of BIP9 with a lower activation threshold and immediate
> mandatory signalling lock-in. This allows for a majority of miners to
> activate mandatory SegWit signalling and prevent a potential chain
> split ahead of BIP148 activation.
>
> This BIP allows for miners to respond to market forces quickly ahead
> of BIP148 activation by signalling for splitprotection. Any miners
> already running BIP148 should be encouraged to use splitprotection.
>
> <pre>
> BIP: splitprotection
> Layer: Consensus (soft fork)
> Title: User Activated Soft Fork Split Protection
> Author: James Hilliard <james.hilliard1 at gmail.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a coordination mechanism for a simple majority
> of miners to prevent a chain split ahead of BIP148 activation.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> The biggest risk of BIP148 is an extended chain split, this BIP
> provides a way for a simple majority of miners to eliminate that risk.
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower before BIP148 activation. Due to time constraints unless
> immediately deployed BIP91 will likely not be able to enforce
> mandatory signalling of segwit before the Aug 1st activation of
> BIP148. This BIP provides a method for rapid miner activation of
> SegWit mandatory signalling ahead of the BIP148 activation date. Since
> the primary goal of this BIP is to reduce the chance of an extended
> chain split as much as possible we activate using a simple miner
> majority of 65% over a 504 block interval rather than a higher
> percentage. This BIP also allows miners to signal their intention to
> run BIP148 in order to prevent a chain split.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required
> will be rejected.
>
> ==Deployment==
>
> This BIP will be deployed by "version bits" with a 65%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "splitprotecion" and using bit 2.
>
> This BIP starts immediately and is a BIP8 style soft fork since
> mandatory signalling will start on midnight August 1st 2017 (epoch
> time 1501545600) regardless of whether or not this BIP has reached its
> own signalling threshold. This BIP will cease to be active when segwit
> is locked-in.
>
> === Reference implementation ===
>
> <pre>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SPLITPROTECTION mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> THRESHOLD_LOCKED_IN &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
>
> // BIP148 mandatory segwit signalling.
> int64_t nMedianTimePast = pindex->GetMedianTimePast();
> if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
> (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
> (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
> // and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> </pre>
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. This deployment is also compatible with the
> existing BIP148 deployment. This BIP is compatible with BIP91 only if
> BIP91 activates before it and before BIP148. Miners will need to
> upgrade their nodes to support splitprotection otherwise they may
> build on top of an invalid block. While this bip is active users
> should either upgrade to splitprotection or wait for additional
> confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requirement for miners
> once activated, this ensures that miners are aware of new rules being
> enforced. This technique can be leveraged to lower the signalling
> threshold of a soft fork while it is in the process of being deployed
> in a backwards compatible way. We also use a BIP8 style timeout to
> ensure that this BIP is compatible with BIP148 and that BIP148
> compatible mandatory signalling activates regardless of miner
> signalling levels.
>
> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> deployment, this BIP can cause the existing "segwit" deployment to
> activate without needing to release a new deployment. As we approach
> BIP148 activation it may be desirable for a majority of miners to have
> a method that will ensure that there is no chain split.
>
> ==References==
>
> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
> Mailing list discussion]
> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
> P2SH flag day activation]
> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> Version 0 Witness Program]]
> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
>
> ==Copyright==
>
> This document is dual licensed as BSD 3-clause, and Creative Commons
> CC0 1.0 Universal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

2023-06-07 20:02:32 CEST

- reply

📅 Original date posted:2017-06-06
📝 Original message:This is a BIP8 style soft fork so mandatory signalling will be active
after Aug 1st regardless.
On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com> wrote:
> What is the probability that a 65% threshold is too low and can allow a
> "surprise miner attack", whereby miners are kept offline before the
> deadline, and brought online immediately after, creating potential havoc?
>
> (Nit: "simple majority" usually refers to >50%, I think, might cause
> confusion.)
>
> -Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Due to the proposed calendar(https://segwit2x.github.io/) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using BIP91 I would like to propose another
> option that miners can use to prevent a chain split ahead of the Aug
> 1st BIP148 activation date.
>
> The splitprotection soft fork is essentially BIP91 but using BIP8
> instead of BIP9 with a lower activation threshold and immediate
> mandatory signalling lock-in. This allows for a majority of miners to
> activate mandatory SegWit signalling and prevent a potential chain
> split ahead of BIP148 activation.
>
> This BIP allows for miners to respond to market forces quickly ahead
> of BIP148 activation by signalling for splitprotection. Any miners
> already running BIP148 should be encouraged to use splitprotection.
>
> <pre>
> BIP: splitprotection
> Layer: Consensus (soft fork)
> Title: User Activated Soft Fork Split Protection
> Author: James Hilliard <james.hilliard1 at gmail.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a coordination mechanism for a simple majority
> of miners to prevent a chain split ahead of BIP148 activation.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> The biggest risk of BIP148 is an extended chain split, this BIP
> provides a way for a simple majority of miners to eliminate that risk.
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower before BIP148 activation. Due to time constraints unless
> immediately deployed BIP91 will likely not be able to enforce
> mandatory signalling of segwit before the Aug 1st activation of
> BIP148. This BIP provides a method for rapid miner activation of
> SegWit mandatory signalling ahead of the BIP148 activation date. Since
> the primary goal of this BIP is to reduce the chance of an extended
> chain split as much as possible we activate using a simple miner
> majority of 65% over a 504 block interval rather than a higher
> percentage. This BIP also allows miners to signal their intention to
> run BIP148 in order to prevent a chain split.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required
> will be rejected.
>
> ==Deployment==
>
> This BIP will be deployed by "version bits" with a 65%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "splitprotecion" and using bit 2.
>
> This BIP starts immediately and is a BIP8 style soft fork since
> mandatory signalling will start on midnight August 1st 2017 (epoch
> time 1501545600) regardless of whether or not this BIP has reached its
> own signalling threshold. This BIP will cease to be active when segwit
> is locked-in.
>
> === Reference implementation ===
>
> <pre>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SPLITPROTECTION mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> THRESHOLD_LOCKED_IN &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
>
> // BIP148 mandatory segwit signalling.
> int64_t nMedianTimePast = pindex->GetMedianTimePast();
> if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
> (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
> (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
> // and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> </pre>
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. This deployment is also compatible with the
> existing BIP148 deployment. This BIP is compatible with BIP91 only if
> BIP91 activates before it and before BIP148. Miners will need to
> upgrade their nodes to support splitprotection otherwise they may
> build on top of an invalid block. While this bip is active users
> should either upgrade to splitprotection or wait for additional
> confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requirement for miners
> once activated, this ensures that miners are aware of new rules being
> enforced. This technique can be leveraged to lower the signalling
> threshold of a soft fork while it is in the process of being deployed
> in a backwards compatible way. We also use a BIP8 style timeout to
> ensure that this BIP is compatible with BIP148 and that BIP148
> compatible mandatory signalling activates regardless of miner
> signalling levels.
>
> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> deployment, this BIP can cause the existing "segwit" deployment to
> activate without needing to release a new deployment. As we approach
> BIP148 activation it may be desirable for a majority of miners to have
> a method that will ensure that there is no chain split.
>
> ==References==
>
> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
> Mailing list discussion]
> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
> P2SH flag day activation]
> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> Version 0 Witness Program]]
> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
>
> ==Copyright==
>
> This document is dual licensed as BSD 3-clause, and Creative Commons
> CC0 1.0 Universal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

2023-06-07 20:02:30 CEST

- reply

📅 Original date posted:2017-06-06
📝 Original message:You need a majority of miners enforcing BIP148 upon BIP148 activation
to prevent a split, not just a majority signalling segwit. This
provides a miner coordination mechanism for BIP148 mandatory
signalling enforcement.
On Tue, Jun 6, 2017 at 8:11 PM, Karl Johan Alm
<karljohan-alm at garage.co.jp> wrote:
> One thing about BIP148 activation that may be affected by this is the
> fact that segwit signalling non-BIP148 miners + BIP148 miners may hold
> majority hash power and prevent a chain split. With this SF, that will
> no longer be the case, right? Or am I completely confused on the
> subject?
>
> On Wed, Jun 7, 2017 at 9:56 AM, James Hilliard via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Due to the proposed calendar(https://segwit2x.github.io/) for the
>> SegWit2x agreement being too slow to activate SegWit mandatory
>> signalling ahead of BIP148 using BIP91 I would like to propose another
>> option that miners can use to prevent a chain split ahead of the Aug
>> 1st BIP148 activation date.
>>
>> The splitprotection soft fork is essentially BIP91 but using BIP8
>> instead of BIP9 with a lower activation threshold and immediate
>> mandatory signalling lock-in. This allows for a majority of miners to
>> activate mandatory SegWit signalling and prevent a potential chain
>> split ahead of BIP148 activation.
>>
>> This BIP allows for miners to respond to market forces quickly ahead
>> of BIP148 activation by signalling for splitprotection. Any miners
>> already running BIP148 should be encouraged to use splitprotection.
>>
>> <pre>
>> BIP: splitprotection
>> Layer: Consensus (soft fork)
>> Title: User Activated Soft Fork Split Protection
>> Author: James Hilliard <james.hilliard1 at gmail.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-3-Clause
>> CC0-1.0
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a coordination mechanism for a simple majority
>> of miners to prevent a chain split ahead of BIP148 activation.
>>
>> ==Definitions==
>>
>> "existing segwit deployment" refer to the BIP9 "segwit" deployment
>> using bit 1, between November 15th 2016 and November 15th 2017 to
>> activate BIP141, BIP143 and BIP147.
>>
>> ==Motivation==
>>
>> The biggest risk of BIP148 is an extended chain split, this BIP
>> provides a way for a simple majority of miners to eliminate that risk.
>>
>> This BIP provides a way for a simple majority of miners to coordinate
>> activation of the existing segwit deployment with less than 95%
>> hashpower before BIP148 activation. Due to time constraints unless
>> immediately deployed BIP91 will likely not be able to enforce
>> mandatory signalling of segwit before the Aug 1st activation of
>> BIP148. This BIP provides a method for rapid miner activation of
>> SegWit mandatory signalling ahead of the BIP148 activation date. Since
>> the primary goal of this BIP is to reduce the chance of an extended
>> chain split as much as possible we activate using a simple miner
>> majority of 65% over a 504 block interval rather than a higher
>> percentage. This BIP also allows miners to signal their intention to
>> run BIP148 in order to prevent a chain split.
>>
>> ==Specification==
>>
>> While this BIP is active, all blocks must set the nVersion header top
>> 3 bits to 001 together with bit field (1<<1) (according to the
>> existing segwit deployment). Blocks that do not signal as required
>> will be rejected.
>>
>> ==Deployment==
>>
>> This BIP will be deployed by "version bits" with a 65%(this can be
>> adjusted if desired) activation threshold BIP9 with the name
>> "splitprotecion" and using bit 2.
>>
>> This BIP starts immediately and is a BIP8 style soft fork since
>> mandatory signalling will start on midnight August 1st 2017 (epoch
>> time 1501545600) regardless of whether or not this BIP has reached its
>> own signalling threshold. This BIP will cease to be active when segwit
>> is locked-in.
>>
>> === Reference implementation ===
>>
>> <pre>
>> // Check if Segregated Witness is Locked In
>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> Consensus::Params& params)
>> {
>> LOCK(cs_main);
>> return (VersionBitsState(pindexPrev, params,
>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> THRESHOLD_LOCKED_IN);
>> }
>>
>> // SPLITPROTECTION mandatory segwit signalling.
>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
>> THRESHOLD_LOCKED_IN &&
>> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>> and is not active.
>> {
>> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>> VERSIONBITS_TOP_BITS;
>> bool fSegbit = (pindex->nVersion &
>> VersionBitsMask(chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> if (!(fVersionBits && fSegbit)) {
>> return state.DoS(0, error("ConnectBlock(): relayed block must
>> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>>
>> // BIP148 mandatory segwit signalling.
>> int64_t nMedianTimePast = pindex->GetMedianTimePast();
>> if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
>> (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
>> (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
>> // and is not active.
>> {
>> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>> VERSIONBITS_TOP_BITS;
>> bool fSegbit = (pindex->nVersion &
>> VersionBitsMask(chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> if (!(fVersionBits && fSegbit)) {
>> return state.DoS(0, error("ConnectBlock(): relayed block must
>> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>> </pre>
>>
>> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1
>> deployment scheduled between midnight November 15th, 2016 and midnight
>> November 15th, 2017. This deployment is also compatible with the
>> existing BIP148 deployment. This BIP is compatible with BIP91 only if
>> BIP91 activates before it and before BIP148. Miners will need to
>> upgrade their nodes to support splitprotection otherwise they may
>> build on top of an invalid block. While this bip is active users
>> should either upgrade to splitprotection or wait for additional
>> confirmations when accepting payments.
>>
>> ==Rationale==
>>
>> Historically we have used IsSuperMajority() to activate soft forks
>> such as BIP66 which has a mandatory signalling requirement for miners
>> once activated, this ensures that miners are aware of new rules being
>> enforced. This technique can be leveraged to lower the signalling
>> threshold of a soft fork while it is in the process of being deployed
>> in a backwards compatible way. We also use a BIP8 style timeout to
>> ensure that this BIP is compatible with BIP148 and that BIP148
>> compatible mandatory signalling activates regardless of miner
>> signalling levels.
>>
>> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
>> deployment, this BIP can cause the existing "segwit" deployment to
>> activate without needing to release a new deployment. As we approach
>> BIP148 activation it may be desirable for a majority of miners to have
>> a method that will ensure that there is no chain split.
>>
>> ==References==
>>
>> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
>> Mailing list discussion]
>> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
>> P2SH flag day activation]
>> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
>> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
>> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
>> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
>> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
>> Version 0 Witness Program]]
>> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
>> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
>> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
>> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
>>
>> ==Copyright==
>>
>> This document is dual licensed as BSD 3-clause, and Creative Commons
>> CC0 1.0 Universal.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:02:29 CEST

- reply

📅 Original date posted:2017-06-06
📝 Original message:Due to the proposed calendar(https://segwit2x.github.io/) for the
SegWit2x agreement being too slow to activate SegWit mandatory
signalling ahead of BIP148 using BIP91 I would like to propose another
option that miners can use to prevent a chain split ahead of the Aug
1st BIP148 activation date.
The splitprotection soft fork is essentially BIP91 but using BIP8
instead of BIP9 with a lower activation threshold and immediate
mandatory signalling lock-in. This allows for a majority of miners to
activate mandatory SegWit signalling and prevent a potential chain
split ahead of BIP148 activation.
This BIP allows for miners to respond to market forces quickly ahead
of BIP148 activation by signalling for splitprotection. Any miners
already running BIP148 should be encouraged to use splitprotection.
<pre>
BIP: splitprotection
Layer: Consensus (soft fork)
Title: User Activated Soft Fork Split Protection
Author: James Hilliard <james.hilliard1 at gmail.com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
</pre>
==Abstract==
This document specifies a coordination mechanism for a simple majority
of miners to prevent a chain split ahead of BIP148 activation.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
The biggest risk of BIP148 is an extended chain split, this BIP
provides a way for a simple majority of miners to eliminate that risk.
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower before BIP148 activation. Due to time constraints unless
immediately deployed BIP91 will likely not be able to enforce
mandatory signalling of segwit before the Aug 1st activation of
BIP148. This BIP provides a method for rapid miner activation of
SegWit mandatory signalling ahead of the BIP148 activation date. Since
the primary goal of this BIP is to reduce the chance of an extended
chain split as much as possible we activate using a simple miner
majority of 65% over a 504 block interval rather than a higher
percentage. This BIP also allows miners to signal their intention to
run BIP148 in order to prevent a chain split.
==Specification==
While this BIP is active, all blocks must set the nVersion header top
3 bits to 001 together with bit field (1<<1) (according to the
existing segwit deployment). Blocks that do not signal as required
will be rejected.
==Deployment==
This BIP will be deployed by "version bits" with a 65%(this can be
adjusted if desired) activation threshold BIP9 with the name
"splitprotecion" and using bit 2.
This BIP starts immediately and is a BIP8 style soft fork since
mandatory signalling will start on midnight August 1st 2017 (epoch
time 1501545600) regardless of whether or not this BIP has reached its
own signalling threshold. This BIP will cease to be active when segwit
is locked-in.
=== Reference implementation ===
<pre>
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SPLITPROTECTION mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
THRESHOLD_LOCKED_IN &&
!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
!IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}
// BIP148 mandatory segwit signalling.
int64_t nMedianTimePast = pindex->GetMedianTimePast();
if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
(nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
(!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
!IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
// and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}
</pre>
https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
==Backwards Compatibility==
This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. This deployment is also compatible with the
existing BIP148 deployment. This BIP is compatible with BIP91 only if
BIP91 activates before it and before BIP148. Miners will need to
upgrade their nodes to support splitprotection otherwise they may
build on top of an invalid block. While this bip is active users
should either upgrade to splitprotection or wait for additional
confirmations when accepting payments.
==Rationale==
Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way. We also use a BIP8 style timeout to
ensure that this BIP is compatible with BIP148 and that BIP148
compatible mandatory signalling activates regardless of miner
signalling levels.
By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment. As we approach
BIP148 activation it may be desirable for a majority of miners to have
a method that will ensure that there is no chain split.
==References==
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
Mailing list discussion]
*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
P2SH flag day activation]
*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
*[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
Version 0 Witness Program]]
*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons
CC0 1.0 Universal.

2023-06-07 20:01:17 CEST

- reply

📅 Original date posted:2017-05-18
📝 Original message:Locking the lower bits on the timestamp will likely break existing
hardware that relies on being able to roll ntime.
On Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Bitcoin Development Mailing List,
>
> I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with our established best practices for security vulnerabilities and suggest what I consider to be an approach closer matching established industry best practices.
>
>
> 1. Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.
>
>
> 2. General ASIC optimisation cannot be considered a Security Vulnerabilities.
>
> Quickly being able to check inputs is not a vulnerability. However, being able to craft inputs that are significantly easier to check than alternative inputs is a vulnerability.
>
>
> 3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.
>
> ‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be considered an exploit of the Bitcoin Proof-of-Work Function.
>
> For a more detailed look at ‘ASICBOOST’, please have a look at this excellent document by Jeremy Rubin:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> The Bitcoin Community should be able to track the progress of restoring the quality of the Bitcoin Proof-of-Work function to its original assumptions.
>
>
> 4. Work should be taken to prudently and swiftly restore Bitcoins Security Properties.
>
> I recommend the Bitcoin Community fix this vulnerability with expediency.
>
>
>
> Cameron.
>
> PS:
>
> With a soft-fork it probably is possible to completely fix this Proof-of-Work vulnerability.
>
> (Here is my working list of things to do):
>
> 1. Include extra data in the Coinbase Transaction, such as the Witness Root.
>
> 2. Lock the Version. (Use a space in the Coinbase Transaction for signalling future upgrades).
>
> 3. Lock the lower-bits on the Timestamp: Block timestamps only need ~1minute granularity.
>
> 4. Make a deterministic ordering of transaction chains within a block. (However, I believe this option is more difficult).
>
> Of course, if we have a hard-fork, we should consider the Proof-of-Work internal merkle structure directly.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:00:58 CEST

- reply

📅 Original date posted:2017-05-09
📝 Original message:Doing a second soft-fork from 50% to 75% sounds more difficult since
that's going from a more restrictive ruleset to less restrictive, you
might be able to hack around it but it wouldn't be a fully backwards
compatible change like going from 75% to 50% would be. 50% vs 75% does
affect max transactions/second in practice, the exact amount depends
on the real world usage of course though.
On Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks Johnson and Hampus for the clarifications.
> However, I would rather do the opposite: soft-fork to 50% now, and soft-fork
> again to 75% discount later if needed, because it doesn't affect the max
> transactions/second.
>
> Segwit as it is today should be activated. However if it is not before
> November, then for the next Segwit attempt I would choose a more
> conservative 50% discount.
>
>
>
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
>>
>>
>> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> >
>> > So it seems the 75% discount has been chosen with the idea that in the
>> > future the current transaction pattern will shift towards multisigs. This is
>> > not a bad idea, as it's the only direction Bitcoin can scale without a HF.
>> > But it's a bad idea if we end up doing, for example, a 2X blocksize
>> > increase HF in the future. In that case it's much better to use a 50%
>> > witness discount, and do not make scaling risky by making the worse case
>> > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>> >
>>
>> As we could change any parameter in a hardfork, I don’t think this has any
>> relation with the current BIP141 proposal. We could just use 75% in a
>> softfork, and change that to a different value (or completely redefine the
>> definition of weight) with a hardfork later.
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 20:00:57 CEST

- reply

📅 Original date posted:2017-05-09
📝 Original message:The discount is designed to reduce UTXO bloat primarily, witness spam
data would not make it into the UTXO set. The discount brings the fee
of a transaction more in line with the actual costs to the network for
the transaction. A miner spamming the network with 4MB witness blocks
would have very little impact on the UTXO size compared with 1MB
non-witness blocks. UTXO size is a bigger issue than blockchain size
since full nodes can't prune the UTXO set.
The discount of 75% for the SegWit softfork doesn't really have any
effect on future hard forks as it can always be adjusted as needed
later on as part of a HF.
On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This [1] article says the current discount prevents witness spam. Witness
> spam is free space in the witness part of the block that can be filled by
> miners to create bigger blocks with almost no cost for the benefit a cluster
> of miners with low latency, increasing centralization.
>
> The 75% discount does not prevent it, but on the contrary leaves a lot of
> extra witness space for spam.
>
> If the maximum block weight is set to 2.7M, each byte of non-witness block
> costs 1.7, and each byte of witness costs 1, then a normal filled block
> would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
> Mbyte block. The worst case would be the average case, and the transaction
> rate would be the maximum possible.
>
> The current 75% discount can only achieve more transactions per second if
> the type of transactions change. Therefore the current 75% discount only
> makes the block size worst case worse (4 Mbytes when it should be 2.7
> Mbytes).
>
> 80% of all inputs/outputs are P2PKH. The only way to make use of the extra
> witness
> space If most P2PKH transactions are replaced by multisigs (typically for
> LN).
>
> So it seems the 75% discount has been chosen with the idea that in the
> future the current transaction pattern will shift towards multisigs. This is
> not a bad idea, as it's the only direction Bitcoin can scale without a HF.
> But it's a bad idea if we end up doing, for example, a 2X blocksize increase
> HF in the future. In that case it's much better to use a 50% witness
> discount, and do not make scaling risky by making the worse case block size
> 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>
> I've uploaded the code here:
> https://github.com/SergioDemianLerner/SegwitStats
>
> [1]
> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>
>
> On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Sergio,
>>
>> I'm not sure what the data you present has to do with the discount. A 75%
>> discount prevents witness spam precisely because it is 75%, nothing more.
>> The current usage simply gives a guideline on how much capacity is gained
>> through a particular discount. With the data you show, it would imply that
>> those blocks, with SegWit used where possible, would result in blocks of
>> ~1.8MB.
>>
>>
>>
>> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> I have processed 1000 blocks starting from Block #461653.
>>>
>>> I computed several metrics, including the supposed size of witness data
>>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>>
>>> This takes into account that other types of transactions will not be
>>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>>> take into account that LN transactions may affect the current state,
>>> increasing the segwit/nosegwit ratio.
>>>
>>> Among a lot of information, I've got the following real world results...
>>>
>>> acMainChainSpace =352608924
>>> acSegwitSpace =599400403
>>> Ratio segwit/nosegwit=1.6999
>>>
>>> This implies that the 75% that discount is not the best option to prevent
>>> witness spam in a block of 4 MB, as stated in
>>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>>>
>>> The non-witness data weight factor should not be 4 but 2.35. The closest
>>> integer value is 2, which leads to a 50% witness discount.
>>>
>>> The Bitcoinj source code is available for anyone to review. I encourage
>>> anyone to re-compute this with another utility to cross-check. Maybe Antoine
>>> Le Calvez (p2sh.info) would like to double-check.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:58:59 CEST

- reply

📅 Original date posted:2017-04-04
📝 Original message:It is a consensus rule
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
> wrote:
>> Someone told me a while back that it would be more natural if we move the
>> nHeight from the coinbase script to the coinbase locktime. Have you
>> considered doing this?
>
> That change would not be a consensus change and thus free to make any day.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:54:50 CEST

- reply

📅 Original date posted:2016-12-11
📝 Original message:I think the main thing you're missing is that there will always be
transactions available to mine simply because demand for blockspace is
effectively unbounded as fees approach 0. Nodes generally have a
static mempool size and dynamic minrelaytxfee nowadays so as
transactions get mined lower fee transactions get accepted into the
mempool. An individual opting to not send a transaction would not make
the blocks smaller simply because there will always be other
transactions available(it would really only have an effect on the
transaction fees needed to get mined).
On Sun, Dec 11, 2016 at 3:40 PM, t. khan <teekhan42 at gmail.com> wrote:
>
> On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <james.hilliard1 at gmail.com>
> wrote:
>>
>> What's most likely to happen is miners will max out the blocks they
>> mine simply to try and get as many transaction fees as possible like
>> they are doing right now(there will be a backlog of transactions at
>> any block size). Having the block size double every year would likely
>> cause major problems and this proposal allows over a 7x increase it
>> seems.
>
>
> Block75 is not exponential scaling. It's true the max theoretical increase
> in the first year would be 7x, but the next year would be a max of 2x, and
> the next could only increase by 50% and so on.
>
> However, to reach the max in the first year: 1) ALL blocks would have to be
> 100% full and 2) transactions would have to increase at the same rate. We'd
> have to be doing 2.1 million transactions a day within a year to make that
> happen, and would therefore need blocks to be that big.
>
> Realistically, max block size will grow (and shrink) at a much slower rate
> ... even more so with SegWit.
>
>>
>> The main problem with this proposal I think is that users effectively
>>
>> have no way to stop the miners from increasing block size
>> continuously.
>
>
> Yes they could, simply by not sending transactions. Users don't care at all
> about block size. They just want their transactions to be fast and
> relatively cheap.
>
> -t.k.

2023-06-07 19:54:49 CEST

- reply

📅 Original date posted:2016-12-11
📝 Original message:What's most likely to happen is miners will max out the blocks they
mine simply to try and get as many transaction fees as possible like
they are doing right now(there will be a backlog of transactions at
any block size). Having the block size double every year would likely
cause major problems and this proposal allows over a 7x increase it
seems.
The main problem with this proposal I think is that users effectively
have no way to stop the miners from increasing block size
continuously.
On Sun, Dec 11, 2016 at 1:55 PM, t. khan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Sun, Dec 11, 2016 at 12:11 PM, s7r <s7r at sky-ip.org> wrote:
>>
>>
>> This is an incentive, if few miners agree to create a large conglomerate
>> that will ultimately control the network.
>>
>> You miss something obvious that makes this attack actually free of cost.
>> Nothing will "cost them more in transaction fees". A miner can create
>> thousands of transactions paying to himself, and not broadcast them to
>> the network, but hold them and include them in the blocks he mines. The
>> fees are collected by him because transactions are included in a block
>> that he mined and the left amount is in another wallet of the same
>> person. Repeat this continuously to fill blocks.
>
>
> No, that wasn't overlooked. Miners could indeed stuff their own blocks for
> free, but they can't stuff blocks mined by others for free.
>
> In the hypothetical scenario where there is a single mining pool which mines
> most (if not all) of the blocks, we would have much larger problems than
> their ability to raise the max block size gradually. Even if they were able
> to fill 100% of the blocks for an entire year, the max block size for that
> 2016 block period would be 7.25MB (not accounting for SegWit). After the
> whole year they would have made no extra profit vs doing nothing. And as
> soon as they stopped this scheme, block size would spring back to it's
> natural level.
>
> The good news is, this scenario has never happened and even when we've come
> remotely close (when ASICs first shipped), the situation was temporary. The
> odds of this happening in the future and persisting long enough to have any
> major effect with Block75 are very close to zero.
>
>>
>> Topology and bandwidth speed / hash rate of the network cannot be
>> controlled - if we make assumptions about these it might have terrible
>> consequences.
>>
>> Even if we take in consideration that bandwidth will only grow and disk
>> space will only cost less (which is not something we can safely assume,
>> by the way) the hard limit max. block size cannot grow to unlimited
>> value (even if the growth happens over time). There is also a validation
>> cost in time for each block, for the health of the network any node
>> should be able to download _and_ validate a block, before next block
>> gets mined.
>>
>> You said in another post that a permanent solution is preferred, rather
>> than kicking the can down the road. I fully agree, as well as many
>> others reading this list, but the permanent solution doesn't necessarily
>> have to be increasing the max block size dynamically.
>
>
> Increasing *and* decreasing max block size dynamically. Block75 is
> self-correcting, whereas any solution with hardcoded limits can't correct
> without human intervention and would rely on our ability to predict the
> future (which as you pointed out, we can't do). Therefore, any solution
> that's not dynamic cannot be permanent.
>
> Additionally, the frequent and gradual changes in max block size would allow
> us to see any consequences well in advance (years probably).
>
>>
>> If you think about it the other way around, dynamically growing the max
>> block size is also kicking the can down the road ... just without having
>> to touch it and get dust on the boot ;)
>
>
> Not having to touch it again = permanent solution. ;)
>
> It would be helpful if some others would run the numbers on how Block75
> would adjust the block size over time:
>
> new max block size = 1000kb + (average block size over last 2016 blocks -
> 750kb)
>
> -t.k.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:54:47 CEST

- reply

📅 Original date posted:2016-12-10
📝 Original message:Miners in general are naturally incentivized to always mine max size
blocks to maximize transaction fees simply because there is very
little marginal cost to including extra transactions(there will always
be a transaction backlog of some sort available to mine since demand
for block space is effectively unbounded as fees approach 0 and they
can even mine their own transactions without any fees). This proposal
would almost certainly cause runaway block size growth and encourage
much more miner centralization.
On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Miners 'gaming' the Block75 system -
> There is no financial incentive for miners to attempt to game the Block75
> system. Even if it were attempted and assuming the goal was to create bigger
> blocks, the maximum possible increase would be 25% over the previous block
> size. And, that size would only last for two weeks before readjusting down.
> It would cost them more in transaction fees to stuff the network than they
> could ever make up. To game the system, they'd have to game it forever with
> no possibility of profit.
>
> Blocks would get too big -
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, the
> incremental adjustments made by Block75 (especially in combination with
> SegWit) wouldn't break anyone's connection or result in significantly more
> orphaned blocks.
>
> The frequent and small adjustments made by Block75 have the added benefit of
> being more easily adapted to, both psychologically and technologically, with
> regards to miners/node operators.
>
> -t.k
>
> On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> t. khan via bitcoin-dev wrote:
>> > BIP Proposal - Managing Bitcoin’s block size the same way we do
>> > difficulty (aka Block75)
>> >
>> > The every two-week adjustment of difficulty has proven to be a
>> > reasonably effective and predictable way of managing how quickly blocks
>> > are mined. Bitcoin needs a reasonably effective and predictable way of
>> > managing the maximum block size.
>> >
>> > It’s clear at this point that human beings should not be involved in the
>> > determination of max block size, just as they’re not involved in
>> > deciding the difficulty.
>> >
>> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
>> > passing the decision to miners/pool operators, the max block size should
>> > be adjusted every two weeks (2016 blocks) using a system similar to how
>> > difficulty is calculated.
>> >
>> > Put another way: let’s stop thinking about what the max block size
>> > should be and start thinking about how full we want the average block to
>> > be regardless of size. Over the last year, we’ve had averages of 75% or
>> > higher, so aiming for 75% full seems reasonable, hence naming this
>> > concept ‘Block75’.
>> >
>> > The target capacity over 2016 blocks would be 75%. If the last 2016
>> > blocks are more than 75% full, add the difference to the max block size.
>> > Like this:
>> >
>> > MAX_BLOCK_BASE_SIZE = 1000000
>> > TARGET_CAPACITY = 750000
>> > AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
>> > TARGET_CAPACITY
>> >
>> > To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
>> >
>> > For example, if the last 2016 blocks are 85% full (average block is 850
>> > KB), add 10% to the max block size. The new max block size would be
>> > 1,100 KB until the next 2016 blocks are mined, then reset and
>> > recalculate. The 1,000,000 byte limit that exists currently would
>> > remain, but would effectively be the minimum max block size.
>> >
>> > Another two weeks goes by, the last 2016 blocks are again 85% full, but
>> > now that means they average 935 KB out of the 1,100 KB max block size.
>> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
>> > that to make the new max block size of 1,185 KB.
>> >
>> > Another two weeks passes. This time, the average block is 1,050 KB. The
>> > new max block size is calculated to 1,300 KB (as blocks were 105% full,
>> > minus the 75% capacity target, so 30% added to max block size).
>> >
>> > Repeat every 2016 blocks, forever.
>> >
>> > If Block75 had been applied at the difficulty adjustment on November
>> > 18th, the max block size would have been 1,080KB, as the average block
>> > during that period was 83% full, so 8% is added to the 1,000KB limit.
>> > The current size, after the December 2nd adjustment would be 1,150K.
>> >
>> > Block75 would allow the max block size to grow (or shrink) in response
>> > to transaction volume, and does so predictably, reasonably quickly, and
>> > in a method that prevents wild swings in block size or transaction fees.
>> > It attempts to keep blocks at 75% total capacity over each two week
>> > period, the same way difficulty tries to keep blocks mined every ten
>> > minutes. It also keeps blocks as small as possible.
>> >
>> > Thoughts?
>> >
>> > -t.k.
>> >
>>
>> I like the idea. It is good wrt growing the max. block size
>> automatically without human action, but the main problem (or question)
>> is not how to grow this number, it is what number can the network
>> handle, considering both miners and users. While disk space requirements
>> might not be a big problem, block propagation time is. The time required
>> for a block to propagate in the network (or at least to all the miners)
>> is directly dependent of its size. If blocks take too much time to
>> propagate in the network, the orphan rate will increase in unpredictable
>> ways. For example if the internet speed in China is worse than in
>> Europe, and miners in China have more than 50% of the hashing power,
>> blocks mined by European miners might get orphaned.
>>
>> The system as described can also be gamed, by filling the network with
>> transactions. Miners have the monetary interest to include as many
>> transactions as possible in a block in order to collect the fees.
>> Regardless how you think about it, there has to be a maximum block size
>> that the network will allow as a consensus rule. Increasing it
>> dynamically based on transaction volume will reach a point where the
>> number got big enough that it broke things. Bitcoin, because its
>> fundamental design, can scale by using offchain solutions.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>