Skip to content


OlKo edited this page Apr 1, 2022 · 39 revisions

Welcome to the devcalls wiki!

Forthcoming devcall agenda:

Date Call type Topic
Apr Community LN & Bifrost workflows demo. LN Q&A session

Backlog (WIPs to cover on the future calls once the topic is ready):

  • Changes to RGB LN. Bifrost protocol design. Issuer meta-info management
  • Demos: secondary issuance of RGB20 assets; burning. NFT (RGB21) and identity (RGB22, 24) basics
  • Progress on Internet2 protocol design and software stack (community)
  • LNP/BP Association: projects overview, roadmaps, membership, funding (community)
  • Storm basics: simple prepaid data storage over LN (community, core devs)
  • DEX protocol design (core devs)
  • RGB/DLC/LN integration (core devs)
  • Taproot in rust-bitcoin, RGB & LN (core devs)
  • RGB technical internals parts IV-IX (core devs)

If you develop software using RGB or other LNP/BP technology and have something to discuss or present (do a demo of it) - please contact @dr_ukolova on Telegram directly or on @rgbtelegram group and we will add you to the agenda

Historical devcall agenda:

Date Topic Materials
22 Mar Agenda:
Presentation of 🔥Deterministic bitcoin commitments and ways of how Taproot modernizes RGB.
1. Update - the day before rust miniscript made a first release-candidate providing full Taproot support, removing many obstacles for RGB and rust-bitcoin. Thus, we will have a sequence of releases (0.6) of all our libs that will have full Taproot support.
2. Agenda to discuss:
a) OP_RETURN commitment scheme,
b) to put all RGB commitments inside the bitcoin transaction into a single output and change the selection mechanism of determining the output in which the RGB commitment will go,
c) use all that to avoid interactive complexity and privacy leaks that happen in LN, conjoin, payjoin protocols.
More details:
1. What are DBCs, how are they different from other types of commitments (OP_RETURN, P2C, S2c)?
- is it that the hardware wallets don’t need to tweak the output now or they already need to tweak the normal Taproot tweaking in the first place, so we’re basically delegating the tweaking complexity that hardware wallets would be facing to the taproot abilities themselves, but in a way if you spend a Taproot output which the end user Tapscript with or without the OP_RETURN inside the tap script, you will need the hardware wallet to tweak the general taproot key?
2. Huffman Merkle tree.
- Can we just duplicate the commitment on both sides of the branch?
Conclusion - it’s decided to support both OP_RETURN and Tap_Return.
3. How to construct multiparty transaction and avoid interactive protocols and RGB asset information leaks?
4. RGB workflow with DBCs.
- Will we always use 1 input and 1 output?
- Does taproot simplify the RGB wallet implementation?
- How dramatic would be these improvements in terms of bitcoin blockchain space?
- So, if you implement OP_RETURN in addition to Tap_Return, will Taproot support still be mandatory for RGB wallets?
- Are there any proposals for proof-of-payment (against the third party) mechanism?
9 Mar Agenda:
1. Presentation of a dedicated initiative for support of 🇺🇦Ukraine internet, mobile and mesh network infrastructure; development of alternative bitcoin- & lightning-based payment and messaging methods.
2. Presentation of the 🔥 2022 roadmap towards a release, pinpointing ways of how anyone can contribute.
3. Q&A session:
- NFT over LN use case
- algorithmical stable coin use case
- Since hashrate follows price, could hashrate or difficulty be used to peg a stablecoin?
- Are there any plans for a daemon management utility for desktop or servers (without needing systemd)?
- We tried to derive from the 'seed phrase' the bitcoin addresses (from descrptor wallet), but we couldn't find out which derivative path was used.
So question: how to calculate the correct descriptor wallet addresses based on the seed?
22 Dec Agenda:
During the call we had the third part of the presentation and demonstration our 🔥LNP Node (Lightning Network node written in Rust🦀 ). We managed to open the first Lightning network channel from LNP Node to a remote c-Lightning; on 🔥Bitcoin mainnet🔥.
Q&A session questions:
1. When will Bifrost be released?
2. I noticed you recommended bip43 purpose keys - will you also support bip44 hardened keys?
3. will there be a demo on the smart contract part of rgb anytime soon? if not how far away are we?
4. How big is the team?
15 Dec Agenda:
During the call we had the second part of the presentation and demonstration our 🔥LNP Node (Lightning Network node written in Rust🦀 ):

- technical deep dive on the node’s internals
- its interoperability with LN
- its connection to c-lightning node
Q&A session questions:
1. Really interested in PTLC and how it would be possible to work with it using LNP Node.
2. Is the LNP Node a prerequisite to building a Rust compiler?
3. What is the reason of maintaining the backwards compatibility between Bifrost and 'legacy LN'?
4. Given different primitives that would allow you to tap into Lightning for liquidity; and because of the way RGB is built, you can build a multisig and bunch of signers of a particular issuance of an asset, and then there can be someone else who can issue another type of asset and he also has the whole setup. Is there any format or way to talk across these issuances so that you could do interesting things cross-asset?
08 Dec Agenda:
The devcall consists of:
1. Second part of the demo of 🔥Descriptor wallet (using Bitcoin mainnet and Taproot-enabled addresses). For more details check
Transactions publicly made for the first time by the descriptor wallet, on 🔥Bitcoin mainnet🔥 to 2 Taproot addresses:
2. First part of 🔥 LNP Node demo and presentation on its internals and changes that have been made to it over the past weeks.
Q&A session questions:
1. I had problems compiling to WASM in past versions, there are some plan to compile to WASM in the future?
2. For next CLI devcalls. can we have the material to compile to follow your presentation?
01 Dec Agenda:
Dr. Maxim Orlovsky gives a presentation and the first part of demonstration of the 🔥Descriptor wallet with Taproot support - explained its technical architecture and used Bitcoin mainnet. Descriptor wallet repository for more details
1. What are input descriptors?
17 Nov Agenda:
Dr. Maxim Orlovsky gives a presentation on 🔥Taproot, Bitfrost and single-use seals - the changes that are brought by Taproot and Bifrost (Generalised Lightning Protocol) to the single-use seals and many core RGB design principles. Peter Todd, Giacomo Zucco, Federico Tenga and many others gave their feedback and approval on various matters.
03 Nov Agenda:
1. Introduction and tech dive into 🔥 Bifrost protocol.
. Q&A session:
- Are the new LNPBPs already written?
- Will the number of different channel types become ever a problem - for example, must every node have channels of each types to use them?
- I've understood that it's going to be released at the end of the year, what is going to be released exactly (sorry if it is said, but i lost the sound sometimes)?
- As a not hard core developer it's difficult to imagine the use cases, could we start a brainstorm with some people what kind of dreams we will accomplish?
- Are there working examples of some RGB operations over Bifrost? Can i work my way to make some RGB transfers in Bifrost with the code published now?
- How will nodes be incentivised to store Bifrost data?
- Why is it not possible to keep using a legacy channel with the legacy LN connection when you upgrade the channel to Bifrost ? What makes it impossible to "separate states" between legacy and bifrost transactions?
- I guess ANYPREVOUT would be very nice for Bifrost? What about other possible bitcoin future softforks?
22 Sept Agenda:
Q&A session
- Is the amount of UTXO, to which a specific RGB asset is assigned, a hidden or public information
- My question is about RGB Node, now is break for the updating in RGB Core and RGB-20, is going to be released updated soon? It's going to have much change respect what we have today, apart from adapting to changes in another libraries?
- What is the link between AluVM and Contractum?
- AluVM will be included on the next reales and be required to run RGB? How RGB-20 is impacted? Can we say AluVM is the current way to do client-side validation?
- Does Bitcoin Pro have to be updated for AluVM?
- In your opinion, what would be the better way to implement LLVM IR to AluVM bytecode? LLVM IR compiling to bytecode or (as you mentionned in a previous call) LLVM IR translated into ALU asm via parser? Or other way like o a Rust pest project? (LLVM IR -> Aluasm). Same questions for WASM - AluVM
- Can RGB be compatible with ZK-Rollups? I understand Roll-up is not preferred. But is it viable as an immediate interim solution to bring already built solutions to RGB before pure client side validation is built?
- Is the unowned state is still a subject? What is it exactly?
- What is a valency in the context of RGB?
- What is the state of LNP in the scope of RGB? How is client-side validation done with LN? Is Francisco ready to dive in this?
- If I have RGB assets assigned to a Bitcoin UTXO and I want to run this UTXO in a CoinJoin, what will happen? Will I loose my RGB assets?
08 Sept Agenda:
1. Presentation of 🔥RGB roadmap: a way towards release.
2. Q&A session:
- Will the exchange rate be always RGB-token/BTC or you there will be RGB-token1/RGB-token2?
- I have the impression that MyCitadel wallet is IOS/macOS that true?
- Do you expect any resistance to current nodes switching to Bifrost?
- How the main lightning implementations devs received the idea to add Bifrost to their own implementation?
- Do you recommend the use of rust-lightning?
- What is the risk of keeping all data on Bifrost instead of locally? Just fees for storage?
- What would be the incentive to run a Bifrost node?
- What happens if we do not have capacity to receive data locally are we aren't using Bifrost? Does transaction get rejected?
- How is the data availability ensured with some/many nodes going offline?
- Will MyCitadel beta be back soon? Or do you plan to release the first non beta version along with RGB in the end of the year?
- What happens if the client-side data is lost (worst case scenario)? Would it affect any smart contract applications?
- To come back to the exchange rate rgb-token/BTC vs rgb-token1/rgb-token2, the principle of "coincidence of wants" would point that it would be more efficient and profitable to price anything into the hard money, aka BTC, as you would have more liquidity and that if you want to go from RGB-token1 to RGB-token2, you would have better offers if you do an indirect exchange through BTC.
- What are the limitations of client-side validation?
25 Aug Agenda:
1. Presentation of 🔥 AluVM Assembly, compiler and linker demo.
2. Q&A session
- How do I do to have the syntax colours for the asm in the IDE?
- Are there any working examples of RGB smart contracts written in Contractum?

Links from the call:
4 Aug Agenda:
Presentation of 🔥 RGB programmability - how to design and program RGB smart contracts.
21 July Agenda:
1. Presentation of 🔥RGB computational model (PRISM).
2. Q&A session:
- How badly Disclosure process exposes your privacy?
- If RGB smart contracts are isolated, can they still cooperate/share information between each other?
- If in Stash many parties can contain alternative histories, how to define which history is the true one?
- I believe that the RGB20 and RGB21 contracts written in rust already existed before AluVM, will there be a reimplementation of RGB20 and RGB21 in AluVM scripts?
- Do you have any further insight into when RGB will work on lightning?
14 July Agenda:
Development update and RGB Q&A session.
1. Category Theory resources: introductory course, additional link.
2. Does category theory has impact on AluVM?
3. Is there a standard in RGB (or bitcoin) in denoting a utxo output e.g. in a single use seal?
4. Does a routing node just need to know about the asset, or do the channels have to be for that RGB asset as opposed to regular NTC LN channels?
5. If an asset created with RGB becomes very valuable, or you just have many of them, you might not want to have it on a lightning hot wallet. Since to move the assets, only a regular BTC signature on a PSBT is required, it should be possible to safeguard those assets in the same cold storage as your regular BTC. The only hard requirement to the cold storage is that it can sign PSBTs. I don't think there should be a problem with multisig here. But in order to be sure you sign the right thing, the cold storage should have some knowledge of the assets that are moved. How could this look like?
6 . If i'm reckless, can I use RGB on mainnet? Is there any precedent of issuing rgb asset on mainnet?
7. There is an idea to put a NFT (the RGB equivalent) in an Opendime to transfer some properties physically. So, on the Opendime attached on the artwork you will have the NFT certificate version of the artwork. Can it be possible with RGB NFTs?
8. RGB and existing Lightning Nodes implementations (e.g. LND).
9. DEX devepoment - progress update.
30 June Agenda:
1. Development and documentation updates.
2. Q&A session:
- How to solve the double issuing problem when the issuing is private?
- Will there be a vanity asset id generator? (vanity = with friendly first asset id characters)
- How can AluVM optimize or control the behavior of assets in a lightning channel?
- Is it possible to use AluVM to write an auction contract "using sats" or bidding?
- Can you talk more about the decentralized data storage for RGB21? Who pays for the storage and who will pay for it in the future?
3. Preliminary introduction of the research on Sigchain and Sealchain concepts, carried out by Dr. Maxim Orlovsky and Pandora Core AG.
16 June Presentation on 🔥Taproot status, its implementation in Rust Bitcoin and Lightning Network upgrades required for Taproot support.
We also gave an overview of the possibilities it brings to the LNP/BP stack & ways the LNP/BP Standards Association and Pandora Core AG contribute to Taproot's development.
9 June Presentation of 🔥 AluVM and its runtime environments Audio
1 June 1. Presentation on 🔥 Single-use seals concept, how it is used in RGB.
2. Brief discussion on DID held as an example of how single-use seals can be applied there (with Christopher Allen from Blockchain Commons/Blockstream joining us).
26 May 1. Description of the features that are already a part of RGB and the ones that are going into production with new release.
2. Q&A session:
- Mainnet/testnet/signet in Bitcoin and LN - RGB perspective.
- Bifrost - what’s the idea and functionality of it?
- Is RGB in production?
- When RGB mainnet?
- Why is the smart contract system part of the MVP when it was not needed before?
- Is simplicity going to be used?
- What is this contractum? Is it a yet another completely new thing?
- Plans for the following months.
- How to track RGB progress and contribute to it.
19 May Presentation of 🔥 AluVM (virtual machine developed by @dr_orlovsky for RGB) and overall computing that can be possible with RGB & Schema. Audio
12 May 1. Technical updates on RGB development (client-side validation)
2. Q&A session:
- Have you thought about bad actors trying to patent stuff, like someone sees something in here and then tries to patent it?
- What are the time estimates and release dates of Storm, Bifrost and other components?
- Do you need Taproot?
- Does lightning support have external dependencies like smth needs to happen in Bitcoin Core or elsewhere (like rust-bitcoin) in order to enable lightning for RGB?
- Smart-contracts and client side validation - RGB POV and high level explanations.
- Are you planning a future conference?
- Do you have plan to work on "channel factories" ?
05 May Presentation on 🔥 RGB 2021 roadmap & beyond:
1. Technical details behind new version of client-side-validation library.
2. Updates on deterministic bitcoin commitment standards.
3. Thoughts on RGB layers & LightningNetwork (LN dissection).
4. LNP/BP technical roadmap.
28 Apr Community-driven call, where community members tried to install RGB Node, issue assets using CLI tools and Bitcoin Pro, transfer assets from Bitcoin Pro to MyCitadel wallet after downloading it from Testflight etc. Audio
7 Apr Presentation on 🔥 RGB Identity, Naming and Reputation Audio
31 Mar 1. RGB v.1 and RGB v.2 overview
2. Development updates:
- Completing the development of disclosures
- Use cases for burn & replacement procedure
- NFT progress
- Subschema for simplified RGB20 asset without replacement procedure
- Data containers API
- RGB20 secondary issuance
- Improving and extending general API to work with state transitions etc

3. Virtualisation of RGB validation rules:
- What is RGB client-side validation?
- Schema & scripting
- Introduction of 🔥 AluVM and Contractum language
24 Mar Presentation on 🔥 NFT-related RGB Schemata & protocols:
1. Implementation progress & updates.
2. Moving from genesis-based information transmission to consignment-based.
3. Subschemata: overview and usage in RGB20 use case.
4. Anarchic DRM systems.
5. How to sell usage rights without onchain transactions.
6. Introduction of Data containers.
7. Introduction to Bifrost.
8. Virtualization of client-side validation.
18 Mar Building RGB adoption presentation:
- Intro. RGB vs Ethereum and 'Multi blockchain world'
- RGB mission & core drivers for its adoption
- LNP/BP Association tools
- Internet 2 architecture
- Bitcoin Pro, Citadel SDK, MyCitadel Node, MyCitadel box, MyCitadel cloud
- Introduction of 🔥 - the first RGB explorer for publishing and sharing information about your assets
- Dev vacancies & Fundraising info
10 Mar Double consignments updates.
Multiple asset transfers
Revealed-merge procedure
Command-line tools: PSBT, RGB, Invoice.
3 Mar 🔥 MyCitadel Wallet Beta release

Components of the wallet:
1. MyCitadel Node -
2. MyCitadel UI -
3. RGB Core library -
4. RGB Node -
5. LNP Core Library -
6. LNP Node -
7. Descriptor wallet -

Other links from the call:
* Universal Invoices: Video, Slides
* Bitcoin Pro asset issuance tool -
Video [WIP]
24 Feb Development updates from @dr-orlovsky
Recap on transition mutability refactoring on the previous week
Review of quality assurance issues from
Priorities for further development process
Developer Q&A
Update Stash merge logic to account for previously known transition data. Ref PR
17 Feb RGB NFT Q&A
🔥 Demo of MyCitadel Node CLI
10 Feb RGB QA session
Wallet integration
Wallet demo
3 Feb Brief demo of RGB working with real-life software (Bitcoin Pro and MyCitadel wallet by Pandora Core)
Proposal to create standards that would cover the ways to visually represent the client-side functionality that is not a part of Core RGB Library and protocol
Overall technical update
RGB workflow diagram
Android bounty bug
27 Jan Presentation on 🔥 RGB Wallets integration:
- diagrams explaining how the wallet part of the business logic, storage etc. should be done in order to use RGB SDK;
- PSBT structure required for RGB work with hardware wallet
- universal invoices updates
- use of Bech32 encodings in RGB & LNP/BP tech stack.
20 Jan Dev updates and future roadmap:
- updates on related projects: rust-bitcoin & rust-miniscript
- updates on refactoring LNP/BP Core Lib and info on new crates (wallet descriptors, RGB Core, LNP Core, Internet2)
- moving repositories into project-specific github orgs (RGB-org, Internet2-org)
- v0.3.0 release of LNP/BP Core Lib, RGB Core Lib & RGB Node
- proposed architecture for mobile wallets using RGB+LNP Node
- RGB/LN invoicing protocol: aspects related to mobile payment
13 Jan 2021 Agenda for LNP/BP Standards Association
🔥 Presentation of the LNP/BP Core Lib BP module: Video, Slides
17 Dec Docs & community updates: RGB Reddit, RGB FAQ website.
Releases: LNP Node v0.2 beta 2, RGB Node v0.2, librgb v0.2 release candidate, RGB SDK updates.
🔥 Universal LNP/BP invoices standard proposal presentation Slides, Video
9 Dec Release of v0.2 of LNP/BP Core Library
Difference between Bitcoin Pro and MyCitadel wallet
How will Taproot affect RGB?
WASM & bindings of RGB SDK
Channel data inconsistency between peers issue
Brief introduction of Universal LNP/BP invoices (BP+LNP+RGB).
2 Dec Presentation of 🔥 Bitcoin Pro
Technical discussion
25 Nov Updates from the call with Ledger
RGB-21 Collectible Schema
18 Nov RGB branding
RGB-20 Schema update:
- removed dust limit
- multiple inflation rights with better control over total inflation
- epoch-based burn and burn-and-replace procedures; enhanced with UTXO set and versioned proofs of burn data, supporting up to 15 burn proof variants (+"no proofs" option)
- asset renomination procedure, for changing asset names or splitting stock shares after @sabina_sa proposal
- standardisation of contract text URL and commitment format
- rights split procedure
Asset name registries and asset name length issues.
12 Nov Reduce asset name length limit - Issue #74
PSBT and deterministic bitcoin commitments / public key tweaks - Issue #69
OP_RETURN - is there still the need in it, should we support it?
Support of multiple assets and funding the LN channel with assets 'on the flight'
Solving the problem of American Call Option
Sign-to-contract and Pay-to-contract schemes
Simplicity language support in RGB (update)
Andrew Poelstra's work on bringing Buletproofs to lib secp256k1 (update)
5 Nov 🔥 LNP Node 0.1 Alpha 4 Demo Audio
28 Oct Presentation of 🔥 LNP Node 0.1 Alpha 1 Audio
21 Oct 1. Releases: LNP/BP Core Lib v0.1, RGB Node v0.1, Amplify library v.2.0, image for RGB Node v0.1, docker v1.1 repo release (RGB+Lightning+Electrum Server).
2. Lightning Network: Generalized payment channels, LNP Node architecture, Universal protocol for node operations, Internet2 stack.
3. Wallet integration: RSBT-based workflows, APIs for read-only access, DBC tweaks of pub keys issues.
4. Protocol future: NFT transfers in Generalized LN with channel factories, UDP hole punching, sign to contract instead of pay to contract commitments, MW-like Pedensen commitment aggregation for the historical data, Merge-mined chain allowing excellend scalability with single-key-per-block concept.
5. Related updates from other projects: proposals for onion messaging BOLT extensions from Rusty Russel for new extenstions allowing non-payment (i.e. generic) messaging; Simplicity in elements/liquid beta; Schnorr signature implementation PR for rust-secp256k1 by Tibo from Digital Garage.
14 Oct RGB-20 Schema update:
- removed dust limit
- multiple inflation rights with better control over total inflation
- epoch-based burn and burn-and-replace procedures; enhanced with UTXO set and versioned proofs of burn data, supporting up to 15 burn proof variants (+"no proofs" option)
- asset renomination procedure, for changing asset names or splitting stock shares after @sabina_sa proposal
- standardisation of contract text URL and commitment format
- rights split procedure
7 Oct 1. Roadmap:
- new release roadmap
- explanation of the relations between LNP/BP Core lib and RGB Node/SDK
- RGB Core roadmap
- RGB LN roadmap
- RGBv1 and what it means

2. Releases:
- Amplify
- Docker containers big update: Bitcoin Core, c-Lightning, ElectrumRs, Elements & RGB Node
- readiness of LNP/BP Core Library first release (v0.1)
- updates on RGB security audit started last week

3. Decisions taken throughout the week & implemented:
- RGB versioning: Schema feature bits
- Storage of whole chain parameters in Genesis, committing only to chain hash
- Reversed schema hierarchy
- Public state extensions: decentralized issuance & "call to contract method"
- Changes to bulletproofs from the week before
- Bech32 encodings for RGB & invoicing

4. Protocol future:
- NFT transfers in generalized LN with channel factories
- Sign to contract instead of pay to contract commitments
- MW-like Pedersen commitment aggregation for the historical data
- Merge-mined chain allowing excellent scalability with single-key-per-block concept

5. Related updates from other projects:
- proposals for onion messaging BOLT extensions from Rusty Russel for new extensions allowing non-payment (i.e. generic) messaging
- Simplicity in elements/liquid beta
- Schnorr signature implementation PR for rust-secp256k1 by Tibo from Digital Garage.
30 Sep 1. RGB protocol
- New unified invoicing proposal with protocol layerization, extensibility, interoperability
- Bech32 encodings for invoicing & RGB-related data entities

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
- How it is used
- More LN-specific asset details for asset geneses
- RGB versioning clarification

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

- 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

2. Dev updates
Notable releases:
- amplify & amplify_derive crates v1.0 release with extensive test coverage using GitHub actions. Repo:
Updated Docker images for bitcoin, c-lightning, elements, electrs & RGB Node with better Signet support released to Docker Hub and GitHub

Completed implementation of Bulletproof commitments (implemented and merged)

- Key management & signing functionality within LNP Node will help wallet devs with this part of functionality. Unfortunately 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
23 Sep 1. Ongoing developments
Last beta 4 pre-release before RC1
Invoicing protocol:
- LNURL downsides
- new LN developments (lni, lno, lnr by Rusty Russel)
- possible applications of the above for RGB LN workflows
- miniscript/descriptor bitcoin invoices with TLV-LN style
- results of research and plans for RGB universal invoicing

PSBT development:
- main format for data storage & exchange
- brining rust-bitcoin libraries closer to full implementation
- Schema/Genesis: versioning, chain params
- Implications: DEX outside RGB in LN

2. Closing old discussions: Monero buletproofs, lexicographic output ordering.
3. CI & infrastructure: Dockerization (full set up images), Signet & Lightning, exhaustive tests
4. Future protocol developments: Zk: bulletproofs aggregation, decentralized issuance with public transitions
5. Tasks for community discussion: LNP-BP/LNPBPs#57, LNP-BP/LNPBPs#46, LNP-BP/rust-lnpbp#104
Clone this wiki locally