- Taproot-based OP_RETURN commitments
- New LNPBP-4 multi-protocol commitments based on merkle trees (support for using RGB alongside other client-side-validation protocols)
- State transition bundling for multi-participant transactions (required for LN, pay/coinjoin)
- Data containers (binary data for NFTs etc)
- Support for arbitrary rich data in contract state with a new schema for representing hierarchies of such data structures.
- Separation of specific schemata into independent libraries
- Introduction of AluVM virtual machine
- Bulletproofs data removed from client-side commitments
- Refactored schema type system
- 0.4.3: Fixing seal_definition old-way of sorting seals before they were held in Vec (and BTreeSet was used instead). This allows to validate multi-output transition history
- 0.4.4: Fixing broken upstream dependency breaking change in
zeroize
crate
- Disclosures
- Improved concealment procedures; fixed node id mutability issue
- Reveal-merge procedure
- PSBT anchor processing refactoring & multiple bug fixes
- Improved commit-encoding and consensus-commit procedures
- Improved owned rights type system
- RGB20: asset data representation refactoring
- RGB20: removed deprecated LNPBP-37 invoicing
- RGB20: transfer API improvements
- Lightning encoding for RGB types used in lightning messages
- Added missed StrictEncoding derives
- Consignment ids & bech32 representation
- RGB Core Library is extracted and externalized from LNP/BP Core Library
- Serde encoding fixes (proper use of
serde_as
for wrapped types) - BIP32 & descriptor enhancements
- Rust bitcoin 0.26 & Miniscript 5.0 migration
- More robust PSBT processing
- Fixed PSBT key serialization issue during commitment procedure
- Fixing serde to use Bech32 encoding for ContractId and SchemaId types
No changes since RC2
- Epic: refactoring of LNP protocols and services crate
- Epic: initial implementation of generalized lightning network
- Epic: lightning network specific encodings and derives
- CI covering different mobile & desktop targets
- New tagged hash implementation defaulting to Bech32 encoding for ContractId
- Using amplify and amplify_derive v2.4
- Fix for the broken tokio upstream dependency breaking issue
- Fix for zero-balance overflow in case of empty arguments
- Eq implementation for Schema object
- Multiple BIP-32 improvements on top of rust-bitcoin functionality
- Better CI
- Android/iOS/Windows/MacOs build fixes
- AnchorId strict encoding
- Fixed issue with broken
serde_with
macro (pinned older version in Cargo.toml) - More collection types supporting
AutoConceal
- Noise handshake
- Abstract state channels
- Payment channels
- Channel extensibility framework
- BOLT3 transaction structure for payment channels
- Additional LN peer messages supporting RGB
- Lexicographic orderings (BIP96) for transactions, PSBTs, inputs and outputs
- LN messaging & LNPWP: Lightning network peer wire protocol (BOLT-1pt2, BOLT-2)
- BOLT-8 noise encryptor and handshake implementation
- Improvements to LN-specific data types
- LNP socket and node addressing large-scale refactoring
- More serde and strict encoding implementations for data types across the library
- Implementation of strict derive macros for enums
- Debugging and display logging improvements with LNP/BP Services library
- ESB functionality improvements in LNP/BP Services libraru
- Improvements to the ESB and RPC service architectures
- Improvements to debug logging and displaying of LN messages and service information
- Enterprise system bus service type with peer addressing
- Complete set of LN peer messages from BOLT-1 and BOLT-2
- Improved logging and error handling
- Improved LNP node address conversions
This is alpha release with some major refactoring in LNP mod adding support for LN and Internet2 protocols.
- Refactoring of LNP protocol stack; introduction of Internet2 architacture
- Services crate implementing common client/server and other node architecture patterns
- Basic implementation of core Lightning network data structures
- Paradigms: generic APIs for L1/L3 best practices
- Client-side validation
- Single-use-seals
- Strict encoding
- Bitcoin protocol: extensions to
bitcoin
crate and L2/L3 APIs- Deterministic bitcoin commitments (DBC) based on LNPBP1-4 standard
- Tagged hashes: additional procedures for working with Tapproot-style tagged hashes
- Short bitcoin identifiers based on LNPBP-4 standard
- Resolver API for requesting transaction graph using providers (like Bitcoin Core RPC, Electrum Server API etc)
- Chains, chain parameters and universal asset identifiers
- Script types for differentiating script cycle through different transaction parts
- Transaction-output-based single-use-seals: bitcoin-specific implementation of single-use-seals
- RGB: confidential smart-contract system for Bitcoin & Lightning Network
based on client-side validation paradigm (LNPBP11-13 standards)
- Schema: structure defining contract creation and evolution rules and restrictions
- Contracts: data types for contract lifecycle
- Scripting with embedded procedures for fungible assets
The library implements RGB Core v1 release candidate set of standards
- Lightning networking protocol: generalized P2P and RPC networking APIs
based on the original Lightning standard; early preview
- Universal P2P node ids supporting IPv4, IPv6, Onion v2 and v3 addresses and public keys
- Feature vectors for defining and workinf with set of feature bits
- LNP networking with ZMQ sockets for RPC interfaces
- Support for Rust stable and MSRV reduction to 1.41.1
- Custom forks for upstream bitcoin-related dependencies are changed onto the latest publicly-released versions
- Updated taproot-based hashed tag system (BIP-340) according to the most recent specs.
- RGB
Amount
renamed intoAtomicValue
- RGB
amount
mod renamed intovalue
- RGB seal definitions and related structures are now
Copy
and returned by value
- Changed embedded procedure names for RGB VM
- Removed requirement for PSBT to contain fee key in RGB anchor creation (it
needs to be a properly constructed PSBT with
witness_utxo
/non_witness_utxo
data)
- More embedded procedures for RGB VM
- Schema serde serialization (YAML, JSON etc)
- Serde serialization for all RGB contract structures
- Strict encoding and decoding of Curve25519 public keys and Ed25519 signatures
- Implementation of Curve25519 public keys and Ed25519 signatures as RGB state and metadata
- Bech types for Pedersen commitments, Bulletproofs, Curve25519 data
- Tweaking factor is added into PSBT information during anchor creation
- Added bitcoin protocol resolvers API
- RGB protocol & schema versioning with feature bits
- Consignment versioning
- Changed Bech32 encodings of RGB data structures; added deflation encoding
- Implemented RGB public state extensions
- Refactored LNP addressing and it's encoding
- Completed Tor v2 and v3 addresses support
- RGB data structures naming refactoring
- Changed bulletproofs commitments which will enable future aggregation
- Introduced Chain and ChainParam types instead of old network versioning
- Test coverage >70%
- Code docs >50%
- Updated upstream crates (bitcoin, bitcoin_hashes, secp256k1, grin_secp256k1zpk, miniscript, lightning) with many PRs merged
- EmbedCommitVerify now can mutate container data (used for returning tweaking factors)
- Upgrading
rand
version to the most recent one (blocked previously by grin_secp256k1zpk dependency) - Changied txout seals to use u32 vouts instead of u16
- Changed txout blinding factor to be u64 instead of u32
- Test coverage >50% (zero-knowledge functionality & RGB contracts structures)
- Returning tweaking factors
- Minimal support for Tor V2 addresses; improved internet address parsing
- Single-use-seals blinding factor changed from 32-bit to 64-bit of entropy
- Transaction output indexes in single-use-seal definitions are now 32-bit, as in Bitcoin Core / rust-bitcoin (previously were 16-bit)
- Initial Tor V2 address support
- Test cases for BP mod strict encoding
- Complete validation workflow with new Validator object
- Virtual machines for RGB contracts (interface + embedded VM)
Consignment
now has a version field, so in the future more space-saving variants can be created (like removing txid from anchors and using short universal bitcoin IDs when BP node adoption will increase)- Anchor contains txid field; so validation can be performed with just Bitcoin Core (no Electrum or BP node is required). This also speeded up validation performance significantly.
- Change of
TransitionId
hash tag value (previously-generated transition ids will be invalid) - Change of
GenesisId
hash tag value (previously-generated contract/assets ids will be invalid) TransitionId
type is replaced withNodeId
NodeId
andContractId
are now equal by value;ContractId
isNodeId
wrapperancestors()
method moved fromTransition
toNode
trait; genesis returns an empty array- Consignment endpoints contain
NodeId
information