[Lightning-dev] Error Codes for LN
Hi all, I’d like to make a case for re-purposing the existing error message (17) in the spec to allow for more structured errors, and create a path for standardized, enriched errors going forward. As is: the error message contains an arbitrary string, and is used to communicate fatal errors to our peers. To (potentially) be: the error message contains an error code, and optional metadata which enriches the context of the error. There are a few benefits of upgrading these messages: * Better debugging information, and standardization across implementations * Clearer information for the end user * Reduced risk of leaking information in an arbitrary string * More fine-grained error handling based on error code Since we shouldn’t have non-ascii values in the error string itself, this can most easily be achieved by adding TLV fields after the data field. In terms of supporting nodes that have not upgraded, we could either include the error code in the data field to cover our bases, or introduce a feature bit so that we know whether to backfill the data field. This gives upgraded nodes an improved quality of life, while leaving older nodes unaffected. While we can’t enumerate every possible error, there are quite a few cases in the spec where we can introduce explicit error codes. For the sake of the skim-readers, I’ve left that list at the end of the email. Taking the example of our node receiving an invalid signature for a htlc, a new error would look like this: 1. type: 17 (`error`) 2. data [Channel_id:channel_id] [u16:len] [len*byte:data] 1. tlv_stream: `invalid_sig_tlvs` 2. Types i. type 0 (`error_code`) data: [u16: error_code] ii. type 1 (`htlc_id`) data: [u64: id] iii. type 2 (`state_number`) data: [u64: commitment_number] This new kind of error provides us with an error code that tells us exactly what has gone wrong, and metadata pointing to the htlc with an invalid sig. This information can be logged, or stored in a more permanent error store to help diagnose issues in the future. Right now, the spec is pretty strict on error handling [13], indicating that senders/recipients of errors `MUST` fail the channel referenced in the error. This isn’t very practical, and I believe that the majority of the impls don’t abide by this instruction. With the addition of error codes, we can pair each error code with a recommended action that is more appropriate for the error at hand - for example, still force closing if we get an invalid signature, but being more lenient if we get a low fee in update fee. While this may already be the case in practise, it’s messy for everybody to roll their own and then figure out what other impls are doing. With a standardized set of errors, and reasonable handling - rather than the current “close-all-da-chans” prescription in the spec - we can clear up some of the ambiguity around errors, and a spec that’s reasonable for the end user to follow. Thanks for reading! - Carla Candidates for error codes: Signature problems: * Incorrect Signature [1] [3] [7] [12] *Non-standard signature [1] [3 [7] Funding Process: * Funding process timeout [2] * Fees greater than base fee [3] * Fees out of range [3] * Funding tx spent [11] * Funding params unacceptable (eg, channel too small) Channel State Machine: * HTLC timeout [4] * Zero htlc add [5] * Htlc add less than minimum [5] * Htlc add can’t afford at current fee rate [5] * Maximum htlc count exceeded [5] * Maximum htlc in flight exceeded [5] * cltv > 5 [5] * Sub-msat values [5] * Fulfill/fail htlc id not found [6] * Incorrect commitment number [10] * Incorrect preimage [6] * Incorrect per commit secret [8] Fee Updates * Update fee to low/high [9] * Unexpected update fee [9] * Cannot afford update fee [9] Connection Level * Disconnecting * Feature bit required Gossip * Incorrect gossip short channel ID [12] [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-funding_created-message [2] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-funding_locked-message [3] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed [4] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8 [5] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-9 [6] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-10 [7] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-11 [8] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-12 [9] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-13 [10]
Re: [Lightning-dev] Escrow Over Lightning?
Good morning Andres, > Hey ZmnSCPxj, > > On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote: > > > Good morning Andres, > > > > > This looks cool but would hinder UX too much for certain scenarios: e.g. > > > if the escrow in place is part of a bitcoin exchange, then you require > > > the bitcoin buyer to have bitcoin already, which makes it harder to > > > on-ramp new users (which could maybe only have fiat). Am I right? > > > > Correct. > > Though note that existing systems like Bisq, to my knowledge, have the same > > problem, a buyer of Bitcoin has to have a small amount of Bitcoin to offer > > as stake that can be revoked in case they attempt to defraud the > > counterparty. > > Without it, the counterparty takes on increased risk (which translate to > > larger exchange spread). > > Yeah I understand Bisq's model. > However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl, > localbitcoins, localcryptos... > At least localbitcoins is custodial, and this scheme is non-custodial (though the escrow must still be trusted to actually judge correctly in case of dispute, so non-custodiality might be a very thin assurance). > > > > In any case, once you have that initial stake, you can then keep increasing > > your ability to provide stake so as to relieve your counterparties of risk > > and have them offer better exchange rates, so it is "only" an issue for > > initial onboarding. > > Presumably, in the later stable state, parents will provide children the > > initial stake needed for them to start transacting over such a system, just > > as they already provide their children with other "initial stakes" > > (education, food, shelter, etc.) anyway. > > > > > > > > So are you saying that this is not doable without PTLCs (with simple > > > HTLCs) unless it's done like suggested? > > > > Yes, it is yet another reason we want PTLCs quickly. > > > > An alternative would be to have dual-hash HTLCs, which would be helpful in > > other escrow-related cases including escrow-facilitated cross-currency > > swaps. > > Is there any disadvantage about using dual-hash HTLCs? > Is it supported by the current LN spec? It is no supported by current LN spec, and PTLCs are overall superior (they are equivalent to having any number of hashes, not just 2 that dual-hash HTLCs can do). So if we need to change the LN spec anyway, PTLCs are still the better choice, since they enable a lot more, and we probably want to support that in the future anyway, so we might as well do HTLC->PTLC rather than HTLC->2HTLC->PTLC. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
> On Feb 11, 2021, at 6:31 AM, ZmnSCPxj wrote: > > Good morning Pedro, > >> Hi Nadav, >> >> You are right that the intermediary (i.e., Ingrid) needs to hold a certain >> amount of coins to allow the virtual channel between Alice and Bob. Some >> comments here: >> - The protocol makes sure that Ingrid will get paid whatever fee she >> decides to charge for the service of creating a virtual channel. Note that >> Ingrid does not have the guarantee that enough payments would be routed >> through her node to gain the same fee in the same amount of time. > > Have not examined this deeply, but what happens if any of the *actual* > Alice-Ingrid or Ingrid-Bob channels are forced unilaterally onchain before > the purported lifetime of the virtual channel? As a safe fallback, the protocol gives time to Ingrid (or Bob depending on the case) to put the other channel onchain before the punishment can be triggered. > > Regards, > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Hi ZmnSCPxj, Not quite up-to-speed back into this, but, I believe an issue with using > feerates rather than fixed fees is "what happens if a channel is forced > onchain"? > > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is > forced onchain, and the blockchain is bloated and the transaction remains > floating in mempools until very close to the timeout of C-D. > C is now liable for a large time the payment is held, and because the C-D > channel was dropped onchain, presumably any parameters of the HTLC > (including penalties D owes to C) have gotten fixed at the time the channel > was dropped onchain. > The simplicity of the fixed fee is that it bounds the amount of risk that C > has in case its outgoing channel is dropped onchain. > The risk is bound in both cases. If you want you can cap the variable fee at a level that isn't considered risky, but it will then not fully cover the actual cost of the locked-up htlc. Also any anti-DoS fee could very well turn out to be insignificant to the cost of closing and reopening a channel with the state of the mempool these days. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
Hey ZmnSCPxj,
On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote:
> Good morning Andres,
>
> > This looks cool but would hinder UX too much for certain scenarios: e.g.
> if the escrow in place is part of a bitcoin exchange, then you require the
> bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
> users (which could maybe only have fiat). Am I right?
>
> Correct.
> Though note that existing systems like Bisq, to my knowledge, have the
> same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to
> offer as stake that can be revoked in case they attempt to defraud the
> counterparty.
> Without it, the counterparty takes on increased risk (which translate to
> larger exchange spread).
>
Yeah I understand Bisq's model.
However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl,
localbitcoins, localcryptos...
>
> In any case, once you have that initial stake, you can then keep
> increasing your ability to provide stake so as to relieve your
> counterparties of risk and have them offer better exchange rates, so it is
> "only" an issue for initial onboarding.
> Presumably, in the later stable state, parents will provide children the
> initial stake needed for them to start transacting over such a system, just
> as they already provide their children with other "initial stakes"
> (education, food, shelter, etc.) anyway.
>
> >
> > So are you saying that this is not doable without PTLCs (with simple
> HTLCs) unless it's done like suggested?
>
> Yes, it is yet another reason we want PTLCs quickly.
>
> An alternative would be to have dual-hash HTLCs, which would be helpful in
> other escrow-related cases including escrow-facilitated cross-currency
> swaps.
>
Is there any disadvantage about using dual-hash HTLCs?
Is it supported by the current LN spec?
>
> Regards,
> ZmnSCPxj
>
>
> >
> > On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj wrote:
> >
> > > Good morning Nadav and Andres,
> > >
> > > Thank you for bringing up this topic again.
> > >
> > > Let me provide a new twist to this old idea.
> > >
> > > This is the entire logic of the contract to the seller:
> > >
> > >SELLER && (BUYER || ESCROW)
> > >
> > > Now, a big issue is that simple `&&` is trivial for PTLCs, it is the
> `||` which is difficult and requires ECDH and proof that the ECDH was done
> correctly.
> > >
> > > But we can observe the De Morgan Theorem:
> > >
> > >A || B <=> !(!A && !B)
> > >
> > > So how about we *invert* the logic?
> > >
> > > So what we do is, we make *two* payments of the same amount:
> > >
> > > * Seller -> Buyer , claimable by BUYER && ESCROW key.
> > > * Buyer -> Seller, claimable by SELLER key.
> > >
> > > So the ritual is this:
> > >
> > > * Seller -> Buyer claimable by BUYER && ESCROW.
> > > * Buyer -> Seller claimable by SELLER.
> > > * Seller hands over item.
> > > * Buyer judges whether to accept, or complain to Escrow.
> > >
> > > Now let us consider our cases:
> > >
> > > * Buyer is satisfied with the product.
> > > * Buyer fails the Seller->Buyer payment after seller claims the
> Buyer->Seller payment, so Seller is paid and has no more obligations.
> > > * Buyer is dissastisfied and wants the Escrow to judge:
> > > * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer,
> who then clawbacks the payment to the seller.
> > > * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not
> ESCROW"), and the Seller->Buyer payment eventually times out, ending the
> obligation of the Seller.
> > >
> > > The "reverse" payment is effectively the inversion of logic by the De
> Morgan theorem, and the "normal case" (buyer ultimately pays seller) has
> the Escrow not revealing the privkey.
> > > In addition, in the case where Buyer is satisfied (i.e. both Buyer and
> Seller agree the trade is beneficial) the Escrow is never involved (the
> Escrow might have a timeout for the temporary ESCROW keypair, which it will
> eventually delete; since all payments on LN need a timeout anyway, this is
> fine) and thus does not know about the trade, except that some trade was
> requested (since it must provide a temporary ESCROW pubkey).
> > >
> > > This even provides a simple BUYER + ESCROW keypair that gives the
> seller a proof-of-refund, and of course the simple SELLER gives the buyer a
> proof-of-payment as well.
> > > It only just requires twice as much Bitcoins getting locked.
> > >
> > > Thoughts?
> > >
> > > Regards,
> > > ZmnSCPxj
>
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Good morning Joost,
Not quite up-to-speed back into this, but, I believe an issue with using
feerates rather than fixed fees is "what happens if a channel is forced
onchain"?
Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
forced onchain, and the blockchain is bloated and the transaction remains
floating in mempools until very close to the timeout of C-D.
C is now liable for a large time the payment is held, and because the C-D
channel was dropped onchain, presumably any parameters of the HTLC (including
penalties D owes to C) have gotten fixed at the time the channel was dropped
onchain.
The simplicity of the fixed fee is that it bounds the amount of risk that C has
in case its outgoing channel is dropped onchain.
Regards,
ZmnSCPxj
> Hi all,
>
> Things have been quiet around channel jamming lately, but the vulnerability
> it still there as much as it was before. I've participated in an (isolated)
> mainnet channel jamming experiment
> (https://bitcoinmagazine.com/articles/good-griefing-a-lingering-vulnerability-on-lightning-network-that-still-needs-fixing)
> which only confirmed the seriousness of the issue.
>
> BIDIRECTIONAL UPFRONT PAYMENT
>
> Of all the proposals that have been presented, t-bast's remix of forward and
> backward upfront payments
> (https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002862.html,
>
> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md#bidirectional-upfront-payment)
> indicates in my opinion the most promising direction.
>
> One characteristic of the proposal is that the `hold_fees` are
> time-independent. If an htlc doesn't resolve within the `grace_period`, the
> receiver of the htlc will be forced to pay the full hold fee. The hold fee
> should cover the expenses for locking up an htlc for the maximum duration
> (could be 2000 blocks), so this can be a significant penalty. Applications
> such as atomic onchain/offchain swaps (Lightning Loop and others) rely on
> locking funds for some time and could get expensive with a fixed hold fee.
>
> HOLD FEE RATE
>
> In this post I'd like to present a variation of bidirectional upfront
> payments that uses a time-proportional hold fee rate to address the
> limitation above. I also tried to come up with a system that aims to relate
> the fees paid more directly to the actual costs incurred and thereby reduce
> the number of parameters.
>
> In a Lightning channel, the sender of an htlc always incurs the cost. The
> htlc value is deduced from their balance and the money can't be used for
> other purposes when the htlc is in flight. Therefore ideally a routing node
> is compensated for the time that their outgoing htlc is in flight.
>
> To communicate this cost to the outside world, routing nodes advertise a
> `hold_fee_rate` as part of their channel forwarding policy. An example would
> be "0.3 msat per sat per minute". So if someone wants to forward 10k sat
> through that channel and the htlc remains in flight for 5 minutes, the
> routing node would like to see a compensation of 0.3msat * 10k sat * 5 mins =
> 15 sat. (it is possible to extend the model with a base fee rate to also
> cover the cost of an occupied slot on the commitment tx)
>
> The question here again is who is going to pay the hold fee. The answer is
> that it is primarily the receiver of the htlc who is going to pay. They are
> the ones that can fail or settle the htlc and are therefore in control of the
> hold time ("Reverse upfront payment")
>
> But this would also mean that anyone can send out an htlc and collect hold
> fees unconditionally. Therefore routing nodes advertise on the network their
> `hold_grace_period`. When routing nodes accept an htlc to forward, they're
> willing to pay hold fees for it. But only if they added a delay greater than
> `hold_grace_period` for relaying the payment and its response. If they
> relayed in a timely fashion, they expect the sender of the htlc to cover
> those costs themselves. If the sender is also a routing node, the sender
> should expect the node before them to cover it. Of course, routing nodes
> can't be trusted. So in practice we can just as well assume that they'll
> always try to claim from the prior node the maximum amount in compensation.
>
> This is the basic idea. Routing nodes have real costs for the lock up of
> their money and will be compensated for it.
>
> To coordinate the payment of the fees, the `update_add_htlc` message is
> extended with:
> * `hold_fee_rate`: the fee rate that the sender charges for having the htlc
> in-flight (msat per sat per min)
> * `hold_fee_discount`: the absolute fee discount (sat) that the receiver gets
> as a compensation for hold fees that couldn't be claimed downstream because
> of the grace periods (the worst case amount).
> (the previous `hold_grace_period` in `update_add_htlc` is no longer needed)
>
> When an htlc is resolved, the receiver of
[Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Hi all,
Things have been quiet around channel jamming lately, but the vulnerability
it still there as much as it was before. I've participated in an (isolated)
mainnet channel jamming experiment (
https://bitcoinmagazine.com/articles/good-griefing-a-lingering-vulnerability-on-lightning-network-that-still-needs-fixing)
which only confirmed the seriousness of the issue.
BIDIRECTIONAL UPFRONT PAYMENT
Of all the proposals that have been presented, t-bast's remix of forward
and backward upfront payments (
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002862.html
,
https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md#bidirectional-upfront-payment)
indicates in my opinion the most promising direction.
One characteristic of the proposal is that the `hold_fees` are
time-independent. If an htlc doesn't resolve within the `grace_period`, the
receiver of the htlc will be forced to pay the full hold fee. The hold fee
should cover the expenses for locking up an htlc for the maximum duration
(could be 2000 blocks), so this can be a significant penalty. Applications
such as atomic onchain/offchain swaps (Lightning Loop and others) rely on
locking funds for some time and could get expensive with a fixed hold fee.
HOLD FEE RATE
In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims to relate
the fees paid more directly to the actual costs incurred and thereby reduce
the number of parameters.
In a Lightning channel, the sender of an htlc always incurs the cost. The
htlc value is deduced from their balance and the money can't be used for
other purposes when the htlc is in flight. Therefore ideally a routing node
is compensated for the time that their outgoing htlc is in flight.
To communicate this cost to the outside world, routing nodes advertise a
`hold_fee_rate` as part of their channel forwarding policy. An example
would be "0.3 msat per sat per minute". So if someone wants to forward 10k
sat through that channel and the htlc remains in flight for 5 minutes, the
routing node would like to see a compensation of 0.3msat * 10k sat * 5 mins
= 15 sat. (it is possible to extend the model with a base fee rate to also
cover the cost of an occupied slot on the commitment tx)
The question here again is who is going to pay the hold fee. The answer is
that it is primarily the receiver of the htlc who is going to pay. They are
the ones that can fail or settle the htlc and are therefore in control of
the hold time ("Reverse upfront payment")
But this would also mean that anyone can send out an htlc and collect hold
fees unconditionally. Therefore routing nodes advertise on the network
their `hold_grace_period`. When routing nodes accept an htlc to forward,
they're willing to pay hold fees for it. But only if they added a delay
greater than `hold_grace_period` for relaying the payment and its response.
If they relayed in a timely fashion, they expect the sender of the htlc to
cover those costs themselves. If the sender is also a routing node, the
sender should expect the node before them to cover it. Of course, routing
nodes can't be trusted. So in practice we can just as well assume that
they'll always try to claim from the prior node the maximum amount in
compensation.
This is the basic idea. Routing nodes have real costs for the lock up of
their money and will be compensated for it.
To coordinate the payment of the fees, the `update_add_htlc` message is
extended with:
* `hold_fee_rate`: the fee rate that the sender charges for having the htlc
in-flight (msat per sat per min)
* `hold_fee_discount`: the absolute fee discount (sat) that the receiver
gets as a compensation for hold fees that couldn't be claimed downstream
because of the grace periods (the worst case amount).
(the previous `hold_grace_period` in `update_add_htlc` is no longer needed)
When an htlc is resolved, the receiver of the htlc will pay the sender the
`hold_fee_rate` minus `hold_fee_discount` (exact details of how to
integrate this into the channel state machine and deal with clock shift
tbd).
It is up to the sender of a payment to construct the onion payloads such
that all nodes along the route will have their costs covered.
EXAMPLE
A > B > C > D
Every node charges 0.6 msat/sat/minute with a hold grace period of 1
minute. In this example, the routing fees are zero.
A wants to send 1000 sat to D.
A will charge B a hold fee rate of 0.6 sat/min (1000 sat at 0.6
msat/sat/min). B will charge C a hold fee rate of 1.2 sat/min to cover both
its own cost and what must be paid back to A. C will charge D a hold fee
rate of 1.8 sat/min to cover the costs of A, B and C.
D has a grace period of 1 minute. At the 1.8 sat/min fee rate that C
charges, D would need to pay a maximum of 1.8 sat if it meets its grace
deadline just in time. C pays the 1.8 sats to D as
