Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil 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.

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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,

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

Also, it's important to take note of the motivation behind not banning duplicate tx hashes outright. Doing so would require that spent tx hashes are retained forever. A pruning node will have no way of knowing whether a new tx duplicates the hash of a preceding tx. Any implementation that does

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

> This means that all future transactions will have different txids... rules do guarantee it. No, it means that the chance is small, there is a difference. If there is an address collision, someone may lose some money. If there is a tx hash collision, and implementations handle this differently,

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Both of these cases resulted from exact duplicate txs, which BIP34 now > precludes. However nothing precludes different txs from having the same > hash. > The only way to have two

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

No, BIP30 prevents duplicate tx hashes in the case where the new tx hash duplicates that of a preceding tx with unspent outputs. There was one such case that had already become buried in the chain at the time, so it was exempted from validation. There was another case of a duplicate hash, but

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev 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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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 wrote: > > I think this is already covered in the BIP text:- >