[Lightning-dev] Block Header commit (c93824e)

[Skyler Saleebyan]

Hi everyone,

Recently there was a commit to change pings from including random data to
now including state data: the most recent bitcoin block header.

https://github.com/lightningnetwork/lnd/pull/5621

I was wondering if there was a discussion around the possible risks for
continuously broadcasting your most recent state to the network. Are there
no counterparty risks associated with this or is the attack surface just
too small/unrealistic outside edge cases?

If I were to just spitball a couple of ideas (and would welcome other
examples), with this data I would wonder if:
a) you could use block header update delays to de-anonymize/identify/locate
nodes by using update times/uncle blocks/fingerprinting attacks
b) any counterparty risks exist from an attacker node pretending to be on
the same block as an out of date node

If the security story around this update has been discussed in detail I'd
love to know where to read more.

Thanks,
Skyler S.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over taproot with PTLCs

[Anthony Towns]

On Tue, Oct 12, 2021 at 04:18:37AM +, ZmnSCPxj via Lightning-dev wrote:
> > A+P + max(0, B'-B)*0.1 to Alice
> > B-f - max(0, B'-B)*0.1 to Bob

> So, if what you propose is widespread, then a theft attempt is costless: 

That's what the "max" part prevents -- if your current balance is B and
you try to claim an old state with B' > B for a profit of B'-B, Alice
will instead take 10% of that value.

(Except maybe all the funds they were trying to steal were in P' rather
than B'; so better might have been "A+P + max(0, min(B'+P'-B)*0.1, B)")

Eltoo would enable costless theft attempts (ignoring fees), particularly
for multiparty channels/factories, of course, so getting the game theory
right in advance of that seems worth the effort anyway.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over taproot with PTLCs

[ZmnSCPxj via Lightning-dev]

Good morning aj,

> On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
>
> > ### Scorched earth punishment
> >
> > Another thing that I'd like to mention is that using revocable signatures
> > enables scorched earth punishments [2].
>
> I kind-of think it'd be more interesting to simulate eltoo's behaviour.
> If Alice's current state has balances (A, B) and P in in-flight
> payments, and Bob posts an earlier state with (A', B') and P' (so A+B+P
> = A'+B'+P'), then maybe Alice's justice transaction should pay:
>
> A+P + max(0, B'-B)*0.1 to Alice
> B-f - max(0, B'-B)*0.1 to Bob
>
> (where "f" is the justice transaction fees)
>
> Idea being that in an ideal world there wouldn't be a hole in your pocket
> that lets all your coins fall out, but in the event that there is such
> a hole, it's a nicer world if the people who find your coins give them
> back to you out of the kindness of their heart.

This may model closer to "two tits for a tat" strategy.

"Tit for tat" is optimum in iterated prisoner dilemma assuming mistakes never 
happen; however, in the real world we know quite well that we may injure 
another person by complete accident.
The usual practice in the real world is that the injured person will accept an 
apology *once*, but a repeat will tend to make people assume you are hostile 
and switch them over to tit for tat.
This overall strategy is then "two tits for a tat", you are (in practice) given 
one chance and then you are expected to be very careful in interacting with 
that person to keep being in their good graces.

So, if what you propose is widespread, then a theft attempt is costless: you 
can try using old state, and your victim will, on finding it, instead just use 
what they think is the latest state.
Thus, merely attempting the theft is costless (modulo onchain fees, which may 
be enough punishment in this case?).

However, if we assume that in practice a lot of "theft attempts" are really 
people not taking RAID systems and database replication seriously and getting 
punished by the trickster god Murphy, then your proposal would actually be 
better, and if theft is unlikely enough to succeed, then even a costless theft 
attempt would still be worthless (and onchain fees will bite you anyway).

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over taproot with PTLCs

[Anthony Towns]

On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
> ### Scorched earth punishment
> Another thing that I'd like to mention is that using revocable signatures
> enables scorched earth punishments [2]. 

I kind-of think it'd be more interesting to simulate eltoo's behaviour.
If Alice's current state has balances (A, B) and P in in-flight
payments, and Bob posts an earlier state with (A', B') and P' (so A+B+P
= A'+B'+P'), then maybe Alice's justice transaction should pay:

   A+P + max(0, B'-B)*0.1 to Alice
   B-f - max(0, B'-B)*0.1 to Bob

(where "f" is the justice transaction fees)

Idea being that in an ideal world there wouldn't be a hole in your pocket
that lets all your coins fall out, but in the event that there is such
a hole, it's a *nicer* world if the people who find your coins give them
back to you out of the kindness of their heart.

> Note that we number each currently inflight transaction by "k",
> starting at 0. The same htlc/ptlc may have a different value for k
> between different inflight transactions.
> Can you expand on why "k" is needed in addition to "n" and "i". k sounds like
> the same thing as i to me.

"k" is used to distinguish the inflight payments (htlcs/ptlcs), not the
inflight state (which is "i").

> Also what does RP/2/k notation imply given the definition of RP you gave 
> above?

I defined earlier that if P=musig(A,B) then P/x/y = musig(A/x/y,B/x/y);
so RP/2/k = musig(A/2/n/i/2/k,RB2(n,i)/2/k).

>  * if the inflight transaction contains a ptlc output, [...]
> What about just doing a scriptless PTLC to avoid this (just CSV input of
> presigned tx)? The cost is pre-sharing more nonces per PTLC message.

Precisely that reason. Means you have to share "k+1" nonce pairs in
advance of every inflight tx update. Not a show stopper, just seemed
like a headache. (It's already a scriptless-script, this would let you
use a key path spend instead of a script path spend)

> This does not support option_static_remotekey, but compensates for that
> by allowing balances to be recovered with only the channel setup data
> even if all revocation data is lost.
> This is rather big drawback but is this really the case? Can't "in-flight"
> transactions send the balance of the remote party to their unencumbered static
> remote key?

They could, but there's no guarantee that there is an inflight
transaction, or that the other party will post it for you. In those case,
you have to be able to redeem your output from the balance tx directly,
and if you can do that, might as well have every possible address be
derived differently to minimise the amount of information any third
parties could glean.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over taproot with PTLCs

[Anthony Towns]

On Mon, Oct 11, 2021 at 09:23:19PM +1100, Lloyd Fournier wrote:
> On Mon, 11 Oct 2021 at 17:30, Anthony Towns  wrote:
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
> This problem may not be as bad as it seems.

Maybe you can break it down a little bit further. Consider *three*
delays:

 1) refund delay: how long you have before a payment attempt starts
getting refunded

 2) channel recovery delay: how long you have to recover from node
failure to prevent an old state being committed to, potentially losing
your entire channel balance

 3) payment recovery delay: how long you have to recover from node
failure to prevent losing funds due to a forwarded payment (eg,
Carol claimed the payment, while Alice claimed the refund, leaving
Bob out of pocket)

(Note that if you allow payments up to the total channel balance, there's
not really any meaningful distinction between (2) and (3), at least in
the worst case)

With layered transactions, (2) and (3) are different -- if Bob's node
fails near the timeout, then both Alice and Carol drop to the blockchain,
and Carol knows the preimage, Bob may have as little as the channel
"delay" parameter to extract the preimage from Carol's layered commitment
tx to be able to post a layered commitment on top of Alice's unilateral
close to avoid being out of pocket.

(Note that that's a worst case -- Carol would normally reveal the preimage
onchain earlier than just before the timeout, giving Bob more time to
recover his node and claim the funds from Alice)

If you're willing to accept that "worst case" happening more often, I
think you could then retain the low latency forwarding, by having the
transaction structure be:

commitment tx
  input:
 funding tx
  outputs:
 Alice's balance
 (others)

low-latency inflight tx:
  input:
Alice's balance
  output:
(1) or (2)
Alice's remaining balance

Bob claim:
  input:
(1) [ CSV bob CHECKSIG]
  output:
[ checksigverify  checksig
 ifdup notif  csv endif]

Too-slow:
  input:
(2) [ CLTV alice CHECKSIG]
  output:
Alice

The idea being:

 * Alice sends the low-latency inflight tx which Bob then forwards
   immediately.

 * Bob then tries to update the base channel state with Alice, so both
   sides have a commitment to the new payment, and the low-latency
   inflight tx is voided (since it's based on a revoked channel state)
   If this succeeds, everything is fine as usual.

 * If Alice is unavailable to confirm that update, Bob closes the
   channel prior to (payment-timeout - payment-recover-delay), and posts
   "Bob claim". After an additional pyment recovery delay (and prior
   to payment-timeout) Bob posts Bob claim, ensuring that the only way
   Alice can claim the funds is if he had posted a revoked state.

 * In this case, Alice has at least one payment-recovery-delay period
   prior to the payment-timeout to notice the transaction onchain and
   recover the preimage.

 * If Bob posted the low-latency inflight tx later than
   (payment-timeout - payment-recovery-delay) then Alice will have
   payment-recovery-delay time to notice and post the "too-slow" tx and
   claim the funds via the timeout path.

 * If Bob posted a revoked state, Alice can also claim the funds via
   Bob claim, provided she notices within the channel-recovery-delay

That only allows one low-latency payment to be inflight though, which I'm
not sure is that interesting... It's also kinda complicated, and doesn't
cover both the low-latency and offline cases, which is disappointing...

Cheers,
aj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

[Martin Habovštiak]

I can confirm I moved a repository few months ago and all links kept
working fine.

On Mon, Oct 11, 2021, 20:58 Matt Corallo  wrote:

>
>
> On 10/11/21 05:29, Bryan Bishop wrote:
> > On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses  >
> > wrote:
> >
> > Completely agree with this. How to move this forward? Set up a vote?
> What would be the reasoning
> > for not moving it?
> >
> >
> > One consideration is broken links, which can be solved by a soft note in
> a README somewhere.
> >
> > - Bryan
> > https://twitter.com/kanzure 
>
> I believe the Github "move repository" feature makes all old links
> auto-redirects, so I'd hope this
> wouldn't happen. This information is at least a few years old, however.
>
> Matt
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over taproot with PTLCs

[Lloyd Fournier]

On Mon, 11 Oct 2021 at 9:23 pm, Lloyd Fournier 
wrote:

>
> Adjust the protocol so that you reciprocate the in-flight txs. So when I
> offer you a HTLC you first forward it and then lazily send me the signature
> for the inflight tx. Therefore I dont have to wait to get the HTLC on chain
> and don’t have to close the channel early.
>
> So against a malicious node you have to go on chain to_self_delay earlier
> than usual but if both are honest you don’t have to. The problem with eltoo
> is that we don’t know how to achieve this even if both parties are honest
> iirc.
>

Err never mind that won’t work. Sending in-flights to both parties makes no
sense because they can be stale of course.

LL

>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

[Matt Corallo]

On 10/11/21 05:29, Bryan Bishop wrote:
On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses mailto:kno...@gmail.com>> 
wrote:


Completely agree with this. How to move this forward? Set up a vote? What 
would be the reasoning
for not moving it?


One consideration is broken links, which can be solved by a soft note in a 
README somewhere.

- Bryan
https://twitter.com/kanzure 


I believe the Github "move repository" feature makes all old links auto-redirects, so I'd hope this 
wouldn't happen. This information is at least a few years old, however.


Matt
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

[Bryan Bishop]

On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses 
wrote:

> Completely agree with this. How to move this forward? Set up a vote? What
> would be the reasoning for not moving it?
>

One consideration is broken links, which can be solved by a soft note in a
README somewhere.

- Bryan
https://twitter.com/kanzure
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over taproot with PTLCs

[Lloyd Fournier]

On Mon, 11 Oct 2021 at 17:30, Anthony Towns  wrote:

>
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
>
> Any time later than that, say T-to_self_delay+x+1, would allow Bob to
> post the inflight tx at T+x (prior to Alice being able to claim her
> balance directly due to the to_self_delay) and then immediately post the
> layered transaction (4, above) revealing the preimage, and preventing
> Alice from claiming the refund.
>

This problem may not be as bad as it seems. Recall that the issue in eltoo
is worse because you are delayed both when you are offering and receiving
the HTLC. In this one you are only delayed on offered HTLC.

Adjust the protocol so that you reciprocate the in-flight txs. So when I
offer you a HTLC you first forward it and then lazily send me the signature
for the inflight tx. Therefore I dont have to wait to get the HTLC on chain
and don’t have to close the channel early.

So against a malicious node you have to go on chain to_self_delay earlier
than usual but if both are honest you don’t have to. The problem with eltoo
is that we don’t know how to achieve this even if both parties are honest
iirc.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev