addr: create new multi-addr scheme to support receiving fungible assets with a group key #291
Description
Today addresses contain the asset ID that the party wants to receive. This works mostly, but once you want to receive one of many possible tranches of a fungible asset with a group key, things break down a bit.
Group Asset ID Multi-Addrs
Consider that an asset group G, may have distinct asset IDs {A, B, C}. The way addresses work today, the receiving party explicitly says that want asset A, as they need this to be able to look for the asset anchoring output on chain. If the receiver doesn't know what the sender will send ahead of time, then this falls short.
One solution to the above is that the address lists a set of asset IDs (in addition to the main group key). With this, they can watch for all 3 potential versions on chain. This works for simple cases where the sender has an asset UTXO that precisely sized to pay K units to the sender. However, things break down once again when you factor in the scenario where the sender has some/all of the asset IDs, and can solve the subset sum problem to send a total amount (eg: 3 units of A, 2 of B, 1 of C).
Unknown Asset Group Amount Distribution
The core issue with the above is that the receiver doesn't know the amount distribution that'll be sent to satisfy the spend. If both sides are communicating, then this isn't as issue as the vPSBT flow can be used.
Late Binding of Split Amounts
In the past, we made some changes to the way splits work to make them less tightly bound. Eg: the split asset has an all zero prev ID, as the receiver doesn't know what inputs will actually be spent.
I think we can extend that further for this special address type, by allowing the amount to be bound by the split inclusion proof itself. In this case, the amount of the leaf on chain will be zero. The asset inserted into the split commitment tree will instead carry the value distribution (it must by definition to prevent asset inflation). When validating the split inclusion proof this value will be assumed, and when spending the asset this is the value that'll be inserted into the input sum tree.
The main quirk of this is that if sending all 3 asset IDs mentioned above, then 3 outputs are required: the receiver is looking for all 3, then knows how to assemble the split proof needed to send them. It's possible to only have a single top-level output be created on chain. In this case, the receiver also looks for the combinations of the asset, and makes a new tree composed of those.