[Bitcoin-ml] Bucketed UTXO Commitment part 2

[Chris Pacia]

So thinking a little more about I'm a little worried a 100kb proof might
be too large for some of the things we might want to do with it.

For example, for scaling purposes it might be nice to shard the UTXO
set. In such an environment the sender of the each transaction

might want to fetch the UTXO proofs for each of his inputs and attach
them to the transaction he relays to peers in the network. Then those

who only have a partial view of the UTXO set can just validate the
transaction using CPU. But at 100kb per input that would use a ton of
bandwidth. :(

Not saying this scheme is useful for other purposes but that is one
thing it probably doesn't work for.


On 10/03/2017 09:33 AM, Tomas via bitcoin-ml wrote:
> I have updated and started implementing the bucketed UTXO commitment
> approach.
>
> Most notable change, is that I now propose to use a variable depth for
> the prefix tree and a fixed maximum bucket size. This absolves the need
> for full recalculation when the bucket count changes, which as Chris
> Pacia noted is rather annoying. The result is also considerably simpler.
>
> The spec, code and results can be found here: 
>
> https://github.com/tomasvdw/bips/blob/master/BIP-UtxoCommitBucket.mediawiki
>
> Still some work is needed to optimize the EC multiset implementation.
> Most notably the current method for normalizing a multiset to hash is
> inefficient,  but I think the results are quite promising as there is
> enough wiggle room for improvement.
>
> Tomas van der Wansem
> bitcrust
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>