more clarity on how taproot assets are received
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- blockchain, documentation
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.
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
TapHrportaproot_asset_hrpwhich 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.
- Dominant language
- Markdown
- Stars
- 73
- Forks
- 73
- Avg merge
- 1h 38m
- Merged PRs (30d)
- 31
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lightninglabs/docs.lightning.engineering
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
-
Difficulty 1/5 Under an hour Newbie friendliness 55/100
All issues in lightninglabs/docs.lightning.engineering
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
MystenLabs/sui#28056 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
filecoin-project/solstice#76 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
CypherBoxLLC/Cypher-Box#283 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
blinklabs-io/bursa#904 ·