Use 32-bit sizing for MPC trees

[dr-orlovsky]

This PR changes the maximum MPC (LNPBP4) tree size to be 2^32 (depth = 32) from depth=16 before. This implies:

• maximum Merkle proof (used in consignments) length changes from 16 hashes to 32 hashes (512 bytes to 1kB)
• maximum storage requirement for stash data per witness tx increases from 100kb to ~20MB
• maximum memory requirement for hardware wallets increases from 100kb to ~20MB
• maximum memory requirement for producing new witness transactions (like in exchanges) increases to ~10 GB

Fixes #128 based on top of #131

Some test results:

Tree with 2'048 protocol-messages: depth 19, cofactor 2. Serialized length 270'353 bytes
Tree with 4'096 protocol-messages: depth 21, cofactor 29. Serialized length 540'689 bytes
Tree with 8'192 protocol-messages: depth 23, cofactor 97. Serialized length 1'081'361 bytes
Tree with 16'384 protocol-messages: depth 25, cofactor 46. Serialized length 2'162'705 bytes
Tree with 32'768 protocol-messages: depth 26, cofactor 265. Serialized length 4'325'393 bytes (14 sec)
Tree with 65'536 protocol-messages: depth 29, cofactor 30. Serialized length 8'650'769 bytes (33 sec)
Tree with 131'072 protocol-messages: depth 30, cofactor 298. Serialized length 17'301'521 bytes (~1min

We see that the time growth is linear and that a normal desktop machine (like mine) can easily handle up to hundred of thousand of different assets put into a single UTXO - making the case for exchange-scale tasks. Taking into account that in Ethereum there are "just" ~2 million contracts, all their state can be assigned to just 8 UTXOs (with RGB/LNPBP4) - that should be good scalability I think and we do not need more.

[cryptoquick]

Agreed, 100k contracts should be plenty enough!

[cryptoquick]

According to the Bitcoin OpTech tx size calculator, a P2TR tx with 100 inputs and 100 outputs would be a little over 10k sats. That means ~39,700 outputs could be spent and created in a single block. Multiply that by 131,072, and we get an upper bound of 5,203,558,400 different contract state transitions per block (though I might be comparing apples and oranges). Theoretical max TPS is ~8,672,597 (600s), though this figure is largely nonsense. It just gives an idea of potential to scale using, say, a federated wallet.

[dr-orlovsky]

and we get an upper bound of 5,203,558,400 different contract state transitions per block

not state transitions, contracts! Each contract may have multiple state transitions (up to the number of inputs).

[dr-orlovsky]

Overall, we can fit the evolution of the Ethereum state into a single bitcoin transaction - so that should be enough for the scalability.

By "massaging" the depth of the non-common denominator search (sacrificing performance) I think we can get up to a million contracts into the same UTXO, so that should be enough!

[cryptoquick]

ACK

[zoedberg]

ACK