Good morning t-bast,
> > An issue with the bidirectional upfront/hold fees is related to trustless
> > offchain-to-onchain swaps, like Boltz and Lightning Loop.
> > As the claiming of the offchain side is dependent on claiming of the
> > onchain side of the trustless swap mechanism, which is
Good morning Joost and Z,
So in your proposal, an htlc that is received by a routing node has the
> following properties:
> * htlc amount
> * forward up-front payment (anti-spam)
> * backward up-front payment (anti-hold)
> * grace period
> The routing node forwards this to the next hop with
> *
Good morning Bastien, Joost, and all,
An issue with the bidirectional upfront/hold fees is related to trustless
offchain-to-onchain swaps, like Boltz and Lightning Loop.
As the claiming of the offchain side is dependent on claiming of the onchain
side of the trustless swap mechanism, which is
Hi Bastien,
I brought up the question about the amounts because it could be that
>> amounts high enough to thwart attacks are too high for honest users or
>> certain uses.
>
>
> I don't think this is a concern for this proposal, unless there's an
> attack vector I missed.
> The reason I claim
Good morning Bastien,
> > C can trivially grief D here, making it look like D is delaying, by
> > delaying its own `commitment_signed` containing the *removal* of the HTLC.
>
> You're right to dive into these, there may be something here.
> But I think your example doesn't work, let me know if
Hey Joost and Z,
I brought up the question about the amounts because it could be that
> amounts high enough to thwart attacks are too high for honest users or
> certain uses.
I don't think this is a concern for this proposal, unless there's an attack
vector I missed.
The reason I claim that is
Good morning t-bast,
> > And in this case C earns.
>
> > Can C delay the refund to D to after the grace period even if D settled the
> > HTLC quickly?
>
> Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent on
> anyone downstream.
> An honest D should settle the HTLC
>
> It is interesting that the forward and backward payments are relatively
>> independent of each other
>
>
> To explain this further, I think it's important to highlight that the
> forward fee is meant to fight
> `uncontrolled spam` (where the recipient is an honest node) while the
> backward
Thanks for your answers,
My first instinct is that additional complications are worse in general.
> However, it looks like simpler solutions are truly not enough, so adding
> the complication may very well be necessary.
I agree with both these statements ;). I'd love to find a simpler solution,
Hi Bastien,
We add a forward upfront payment of 1 msat (fixed) that is paid
> unconditionally when offering an HTLC.
> We add a backwards upfront payment of `hold_fees` that is paid when
> receiving an HTLC, but refunded
> if the HTLC is settled before the `hold_grace_period` ends (see footnotes
Good morning t-bast,
> Sorry in advance for the lengthy email,
Come on, ZmnSCPxj writes lengthier.
> but I think it's worth detailing my hybrid proposal
> (bidirectional upfront payments), it feels to me like a workable solution
> that builds on
> previous proposals. You can safely ignore the
Good morning list,
Sorry in advance for the lengthy email, but I think it's worth detailing my
hybrid proposal
(bidirectional upfront payments), it feels to me like a workable solution
that builds on
previous proposals. You can safely ignore the details at the end of the
email and focus only on
Good morning t-bast,
>
> I've started summarizing proposals, attacks and threat models on github [1].
> I'm hoping it will help readers get up-to-speed and avoid falling in the same
> pitfalls we already
> fell into with previous proposals.
Would my inane incremental routing idea also be in
Hi Bastien,
Thanks for creating the summary!
While doing this exercise, I couldn't find a reason why the `reverse
> upfront payment` proposal
> would be broken (notice that I described it using a flat amount after a
> grace period, not an amount
> based on the time HTLCs are held). Can someone
Good morning list,
I've started summarizing proposals, attacks and threat models on github [1].
I'm hoping it will help readers get up-to-speed and avoid falling in the
same pitfalls we already
fell into with previous proposals.
I've kept it very high-level for now; we can add nitty-gritty
>
> > We've looked at all kinds of trustless payment schemes to keep users
>
> > honest, but it appears that none of them is satisfactory. Maybe it is
> even
> > theoretically impossible to create a scheme that is trustless and has
> all
> > the properties that we're looking for. (A proof of that
Hi Joost,
Thanks for your proposal, please find my following opinion which is
deliberately on a high-level as IMO defining better threats model and
agreeing on expected network dynamics resulting from any solution
trade-offs sounds required before to work on any solution.
> We've looked at all
Joost Jager writes:
>>
>> > A crucial thing is that these hold fees don't need to be symmetric. A new
>> > node for example that opens a channel to a well-known, established
>> routing
>> > node will be forced to pay a hold fee, but won't see any traffic coming
>> in
>> > anymore if it announces
Good morning Joost,
> > * I convince Rene to make a channel to me.
>
> You may succeed, but Rene is probably not going to pay you a hold fee because
> you're untrusted.
Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene
relationships, not necessarily recouping these funds.
Joost Jager writes:
>> The LOW-REP node being out of pocket is the clue here: if one party
>> loses funds, even a tiny bit, another party gains some funds. In this
>> case the HIGH-REP node collaborating with the ATTACKER can extract some
>> funds from the intermediate node, allowing them to dime
>
> > If I were LOW-REP, I'd still charge an unknown node a hold fee. I
> > would only waive the hold fee for high-reputation nodes. In that case,
> > the attacker is still paying for the attack. I may be forced to take a
> > small loss on the difference, but at least the larger part of the pain
>
>
> > The idea is that the available prepaid hold fee balance is enough to
> cover the worst case hold fee. Otherwise the forward won't happen. The main
> difference with option B is that you pay a sum upfront which can be used to
> cover multiple forwards. And that this payment is a separate
I think the mechanism can indeed create interesting dynamics, but not in
a good sense :-)
>> I can still establish channels to various low-reputation nodes, and
>> then use them to grief a high-reputation node. Not only do I get to
>> jam up the high-reputation channels, as a bonus I get the
>>
Good morning Joost,
> > > A. Prepayment: node pays an amount to its channel peer (for example via
> > > keysend) and the channel peer deducts the hold fees from that prepaid
> > > balance until it is at zero. At that point it somehow (in the htlc fail
> > > message?) communicates Lightning's
>
> > A crucial thing is that these hold fees don't need to be symmetric. A new
> > node for example that opens a channel to a well-known, established
> routing
> > node will be forced to pay a hold fee, but won't see any traffic coming
> in
> > anymore if it announces a hold fee itself. Nodes
Joost Jager writes:
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.
...
>
> In both cases the sender needs to trust its peer to not steal the payment
> and/or
>
> > A. Prepayment: node pays an amount to its channel peer (for example via
> keysend) and the channel peer deducts the hold fees from that prepaid
> balance until it is at zero. At that point it somehow (in the htlc fail
> message?) communicates Lightning's version of http 402 to ask for more
>
Good morning Joost,
I would like some clarifications on this mechanism.
> A. Prepayment: node pays an amount to its channel peer (for example via
> keysend) and the channel peer deducts the hold fees from that prepaid balance
> until it is at zero. At that point it somehow (in the htlc fail
Hello list,
Many discussions have taken place on this list on how to prevent undesired
use of the Lightning network. Spamming the network with HTLCs (for probing
purposes or otherwise) or holding HTLCs to incapacitate channels can be
done on today's network at very little cost to an attacker. So
29 matches
Mail list logo
