bolts
bolts copied to clipboard
lightning
BOLT: Basis of Lightning Technology (Lightning Network Specifications)
Draft spec for adding 'liquidity ads' to the dual-funding flow. Allows peers to signal fees that they'll charge for committing liquidity into a dual-funded open, which are then locked until...
Based on ~https://github.com/lightningnetwork/lightning-rfc/pull/862~ https://github.com/lightningnetwork/lightning-rfc/pull/869: We use the interactive tx construction protocol to make a splice: 1. Initiator pays for input and output, sets fees. 2. You can do more than...
This commit adds the interactive transaction construction protocol, as well as the first practical example of using it, v2 of channel establishment. Note that for v2 we also update the...
Route blinding allows a recipient to provide a blinded route to potential payers. Each `node_id` in the route is tweaked, and dummy hops may be included. This is an alternative...
Adds a feature bit. It's optional, but does simplify some of the spec logic and I think it's nice to have. The naming can change. It works with simple-taproot-channels to...
This PR puts forth two concepts: 1. The concept of an "extension BOLT", which is a single documentation extension to the _base_ BOLT spec that references existing "base" BOLTs with...
Offers
Offers are "static invoices", with many more features. This is mostly implemented in c-lightning already, and is now ready for wider testing. This PR is based on onion messages specified...
Dependent on PR https://github.com/lightning/bolts/pull/851
These use onion encoding for simple one-way messaging: there are no error returns. Any reply is done with an enclosed blinded path, a-la @t-bast (in fact, this is based on...
I am a little confused about the fee_range requirements for coop close. I asked some clarifying questions of @t-bast in https://github.com/lightning/bolts/pull/847#discussion_r893605295: "Yes, fee_range allows the funder to update its fee_range...