Skip to content

Latest commit

 

History

History
160 lines (141 loc) · 8.17 KB

2020-09-30-agenda.md

File metadata and controls

160 lines (141 loc) · 8.17 KB

Dev call 30 Sept 2020

RGB Protocol

Invoicing

  • New unified invoicing proposal with protocol layerization, extensibility, interoperability:
    • "Payment specification" layer. Current example - Bitcoin addresses. Will be extended for RGB with new types from this table:
      • Blinded UTXO (RGB-specific)
      • Descriptor-based (can be used for Bitcoin also). Hints:
        • Deterministic key derivation with block height
        • In RGB we can make keys truly random since we know payment txo anyway from the consignment
      • PSBT-based (can be used for Bitcoin!)
      • Channel (LN)-based: not the same as BOLT-11, but just a node id, address and routing hints
    • "Invoce" layer (current example - BOLT-11, parts of the proposed BOLT-12/13)
      • Just an LN message serialized into Bech32 format!
      • Now LN messages can be send over non-interactive or high-latency networks (mesh, satellite, SMTP/mail, messengers/tweets)
      • Very extensible: TLVs, new message types. Making new invoice type is just like defining new LN message: decentralized
    • "Interactive payment protocol" layer (current examples - BIP70, LNURL, BOLT12 from above)
      • Potentially should work with any invoice and data type (it is the case for LNURL already; will try to direct BOLT12 into this; BIP70 is depricated anyway)
      • We will have Bifrost for RGB-related interactivity; it will utilize LN messaging format so complete invoice data workflow (offer/request/invoice/ failback/alternative) may fit into bech32-encoded strings as described below:
  • Bech32 encodings for invoicing & RGB-related data entities
    • Any message can be serialized with <4hex>_lnp1bechdata, or for known formats <id>[_<4hex>_lnp]1bechdata (this is interoperable with Russel new invoices), for instance inv1invoicedata can be a universal invoice message.
    • Bech32 for raw data (non-LN messages) will use normal HRPs, so this is backward-compatible with current Bech32 use, and will fit well with RGB- related Bech32 for hashes (RGB contract id, schema id etc) and data types. See sample implementation in https://github.com/LNP-BP/rust-lnpbp/pull/112/commits/485ea355e625624aba40679f134be94cd47882d5
    • Public keys & LN node ids can also use Bech32 encoding with pk_ prefixes:
      • pk1keydata - for public keys
      • pkx1keydata - for extended public keys
      • pkn1keydata - for node ids in LN (b/c of the unification, see below, this id will work with LN, RGB network & Bifrost) This can potentially replace multiple formats (WIFs, hex encoded keys, BASE64 encoded xpubs and serve the original goals for which Bech32 encoding was proposed.

Schema, genesis, versioning

  • Schema extensibility for things like multiple asset schemas: instead of extending schema, we will have one "most advanced" schema with all features (for assets, NFTs, reputation etc) and smaller sub-schemas which will commit to the most advanced schema for which they are just a subset. It will resolve security considerations by Alekos Filini and allow simple wallet adoption of new asset schema types.
  • Interoperability & networks explanations and structuring:
    • P2P network differentiation (P2pNetworkIds and NetworkMagic)
    • Layer 1 differentiation: ChainHash and ChainParams
    • Xpub/Xpriv specifics: ChainCode
    • Bringing it all Layer 1 stuff together with single & simple Chain
    • Asset cross-layer differentiation (on-chain ChainHash, Liquid CA, RGB, OMNI): AssetId
  • How it is used:
    • Schema do not commit to anything
    • Genesis commits to chain hash, but stores full set of chain params
    • This is why genesis needs a "data structure version" flag in chainparams field (to allow chain params extensibility), and must represent a list of data, starting from the first version
    • LN nodes uses AssetId as a ChainHash to identify in which "network" they operate/accept channels
  • More LN-specific asset details for asset geneses: LNP-BP/LNPBPs#60
  • RGB versioning clarification:
    • Schema has a version identifying RGB protocol version LNP-BP/LNPBPs#45. An RGB contract genesis (asset issuance) commits to Schema and thus to a specific RGB protocol version forever: no "forks"/version upgrades within single contracts, but different contracts from different issuers may operate on different RGB versions
    • Consignments use "serializetion version" field indicating network serialization format used for data transfer. Receiver specifies desired/ supported formats as a part of invoice data. This allows more efficient compression of network-transferred data (like use of bulletproof/pedersen aggregation, shor bitcoin ids)
    • Genesis uses version for ChainParams field data structure (see above), which has nothing to do with protocol or serialization version. Receiver do not need to specify version in invoice, since all legacy versions are always included.

Protocol unification

  • Proposed invoicing protocol operate not only with RGB, but also can be used for native bitcoin on-chain and LN payments.
  • API/message type unification for RGB Node, Ligthning network (all nodes) and future Bifrost. Now node type will be defined just by the set of features, and networks can inter-operate.
  • RGB Node, LNP Node and Bifrost will be unifiable into a single piece of software, so wallet devs will be able to use just a single integration point to run RGB onchain, RGB lightning & native lightning payments.

Other

  • Decentralized issuance & "call to contract method": public extensions to RGB contract state proposal & PR to the core library
  • Mimblewimble-style Pedersen commitment aggregation & history cut-through better privacy concept for the future & updated RGB scalability roadmap

Dev updates

Notable releases

Completed implementation

WIP

  • Key management & signing functionality within LNP Node will help wallet devs with this part of functionality. Unfortunatelly we can't use BDK since it lacks RGB specific PSBT key type support (for Pk tweaks) and Xpub/Xpriv other chains, so LNP/BP Core library will include special mod for all necessary extensions to Xpub/Xpriv keys and PSBTs, as well as signers, based on miniscript, supporting necessary RGB functionality. See sections above on more details to Xpub/Xpriv specifics.
  • Better test coverage approaching ~60% for the Core Library and ~100% for the underlying amplify crate, including new exhaustive tests for some encodings covering all possible encoding options.
  • Better code docs: ~50% for the Core Library & 100% for the underlying amplify crate.

Related updates from other projects

  • Proposals (first, second) for onion messaging BOLT extensions from Rusty Russel for new extenstions allowing non-payment (i.e. generic) messaging.
  • Simplicity WIP branch in elements/liquid beta
  • Schnorr signature implementation PR for rust-secp256k1 by Tibo from Digital garage.