mirror of
https://github.com/bits-wallet/specs.git
synced 2025-12-17 05:34:21 +01:00
Update 02.md
This commit is contained in:
86
02.md
86
02.md
@@ -1,56 +1,52 @@
|
|||||||
|
|
||||||
BDS-02
|
|
||||||
|
|
||||||
|
CDS-02 Metadata Structure
|
||||||
======
|
======
|
||||||
|
|
||||||
Expiring Channel Addresses
|
Metadata Structure
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
`draft` `mandatory` `author:brqgoo`
|
`draft` `mandatory` `author:brqgoo`
|
||||||
|
|
||||||
This BDS defines a non-interactive channel opening scheme.
|
|
||||||
|
|
||||||
## Rationale
|
## Metadata Structure
|
||||||
|
|
||||||
Today, funding outpoints must be known before establishing a new channel to craft a refund from the 2-of-2 multisig. This has three main drawbacks:
|
### img_content_prefix
|
||||||
|
| Type | Description | Size |Bytecode |
|
||||||
|
|--------------------|--------------|--------------|--------------|
|
||||||
|
| _file_hash_ | 32-byte IPFS file hash | 1 | 0x00 |
|
||||||
|
| _url_png_ | PNG URL | 2| 0x01 + _url_len_|
|
||||||
|
| _url_jpg_ | JPG URL | 2 | 0x02 + _url_len_ |
|
||||||
|
| _url_jpeg_ | JPEG URL | 2 | 0x03 + _url_len_ |
|
||||||
|
| _url_gif_ | GIF URL | 2 | 0x04 + _url_len_ |
|
||||||
|
| _url_svg_ | SVG URL | 2 | 0x05 + _url_len_ |
|
||||||
|
| _url_webm_ | Webm URL | 2 | 0x06 + _url_len_ |
|
||||||
|
| _url_mp3_ | MP3 URL | 2 | 0x07 + _url_len_ |
|
||||||
|
| _url_mp4_ | MP4 URL | 2 | 0x08 + _url_len_ |
|
||||||
|
| _url_fvg_ | FVG URL | 2 | 0x09 + _url_len_ |
|
||||||
|
| _url_wav_ | WAV URL | 2 | 0x0a + _url_len_ |
|
||||||
|
| _url_ogg_ | OGG URL | 2 | 0x0b + _url_len_ |
|
||||||
|
| _url_clb_ | CLB URL | 2 | 0x0c + _url_len_ |
|
||||||
|
| _url_gltf_ | GLTF URL | 2 | 0x0d + _url_len_ |
|
||||||
|
|
||||||
### On-chain footprint
|
### collectible_metadata
|
||||||
Cannot allow batch openings, consuming more on-chain footprint. A third party (i.e. on-ramp exchange) cannot open a channel for two other parties (between the user and LSP), among other outputs. Note that Vortex enables batch openings as a side result but requires interactivity pre-channel formation.
|
| Type | Description | Bytes | vBytes |
|
||||||
|
|--------------------|--------------|--------------|--------------|
|
||||||
|
| _name_len_ | _uint8_t_ size of _name_ | 1 | 0.25 |
|
||||||
|
| _name_ | Name of the issued collectible | 0-40 | 0-10 |
|
||||||
|
| _description_len_ |_uint8_t_ size of _description_ | 1 | 0.25 |
|
||||||
|
| _description_ | Description about the issued collectible | 0-255 | 0-63.75 |
|
||||||
|
| _img_content_prefix_ | Type of the _img_content_ | 1 or 2 | 0.25 or 0.5 |
|
||||||
|
| _img_content_ | The image content of issued collectible | 6-40 | 1.5-10 |
|
||||||
|
| _optional_data_len_ |_uint8_t_ size of _description_ | 1 | 0.25 |
|
||||||
|
| _optional_data_ | Optional data push | 0-255 | 0-63.75 |
|
||||||
|
| _attributes_num_ | Number of _attributes_, 1-20 in decimal range | 1 | 0.25 |
|
||||||
|
| _attributes_ | Attributes | 3-65535 | 0.75-16383.75 |
|
||||||
|
|
||||||
### On-chain privacy
|
### collectible_payload
|
||||||
In comparison to batch openings, regular channel establishments are less privacy-preserving. Funding transaction consumes one or more inputs, a channel output, and a probabilistic change. It might have two changes if dual-funded. On-chain observers MAY have an idea whether this might be a funding transaction.
|
- The number _u_ of number of collectibles being minted.
|
||||||
|
- For _i = 1 < u< 2<sup>16</sup>_:
|
||||||
### Convenience
|
- - Let _collectible_metadata_len<sub>u</sub>_ = [Prefix compact size](https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer) of _collectible_metadata<sub>u</sub>_
|
||||||
Inconvenient for onboarding new users who have no UTXO possession in the beginning.
|
- - Let _collectible_metadata_con<sub>u</sub>_ = _collectible_metadata_len<sub>u</sub>_ || _collectible_metadata<sub>u</sub>_
|
||||||
|
- - The _collectible_payload_ : bytes(_u_, 2) || _collectible_metadata_con<sub>u</sub>_
|
||||||
## Specification
|
|
||||||
`Channel addresses`, as seen [here](https://burakkeceli.medium.com/channel-addresses-bd85e9ab8fe1) and [here](https://rubin.io/bitcoin/2021/12/11/advent-14/), make it possible to craft on-chain bitcoin addresses such that whenever funded by someone, becomes a payment channel between the user and the channel partner (LSP), where the channel funds are initially kept on the user's side. Channel address require new additions to the bitcoin scripting system, and planned as a future extension under [BDS-19](https://github.com/bits-wallet/specs/blob/main/19.md).
|
|
||||||
|
|
||||||
`Expiring channel addresses` proposes a much more primitive version of channel addresses that can be built on Bitcoin today. If we add to the 2-of-2 musig inner key a single-leaf script path after a relative locktime to the user, similar to pre-segwit timeout channel design, it becomes no longer necessary to craft a refund transaction in advance of funding the output. If the channel partner (LSP) is non-collaborative in exchanging signatures for a refund once the address is funded, the user can exit from the script path after the expiry. Ultimately, it's LSP's responsibility to close the channel shortly before its expiry. While this may seem a bad idea from an on-chain footprint standpoint, we anticipate users to mostly receive funds over silent swaps and only rarely receive on-chain through expiring channel addresses.
|
|
||||||
|
|
||||||
- The nostr parent secret key _nsec_: a 32-byte array.
|
|
||||||
- The nostr parent public key _npub_: _cbytes(int(nsec)⋅G)_.
|
|
||||||
- The tweak derivation secret _ds_: a 32-byte array.
|
|
||||||
- The number _u_ of child keys _2<sup>32</sup>_.
|
|
||||||
- Let _ds_ = _hash<sub>BDS-02 dersec</sub>(nsec)_.
|
|
||||||
- For _i = 1 .. u_:
|
|
||||||
- - The BDS-02 child secret key _sk<sub>i</sub>_.
|
|
||||||
- - The BDS-02 child public key _pk<sub>i</sub>_.
|
|
||||||
- - pk<sub>i</sub> BIP-340 tweak t<sub>i</sub> : 32-byte array.
|
|
||||||
- - Let _t<sub>i</sub>_ = _hash<sub>BDS-02 tweak</sub>(ds || bytes(32, i))_.
|
|
||||||
- - Let _pk<sub>i</sub>_ = _cbytes(npub + int(t<sub>i</sub>)⋅G)_.
|
|
||||||
- - Let _sk<sub>i</sub>_ = _bytes(32, (int(nsec) + int(t<sub>i</sub> )) mod n)_.
|
|
||||||
|
|
||||||
- For _i = 1 < u< 2<sup>32</sup>_:
|
|
||||||
- - The _to_self_ : 32-byte x-only user child public key.
|
|
||||||
- - The _to_remote_ : 32-byte x-only well-known LSP public key.
|
|
||||||
- - The _keygen_ctx_ : MuSig2 keygen context containing the aggregate key.
|
|
||||||
- - Let _to_self_ = _cbytes(pk<sub>i</sub>)_.
|
|
||||||
- - Let _to_remote_ = _cbytes(bytes(33, 0x025de7cd8fd3a0a38f1cab124defd4c3043203c3f2b66328484e321d3ede5f84f6))_.
|
|
||||||
- - Let _keygen_ctx_ = _KeyAgg([to_self, to_remote])_.
|
|
||||||
- - The _ex_ : a 2-byte minimally encoded channel expiry as relative locktime.
|
|
||||||
- - The _ts_ : a 39-byte raw tapscript for a non-interactive refund closure.
|
|
||||||
- - Let _ex_ = _CScriptNum(26280)_.
|
|
||||||
- - Let _ts_ = `<ex> OP_CHECKSEQUENCEVERIFY OP_DROP <to_self> OP_CHECKSIG`.
|
|
||||||
- - Let _ts<sub>hash</sub>_ = _hash<sub>TapLeaf</sub>(0xc0 || 0x27 || ts)_.
|
|
||||||
- - Let _ts<sub>tweak</sub>_ = _hash<sub>TapTweak</sub>(xbytes(keygen_ctx<sub>Q</sub>) || ts<sub>hash</sub>)_.
|
|
||||||
- - Let _keygen_ctx'_ = _ApplyTweak(keygen_ctx, ts<sub>tweak</sub>, true)_.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user