lightninglabs / lightninglabs/docs.lightning.engineering

more clarity on how taproot assets are received

Open
#733 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Markdown
Stars
73
Forks
73
Avg merge
1h 38m
Merged PRs (30d)
31

Description

I think there needs to be more clarity on how taproot assets are received. There are some key differences between normal bitcoin transactions.

Need to add/change some things here: https://github.com/lightninglabs/docs.lightning.engineering/blob/dede15c7582612cc2de21517825added28a5aad0/the-lightning-network/taproot-assets/taproot-assets-protocol.md?plain=1#L141-L149

  • Need to standardize on TapHrp or taproot_asset_hrp which is used at https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-addr.mediawiki

  • A taproot asset address includes a specific amount that can be received. We need some explanation on why that also has to be included.

  • When a sender sends taproot assets, they make an on chain transaction. They also mush share proof data as well. That needs to be published via a universe server, or they need to send it via hashmail. The taproot asset address format includes a hashmail server for the sender to use to communicate this information. If the receiver never gets the proof, the sender never proved they actually did it, so it's almost as if the payment was never made. So, it's critical that the receiver get this information too.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the taproot-assets-protocol.md section at lines 141-149 and compare its terminology with the referenced BIP tap address specification. Update the documentation to cover the address amount, on-chain transaction, proof delivery, universe server, and hashmail points, while standardizing the HRP name. Done means the receiving flow and required proof communication are clearly explained.

Written by the indexing model from the issue text.

Assessment

Domain
blockchain, documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.