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

What is the difference between downloading a hash and comparing it to a hash vs downloading a hash and then a block and comparing it to a block? You are talking about breaking a system in order to make it run faster. Using the hash is an non-optimization trade against correctness. There is no "

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

In this case I don’t understand how your implementation won’t be DoS-ed. An attacker could keep sending you inv for the same block / transaction. Since you don’t assume the hash is unique, each time you have to download the block/tx again before you could tell if that is the same one you have al

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

You are suggesting that, since a node implements a denial of service policy that actually denies itself otherwise valid blocks, those blocks are conditionally invalid. And that, since the validity condition is based on order of arrival and therefore independently unverifiable, Bitcoin consensus

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

Actually both possibilities were specifically covered in my description. Sorry if it wasn't clear. If you create a new valid block out of an old one it's has potential to cause a reorg. The blocks that previously built on the original are still able to do so but presumably cannot build forever

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

The fact that some implementations ban an invalid block hash and some do not, suggests that it’s not a pure p2p protocol issue. A pure p2p split should be unified by a bridge node. However, a bridge node is not helpful in this case. Banning an invalid block hash is an implicit “first seen” conse

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

I’m not sure if you really understand what you and I am talking. It has nothing to do with BIP30, 34, nor any other BIPs. Say tx1 is confirmed 3 years ago in block X. An attacker finds a valid tx2 which (tx1 != tx2) and (SHA256(tx1) == SHA256(tx2)). Now he could replace tx1 with tx2 in block X

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

On 11/17/2016 07:40 AM, Johnson Lau wrote: > >> On 17 Nov 2016, at 20:22, Eric Voskuil via bitcoin-dev wrote: >> >> Given that hash collisions are unquestionably possible, > > Everything you said after this point is irrelevant. So... you think hash collisions are not possible, or that it's moot b

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

> On 17 Nov 2016, at 20:22, Eric Voskuil via bitcoin-dev > wrote: > > > Given that hash collisions are unquestionably possible, Everything you said after this point is irrelevant. Having hash collision is **by definition** a consensus failure, or a hardfork. You could replace the already-o

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

On 11/17/2016 03:38 AM, Alex Morcos wrote: > I think this conversation has gone off the rails and is no longer really > appropriate for the list. If this discussion is not appropriate for the Bitcoin Protocol Discussion list then the list is pointless. > But just to be clear to any readers. Bitc

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

I think this conversation has gone off the rails and is no longer really appropriate for the list. But just to be clear to any readers. Bitcoin Core absolutely does rely on the impossibility of a hash collision for maintaining consensus. This happens in multiple places in the code but in particu

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

On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote: > On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil > wrote: > > > This means that all future transactions will have different txids... > rules do guarantee it. > > No, it means that the chance is small,

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

On 11/17/2016 12:44 AM, Peter Todd wrote: > On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev wrote: >>> 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 t

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

On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil wrote: > > 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. > I think we are mostly in agreement then? It is just terminology. In terms

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

On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev wrote: > > 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

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 reta

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 tran

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 it's

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

On Thu, Nov 17, 2016 at 1:00 AM, Eric Voskuil wrote: > This is a misinterpretation of BIP30. Duplicate transaction hashes can > and will happen and are perfectly valid in Bitcoin. BIP34 does not > prevent this. Sorry for moving the topic, but isn't duplication of tx hashes precisely what BIP30 pr