[Bitcoin-ml] What i would like to see in the next HF + timeline

[Tom Zander]

On Thursday, 31 August 2017 00:44:41 CEST Amaury Séchet wrote:
> 2017-08-29 16:55 GMT+02:00 Tom Zander via bitcoin-ml 
> > This will fail in the case of these two transactions are included in a
> > block.
> > a) a TX that spends the last output of txid1
> > b) a new TX that also hashes to txid1
> > 
> > I can think of a simple 3-transaction loop that is capable of creating a
> > duplicate transaction-id. (and, yes, this is legal even wrt to bip 30).
> > 
> > This unfortunately kills the optimization you are thinking about.
> 
> I would really like to understand this better.
...
>  This is possible in theory, but if we assume a giant reorg
> of several years won't happen, then I think it is impossible (I'd have to
> double check).

The block height being a mandatory inclusion is a software patch you (=ABC)
inherited from Core, none of the other clients inherited that patch. [1]

As such its a reorg of less than a day.
But I do agree that such a reorg is impractical.

> Am I missing something ?

The situation I was thinking about is a loop where the first txid is used by 
the second. etc. and the 3rd points to the first again.
This naturally, can’t be done without brute-forcing sha256 and that makes it 
academical.
Which is not the same thing as impractical as academical things can turn out 
to be attack vectors. Impractical things are just too expensive to try to 
get a profit.

The result is that you can create money out of thin air, provided you spend 
it in the same block. Yes, you may need to brute-force hashes, but you have 
years to do it. Not saying this is a likely attack, but it a problem that is 
introduced here. I see value in avoiding attack vectors where people can 
create coins out of thin air because I likely can’t oversee all the possible 
attacks that this creates.


In the end, my objection to the relaxing of the block-tx-ordering stands.
First, I don’t see the point. You try to make a protocol rule out of 
something that can be done by software. This has the natural effect of 
forcing everyone in the ecosystem to do the software refactor. This is not 
good design.
Just do the software update on your client. Leave the ordering intact.

I have the impression that you think we need to relax the ordering if we are 
to benefit from the merkle-tree change. I don’t see that connection. We can 
have the merkle-tree change without any changes in transaction ordering.
All that needs to happen is that the merkle-root calculation gets
a) a set of transaction-ids. Which it sorts before making the (sub) tree.
b) the coinbase-txid

How does that sound?


footnote;
1) would be interesting to check how many SPV wallets make the usage of the 
height a mandatory thing in the coinbase comment.
I would not be against removing that requirement as its only there as way to 
fix for BIP 30. It is technical debt. Naturally, the explicit requirement can 
be removed only because the implicit requirement of the txid being unique 
keeps it there.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel