Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

universe: resolve overflow issues, use distinct issuance + transfer trees #544

Closed
3 tasks
Roasbeef opened this issue Oct 3, 2023 · 1 comment
Closed
3 tasks

universe: resolve overflow issues, use distinct issuance + transfer trees #544

Roasbeef opened this issue Oct 3, 2023 · 1 comment
Assignees
@Roasbeef @ffranr
Labels
mainnet preparedness Goal issues to be completed before mainnet release needs triage universe

Comments

@Roasbeef
Copy link
Member

Roasbeef commented Oct 3, 2023

This is a simple variant to: #479. Rather than introduce 128-bit integers, which'll need some custom DB extensions to support properly, we instead aim to go with a simpler approach, leaving room for future protocol versions to go with a 128-bit sum value.

Steps To Completion

  • Enforce a max issuance value of a 32-bit value. This just restricts the amount that a single issuance UTXO can create. A single transaction can create more units with bundled UTXOs in the some genesis transaction. Most assets won't feasibly run through the entire 64-bit unit space. For the Universe issuance trees for grouped assets, the limit applies there as well.
  • Modify the Universe transfer tree to use a sum value of 1 everywhere. This makes the value more useful, as it's no longer summing different units. Instead it represents a count of the total number of registered transfers.
  • Split the issuance + transfer trees across the RPC API and database. This simplifies syncing, as you have two roots, if one isn't present, then you know that they don't have transfers or otherwise.
@Roasbeef Roasbeef added universe needs triage mainnet preparedness Goal issues to be completed before mainnet release labels Oct 3, 2023
Roasbeef added a commit to Roasbeef/taproot-assets that referenced this issue Oct 3, 2023
@Roasbeef
asset: limit max value of issuance leaf to math.MaxUint32
9da3366 
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 Roasbeef mentioned this issue Oct 3, 2023
Closed
@dstadulis dstadulis moved this from 🆕 New to 🏗 In progress in Taproot-Assets Project Board Oct 4, 2023
@Roasbeef Roasbeef mentioned this issue Oct 4, 2023
Merged
Roasbeef added a commit to Roasbeef/taproot-assets that referenced this issue Oct 4, 2023
@Roasbeef
asset: limit max value of issuance leaf to math.MaxUint32
d8d4a0f 
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
Copy link
Member Author

Fixed by #564

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Roasbeef Roasbeef

@ffranr ffranr

Labels
mainnet preparedness Goal issues to be completed before mainnet release needs triage universe
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Roasbeef @ffranr