Releases

Roadmap: #29
Tracking RGB Core release: #26

LNP/BP Core Lib v0.1
- https://github.com/LNP-BP/rust-lnpbp/releases/tag/v0.1.0
- https://crates.io/crates/lnpbp
RGB Node v0.1
- https://github.com/LNP-BP/rgb-node/releases/tag/v0.1.0
- https://crates.io/crates/rgb_node
Amplify library v2.0 https://crates.io/crates/amplify
Docker
- image for RGB Node v0.1 https://hub.docker.com/layers/lnpbp/rgbd/v0.1.0/images/sha256-e0d6f7b0e7b8da32c77026d43df2674df6d9069bf93f415b91e8f15a62947100?context=explore
- docker v1.1 repo release (RGB + Bitcoin + Lightning + Electrum Server): https://github.com/LNP-BP/docker/releases/tag/v1.1.0

Features:

Supporting Rust stable and down to v1.41! Removed all unstable language components
No more upstream forks, for now dependencies are only on published bitcoin-related crates (miniscript v2, bitcoin v0.25, latest bitcoin_hashes with Taproot updates, removed unstable lightning dependency)
SQLite support for RGB Node by @rajarshimaitra

RGB SDK https://github.com/LNP-BP/rgb-sdk is prepared for the release this week by @zoedberg

Lightning Network

Generalized payment channels and relation to RGB and LN Node
LNP Node architecture and overall design approach to node architecture
Universal protocol for node oprations (RGB, LNP, Bifrost ...): node ids, compatible messaging system & message ids (see details in last call agenda) LNP-BP/LNPBPs#55. Explanation on RGB peer network and Bitfrost peer network as a part of Lightning peer network. Considerations and discussions.
Generalized Lightning networking on top of alternative transports (Websocket, HTTP overlay, SMTP, messaging) and RPC stack with ZMQ et al
Ongoing work on structuring Internet2 stack as a set of Lightning related networking protocols on top of Tor

Explanations on matters related to DBC tweaks of public keys: lessons learned from Liquid LNP-BP/LNPBPs#69 Excerpt: After discussion with Andrew Poelstra it became obvious that the previous decision of storing public key tweak information within PSBT as a single value (LNP-BP/rust-lnpbp#86) will be insecure and incompatible with hardware signing units, wallets or airgapped solutions. The problems is that the device must be able to verify what is hidden behind the tweak, otherwise it will be possible for a malware to change the tweak in such a way that it will substitue the underlying state transition with some other (assigning assets to the thief-controlled UTXOs) or, even, apply some taproot-based alternative spending conditions.
PSBT-based workflows LNP-BP/LNPBPs#71
Simple APIs for read-only access RGB-WG/rgb-node#84

NFT transfers in generalized LN with channel factories
UDP hole punchng discussion results LNP-BP/LNPBPs#39 and overall UDP support + Dazaar/Hypercore integration
Sign to contract instead of pay to contract commitments LNP-BP/LNPBPs#65
MW-like Pedensen commitment aggregation for the historical data LNP-BP/LNPBPs#57
Merge-mined chain allowing excellend scalability with single-key-per-block concept

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.