asset: limit max value of issuance leaf to math.MaxUint32 #545
Conversation
This is a step towards fixing: lightninglabs#544. In this commit, we limit the max amount of an asset that can be issued at one time to math.MaxUint32. The existing 32-bit sum is left in place. This gives us enough buffer room, as we'd need 4 billion UTXOs of the same assets to overflow the root sum. In the future, we can lift this limit with future asset versions. An asset can have more than 4 billion ish units if they issue with distinct UTXOs. This value can be viewed as the max amt that can be issued in a single tranche.
Roasbeef
force-pushed
the
32-bit-issuance-max
branch
from
3f55973 to
e8ec228
Compare
|
Thinking that the amount field for addresses should now also be a uint32? And receiving more than that requires the interactive flow or multiple addresses. |
Hmm, yeah good point, hadn't thought about that interaction. In that case, it's possible to actually just re-use the address if needed. |
|
Should also update the overflow checks we have for tree leaves so we can fail earlier than taproot-assets/tapscript/send.go Line 323 in 5373ccc RPC types also need to be updated, like |
Unrelated but would be neat to signal to the sender that those two asset leaves could be merged into the same anchor output; maybe if they share the same internal key? Could also be useful for handling receiving for asset groups. |
This is a step towards fixing:
#544.
In this commit, we limit the max amount of an asset that can be issued
at one time to math.MaxUint32. The existing 32-bit sum is left in place.
This gives us enough buffer room, as we'd need 4 billion UTXOs of the
same assets to overflow the root sum. In the future, we can lift this
limit with future asset versions.
An asset can have more than 4 billion ish units if they issue with
distinct UTXOs. This value can be viewed as the max amt that can be
issued in a single tranche.