* [bitcoin-dev] [BIP Proposal] Buried Deployments @ 2016-11-14 18:17 Suhas Daftuar 2016-11-14 18:47 ` Eric Voskuil 0 siblings, 1 reply; 24+ messages in thread From: Suhas Daftuar @ 2016-11-14 18:17 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 788 bytes --] Hi, Recently Bitcoin Core merged a simplification to the consensus rules surrounding deployment of BIPs 34, 66, and 65 ( https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a minor one, I thought it was worth documenting the rationale in a BIP for posterity. Here's the abstract: Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification and optimization) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. The full draft can be found here: https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki [-- Attachment #2: Type: text/html, Size: 1190 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-14 18:17 [bitcoin-dev] [BIP Proposal] Buried Deployments Suhas Daftuar @ 2016-11-14 18:47 ` Eric Voskuil 2016-11-15 14:42 ` Suhas Daftuar ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Eric Voskuil @ 2016-11-14 18:47 UTC (permalink / raw) To: Suhas Daftuar, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1459 bytes --] NACK Horrible precedent (hardcoding rule changes based on the assumption that large forks indicate a catastrophic failure), extremely poor process (already shipped, now the discussion), and not even a material performance optimization (the checks are avoidable once activated until a sufficiently deep reorg deactivates them). e > On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi, > > Recently Bitcoin Core merged a simplification to the consensus rules surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a minor one, I thought it was worth documenting the rationale in a BIP for posterity. > > Here's the abstract: > > Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification and optimization) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. > > The full draft can be found here: > > https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 2371 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-14 18:47 ` Eric Voskuil @ 2016-11-15 14:42 ` Suhas Daftuar 2016-11-15 17:45 ` Btc Drak 2016-11-16 14:38 ` Tom Zander 2 siblings, 0 replies; 24+ messages in thread From: Suhas Daftuar @ 2016-11-15 14:42 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1867 bytes --] Just want to clarify two points: This change has not yet appeared in any released software (but I assume it will be in the next release, 0.14.0). I agree that the performance optimization is not the point of this change; I can modify the BIP draft to de-emphasize that further (perhaps remove mention of it entirely). On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <eric@voskuil•org> wrote: > NACK > > Horrible precedent (hardcoding rule changes based on the assumption that > large forks indicate a catastrophic failure), extremely poor process > (already shipped, now the discussion), and not even a material performance > optimization (the checks are avoidable once activated until a sufficiently > deep reorg deactivates them). > > e > > On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi, > > Recently Bitcoin Core merged a simplification to the consensus rules > surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/ > bitcoin/pull/8391), and though the change is a minor one, I thought it > was worth documenting the rationale in a BIP for posterity. > > Here's the abstract: > > Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner > signaling in block version numbers. Now that the chain has long since > passed the blocks at which those consensus rules have triggered, we can (as > a simplification and optimization) replace the trigger mechanism by caching > the block heights at which those consensus rules became enforced. > > The full draft can be found here: > > https://github.com/sdaftuar/bips/blob/buried-deployments/ > bip-buried-deployments.mediawiki > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3182 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-14 18:47 ` Eric Voskuil 2016-11-15 14:42 ` Suhas Daftuar @ 2016-11-15 17:45 ` Btc Drak 2016-11-15 22:42 ` Eric Voskuil 2016-11-16 14:38 ` Tom Zander 2 siblings, 1 reply; 24+ messages in thread From: Btc Drak @ 2016-11-15 17:45 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion I think this is already covered in the BIP text:- "As of November 2016, the most recent of these changes (BIP 65, enforced since December 2015) has nearly 50,000 blocks built on top of it. The occurrence of such a reorg that would cause the activating block to be disconnected would raise fundamental concerns about the security assumptions of Bitcoin, a far bigger issue than any non-backwards compatible change. So while this proposal could theoretically result in a consensus split, it is extremely unlikely, and in particular any such circumstances would be sufficiently damaging to the Bitcoin network to dwarf any concerns about the effects of this proposed change." On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > NACK > > Horrible precedent (hardcoding rule changes based on the assumption that > large forks indicate a catastrophic failure), extremely poor process > (already shipped, now the discussion), and not even a material performance > optimization (the checks are avoidable once activated until a sufficiently > deep reorg deactivates them). > > e > > On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi, > > Recently Bitcoin Core merged a simplification to the consensus rules > surrounding deployment of BIPs 34, 66, and 65 > (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a > minor one, I thought it was worth documenting the rationale in a BIP for > posterity. > > Here's the abstract: > > Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner > signaling in block version numbers. Now that the chain has long since passed > the blocks at which those consensus rules have triggered, we can (as a > simplification and optimization) replace the trigger mechanism by caching > the block heights at which those consensus rules became enforced. > > The full draft can be found here: > > https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki > > _______________________________________________ > 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 > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-15 17:45 ` Btc Drak @ 2016-11-15 22:42 ` Eric Voskuil 2016-11-16 13:29 ` Jameson Lopp 0 siblings, 1 reply; 24+ messages in thread From: Eric Voskuil @ 2016-11-15 22:42 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Protocol Discussion Actually this does nothing to provide justification for this consensus rule change. It is just an attempt to deflect criticism from the fact that it is such a change. e > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail•com> wrote: > > I think this is already covered in the BIP text:- > > "As of November 2016, the most recent of these changes (BIP 65, > enforced since December 2015) has nearly 50,000 blocks built on top of > it. The occurrence of such a reorg that would cause the activating > block to be disconnected would raise fundamental concerns about the > security assumptions of Bitcoin, a far bigger issue than any > non-backwards compatible change. > > So while this proposal could theoretically result in a consensus > split, it is extremely unlikely, and in particular any such > circumstances would be sufficiently damaging to the Bitcoin network to > dwarf any concerns about the effects of this proposed change." > > > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> NACK >> >> Horrible precedent (hardcoding rule changes based on the assumption that >> large forks indicate a catastrophic failure), extremely poor process >> (already shipped, now the discussion), and not even a material performance >> optimization (the checks are avoidable once activated until a sufficiently >> deep reorg deactivates them). >> >> e >> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> Hi, >> >> Recently Bitcoin Core merged a simplification to the consensus rules >> surrounding deployment of BIPs 34, 66, and 65 >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a >> minor one, I thought it was worth documenting the rationale in a BIP for >> posterity. >> >> Here's the abstract: >> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner >> signaling in block version numbers. Now that the chain has long since passed >> the blocks at which those consensus rules have triggered, we can (as a >> simplification and optimization) replace the trigger mechanism by caching >> the block heights at which those consensus rules became enforced. >> >> The full draft can be found here: >> >> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki >> >> _______________________________________________ >> 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 >> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-15 22:42 ` Eric Voskuil @ 2016-11-16 13:29 ` Jameson Lopp 2016-11-16 13:58 ` Eric Voskuil 0 siblings, 1 reply; 24+ messages in thread From: Jameson Lopp @ 2016-11-16 13:29 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3686 bytes --] Since "buried deployments" are specifically in reference to historical consensus changes, I think the question is more one of human consensus than machine consensus. Is there any disagreement amongst Bitcoin users that BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66 activated at block 363725? Somehow I doubt it. It seems to me that this change is merely cementing into place a few attributes of the blockchain's history that are not in dispute. - Jameson On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Actually this does nothing to provide justification for this consensus > rule change. It is just an attempt to deflect criticism from the fact that > it is such a change. > > e > > > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail•com> wrote: > > > > I think this is already covered in the BIP text:- > > > > "As of November 2016, the most recent of these changes (BIP 65, > > enforced since December 2015) has nearly 50,000 blocks built on top of > > it. The occurrence of such a reorg that would cause the activating > > block to be disconnected would raise fundamental concerns about the > > security assumptions of Bitcoin, a far bigger issue than any > > non-backwards compatible change. > > > > So while this proposal could theoretically result in a consensus > > split, it is extremely unlikely, and in particular any such > > circumstances would be sufficiently damaging to the Bitcoin network to > > dwarf any concerns about the effects of this proposed change." > > > > > > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> NACK > >> > >> Horrible precedent (hardcoding rule changes based on the assumption that > >> large forks indicate a catastrophic failure), extremely poor process > >> (already shipped, now the discussion), and not even a material > performance > >> optimization (the checks are avoidable once activated until a > sufficiently > >> deep reorg deactivates them). > >> > >> e > >> > >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev > >> <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> > >> Hi, > >> > >> Recently Bitcoin Core merged a simplification to the consensus rules > >> surrounding deployment of BIPs 34, 66, and 65 > >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change > is a > >> minor one, I thought it was worth documenting the rationale in a BIP for > >> posterity. > >> > >> Here's the abstract: > >> > >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner > >> signaling in block version numbers. Now that the chain has long since > passed > >> the blocks at which those consensus rules have triggered, we can (as a > >> simplification and optimization) replace the trigger mechanism by > caching > >> the block heights at which those consensus rules became enforced. > >> > >> The full draft can be found here: > >> > >> https://github.com/sdaftuar/bips/blob/buried-deployments/ > bip-buried-deployments.mediawiki > >> > >> _______________________________________________ > >> 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: 6020 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 13:29 ` Jameson Lopp @ 2016-11-16 13:58 ` Eric Voskuil 2016-11-16 14:18 ` Tier Nolan ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Eric Voskuil @ 2016-11-16 13:58 UTC (permalink / raw) To: Jameson Lopp; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4661 bytes --] This sort of statement represents one consequence of the aforementioned bad precedent. Are checkpoints good now? Are hard forks okay now? What is the maximum depth of a reorg allowed by this non-machine consensus? Shouldn't we just define a max depth so that all cruft deeper than that can just be discarded on a regular basis? Why are there activation heights defined by this hard fork if it's not possible to reorg back to them? The "BIP" is neither a Proposal (it's been decided, just documenting for posterity), nor an Improvement (there is no actual benefit, just some tidying up in the notoriously obtuse satoshi code base), nor Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has been CoreCoin). e > On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail•com> wrote: > > Since "buried deployments" are specifically in reference to historical consensus changes, I think the question is more one of human consensus than machine consensus. Is there any disagreement amongst Bitcoin users that BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66 activated at block 363725? Somehow I doubt it. > > It seems to me that this change is merely cementing into place a few attributes of the blockchain's history that are not in dispute. > > - Jameson > >> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> Actually this does nothing to provide justification for this consensus rule change. It is just an attempt to deflect criticism from the fact that it is such a change. >> >> e >> >> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail•com> wrote: >> > >> > I think this is already covered in the BIP text:- >> > >> > "As of November 2016, the most recent of these changes (BIP 65, >> > enforced since December 2015) has nearly 50,000 blocks built on top of >> > it. The occurrence of such a reorg that would cause the activating >> > block to be disconnected would raise fundamental concerns about the >> > security assumptions of Bitcoin, a far bigger issue than any >> > non-backwards compatible change. >> > >> > So while this proposal could theoretically result in a consensus >> > split, it is extremely unlikely, and in particular any such >> > circumstances would be sufficiently damaging to the Bitcoin network to >> > dwarf any concerns about the effects of this proposed change." >> > >> > >> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev >> > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> NACK >> >> >> >> Horrible precedent (hardcoding rule changes based on the assumption that >> >> large forks indicate a catastrophic failure), extremely poor process >> >> (already shipped, now the discussion), and not even a material performance >> >> optimization (the checks are avoidable once activated until a sufficiently >> >> deep reorg deactivates them). >> >> >> >> e >> >> >> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev >> >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> >> >> Hi, >> >> >> >> Recently Bitcoin Core merged a simplification to the consensus rules >> >> surrounding deployment of BIPs 34, 66, and 65 >> >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a >> >> minor one, I thought it was worth documenting the rationale in a BIP for >> >> posterity. >> >> >> >> Here's the abstract: >> >> >> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner >> >> signaling in block version numbers. Now that the chain has long since passed >> >> the blocks at which those consensus rules have triggered, we can (as a >> >> simplification and optimization) replace the trigger mechanism by caching >> >> the block heights at which those consensus rules became enforced. >> >> >> >> The full draft can be found here: >> >> >> >> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki >> >> >> >> _______________________________________________ >> >> 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: 7198 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 13:58 ` Eric Voskuil @ 2016-11-16 14:18 ` Tier Nolan 2016-11-16 14:32 ` Alex Morcos 2016-11-16 14:18 ` Thomas Kerin ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Tier Nolan @ 2016-11-16 14:18 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 813 bytes --] On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Are checkpoints good now? Are hard forks okay now? > I think that at least one checkpoint should be included. The assumption is that no 50k re-orgs will happen, and that assumption should be directly checked. Checkpointing only needs to happen during the headers-first part of the download. If the block at the BIP-65 height is checkpointed, then the comparisons for the other ones are automatically correct. They are unnecessary, since the checkpoint protects all earlier block, but many people would like to be able to verify the legacy chain. This makes the change a soft-fork rather than a hard fork. Chains that don't go through the checkpoint are rejected but no new chains are allowed. [-- Attachment #2: Type: text/html, Size: 1243 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 14:18 ` Tier Nolan @ 2016-11-16 14:32 ` Alex Morcos 2016-11-16 21:01 ` Peter Todd 0 siblings, 1 reply; 24+ messages in thread From: Alex Morcos @ 2016-11-16 14:32 UTC (permalink / raw) To: Tier Nolan, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2563 bytes --] I think we are misunderstanding the effect of this change. It's still "OK" for a 50k re-org to happen. We're just saying that if it does, we will now have potentially introduced a hard fork between new client and old clients if the reorg contains earlier signaling for the most recent ISM soft fork and then blocks which do not conform to that soft fork before the block height encoded activation. I think the argument is this doesn't substantially add to the confusion or usability of the system as its likely that old software won't even handle 50k block reorgs cleanly anyway and there will clearly have to be human coordination at the time of the event. In the unlikely event that the new chain does cause such a hard fork, that coordination can result in everyone upgrading to software that supports the new rules anyway. So no, I don't think we should add a checkpoint. I think we should all just agree to a hard fork that only has a very very slim chance of any practical effect. In response to Thomas' email. I think ideally we would treat these soft forks the way we did BIP30 which is to say that we're just introducing a further soft fork that applies to all blocks except for the historical exceptions. So then its a almost no-op soft fork with no risk of hard fork. This however isn't practical with at least BIP 34 without storing the hashes of all 200K blocks that don't meet the requirement. On Wed, Nov 16, 2016 at 9:18 AM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Are checkpoints good now? Are hard forks okay now? >> > > I think that at least one checkpoint should be included. The assumption > is that no 50k re-orgs will happen, and that assumption should be directly > checked. > > Checkpointing only needs to happen during the headers-first part of the > download. > > If the block at the BIP-65 height is checkpointed, then the comparisons > for the other ones are automatically correct. They are unnecessary, since > the checkpoint protects all earlier block, but many people would like to be > able to verify the legacy chain. > > This makes the change a soft-fork rather than a hard fork. Chains that > don't go through the checkpoint are rejected but no new chains are allowed. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3672 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 14:32 ` Alex Morcos @ 2016-11-16 21:01 ` Peter Todd 2016-11-16 22:21 ` Eric Voskuil 2016-11-17 3:06 ` Luke Dashjr 0 siblings, 2 replies; 24+ messages in thread From: Peter Todd @ 2016-11-16 21:01 UTC (permalink / raw) To: Alex Morcos, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1791 bytes --] On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote: > I think we are misunderstanding the effect of this change. > It's still "OK" for a 50k re-org to happen. > We're just saying that if it does, we will now have potentially introduced > a hard fork between new client and old clients if the reorg contains > earlier signaling for the most recent ISM soft fork and then blocks which > do not conform to that soft fork before the block height encoded activation. > > I think the argument is this doesn't substantially add to the confusion or > usability of the system as its likely that old software won't even handle > 50k block reorgs cleanly anyway and there will clearly have to be human > coordination at the time of the event. In the unlikely event that the new > chain does cause such a hard fork, that coordination can result in everyone > upgrading to software that supports the new rules anyway. > > So no, I don't think we should add a checkpoint. I think we should all > just agree to a hard fork that only has a very very slim chance of any > practical effect. So, conceptually, another way to deal with this is to hardcode a blockhash where we allow blocks in a chain ending with that blockhash to _not_ follow BIP65, up until that blockhash, and any blockchain without that blockhash must respect BIP65 for all blocks in the chain. This is a softfork: we've only added rules that made otherwise valid chains invalid, and at the same time we are still accepting large reorgs (albeit under stricter rules than before). I'd suggest we call this a exemption hash - we've exempted a particular blockchains from a soft-forked rule that we would otherwise enforce. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 21:01 ` Peter Todd @ 2016-11-16 22:21 ` Eric Voskuil 2016-11-17 3:06 ` Luke Dashjr 1 sibling, 0 replies; 24+ messages in thread From: Eric Voskuil @ 2016-11-16 22:21 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion I would suggest that, before discussing how best to fork the chain to meet this objective, we consider the objective. The implementers have acknowledged that this does not represent a performance improvement. Especially given that this was apparently not initially understood, that alone is good reason for them to reconsider. The remaining stated objective is reduction of code complexity. Let us be very clear, a proposal to change the protocol must be considered independently of any particular implementation of the protocol. While the implementation of BIP34 style activation may be hugely complex in the satoshi code, it is definitely not complex as a matter of necessity. Activation constitutes maybe a dozen lines of additional code in libbitcoin. The need to hit the chain (or cache) to obtain historical header info will remain for proof of work, so this change doesn't even accomplish some sort of beneficial isolation from blockchain history. So, at best, we are talking about various ways to introduce a consensus fork so that a well designed implementation can remove a tiny amount of already-written code and associated tests. In my opinion this is embarrassingly poor reasoning. It would be much more productive to reduce satoshi code complexity in ways that do not impact the protocol. There are a *huge* number of such opportunities, and in fact activation is one of them. Once that is done, we can talk about forking to reduce source code complexity. These fork suggestions actually increase *necessary* complexity for any implantation that takes a rational approach to forks. By rational I mean *additive*. Deleting rules from Bitcoin code is simply bad design. Rules are never removed, they are added. A new rule to modify an old rule is simply a new rule. This is new and additional code. So please don't assume in this "proposal" that this makes development simpler for other implementations, that is not a necessary conclusion. e > On Nov 16, 2016, at 1:01 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote: >> I think we are misunderstanding the effect of this change. >> It's still "OK" for a 50k re-org to happen. >> We're just saying that if it does, we will now have potentially introduced >> a hard fork between new client and old clients if the reorg contains >> earlier signaling for the most recent ISM soft fork and then blocks which >> do not conform to that soft fork before the block height encoded activation. >> >> I think the argument is this doesn't substantially add to the confusion or >> usability of the system as its likely that old software won't even handle >> 50k block reorgs cleanly anyway and there will clearly have to be human >> coordination at the time of the event. In the unlikely event that the new >> chain does cause such a hard fork, that coordination can result in everyone >> upgrading to software that supports the new rules anyway. >> >> So no, I don't think we should add a checkpoint. I think we should all >> just agree to a hard fork that only has a very very slim chance of any >> practical effect. > > So, conceptually, another way to deal with this is to hardcode a blockhash > where we allow blocks in a chain ending with that blockhash to _not_ follow > BIP65, up until that blockhash, and any blockchain without that blockhash must > respect BIP65 for all blocks in the chain. > > This is a softfork: we've only added rules that made otherwise valid chains > invalid, and at the same time we are still accepting large reorgs (albeit under > stricter rules than before). > > I'd suggest we call this a exemption hash - we've exempted a particular > blockchains from a soft-forked rule that we would otherwise enforce. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 21:01 ` Peter Todd 2016-11-16 22:21 ` Eric Voskuil @ 2016-11-17 3:06 ` Luke Dashjr 1 sibling, 0 replies; 24+ messages in thread From: Luke Dashjr @ 2016-11-17 3:06 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion On Wednesday, November 16, 2016 9:01:00 PM Peter Todd via bitcoin-dev wrote: > So, conceptually, another way to deal with this is to hardcode a blockhash > where we allow blocks in a chain ending with that blockhash to _not_ follow > BIP65, up until that blockhash, and any blockchain without that blockhash > must respect BIP65 for all blocks in the chain. > > This is a softfork: we've only added rules that made otherwise valid chains > invalid, and at the same time we are still accepting large reorgs (albeit > under stricter rules than before). > > I'd suggest we call this a exemption hash - we've exempted a particular > blockchains from a soft-forked rule that we would otherwise enforce. While this is technically a softfork, I think it may behave somewhat like a hardfork if we're not careful. Particularly, is the chain up to the block immediately before the checkpoint itself valid on its own, or does it simply become retroactively valid when it hits that checkpoint? P.S. Your PGP signature is invalid? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 13:58 ` Eric Voskuil 2016-11-16 14:18 ` Tier Nolan @ 2016-11-16 14:18 ` Thomas Kerin 2016-11-16 23:58 ` Jorge Timón 2016-11-17 0:13 ` Eric Voskuil 2016-11-16 23:48 ` Jorge Timón 2016-11-17 1:50 ` Pieter Wuille 3 siblings, 2 replies; 24+ messages in thread From: Thomas Kerin @ 2016-11-16 14:18 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6616 bytes --] BIP30 actually was given similar treatment after a reasonable amount of time had passed. https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which neither benefited nor improved bitcoin, but did document an event for posterity. This is not a hard fork. Removing ISM just means we've committed to those soft-forks only locking into the chain we use now. On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote: > This sort of statement represents one consequence of the > aforementioned bad precedent. > > Are checkpoints good now? Are hard forks okay now? > > What is the maximum depth of a reorg allowed by this non-machine > consensus? > > Shouldn't we just define a max depth so that all cruft deeper than > that can just be discarded on a regular basis? > > Why are there activation heights defined by this hard fork if it's not > possible to reorg back to them? > > The "BIP" is neither a Proposal (it's been decided, just documenting > for posterity), nor an Improvement (there is no actual benefit, just > some tidying up in the notoriously obtuse satoshi code base), nor > Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has > been CoreCoin). > > e > > On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail•com > <mailto:jameson.lopp@gmail•com>> wrote: > >> Since "buried deployments" are specifically in reference to >> historical consensus changes, I think the question is more one of >> human consensus than machine consensus. Is there any disagreement >> amongst Bitcoin users that BIP34 activated at block 227931, BIP65 >> activated at block 388381, and BIP66 activated at block 363725? >> Somehow I doubt it. >> >> It seems to me that this change is merely cementing into place a few >> attributes of the blockchain's history that are not in dispute. >> >> - Jameson >> >> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >> >> Actually this does nothing to provide justification for this >> consensus rule change. It is just an attempt to deflect criticism >> from the fact that it is such a change. >> >> e >> >> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail•com >> <mailto:btcdrak@gmail•com>> wrote: >> > >> > I think this is already covered in the BIP text:- >> > >> > "As of November 2016, the most recent of these changes (BIP 65, >> > enforced since December 2015) has nearly 50,000 blocks built on >> top of >> > it. The occurrence of such a reorg that would cause the activating >> > block to be disconnected would raise fundamental concerns about the >> > security assumptions of Bitcoin, a far bigger issue than any >> > non-backwards compatible change. >> > >> > So while this proposal could theoretically result in a consensus >> > split, it is extremely unlikely, and in particular any such >> > circumstances would be sufficiently damaging to the Bitcoin >> network to >> > dwarf any concerns about the effects of this proposed change." >> > >> > >> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev >> > <bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >> >> NACK >> >> >> >> Horrible precedent (hardcoding rule changes based on the >> assumption that >> >> large forks indicate a catastrophic failure), extremely poor >> process >> >> (already shipped, now the discussion), and not even a material >> performance >> >> optimization (the checks are avoidable once activated until a >> sufficiently >> >> deep reorg deactivates them). >> >> >> >> e >> >> >> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev >> >> <bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >> >> >> >> Hi, >> >> >> >> Recently Bitcoin Core merged a simplification to the consensus >> rules >> >> surrounding deployment of BIPs 34, 66, and 65 >> >> (https://github.com/bitcoin/bitcoin/pull/8391 >> <https://github.com/bitcoin/bitcoin/pull/8391>), and though the >> change is a >> >> minor one, I thought it was worth documenting the rationale in >> a BIP for >> >> posterity. >> >> >> >> Here's the abstract: >> >> >> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated >> via miner >> >> signaling in block version numbers. Now that the chain has >> long since passed >> >> the blocks at which those consensus rules have triggered, we >> can (as a >> >> simplification and optimization) replace the trigger mechanism >> by caching >> >> the block heights at which those consensus rules became enforced. >> >> >> >> The full draft can be found here: >> >> >> >> >> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki >> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki> >> >> >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> >> >> >> >> >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> <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: 12178 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 14:18 ` Thomas Kerin @ 2016-11-16 23:58 ` Jorge Timón 2016-11-17 0:00 ` Eric Voskuil 2016-11-17 0:13 ` Eric Voskuil 1 sibling, 1 reply; 24+ messages in thread From: Jorge Timón @ 2016-11-16 23:58 UTC (permalink / raw) To: Thomas Kerin, Bitcoin Protocol Discussion On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > BIP30 actually was given similar treatment after a reasonable amount of time > had passed. > https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 This is not really the same. BIP30 is not validated after BIP34 is active because blocks complying with BIP34 will always necessarily comply with BIP30 (ie coinbases cannot be duplicated after they include the block height). ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 23:58 ` Jorge Timón @ 2016-11-17 0:00 ` Eric Voskuil 2016-11-17 1:24 ` Alex Morcos 0 siblings, 1 reply; 24+ messages in thread From: Eric Voskuil @ 2016-11-17 0:00 UTC (permalink / raw) To: Jorge Timón, Bitcoin Protocol Discussion, Thomas Kerin [-- Attachment #1: Type: text/plain, Size: 748 bytes --] On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote: > On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> BIP30 actually was given similar treatment after a reasonable amount of time >> had passed. >> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 > > This is not really the same. BIP30 is not validated after BIP34 is > active because blocks complying with BIP34 will always necessarily > comply with BIP30 (ie coinbases cannot be duplicated after they > include the block height). This is a misinterpretation of BIP30. Duplicate transaction hashes can and will happen and are perfectly valid in Bitcoin. BIP34 does not prevent this. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-17 0:00 ` Eric Voskuil @ 2016-11-17 1:24 ` Alex Morcos 2016-11-17 1:41 ` Eric Voskuil 0 siblings, 1 reply; 24+ messages in thread From: Alex Morcos @ 2016-11-17 1:24 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion; +Cc: Thomas Kerin [-- Attachment #1: Type: text/plain, Size: 1208 bytes --] huh? can you give an example of how a duplicate transaction hash (in the same chain) can happen given BIP34? On Wed, Nov 16, 2016 at 7:00 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote: > > On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> BIP30 actually was given similar treatment after a reasonable amount of > time > >> had passed. > >> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 > > > > This is not really the same. BIP30 is not validated after BIP34 is > > active because blocks complying with BIP34 will always necessarily > > comply with BIP30 (ie coinbases cannot be duplicated after they > > include the block height). > > This is a misinterpretation of BIP30. Duplicate transaction hashes can > and will happen and are perfectly valid in Bitcoin. BIP34 does not > prevent this. > > e > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2026 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-17 1:24 ` Alex Morcos @ 2016-11-17 1:41 ` Eric Voskuil 0 siblings, 0 replies; 24+ messages in thread From: Eric Voskuil @ 2016-11-17 1:41 UTC (permalink / raw) To: Alex Morcos, Bitcoin Protocol Discussion; +Cc: Thomas Kerin [-- Attachment #1: Type: text/plain, Size: 1539 bytes --] On 11/16/2016 05:24 PM, Alex Morcos wrote: > huh? > can you give an example of how a duplicate transaction hash (in the same > chain) can happen given BIP34? "The pigeonhole principle arises in computer science. For example, collisions are inevitable in a hash table because the number of possible keys exceeds the number of indices in the array. A hashing algorithm, no matter how clever, cannot avoid these collisions." https://en.wikipedia.org/wiki/Pigeonhole_principle e > On Wed, Nov 16, 2016 at 7:00 PM, Eric Voskuil via bitcoin-dev wrote: > > On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote: > > On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > >> BIP30 actually was given similar treatment after a reasonable amount of time > >> had passed. > >> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 > <https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392> > > > > This is not really the same. BIP30 is not validated after BIP34 is > > active because blocks complying with BIP34 will always necessarily > > comply with BIP30 (ie coinbases cannot be duplicated after they > > include the block height). > > This is a misinterpretation of BIP30. Duplicate transaction hashes can > and will happen and are perfectly valid in Bitcoin. BIP34 does not > prevent this. > > e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 14:18 ` Thomas Kerin 2016-11-16 23:58 ` Jorge Timón @ 2016-11-17 0:13 ` Eric Voskuil 1 sibling, 0 replies; 24+ messages in thread From: Eric Voskuil @ 2016-11-17 0:13 UTC (permalink / raw) To: Thomas Kerin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8041 bytes --] On 11/16/2016 06:18 AM, Thomas Kerin wrote: > BIP30 actually was given similar treatment after a reasonable amount of > time had passed. > https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 BIP30 was the resolution to a catostrophic protocol flaw that would impact any block whether above or below the point where the rule was applied. Applying it to all future blocks, regardless of whether there is a reorg back to genesis, was the only option as far as I can tell. So the comparison to an unnecessary fork is hardly apt. > You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which > neither benefited nor improved bitcoin, but did document an event for > posterity. BIP50 documents the release of an "unexpected" hard fork to a large number of users. Given that Core code is considered by some to be the *definition* of the true protocol, this led to two "legitimate" Bitcoin chains. Leveraging the centralized state of Bitcoin mining, the development team was able to kill the newer chain. This was simply an altcoin that didn't survive because people stopped using it. Anyone can create an altcoin - the question here is specifically, why would we want to do so in this case. > This is not a hard fork. Removing ISM just means we've committed to > those soft-forks only locking into the chain we use now. There didn't seem to be any confusion among the implementers that it is a hard fork. I will correct one implication I made below. The heights in the proposal are required in the absence of BIP34-style activation so that the soft fork validation rules can be properly enforced at those points (whether or not a deep reorg happens). e > On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote: >> This sort of statement represents one consequence of the >> aforementioned bad precedent. >> >> Are checkpoints good now? Are hard forks okay now? >> >> What is the maximum depth of a reorg allowed by this non-machine >> consensus? >> >> Shouldn't we just define a max depth so that all cruft deeper than >> that can just be discarded on a regular basis? >> >> Why are there activation heights defined by this hard fork if it's not >> possible to reorg back to them? >> >> The "BIP" is neither a Proposal (it's been decided, just documenting >> for posterity), nor an Improvement (there is no actual benefit, just >> some tidying up in the notoriously obtuse satoshi code base), nor >> Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has >> been CoreCoin). >> >> e >> >> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail•com >> <mailto:jameson.lopp@gmail•com>> wrote: >> >>> Since "buried deployments" are specifically in reference to >>> historical consensus changes, I think the question is more one of >>> human consensus than machine consensus. Is there any disagreement >>> amongst Bitcoin users that BIP34 activated at block 227931, BIP65 >>> activated at block 388381, and BIP66 activated at block 363725? >>> Somehow I doubt it. >>> >>> It seems to me that this change is merely cementing into place a few >>> attributes of the blockchain's history that are not in dispute. >>> >>> - Jameson >>> >>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev >>> <bitcoin-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >>> >>> Actually this does nothing to provide justification for this >>> consensus rule change. It is just an attempt to deflect criticism >>> from the fact that it is such a change. >>> >>> e >>> >>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail•com >>> <mailto:btcdrak@gmail•com>> wrote: >>> > >>> > I think this is already covered in the BIP text:- >>> > >>> > "As of November 2016, the most recent of these changes (BIP 65, >>> > enforced since December 2015) has nearly 50,000 blocks built on >>> top of >>> > it. The occurrence of such a reorg that would cause the activating >>> > block to be disconnected would raise fundamental concerns about the >>> > security assumptions of Bitcoin, a far bigger issue than any >>> > non-backwards compatible change. >>> > >>> > So while this proposal could theoretically result in a consensus >>> > split, it is extremely unlikely, and in particular any such >>> > circumstances would be sufficiently damaging to the Bitcoin >>> network to >>> > dwarf any concerns about the effects of this proposed change." >>> > >>> > >>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev >>> > <bitcoin-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >>> >> NACK >>> >> >>> >> Horrible precedent (hardcoding rule changes based on the >>> assumption that >>> >> large forks indicate a catastrophic failure), extremely poor >>> process >>> >> (already shipped, now the discussion), and not even a material >>> performance >>> >> optimization (the checks are avoidable once activated until a >>> sufficiently >>> >> deep reorg deactivates them). >>> >> >>> >> e >>> >> >>> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev >>> >> <bitcoin-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >>> >> >>> >> Hi, >>> >> >>> >> Recently Bitcoin Core merged a simplification to the consensus >>> rules >>> >> surrounding deployment of BIPs 34, 66, and 65 >>> >> (https://github.com/bitcoin/bitcoin/pull/8391 >>> <https://github.com/bitcoin/bitcoin/pull/8391>), and though the >>> change is a >>> >> minor one, I thought it was worth documenting the rationale in >>> a BIP for >>> >> posterity. >>> >> >>> >> Here's the abstract: >>> >> >>> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated >>> via miner >>> >> signaling in block version numbers. Now that the chain has >>> long since passed >>> >> the blocks at which those consensus rules have triggered, we >>> can (as a >>> >> simplification and optimization) replace the trigger mechanism >>> by caching >>> >> the block heights at which those consensus rules became enforced. >>> >> >>> >> The full draft can be found here: >>> >> >>> >> >>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki >>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki> >>> >> >>> >> _______________________________________________ >>> >> bitcoin-dev mailing list >>> >> bitcoin-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> >>> >> >>> >> >>> >> _______________________________________________ >>> >> bitcoin-dev mailing list >>> >> bitcoin-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> >>> >> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> <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: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 13:58 ` Eric Voskuil 2016-11-16 14:18 ` Tier Nolan 2016-11-16 14:18 ` Thomas Kerin @ 2016-11-16 23:48 ` Jorge Timón 2016-11-17 1:50 ` Pieter Wuille 3 siblings, 0 replies; 24+ messages in thread From: Jorge Timón @ 2016-11-16 23:48 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > This sort of statement represents one consequence of the aforementioned bad > precedent. > > Are checkpoints good now? Checkpoints are not necessary for consensus and work is being done to remove them completely from Bitcoin Core in particular. > Are hard forks okay now? I personally think uncontroversial hardforks are ok. > What is the maximum depth of a reorg allowed by this non-machine consensus? Good question, specially if we plan to do this with future buried deployments. What about 1 year reorg? > Shouldn't we just define a max depth so that all cruft deeper than that can > just be discarded on a regular basis? Not sure I understand this question. > Why are there activation heights defined by this hard fork if it's not > possible to reorg back to them? If this is a hardfork, it is one that will only be visible if/when there's a very deep reorg , one of the kind where we can practically consider Bitcoin done (and only if some nodes keep the ISM code). But I could accept that definition. Another way to see it (even though other said the optimization part was not important) as such an optimization and simplification. The way I see it, ISM and BIP9 are just coordination mechanisms for uncontroversial rule changes. Once the coordination happened and is long in the past, I really don't see the problem with replacing the mechanism with a simpler height. > The "BIP" is neither a Proposal (it's been decided, just documenting for > posterity), nor an Improvement (there is no actual benefit, just some > tidying up in the notoriously obtuse satoshi code base), nor Bitcoin (a hard > fork defines an alt coin, so from Aug 4 forward it has been CoreCoin). Mhmm, I disagree on the notion that any hardfork necessarily represents an altcoin. It is certainly an improvement in the sense that it simplifies implementations and optimizes validation. You may argue that you don't consider the improvement important though. These changes to Bitcoin Core could be rolled back (and obviously other implementations don't need to adopt them unless they want to benefit from the simplification/optimization or fear such a long reaorg), but I really hope we don't. Trying to understand you better... Accepting your definition of this as a hardfork, do you oppose to it simply because it is a hardfork, or because you consider this "hardfork" a bad idea for some reason I am missing? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-16 13:58 ` Eric Voskuil ` (2 preceding siblings ...) 2016-11-16 23:48 ` Jorge Timón @ 2016-11-17 1:50 ` Pieter Wuille 2016-11-17 2:16 ` Eric Voskuil 3 siblings, 1 reply; 24+ messages in thread From: Pieter Wuille @ 2016-11-17 1:50 UTC (permalink / raw) To: Eric Voskuil, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1198 bytes --] On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > This sort of statement represents one consequence of the aforementioned > bad precedent. > > Are checkpoints good now? > So far in this discussion, and in a thread that has forked off, I think 3 cases of implementation aspects have been mentioned that under certain circumstances result in the validity of chains changing: * Buried softforks (by simplifying the activation rules for certain rules) * Not verifying BIP30 after BIP34 is active (since only under a SHA256^2 collision a duplicate txid can occur) * The existence (and/or removal) of checkpoints (in one form or another). None of these will influence the accepted main chain, however. If they ever do, Bitcoin has far worse things to worry about (years-deep reorgs, or SHA256 collisions). If you were trying to point out that buried softforks are similar to checkpoints in this regard, I agree. So are checkpoints good now? I believe we should get rid of checkpoints because they seem to be misunderstood as a security feature rather than as an optimization. I don't think buried softforks have that problem. -- Pieter [-- Attachment #2: Type: text/html, Size: 1697 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-17 1:50 ` Pieter Wuille @ 2016-11-17 2:16 ` Eric Voskuil 2016-11-17 2:47 ` Pieter Wuille 0 siblings, 1 reply; 24+ messages in thread From: Eric Voskuil @ 2016-11-17 2:16 UTC (permalink / raw) To: Pieter Wuille, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1428 bytes --] On 11/16/2016 05:50 PM, Pieter Wuille wrote: > If you were trying to point out that buried softforks are similar to > checkpoints in this regard, I agree. Yes, that was my point. > So are checkpoints good now? > I believe we should get rid of checkpoints because they seem to be misunderstood as a security feature rather than as an optimization. Or maybe because they place control of the "true chain" in the hands of those selecting the checkpoints? It's not a great leap for the parties distributing the checkpoints to become the central authority. I recommend users of our node validate the full chain without checkpoints and from that chain select their own checkpoints and place them into config. From that point forward they can apply the optimization. Checkpoints should never be hardcoded into the source. > I don't think buried softforks have that problem. I find "buried softfork" a curious name as you are using it. You seem to be implying that this type of change is itself a softfork as opposed to a hardfork that changes the activation of a softfork. It was my understanding that the term referred to the 3 softforks that were being "buried", or the proposal, but not the burial itself. Nevertheless, this proposal shouldn't have "that problem" because it is clearly neither a security feature nor an optimization. That is the first issue that needs to be addressed. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-17 2:16 ` Eric Voskuil @ 2016-11-17 2:47 ` Pieter Wuille 2016-11-17 10:10 ` Eric Voskuil 0 siblings, 1 reply; 24+ messages in thread From: Pieter Wuille @ 2016-11-17 2:47 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2988 bytes --] On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil <eric@voskuil•org> wrote: > On 11/16/2016 05:50 PM, Pieter Wuille wrote: > > > So are checkpoints good now? > > I believe we should get rid of checkpoints because they seem to be > misunderstood as a security feature rather than as an optimization. > > Or maybe because they place control of the "true chain" in the hands of > those selecting the checkpoints? It's not a great leap for the parties > distributing the checkpoints to become the central authority. > Yes, they can be used to control the "true chain", and this has happened with various forks. But developers inevitably have this possibility, if you ignore review. If review is good enough to catch unintended consensus changes, it is certainly enough to catch the introduction of an invalid checkpoint. The risk you point out is real, but the way to deal with it is good review and release practices. I wish we had never used checkpoints the way we did, but here we are. Because of this, I want to get rid of them. However, It's not because I think they offer an excessive power to developers - but because they're often perceived this way (partially as a result of how they've been abused in other systems). > I recommend users of our node validate the full chain without > checkpoints and from that chain select their own checkpoints and place > them into config. From that point forward they can apply the > optimization. Checkpoints should never be hardcoded into the source. > Having users with the discipline you suggest would be wonderful to have. I don't think it's very realistic, though, and I fear that the result would be that everyone copies their config from one or a few websites "because that's what everyone uses". > I don't think buried softforks have that problem. > > I find "buried softfork" a curious name as you are using it. You seem to > be implying that this type of change is itself a softfork as opposed to > a hardfork that changes the activation of a softfork. It was my > understanding that the term referred to the 3 softforks that were being > "buried", or the proposal, but not the burial itself. > I do not consider the practice of "buried softforks" to be a fork at all. It is a change that modifies the validity of a theoretically construable chain from invalid to valid. However, a reorganization to that theoretical chain itself is likely already impossible due to the vast number of blocks to rewind, and economic damage that is far greater than chain divergence itself. > Nevertheless, this proposal shouldn't have "that problem" because it is > clearly neither a security feature nor an optimization. That is the > first issue that needs to be addressed. It is clearly not a security feature, agreed. But how would you propose to avoid the ISM checks for BIP34 and BIP66 all the time? I feel this approach is a perfectly reasonable choice for code that likely won't ever affect the valid chain again. Cheers, -- Pieter [-- Attachment #2: Type: text/html, Size: 4278 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-17 2:47 ` Pieter Wuille @ 2016-11-17 10:10 ` Eric Voskuil 0 siblings, 0 replies; 24+ messages in thread From: Eric Voskuil @ 2016-11-17 10:10 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6680 bytes --] On 11/16/2016 06:47 PM, Pieter Wuille wrote: > On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil <eric@voskuil•org > <mailto:eric@voskuil•org>> wrote: > > On 11/16/2016 05:50 PM, Pieter Wuille wrote: > > > So are checkpoints good now? > > I believe we should get rid of checkpoints because they seem to be > misunderstood as a security feature rather than as an optimization. > > Or maybe because they place control of the "true chain" in the hands of > those selecting the checkpoints? It's not a great leap for the parties > distributing the checkpoints to become the central authority. > > Yes, they can be used to control the "true chain", and this has happened > with various forks. But developers inevitably have this possibility, if > you ignore review. If review is good enough to catch unintended > consensus changes, it is certainly enough to catch the introduction of > an invalid checkpoint. The risk you point out is real, but the way to > deal with it is good review and release practices. > > I wish we had never used checkpoints the way we did, but here we are. > Because of this, I want to get rid of them. However, It's not because I > think they offer an excessive power to developers - but because they're > often perceived this way (partially as a result of how they've been > abused in other systems). > > I recommend users of our node validate the full chain without > checkpoints and from that chain select their own checkpoints and place > them into config. From that point forward they can apply the > optimization. Checkpoints should never be hardcoded into the source. > > Having users with the discipline you suggest would be wonderful to have. > I don't think it's very realistic, though, and I fear that the result > would be that everyone copies their config from one or a few websites > "because that's what everyone uses". Certainly, but embedding them in the code makes that a practical certainty. People cannot be prevented from doing dumb things, but let's not make it hard for them to be smart. > > I don't think buried softforks have that problem. > > I find "buried softfork" a curious name as you are using it. You seem to > be implying that this type of change is itself a softfork as opposed to > a hardfork that changes the activation of a softfork. It was my > understanding that the term referred to the 3 softforks that were being > "buried", or the proposal, but not the burial itself. > I do not consider the practice of "buried softforks" to be a fork at > all. It is a change that modifies the validity of a theoretically > construable chain from invalid to valid. I was out at a Bitcoin meetup when I read this and I think beer actually came out of my nose. > However, a reorganization to > that theoretical chain itself is likely already impossible due to the > vast number of blocks to rewind, and economic damage that is far greater > than chain divergence itself. It's either possible or it is not. If it is not there is no reason for a proposal - just make the change and don't bother to tell anyone. The reason we are having this discussion is because it is not impossible. > Nevertheless, this proposal shouldn't have "that problem" because it is > clearly neither a security feature nor an optimization. That is the > first issue that needs to be addressed. > > It is clearly not a security feature, agreed. But how would you propose > to avoid the ISM checks for BIP34 and BIP66 all the time? I'll call straw man on the question. It is not important to avoid the activation checks. The question is whether there is a material performance optimization in eliminating them. This would have to be significant enough to rise to the level of a change to the protocol. Having said that there are a few options: 1. The naive approach to activation is, for each new block, to query the store for the previous 1000 block headers (to the extent there are that many), and just do so forever, summing up after the query. This is the most straightforward but also the most costly approach. 2. A slightly less costly approach is, for each new block, to reverse iterate over the store until all decisions can be made. This would be an improvement below activation in that it would take it takes as little as 251 vs. 1000 queries to make the determinations. 3. A further improvement is available by caching the height of full activation of all three soft forks. Unless there is a subsequent reorg with a fork point prior that height, there is never a need to make another query. Once fully activated the activation height is cached to the store (otherwise just query the last 1000 versions at startup to determine the state), eliminating any ongoing material cost. 4. We may also be interested in optimizing initial block download. A cache of the last 1000 block versions can be maintained by adding each to a circular buffer as they are committed. This eliminates *all* querying for block versions unless: (1) there is a restart prior to full activation - in which case there is a query of up to 1000 versions to prime the cache. (2) there is a potential reorg after full activation, and the fork point precedes the saved full activation height - in which case the cache must be reprimed. (3) there is a potential reorg. before reaching full activation - in which case the cache must be backfilled with a query for a number of versions equal to the depth of the fork point. During initial block download potential reorgs are exceedingly rare (reorgs don't have potential unless they have sufficient work to overcome the long chain) and the cost of handling them as described above is trivial. The cost of priming the cache is immaterial in the context of a restart. So even with a full chain validation one is not likely to *ever* need to query the store. The memory cost of the cache is strictly 3 bits per block (375 bytes total). A simpler less memory-sensitive approach is to use one byte (1,000 bytes total). The computational cost is trivial. This should already be implemented. A protocol fork (or "change that modifies the validity of a theoretically construable chain from invalid to valid") to avoid doing so is not a performance optimization. > I feel this > approach is a perfectly reasonable choice for code that likely won't > ever affect the valid chain again. I find it to be completely unsupportable as there is no security, performance, or feature benefit in it. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Buried Deployments 2016-11-14 18:47 ` Eric Voskuil 2016-11-15 14:42 ` Suhas Daftuar 2016-11-15 17:45 ` Btc Drak @ 2016-11-16 14:38 ` Tom Zander 2 siblings, 0 replies; 24+ messages in thread From: Tom Zander @ 2016-11-16 14:38 UTC (permalink / raw) To: bitcoin-dev Here is my thinking. The BIP process is about changes to a living project which is the bitcoin prptocol. This specific BIP got accepted and we know in the blockchain that this event (the acceptance) is recorded. Before a certain block the rules were one way, after they were changed. I have no problem with changing the *code* to be less complex because it already knows the past. A checkpoint is the same, it is the registeration of a past event. This makes software less complex and still capable of checking the entire blockchain from genesis. I don’t see any harm in this change. I see prudent software engineering practices. On Monday, 14 November 2016 10:47:35 CET Eric Voskuil via bitcoin-dev wrote: > NACK > > Horrible precedent (hardcoding rule changes based on the assumption that > large forks indicate a catastrophic failure), extremely poor process > (already shipped, now the discussion), and not even a material > performance optimization (the checks are avoidable once activated until a > sufficiently deep reorg deactivates them). -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-11-17 10:10 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-14 18:17 [bitcoin-dev] [BIP Proposal] Buried Deployments Suhas Daftuar 2016-11-14 18:47 ` Eric Voskuil 2016-11-15 14:42 ` Suhas Daftuar 2016-11-15 17:45 ` Btc Drak 2016-11-15 22:42 ` Eric Voskuil 2016-11-16 13:29 ` Jameson Lopp 2016-11-16 13:58 ` Eric Voskuil 2016-11-16 14:18 ` Tier Nolan 2016-11-16 14:32 ` Alex Morcos 2016-11-16 21:01 ` Peter Todd 2016-11-16 22:21 ` Eric Voskuil 2016-11-17 3:06 ` Luke Dashjr 2016-11-16 14:18 ` Thomas Kerin 2016-11-16 23:58 ` Jorge Timón 2016-11-17 0:00 ` Eric Voskuil 2016-11-17 1:24 ` Alex Morcos 2016-11-17 1:41 ` Eric Voskuil 2016-11-17 0:13 ` Eric Voskuil 2016-11-16 23:48 ` Jorge Timón 2016-11-17 1:50 ` Pieter Wuille 2016-11-17 2:16 ` Eric Voskuil 2016-11-17 2:47 ` Pieter Wuille 2016-11-17 10:10 ` Eric Voskuil 2016-11-16 14:38 ` Tom Zander
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox