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

[Tomas]

On Thu, Aug 31, 2017, at 10:40, Tom Zander via bitcoin-ml wrote:
> 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] 

The requirement for the coinbase to contain the height, is a rule for
version 2 blocks per BIP 34 since march 2013.


> 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.

If you can create two transactions with the same hash, you can already
create money out of thin air. You can create replace a block with
another without effecting the merkle root or recalculating the PoW,
effectively undoing a transaction. 


> 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?

I believe you are suggesting the same thing. We change the requirement
for validity of  the blockheader from

"There must exist a sequence of valid transactions which hashes to the
merkle root"

to 

"There must exist a sequence of valid transactions which after ordering
by txid hashes to the merkle root".

Whether you implement verifying this by 

1. Assuming that the set of transactions you receive are in valid order.
(which you suggest)
2. Attempt to reorder the transactions you receive to a valid order
(which I suggested)
3. Use a batched update of the UXTO set  (which Amaury suggests)

is an implementation detail, although Amaury correctly points out that
as we may assume no txid collisions, checking 3 already properly
verifies the new rule for the merkle root.

> First, I don’t see the point. You try to make a protocol rule out of 
> something that can be done by software. 

I also believe the change needs more motivation. We shouldn't make
changes just because the slightly improve stuff.

The argument that this could help in possible improvements by sub-block
syncing are valid, but only if this is a viable future optimization to
begin with.

Tomas
Bitcrust