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

[Tomas]

On Sat, Aug 26, 2017, at 14:31, Amaury Séchet via bitcoin-ml wrote:
> 
> newUTXO = utxo.add(block.getAllOutputs());
> foreach (i; block.GetAllInput()) {
>     if (!newUtxo.spend(i)) {
>         // Error !
>     }
> }
> 
> utxo = newUTXO;
> 
> Note that it is superior because the live set we are working with is
> the UTXO set, but all the spend operation do not need to be ordered
> anymore, so they can processed in parallel, or even on a cluster of
> machines.
This would allow "back references". A block could contain:

Transaction 1. spending A containing output B.
Transaction 2. spending B containing output A.

This would complicate clients/tools that prefer tx-by-tx processing.

You can use canonical ordering in the merkle tree without this. The
"consensus" rule would then be that their must be a valid linear
reordering of the transactions that hash to merkle root. The
implementation would then work tx-by-tx but simply pushing txs with
missing imputs to the end of the queue.
> 
> Which leads to the way the merkle root is computed. It has a few
> issues. The first one is that it is susceptible to subtree repetition
> that would recompute the same root. It is possible to check for this,
> and indeed the software does it, but any software that does so
> incorrectly will be susceptible to being fed invalid blocks. This is
> undesirable. The second problem is that as blocks gets bigger,
> swapping the coinbase become expensive. On the other hand, we want to
> deploy solution to build the block over time sub as NG, subchains or
> alike (not that they are alike in what they do, but the underlying
> idea, to build the block over time, is the same). This is important
> for scaling. Finally, if we get rid of the strict ordering rule above,
> we can define a canonical ordering in the merkle tree so that block
> can be merged in a deterministic manner which is useful for NG or
> subchains, but also opens opportunity for extra compression in
> CB/XThin and allows for proof of absence in a block.> The merkle tree computation could be changed as follow:
> The left branch starting from the root contains only the coinbase.
> The right branch contains all the transactions - minus the coinbase,
> ordered by txid.> Empty subtrees (when there is an odd number of nodes at some level)
> are 0x000...0001
Note, I think you can just as well take the remainder hash of an odd set
one level up without hashing it to 1?
I certainly see that an ordered merkle tree and a left branch for the
coinbase are an improvement, though I am not sure whether it is enough
to merit changing.
The compression by ordering seems to be rather tiny on 32-byte hashes,
and although coinbase reordering is expensive, it is equally expensive
for all miners. If we want to pursue subchains/NG/other block-over-time
solutions) shouldn't we first be work out of the viability of this
direction?
> Now among the more sexy changes. One is adopting a more interesting
> difficulty adjustment algorithm would also be nice. I discussed this
> in another email, so there is no point repeating it all here.> The maximal target ensure that several bits in the block hash are
> always 0, no matter what. These bits can be repurposed as an extra
> nonce. This is a very small and easy patch and current nonce space is
> not quite large enough.

Personally, although we shouldn't be afraid of hardforks, I think we
should aim for protocol change minimalism. Changing things that can be
worked around and are only an optimization should be avoided as for
every change, a fully validating client must understand old and new. The
spec can only grow.
For instance, if it is deemed unnecessary  to update the difficulty
algorithm as an emergency patch for the oscillations, then why change
at all? Are we suspecting more problems than we currently have? I think
that apart from the current fork problems, the existing algorithm
serves us well.
It is tempting to try to improve stuff,  but is there really  strong
enough motivation or demand for such fundamental changes to the merkle
tree or the long term difficulty rules at this moment?
Regards,
Tomas
bitcrust
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170826/bbf0b20e/attachment.html>