Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
If it is to be uncontroversial and everybody will upgrade, there's no fear of a "veto power" and there's no good reason not to wait for 95% block version signaling for deployment coordination, ideally using bip9. But that's for chosing the exact block where to start. The grace period to give time to all users to upgrade should be before and not after miner's final confirmation: that simplifies and accelerates things. Assuming we chose a grace period that is really adequate, nearly 100% of miners will have likely upgraded long before everyone (since miners are a subset of "everyone"). If that is not the case and miners happen to be the latest to upgrade, using bip9 after the grace period (aka starting median-time/height) will make sure the hardfork doesn't get activated without 95% of the miners having upgraded. 28 days seems extremely short (specially if the grace period comes first), some people have suggested one year for simple hardforks like this one. On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev wrote: > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote: >> Blog post on a couple of the constants chosen: >> http://gavinandresen.ninja/seventyfive-twentyeight > > Can you put this in the BIP's Rationale section (which appears to be mis-named > "Discussion" in the current draft)? > >> Signature operations in un-executed branches of a Script are not counted >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top >> of the execution stack, it is counted as one signature operation. If it is >> satisfied by the public key nearest the bottom of the execution stack, it >> is counted as twenty signature operations. Signature operations involving >> invalidly encoded signatures or public keys are not counted towards the >> limit > > These seem like they will break static analysis entirely. That was a noted > reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would > it make sense to require scripts to commit to the total accurate-sigop count > to fix this? > >> The amount of data hashed to compute signature hashes is limited to >> 1,300,000,000 bytes per block. > > The rationale for this wasn't in your blog post. I assume it's based on the > current theoretical max at 1 MB blocks? Even a high-end PC would probably take > 40-80 seconds just for the hashing, however - maybe a lower limit would be > best? > >> Miners express their support for this BIP by ... > > But miners don't get to decide hardforks. How does the economy express their > support for it? What happens if miners trigger it without consent from the > economy? > > If you are intent on using the version bits to trigger the hardfork, I suggest > rephrasing this such that miners should only enable the bit when they have > independently confirmed economic support (this means implementations need a > config option that defaults to off). > >> SPV (simple payment validation) wallets are compatible with this change. > > Would prefer if this is corrected to "Light clients" or something. Actual SPV > wallets do not exist at this time, and would not be compatible with a > hardfork. > >> In the short term, an increase is needed to continue the current economic >> policies with regards to fees and block space, matching market expectations >> and preventing market disruption. > > IMO this sentence is the most controversial part of your draft, and it > wouldn't suffer a loss to remove it (or at least make it subjective). > > I would also prefer to see any hardfork: > > 1. Address at least the simple tasks on the hardfork wishlist (eg, enable some >disabled opcodes; fix P2SH for N-of->15 multisig; etc). > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely >insecure. > > Luke > ___ > 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] BIP proposal: Increase block size limit to 2 megabytes
On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote: > Blog post on a couple of the constants chosen: > http://gavinandresen.ninja/seventyfive-twentyeight Can you put this in the BIP's Rationale section (which appears to be mis-named "Discussion" in the current draft)? > Signature operations in un-executed branches of a Script are not counted > OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a > 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top > of the execution stack, it is counted as one signature operation. If it is > satisfied by the public key nearest the bottom of the execution stack, it > is counted as twenty signature operations. Signature operations involving > invalidly encoded signatures or public keys are not counted towards the > limit These seem like they will break static analysis entirely. That was a noted reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would it make sense to require scripts to commit to the total accurate-sigop count to fix this? > The amount of data hashed to compute signature hashes is limited to > 1,300,000,000 bytes per block. The rationale for this wasn't in your blog post. I assume it's based on the current theoretical max at 1 MB blocks? Even a high-end PC would probably take 40-80 seconds just for the hashing, however - maybe a lower limit would be best? > Miners express their support for this BIP by ... But miners don't get to decide hardforks. How does the economy express their support for it? What happens if miners trigger it without consent from the economy? If you are intent on using the version bits to trigger the hardfork, I suggest rephrasing this such that miners should only enable the bit when they have independently confirmed economic support (this means implementations need a config option that defaults to off). > SPV (simple payment validation) wallets are compatible with this change. Would prefer if this is corrected to "Light clients" or something. Actual SPV wallets do not exist at this time, and would not be compatible with a hardfork. > In the short term, an increase is needed to continue the current economic > policies with regards to fees and block space, matching market expectations > and preventing market disruption. IMO this sentence is the most controversial part of your draft, and it wouldn't suffer a loss to remove it (or at least make it subjective). I would also prefer to see any hardfork: 1. Address at least the simple tasks on the hardfork wishlist (eg, enable some disabled opcodes; fix P2SH for N-of->15 multisig; etc). 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely insecure. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Hard fork opt-in mechanism for SPV nodes
Soft-hardforks have the same behaviour for both SPV and full nodes. I don't see the point in making this SPV-only "middle layer"... On Friday, February 05, 2016 6:40:57 PM jl2012 via bitcoin-dev wrote: > BIP draft: Hard fork opt-in mechanism for SPV nodes: > https://github.com/bitcoin/bips/pull/320 > > This is a supplement, instead of a replacement, of the hardfork bit BIP: > https://github.com/bitcoin/bips/pull/317 > > They solves different problems: > > The hardfork bit tells full and SPV that a planned hardfork (instead of > a softfork) has happened. > > This BIP makes sure SPV nodes won't lose any money in a hardfork, even > if they do not check the hardfork bit. > > - > > BIP: ? > Title: Hard fork opt-in mechanism for SPV nodes > Author: Johnson Lau > Status: Draft > Type: Standard Track > Created: 2016-02-05 > > ABSTRACT > > This document specifies a new algorithm for the transaction commitment > in block header, to ensure that SPV nodes will not automatically follow > a planned hard fork without explicit opt-in consent. > > [1]MOTIVATION > > A hard fork in Bitcoin is a consensus rule change where previously > invalid blocks become valid. For the operators of fully validating > nodes, migration to the new fork requires conscious actions. However, > this may not be true for SPV node, as many consensus rules are > transparent to them. SPV nodes may follow the chain with most > proof-of-work, even if the operators do not agree with the economical or > ideological properties of the chain. > > By specifying a new algorithm for the transaction commitment in block > header, migration to the new fork requires explicit opt-in consent for > SPV nodes. It is expected that this proposal will be implemented with > other backward-incompatible consensus rule changes at the same time. > > [2]SPECIFICATION > > The calculation of Merkle root remains unchanged. Instead of directly > committing the Merkle root to the header, we commit > > Double-SHA256(zero|merkle_root|zero) > > where zero is 0x with 32 bytes. > > [3]RATIONALE > > Since the header structure is not changed, non-upgraded SPV nodes will > still be able to verify the proof-of-work of the new chain, and they > will follow the new chain if it has most proof-of-work. However, they > will not be able to the accept any incoming transactions on the new > chain since they cannot verify them with the new commitment format. At > the same time, SPV nodes will not accept any new transactions on the old > chain, as they find it has less proof-of-work. Effectively, SPV nodes > stop accepting any transactions, until their operators take further > actions. > > Zero-padding is applied before and after the merkle_root, so it is not > possible to circumvent the rule change with any current implementations, > even for faulty ones. > > A future hard fork should change the padding value to stop non-upgraded > SPV nodes from processing new transactions. > > Hard forks may sometimes be totally uncontroversial and make barely > noticeable change (BIP50 [4], for example). In such cases, changing the > padding value may not be needed as it may cause unnecessary disruption. > The risk and benefit should be evaluated case-by-case. > > [5]COMPATIBILITY > > As a mechanism to indicate hard fork deployment, this BIP breaks > backward compatibility intentionally. However, without further changes > in the block header format, non-upgraded full nodes and SPV nodes could > still verify the proof-of-work of upgraded blocks. > > INTERACTION WITH FRAUD PROOF SYSTEM A fraud proof system is full nodes > that will generate compact proofs to testify invalid blocks on the > blockchain, verifiable by SPV nodes. Hard forks without any malicious > intention may also be considered as a "fraud" among non-upgraded nodes. > This may not be desirable, as the SPV node may accept devalued tokens on > the old chain with less proof-of-work. With this BIP, non-upgraded SPV > nodes will always believe the new chain is valid (since they cannot > verify any fraud proof), while cannot be defrauded as they will not see > any incoming transactions. > > [6]COPYRIGHT > > This document is placed in the public domain. > > Links: > -- > [1] > https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#motivat > ion [2] > https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#specifi > cation [3] > https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#rationa > le [4] https://github.com/jl2012/bips/blob/merkleroot/bip-0050.mediawiki > [5] > https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#compati > bility [6] > https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#copyrig > ht ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This has been reviewed by merchants, miners and exchanges for a couple of > weeks, and has been implemented and tested as part of the Bitcoin Classic > and Bitcoin XT implementations. > > Constructive feedback welcome; argument about whether or not it is a good > idea to roll out a hard fork now will be unproductive, so I vote we don't > go there. > > Draft BIP: > https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki > > Summary: > Increase block size limit to 2,000,000 bytes. > After 75% hashpower support then 28-day grace period. > With accurate sigop counting, but existing sigop limit (20,000) > And a new, high limit on signature hashing > > Blog post walking through the code: > http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork > > Blog post on a couple of the constants chosen: > http://gavinandresen.ninja/seventyfive-twentyeight > It's great to finally see a BIP, although seems strange to ask for feedback after releasing binaries. In any case, the issue isn't about "whether or not it is a good idea to roll out a hard fork", the question has always been about how to do safe hard fork deployment and what the technological requirements are for doing so. Your BIP/blogs do not actually address any of this. 75% miner signalling with a 28 day flag day thereafter gives virtually no time for the entire ecosystem to migrate and is widely considered unsafe. It's plainly obvious that an entire ecosystem of 5000 full nodes cannot be prepared in a month. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
"We can look at the adoption of the last major Bitcoin core release to guess how long it might take people to upgrade. 0.11.0 was released on 12 July, 2015. Twenty eight days later, about 38% of full nodes were running that release. Three months later, about 50% of the network was running that release, and six months later about 66% of the network was running some flavor of 0.11." On what grounds do you think it is reasonable to assume that this update will roll out 6x faster than previous data suggested, as oppose to your own observation of 66% adoption in 6 month. or do you believe 38% node upgrade-coverage ( in 28 days ) on the network for a hard fork is good enough? There are no harm in choosing a longer grace period but picking one short as 28 days you risk on alienating the nodes who do not upgrade with the aggressive upgrade timeline you proposed. On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This has been reviewed by merchants, miners and exchanges for a couple of > weeks, and has been implemented and tested as part of the Bitcoin Classic > and Bitcoin XT implementations. > > Constructive feedback welcome; argument about whether or not it is a good > idea to roll out a hard fork now will be unproductive, so I vote we don't > go there. > > Draft BIP: > https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki > > Summary: > Increase block size limit to 2,000,000 bytes. > After 75% hashpower support then 28-day grace period. > With accurate sigop counting, but existing sigop limit (20,000) > And a new, high limit on signature hashing > > Blog post walking through the code: > http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork > > Blog post on a couple of the constants chosen: > http://gavinandresen.ninja/seventyfive-twentyeight > > -- > -- > Gavin Andresen > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- *Yifu Guo* *"Life is an everlasting self-improvement."* ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
This has been reviewed by merchants, miners and exchanges for a couple of weeks, and has been implemented and tested as part of the Bitcoin Classic and Bitcoin XT implementations. Constructive feedback welcome; argument about whether or not it is a good idea to roll out a hard fork now will be unproductive, so I vote we don't go there. Draft BIP: https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki Summary: Increase block size limit to 2,000,000 bytes. After 75% hashpower support then 28-day grace period. With accurate sigop counting, but existing sigop limit (20,000) And a new, high limit on signature hashing Blog post walking through the code: http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork Blog post on a couple of the constants chosen: http://gavinandresen.ninja/seventyfive-twentyeight -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP draft: Hard fork opt-in mechanism for SPV nodes
BIP draft: Hard fork opt-in mechanism for SPV nodes: https://github.com/bitcoin/bips/pull/320 This is a supplement, instead of a replacement, of the hardfork bit BIP: https://github.com/bitcoin/bips/pull/317 They solves different problems: The hardfork bit tells full and SPV that a planned hardfork (instead of a softfork) has happened. This BIP makes sure SPV nodes won't lose any money in a hardfork, even if they do not check the hardfork bit. - BIP: ? Title: Hard fork opt-in mechanism for SPV nodes Author: Johnson Lau Status: Draft Type: Standard Track Created: 2016-02-05 ABSTRACT This document specifies a new algorithm for the transaction commitment in block header, to ensure that SPV nodes will not automatically follow a planned hard fork without explicit opt-in consent. [1]MOTIVATION A hard fork in Bitcoin is a consensus rule change where previously invalid blocks become valid. For the operators of fully validating nodes, migration to the new fork requires conscious actions. However, this may not be true for SPV node, as many consensus rules are transparent to them. SPV nodes may follow the chain with most proof-of-work, even if the operators do not agree with the economical or ideological properties of the chain. By specifying a new algorithm for the transaction commitment in block header, migration to the new fork requires explicit opt-in consent for SPV nodes. It is expected that this proposal will be implemented with other backward-incompatible consensus rule changes at the same time. [2]SPECIFICATION The calculation of Merkle root remains unchanged. Instead of directly committing the Merkle root to the header, we commit Double-SHA256(zero|merkle_root|zero) where zero is 0x with 32 bytes. [3]RATIONALE Since the header structure is not changed, non-upgraded SPV nodes will still be able to verify the proof-of-work of the new chain, and they will follow the new chain if it has most proof-of-work. However, they will not be able to the accept any incoming transactions on the new chain since they cannot verify them with the new commitment format. At the same time, SPV nodes will not accept any new transactions on the old chain, as they find it has less proof-of-work. Effectively, SPV nodes stop accepting any transactions, until their operators take further actions. Zero-padding is applied before and after the merkle_root, so it is not possible to circumvent the rule change with any current implementations, even for faulty ones. A future hard fork should change the padding value to stop non-upgraded SPV nodes from processing new transactions. Hard forks may sometimes be totally uncontroversial and make barely noticeable change (BIP50 [4], for example). In such cases, changing the padding value may not be needed as it may cause unnecessary disruption. The risk and benefit should be evaluated case-by-case. [5]COMPATIBILITY As a mechanism to indicate hard fork deployment, this BIP breaks backward compatibility intentionally. However, without further changes in the block header format, non-upgraded full nodes and SPV nodes could still verify the proof-of-work of upgraded blocks. INTERACTION WITH FRAUD PROOF SYSTEM A fraud proof system is full nodes that will generate compact proofs to testify invalid blocks on the blockchain, verifiable by SPV nodes. Hard forks without any malicious intention may also be considered as a "fraud" among non-upgraded nodes. This may not be desirable, as the SPV node may accept devalued tokens on the old chain with less proof-of-work. With this BIP, non-upgraded SPV nodes will always believe the new chain is valid (since they cannot verify any fraud proof), while cannot be defrauded as they will not see any incoming transactions. [6]COPYRIGHT This document is placed in the public domain. Links: -- [1] https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#motivation [2] https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#specification [3] https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#rationale [4] https://github.com/jl2012/bips/blob/merkleroot/bip-0050.mediawiki [5] https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#compatibility [6] https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#copyright___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 3 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Binaries for bitcoin Core version 0.12.0rc3 are available from: https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ Source code can be found on github under the signed tag https://github.com/bitcoin/bitcoin/tree/v0.12.0rc3 This is a release candidate for a new major version release, bringing new features, bug fixes, as well as other improvements. Preliminary release notes for the release can be found here: https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md Release candidates are test versions for releases. When no critical problems are found, this release candidate will be tagged as 0.12.0. Diff since rc2: - - #7440 `c76bfff` Rename permitrbf to mempoolreplacement and provide minimal string-list forward compatibility - - #7415 `cb83beb` net: Hardcoded seeds update January 2016 - - #7438 `e2d9a58` Do not absolutely protect local peers; decide group ties based on time - - #7439 `86755bc` Add whitelistforcerelay to control forced relaying. [#7099 redux] - - #7424 `aa26ee0` Add security/export checks to gitian and fix current failures - - #7384 `294f432` [qt] Peertable: Increase SUBVERSION_COLUMN_WIDTH Also, a new certificate was used to sign the Windows installer, which should solve Win7 compatibility issues. Thanks to the gitian builders for keeping up so quickly, thanks to them there are executables so quickly after tagging. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWtIe6AAoJEHSBCwEjRsmmuX0IAJP7JJ4OozZZ5psY7QF35ouV E0Vxws470pFyn+iFvz1OwLbeSyhIiLvR1xHZCrFkLbt5vrolJGILQb5xWaFfqDVv uXIPDzbQ+mJ/cPr2BXWrkjkVC33TBuwiLGethDDb4xlQhSki79EvZqbTkhIz7HxX jrW8d+zUq+2pOilhqDyZGlzCRhQOZI6W+TFwo4jEunZN+m1BSD2/vhVxIZQzP6jf Vt6xw23SFbTH+b9dY3Skho/A+gdXSitVpYmDttbOlcIX4AQ7lUmsaqFeaV4z92d+ YqipqLiNkGqXdEYFikyQgM24J4fYm4htZhTBg5y5W8tsIWO6z36tUXVBxmqq6A0= =mevA -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hardfork bit BIP
On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote: > > ABSTRACT > > > > This document specifies a proposed change to the semantics of the sign > > bit of the "version" field in Bitcoin block headers, as a mechanism to > > indicate a hardfork is deployed. > > Disagree with treating the "version" field as a number, in BIP 9 or this BIP > which reinterpret it as a bit vector. I don't interpret this as "treating version bits as a number" it is just being explained which bit we're talking about. Could you propose some concrete rephrasing instead of leaving the task of somehow solving this vague and subtle concern to the author? > > FLAG BLOCK Any planned hardfork must have one and only one flag block > > which is the "point of no return". To ensure monotonicity, flag block > > should be determined by block height, or as the first block with > > GetMedianTimePast() greater than a threshold. Other mechanisms could be > > difficult for SPV nodes to follow. The height/time threshold could be a > > predetermined value or relative to other events (e.g. 1 blocks / 100 > > days after 95% of miner support). The exact mechanism is out of the > > scope of this BIP. No matter what mechanism is used, the threshold is > > consensus critical. It must be publicly verifiable with only blockchain > > data, and preferably SPV-friendly (i.e. verifiable with block headers > > only, without downloading any transaction). > > With the current codebase, it is significantly easier to trigger on the block > timestamp rather than its height or median-time-past. Using either of the > latter would require refactoring of CBlockIndex. As a hard-fork, even if the > rules are ineffective for a few blocks following the forking point, using the > hardfork version bit in this BIP would still ensure a clean break. While I > agree that median-time-past and height are superior methods that ought to be > used for hardforks, an emergency hardfork may need to avoid them for > simplicity, and I don't think they need to be mandated as such in this BIP. I very much disagree with "significant" and in any case it depends on the hardfork: the changes required can still be quite minimal in all cases and it should never be a problem, even for emergency hardforks. In emergency, we could for example just a new global (we have many already anyway), although activeChain.tip () is already there and one can simply get the last height or median time from there. > > VERSION BITS This proposal is also compatible with the BIP9. The version > > bits mechanism could be employed to measure miner support towards a > > hardfork proposal, and to determine the height or time threshold of the > > flag block. Also, miners of the flag block may still cast votes for > > other concurrent softfork or hardfork proposals as normal. > > Rather not imply BIP 9 should be used for hardforks, or that miners have any > voice in the decision. This is already a serious misconception. This is consistent with bip99, which recommends bip9 for deploying uncontroversial hardforks. > > POINT OF NO RETURN After the flag block is generated, a miner may > > support either the original rules or the new rules, but not both. It is > > not possible for miners in one fork to attack or overtake the other fork > > without giving up the mining reward of their preferred fork. > > This is not actually desirable, and would suggest a possible reason *not* to > comply with this BIP. A legitimate hardfork would never have two continued > sets of rules for miners to choose from. Controversial hardforks (as defined bip9) always have the potential to create two chains that survive for unbounded amounts of time (maybe forever) as discussed in one of the few threads of the bitcoin discuss mailing list. Of course, BIP99 cannot say anything general about the "legitimacy" of all controversial hardforks since ASIC-reset hardforks, for example, are controversial hardforks by definition in the context of bip99 (and the definitions in bip99 seem to apply to this bip). BIP99 can only warn about the dangers and risks of controversial hardforks but at some point (let's hope never) a controversial hardfork may be required to save the system from some evil (say, evil miners blacklisting via softforking out the miners that don't blacklist or something) and that controversial hardfork would be legitimate (at least to the eyes of some). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hardfork bit BIP
Concept ACK. I've been talking about adding this to BIP99 since before scaling bitcoin Hong Kong, so it will be nice to have a BIP to just point to. Also I hadn't thought about concurrent deployment of 2 hardforks, nice. On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the worry is full nodes that are not upgraded, then a block with a negative version number will, indeed, fork them off the the chain, in exactly the same way a block with new hard-forking consensus rules would. And with the same consequences (if there is any hashpower not paying attention, then a worthless minority chain might continue on with the old rules). Additionally, a warning or special error could be thrown when a block is rejected due to the hardfork bit being activated. > I think a much better idea than this proposed BIP would be a BIP that recommends that SPV clients to pay attention to block version numbers in the headers that they download, and warn if there is a soft OR hard fork that they don't know about. Although I agree this PR should include such warning/error recommendations, SPV nodes can't tell whether a change is a hardfork or a softfork just by looking at the version bits, even in the case of uncontroversial hardforks deployed with bip9 as recommended by bip99. For controversial hardforks where bip9 should NOT be used for deployment, setting the hardfork bit is even more important. > It is also a very good idea for SPV clients to pay attention to timestamps in the block headers that the receive, and to warn if blocks were generated either much slower or faster than statistically likely. Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in general. This seems out of the scope of this PR. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
