- Refactor LNP/BP Core library into client-side-validation library with
core
,bp
and (future)mw
. Move ElGamal, Bech32 and tagged hash intocore
- Refactor single-use-seals; finalize API
- Move
chain
to BP Core library - Finalized string representation for bitcoin seals data
- Removed unused
seals::tx_graph
API
- Serde serialization/deserialization for DBCs and multimessage commitments
- Chain type improvements: signet support, native asset types
- Bech32 helpers
- Resolvers API improvements
- Tagged hashes refactoring
- Script type system convertors
- Client-side-validation v0.4 with multiple commitment structure improvements
- Compressed Bech32 encodings with derivation strategy
CompressedStrictEncoding
- Bech32 encodings (LNPBP-39 & general traits)
- Fixed tagged hash midstate representation
- RGB Core Library is extracted and externalized from LNP/BP Core Library to https://github.com/rgb-org/rgb-core
- LNP Core Library is extracted and externalized from LNP/BP Core Library https://github.com/LNP-BP/lnb-core
- Internet2 repo & crates are extracted & externalized from LNP/BP Core Library https://github.com/internet-org/rust-internet2
- Bitcoin descriptors wallet repo & crates are extracted & externalized from LNP/BP Core Library to https://github.com/LNP-BP/descriptor-wallet
- Repository split into multiple crates (lnpbp, client_side_validation, strict_encoding, strict_encoding_derive)
- Serde encoding fixes (proper use of
serde_as
for wrapped types) - Miniscript 4.0 & bitcoin 0.26 migration
- Refactored unified network address format & encodings (inside strict_encoding)
- Refactored deterministic bitcoin commitments (LNPBP-4)
- 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
- AchorId 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 library
- 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