Skip to content

Lightning Specification 1.1 Proposal States

Jump to bottom
ZmnSCPxj edited this page Jun 11, 2019 · 12 revisions

Index of Accepted Proposals

  • to-remote to use static address
    • option_static_remotekey (peer feature: 38/39)
  • Add symmetric CSV delay commitment outputs
    • _option_static_remotekey)
  • One "pushme" output for each of to_local/to_remote
  • Add 2-byte error codes
    • option_error_codes (peer feature: 10/11)
  • Should ping before sending commitment signed
  • Define inline BIP69
  • Splicing w/ renegotiated channel params!
    • Splice out w/ upfront shutdown script
    • option_splice (peer feature: 12/13)
  • Wumbo bit for large channels
    • option_i_wumbo_you_wumbo (peer feature: 14/15) - I want to wumbo with you
    • option_wumborama (channel feature: 16/17) - I want to wumbo with everyone
  • Dual funded channels, maker advertisement
    • option_dual_fund (peer feature: 18/19)
    • option_will_fund_for_food (peer feature: 20/21)
  • RBF for funding txns, continue on ML
    • option_splice
  • 2p-ecdsa for private channel funding
    • option_2p_ecdsa (peer feature: 23/24)
  • Extra Onion Blob decoding
  • Base+OG AMP
    • Needs BOLT11 option (node may not be public).
    • BOLT11 letter '9', followed by feature bits (0 = base amp, 1 = OG amp?)
  • Document non-strict forwarding
  • Rendezvous routing proposal
    • BOLT11 letter 'v'.
    • option_switch_ephkey (channel feature: 36/37)
  • Protocol-level ACK/soft errors
  • DNS queries + global list
  • New scid format
  • INV gossip
    • option_inv_gossip (peer feature: 24/25)
  • Set-reconciliation gossip
    • option_fec_gossip (peer feature: 26/27)
  • Maximum CLTV of 2016
  • Chain hashes in Init message
  • Schnorr gossip messages
    • option_schnorr_gossip (peer feature: 28/29)
    • Nodes generate & relay both, unless EVEN bit is set: then don't send old ones.
  • Separate port for gossip/ephemeral gossip pubkey
  • Channel range queries w/ timestamps
    • option_channel_range_timestamps (?)
  • Channel_announcement + channel_close w/ merkle proofs
    • option_offer_tx_proof (peer feature: 30/31)
    • option_want_tx_proof (peer feature: 32/33)
      • Global option allows lite nodes to find nodes which offer.
  • Block header forwarding (in ping?)
    • Uses odd message, not a new feature bit.
  • channel_update really_really_really_disable bit 2
    • Does not need explicit feature.
  • Soft error support:
    • option_status (?)

Accepted Proposal List

The attendees edited a Google Doc, which became a rough agenda in which the decisions were noted. These have been preserved below:

Simple Protocol Modifications

  • Nodes SHOULD NOT offer less than 2000 satoshis for a channel.
  • Nodes SHOULD NOT offer to_self_delay > 2016.
  • SHOULD NOT offer minimum_depth > 10
    • Reason: Recognizes existing limits
  • Nodes SHOULD offer dust_limit_satoshis of 546
    • Reason: Simplicity?
  • Nodes MUST set max_accepted_htlcs to 483.
    • Reason: there's no reason not to accept (then fail) htlcs.
  • to_remote output key is static, not rotated:
    • This removes requirement for option_data_loss_protect my_current_per_commitment_point field
  • Add delay to both sides of a unilateral close
    • Symmetry removes game theory where I try to get you to close and vice-versa.

Probing and Errors

  • New return message of same format as error (ie. must be tied to an HTLC)
    • Soft error: “HTLC STUCK MORE THAN 30? SECONDS” (intermediate node)
    • “HTLC PARTIAL RECEIVED” (final recipient) for AMP.
    • Add node_announcement (ie. global) feature bit and define soft error message format
  • Proper error codes
    • DECISION: add 2 byte code (append for backwards compat)
    • (DECISION: defer programmatic payload)
  • Switch to encrypt-then-mac, using mac-then-encrypt atm (for final error payload)
    • DECISION: document why, or fix it.
  • Nodes SHOULD ping ahead of commitment_signed if no recently received traffic
    • Should prevent many stuck HTLCs.
  • Nodes SHOULD randomly probe network with circular payments (or maybe fake payment_hash)
    • Triggers detection of dead channels.

TX And Fees

  • Remove BIP69 reference, incorporate exact specification into BOLT#3.
  • Use CPFP and P2WSH(OP_TRUE) output
    • RBF is impossible for uncooperative close, and CPFP doesn't work with CSV delayed outputs, and guessing what future fees will be at commitment time is impossible.
    • sighash single+anyonecanpay on 2nd level txes to allow batching and fee increase
    • Long discussion: RBF rules and package size rules for bitcoind's mempool make avoiding the possibility of blocking with low-fee giant tx difficult. But outputs should be spent-by-anyone to avoid UTXO bloat.
    • DECISION: Feerate 253 sat/kSipa. One 1000-satoshi "pushme" output for each to_local/remote (ie. iff they exist). Script uses same pubkey as to_local/remote, OR 100-CSV delay (once in chain, turns into anyone can spend once they see the to_local/remote spend).
    • DECISION: commitment_tx fees are always paid by open_channel sender (initiator).
    • DECISION: requires slight bitcoind exception to exceed package size as special case to avoid corner case DoS possibility.

Funding and Splicing

  • Reanchoring/Splicing
  • Dual Funded channels
    • Needs exact details for how each side specifies what utxos to use (backwards compat!).
    • Funding tx fees are always paid by open_channel sender (initiator).
    • Closing negotiation goes as current, but starting with >= current commitment_tx fee + push-button outputs as lowest possible fee amount.
  • Advertisement of offer to dual funding, as per https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html
  • Define global feature bit for using 2of2 for private channels
    • If both sides offer, and do not both say they want channel public, use this construction
    • Avoids problem that gossip channel_announce assumes current construction.
    • Conner to write up details.

Routing and Onions

  • 'realm' byte becomes 'type' byte.
    • Instead of defining what chain to use, top bit means "next 32 bytes are the chainid".
    • Lower 4 bits are how many hops_data to consume (minus one) -> [1 - 17] hops.
    • To be bikeshedded on-list:
      • Do we use zero next addr and consume the hmac?
      • Do we have two signalling types, the intermediate and the exit hop?
      • Can the signalling hop also allow you to consume data? (the 12 bytes)
  • "Base AMP" is to be implemented with an onion flag to tell final node to wait for more payment.
    • This could be a flag in the BOLT11 invoice, or global feature.
    • This provides Proof-of-Payment, but no decorrelation between paths.
  • "Original AMP" is also to be implemented, similarly needs bolt11 flag or global feature.
    • Provides decorrelation between paths, but no Proof-of-Payment.
    • Spontaneous payment as subset of OG AMP.
  • Document that scid is not binding, allow extra channel_updates in errors for “upselling”.
  • Rendez-vous routing (CJP, cdecker):
    • New global "I understand rendezvous" feature bit.
    • Include the ephemeral key switch at the rendez-vous point: Only requires a global feature bit to signal ephkey switching support and the multi per-hop payloads to include the ephkey at that hop
    • Recommend nodes creating payments sometimes use this spontaneously.
    • DECISION: Ack pending analysis, needs new bolt11 field.
    • Design document
  • DNS seeds DECISION: needs proposal for filter by global feature bits / tor address? DECISION: better care and feeding of DNS seeds, and set up global list.

Gossip Changes

  • Short-channel-ids should be formatted as 2223x4456x1: decimal, x-separated
  • INV (inventory) based gossip
  • Ann tuples:
    • Chan update: (chanID, updateTime, flags)
    • Node ann: (nodeID, updateTime) <- use chanID/direction instead of nodeid.
    • Chan ann: (chanID, updateTime)
    • DECISION: Ack, need detailed proposal.
    • DECISION: MC to propose set reconciliation.
  • Extend init to have num_chain_hash and chain_hash fields.
    • Helps you tell if you are interested in any chains peer is.
  • Moving to Schnorr signatures on announcements/updates
    • DECISION: Use Schnorr-BIP. New channel_announce2(?) Debate removal of chain_id for bitcoin mainnet. New local bit. Create proposal on-list.
    • Consider channel_update2 maybe to also remove chain_id?
  • Updating channel range queries to include timestamps See https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001426.html and https://github.com/lightningnetwork/lightning-rfc/issues/480
    • DECISION: Accept, local feature, new message types
  • Forwarding Bitcoin data over the overlay
    • channel_announcement proofs
      • channel_announcement_plus_proof (channel_announce + tx + merkle)
    • channel_close proof
      • A new msg with tx and proof.
      • DECISION: Bikeshed on list?
    • Bitcoin block header forwarding
      • 80 bytes every 10 minutes
      • DECISION: Bikeshed on list?
  • channel_update permanently-close bit
    • really_really_really_disable (bit 2).
    • DECISION: yes (and also set disable bit for backwards compat).

Deferred Decisions

  • RBF for funding transactions? (Conner)
    • Can add/remove new inputs (ie both sides double-spend at least one input)? Or only pull from existing inputs?
    • New message type.
  • Actually need maps for optional fields to work properly?
    • TLV? (type, length, value)
    • Top-level keys should be unique
    • Can add arrays/dictionaries as subtype
    • DECISION: Agreement, but we don’t have an immediate need (wait until we do).
  • Elimination subsatoshi amounts as an option
    • Just set min_htlc amount, and add 999 msat to base fee.
    • DECISION: defer
  • Reliable/provable error return chain-of-custody
    • Attributable errors
    • Sign with signature as well
    • Able to then use to prove failures
      DECISION: Rusty to write up scheme, rewrite several times, if sane, post. DEFER
  • DoS Avoidance by Onion Unwrapping
  • Increasing maxchannel capacity:
    • Define WUMBO bit.
    • "Wumbology" is the study of wumbo and anything that is or of a wumbo nature
    • Applies iff both sides flag it. SHOULD be explicitly requested by user. Defer?
  • Link-level payment splitting:
    • an htlc came on an incoming chan, to the next hop i have 4 chans, neither of these chans themselves can carry the htlc, this would let me split the htlc at the link level and send 3 htlcs
    • Fee schedule: use one fee/timelock policy for all channels between two nodes? Simplifies routing/gossip, decreases failure rates (between multi-channel peers) since intermediaries can use local knowledge of channel balance to split payment
    • DECISION: proposal on list, bikeshed there.
  • “Local routes” for advertising private channels
  • HORNET
    • DECISION: defer
  • Commit to version properly in onion payload
    • DECISION: fix this when we introduce non-0 version!
  • Key rotation onion blob
    • DECISION: discuss on-list, what messaging, what timing.
  • “Backbone” channels for fast routing sync?
    • A roughly agreed (rotating) subset of channels which get send in gossip sync first
    • DECISION: defer, needs proposal on list.
  • fee functions
    • Should time lock also become a factor in the fee function? The sender tries to weigh in time lock during path finding, but for intermediaries there is no extra fee for long time locks.
    • DECISION: defer needs more research
  • Standard format for LApps to get an invoice from LN wallet
    • "lightning:" format is recommended in BOLT #11 when requesting lightning payment from LApps to LN wallet. I think that opposite way is also needed, that is, a case that LApps want to send lightning payment to LN wallet seamlessly.
    • Spontaneous and recurring/streamed payments (shachain, or similar)
    • Continuous Payment Chunk (like coupon tickets)
    • LApps like pay-per-click needs to issue many invoices for api provider to receive lightning pay. It is possible to implement on application side but overhead for payment process is very large. "Streaming Payments" is a solution for it. Payment amount is changeable for one invoice (one preimage hash) by delaying to send preimage but receiving lightning pay by "Streaming Payments" is not continuous but just last and it needs user permission to pay for each amount changes. "Continuous Payments Chunk" is a way to receive many lightning payments by just one invoice. This way is to make one invoice include several preimage hashes such as 100 hashes and limit payment amount for one preimage hash in advance in order to make seamless lightning payments with just the first user permission securely.
      • Easier post-Schnorr
    • Actual “Proof that I paid” instead of “proof that someone paid”. Maybe it can only be done interactively (payer passes pubkey to payee, payee includes pubkey in invoice) ?
      • Payee sends encrypted 32 bytes to payer. Encryption key for this data is payment preimage. Payer can show decrypted form of 32 bytes to prove that it received the payment preimage, and if payee->payer channel is secure, only the payer could have gotten the encrypted 32 bytes. When decrypted form is presented by the payer, it shows (1) the payer paid (since they could decrypt it) and (2) the payer is the one that was given the encrypted 32 bytes in the first place. If the product being sold is a digital good, it could be an activation key or decryption key for the digital good, without requiring an external court system to enforce the exchange.
      • Easier post-Schnorr
    • Updateable / revokeable proofs of payment (e.g. for refunds). Updates will of course require signatures from affected parties, and if applicable the preimage of an update payment.
    • DECISION: Defer on-list discussion...
  • Decorrelation
    • DECISION: start work but no time pressure, at least before 1.2/2.0
Clone this wiki locally