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

[Anthony Towns]

On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
> taproot and implement PTLCs. 

I think the conclusion from the discussions at the in-person LN summit
was to split these features up an implement them gradually. I think that
would look like:

 1) taproot funding/anchor output
benefits:
 * LN utxos just look normal, so better privacy
 * mutual closes also look normal, and only need one sig and no
   script, better privacy and lower fees
 * doesn't require updating any HTLC scripts
complexities:
 * requires implementing musig/musig2/similar for mutual
   closes and signing commitment txs
 * affects gossip, which wants to link channels with utxos so needs
   to understand the new utxo format
 * affects splicing -- maybe it's literally an update to the
   splicing spec, and takes effect only when you open new channels
   or splice existing ones?

 2) update commitment outputs to taproot
benefits:
 * slightly cheaper unilateral closes, maybe more private?
complexities:
 * just need to support taproot script path spends

 3) PTLC outputs
benefits:
 * has a different "hash" at every hop, arguably better privacy
 * can easily do cool things with points/secrets that would require
   zkp's to do with hashes/secrets
 * no need to remember PTLCs indefinitely in case of old 
complexities:
 * needs a routing feature bit
 * not usable unless lots of the network upgrades to support PTLCs
 * requires implementing adaptor signatures

 4) symmetric commitment tx (revocation via signature info)
benefits:
 * reduces complexity of layered txs?
 * reduces gamesmanship of who posts the commitment tx?
 * enables low-latency/offline payments?
complexities:
 * requires careful nonce management?

 5) low-latency payments?
benefits:
 * for payments that have no problems, halves the time to complete
 * the latency introduced by synchronous commitment updates doesn't
   matter for successful payments, so peer protocol can be simplified
complexities:
 * ?

 6) offline receipt?

 7) eltoo channels?

 8) eltoo factories?

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 Wed, Oct 13, 2021 at 03:15:14PM +1100, Lloyd Fournier wrote:
> 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:

So the idea here is that we have two channel parameters:

   PD - the payment delay or payment timeout delta, say 40 blocks
   RD - the channel recovery delay, say 2016 blocks

and the idea is that if you publish an old state, I have the longer delay
(RD) to correct that; *but* if the currently active state includes a
payment that I've forwarded to you, I may only have the shorter delay
(PD) in order to forward the payment claim details back in order to
avoid being out of pocket.

The goal is to keep that working while also allowing me to tell you about
a payment to you in such a way that you can safely forward it on *without*
an additional round-trip back to me (to acknowledge that you've received
it and that I've received your acknowledgement).

It's not really a super-important goal; it could shave off 50% of
the time to accept a ln tx when everything goes right, and there's no
bottlenecks elsewhere in the implementation, but it can't do anything
more than that, and doesn't help the really slow cases when things go
wrong. Mostly, I just find it interesting.

Suppose that a payment is forwarded from Alice to Bob, Carol and finally
reaches Dave. Alice/Bob and Carol/Dave are both colocated in a data centre
and have high bandwidth and have 1ms (rtt) latency, but Bob/Carol are
on different continents (but not via tor) and have 100ms (rtt) latency.

With 1.5 round-trips before forwarding, we'd get:

  t=0 Alice tells Bob
  t=1.5   Bob tells Carol
  t=151.5 Carol tells Dave
  t=153   Dave reveals the secret to Carol
  t=153.5 Carol reveals the secret to Bob
  t=203.5 Bob reveals the secret to Alice
  t=204   Alice knows the secret!

That's how things work now, with "X tells Y" being:

  X->Y: update_add_htlc, commitment_signed
  Y->X: commitment_signed, revoke_and_ack
  X->Y: revoke_and_ack

and "X reveals the secret to Y" being:

  X->Y: update_fulfill_htlc

However, if we could do it optimally we would have:

  t=0 Alice tells Bob about the payment
  t=0.5   Bob tells Carol about the payment
  t=50.5  Carol tells Dave about the payment
  t=51Dave accepts the payment and tells Carol the secret
  t=51.5  Carol accepts the payment and tells Bob the secret
  t=101.5 Bob accepts the payment and tells Alice the secret
  t=102   Alice knows the secret!

Looking just at Bob/Carol we might also have the underlying commitment
state updates:

  t=50.5  Carol acks the payment to Bob (commitment_signed,
  revoke_and_ack)
  t=100.5 Bob acks Carol's ack, revoking old state (revoke_and_ack)
  t=150.5 Carol's safe with the new state including the payment

  t=51.5  Carol reveals the secret and signs a new updated state
  (update_fulfill_htlc, commitmnt_signed)
  t=101.5 Bob acks receipt of the secret (commitment_signed,
  revoke_and_ack)
  t=151.5 Carol's safe with the new state with an increased balance
  (revoke_and_ack)
  t=201.5 Bob's state is up to date

Note that the first of those doesn't complete until well after Alice
would know the secret in an optimal construction; and that as described
the second upate overlaps the first, which might not be particularly
desirable.

> In my mind your "update the base channel state" idea seems to fix everything 
> by
> itself.

Yeah -- if you're willing to do 1.5 round-trips (and thanks to musig2 this
doesn't blow out to 2.5 (?) round-trips) that does solve everything. The
challenge is to do it in 0.5 round-trips. :)

> So at T - to_self_delay (or a bit before) you say to your counterparty
> "can we lift this HTLC out of your in-flight tx into the 'balance tx' (which
> will go back to naming a 'commitment tx' since it doesn't just have balance
> outputs anymore) so I can use it too? -- otherwise I'll have to close the
> channel on chain now to force you to reveal it to me on time?". If they agree,
> after the revocation and new commit tx everything is back to (tx symmetric)
> Poon-Dryja so no need for extra CSVs.

Maybe? So the idea is that:

 1) Bob gets a "low-latency" tx that spends Alice's balance and has a
bunch of outputs for really recent payments
 2) In normal conditions, in 5 or 10 or 30 seconds, Alice/Bob renegotiate
the base commitment to move those payments out of the "low-latency"
tx
 3) In abnormal conditions, with an active forwarded "low-latency" tx and
communications failure of length up to "PD", Alice closes the channel
on chain.
 4) Bob then has "PD" period to post the "low-latency" tx, if he
doesn't, Alice can do a layered claim of her balance preventing Bob
from oing so.
 5) If Bob does post his "low-latency" tx, then he'll also need to reveal
secrets prior to the payment timeout.

So taking the payment timeout as T, then he'll have to post 

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

[Lloyd Fournier]

On Tue, 12 Oct 2021 at 14:08, Anthony Towns  wrote:

>
> 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
>

In my mind your "update the base channel state" idea seems to fix
everything by itself. So at T - to_self_delay (or a bit before) you say to
your counterparty "can we lift this HTLC out of your in-flight tx into the
'balance tx' (which will go back to naming a 'commitment tx' since it
doesn't just have balance outputs anymore) so I can use it too? --
otherwise I'll have to close the channel on chain now to force you to
reveal it to me on time?". If they agree, after the revocation and new
commit tx everything is back to (tx symmetric) Poon-Dryja so no need for
extra CSVs. Am I missing something?

I realise this kills some of the elegance of your original protocol and
adds quite a bit of complexity but I think it retains the important
properties.


> 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...
>
>
It seems to me lazily lifting the HTLCs into the commitment tx would allow
as many low-latency payments as you want to be in-flight. You would
probably just lift them all up to the commitment tx if you lift one. I
think in the case of nodes that want to keep channel keys offline, having
to go on-chain at T - to_self_delay is not a disaster since it will likely
only be the payment receiver who has their keys offline i.e. the merchant
or end user. So only the last hop would go on chain if the user fails to
claim payment as per usual (just to_self_delay earlier than usual).

Cheers,

LL
___
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] 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] 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

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

[Anthony Towns]

On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
>  2. The balance transaction - tracks the funding transaction, contains
> a "balance" output for each of the participants.
>  3. The inflight transactions - spends a balance output from the balance
> transaction and provides outputs for any inflight htlc/ptlc transactions.
>  4. Layered transactions - spends inflight htlc/ptlc outputs by revealing
> the preimage, while still allowing for the penalty path.

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.

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

[Lloyd Fournier]

Hey aj,

This is awesome work. My line of research on "witness asymmetric channels"
essentially ended up in a dead end because I couldn't see how they were
much better than naive PTLC lightning. The idea I really liked from it was
"revocable signatures". I hoped someone would eventually figure out what to
do with them. Looks like you've done that!

I also didn't make the connection to how revocable signatures actually
solves the constant size storage problem. I knew it could make the protocol
in "generalized payment channels" [1] only require constant size which was
the target of the idea but I hadn't considered that lightning already
suffers from this problem so it can be applied more generally.

The other big breakthrough you made is showing how you can do concurrent
non-interactive payment forwarding by using a refined version of Z's fast
forward idea. In my mind the most practical way to make FF work on
Poon-Dryja channels was to do it asymmetrically [3] but this meant that if
a payment was sent the other way you'd have to do a 3 phase commit first.
With your idea as long as you have balance to spare in your balance output
you can always forward a payment in one message. A nice speed boost for
busy routing nodes.

### Scorched earth punishment

Another thing that I'd like to mention is that using revocable signatures
enables scorched earth punishments [2]. The key you reveal when you post a
revoked state does not have to be limited to your channel -- it could be
used in multiple channels allowing the wronged party to take coins from all
their channels with the perpetrator. Furthermore, a lightning service
provider that offers channels with the same channel key to all their
customers is putting up all their coins in all their existing channels as
their good behaviour bond rather than just the coins they have in the
channels they have with you.

For many users this will be sufficient to go without a "watchtower" to do
punishments for them. They know if the LSP takes their coins with a revoked
state whenever they come back online they can punish the LSP by revealing
their static channel key to everyone. They can even do this weeks or months
after the theft assuming the LSP is still operating with the same key.

Some people feel this idea is too spicy but I prefer it to introducing a
trusted third party for people that cannot be online all the time.

[1] https://eprint.iacr.org/2020/476.pdf
[2]
https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003045.html

Some queries below:

On Sat, 9 Oct 2021 at 12:12, Anthony Towns  wrote:

>
> We will use "i" to represent the number of times a given inflight
> transaction has been updated for the nth update to the balance
> transaction.
>
> At any time Alice can update the inflight transaction spending her balance
> to transfer funds towards Bob, either by updating the balances directly,
> or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And
> conversely for Bob)
>
> We will define RP=musig(A/2/n/i, RB2(n,i)).
>
> The inflight transaction spending Alice's balance can have multiple
> types of outputs:
>
>  * Alice's remaining balance: pays directly to A/2/n/i
>
>  * Bob's remaining balances: pays to RP/2 with script path
>" CHECKSIGVERIFY  CSV"
>
>  * An htlc paying to Bob: pays to RP/2/k with script paths:
>+ "LENGTH 32 EQUALVERIFY HASH160  EQUALVERIFY 
> CHECKSIGVERIFY  CHECKSIG"
>+ " CHECKSIGVERIFY  CLTV"
>
>  * A ptlc paying to Bob: pays to RP/2/k with script paths:
>+ " CHECKSIG NOTIF  CLTV DROP ENDIF  CHECKSIG"
>
> Any outputs that would be zero or dust are not included.
>
> 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.

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


>  * if the inflight transaction contains a ptlc output, then if Alice
>has not retained the old ptlc details (the point and the timeout)
>she will not trivially be able to reconstruct the script path,
>which includes the timeout. However, presuming the timeout was
>within 5000 blocks, then the only possible timeouts are the inflight
>tx's nlocktime+i with 05000*k cases and match the corresponding scriptPubKeys to exhaustively
>enumerate every possible ptlc output, which should take under a minute,
>and be easily achievable. In addition, if Bob attempts to claim the
>funds, he will reveal the script path, and Alice will be either able
>to claim the inflight output directly or the layered 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.

This does not 

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

[Jonas Nick]

> H( private-key, msg, other-party's-nonce-pair, 1 )

That should work. I had thought that other-party's-nonce-pair would be unique
unknown randomness, but I can see now that it can be rederived from RA(n) or
RB(n).

> Hmm, you had me panicking that I'd been describing how to combine the
> two despite having decided it wasn't necessary to combine them...

Ah, should have read that part more closely. The proposal uses the single sig
adaptor sig variant.
___
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 Sat, Oct 09, 2021 at 12:21:03PM +, Jonas Nick wrote:
> it seems like parts of this proposal rely on deterministic nonces in MuSig.

The "deterministic" nonces are combined with "recoverable" nonces via
musig2, so I think that part is a red-herring?

They're "deterministic" in the sense that the person who generated the
nonce needs to be able to recover the secret/dlog for the nonce later,
without having to store unique randomness for it. Thinking about it,
I think you could make the "deterministic" nonce secrets be

   H( private-key, msg, other-party's-nonce-pair, 1 )
   H( private-key, msg, other-party's-nonce-pair, 2 )

because you only need to recover the secret if the other party posts a
sig for a revoked transaction, in which case you can lookup their nonce
directly anyway. And you're choosing your "deterministic" nonce after
knowing what their ("revocable") nonce is, so can include it in the hash.

As far as the revocable nonce goes, you should only be generating a
single signature based on that, since that's used to finish things off
and post the tx on chain.

> Generally, this is insecure unless combined with heavy machinery that proves
> correctness of the nonce derivation in zero knowledge. If one signer uses
> deterministic nonces and another signer uses random nonces, then two signing
> sessions will have different challenge hashes which results in nonce reuse by
> the first signer [0]. Is there a countermeasure against this attack in the
> proposal? What are the inputs to the function that derive DA1, DA2? Is the
> assumption that a signer will not sign the same message more than once?

I had been thinking DA1,DA2 = f(seed,n) where n increases each round, but I
think the above would work and be an improvement. ie:

   Bob has a shachain based secret generator, producing secrets s_0 to
   s_(2**48). If you've seen s_0 to s_n, you only need to keep O(log(n))
   of those values to regenerate all of them.

   Bob generates RB1_n and RB2_n as H(s_n, 1)*G and H(s_n, 2)*G and sends
   those values to Alice.

   Alice determines the message (ie, the transaction), and sets da1_n
   and da2_n as H(A_priv, msg, RB1_n, RB2_n, 1) and H(A_priv, msg, RB1_n,
   RB2_n, 2). She then calculates k=H(da1_n, da2_n, RB1_n, RB2_n), and
   signs for her nonce which da1_n+k*da2_n, and sends da1_n*G and
   da2_n*G and the partial signature to Bob.

   Bob checks and records Alice's musig2 derivation and partial signature,
   but does not sign himself.

   _If_ Bob wants to close the channel and publish the tx, he completes
   the signature by signing with nonce RB1_n + k*RB2_n.

If you can convince Bob to close the channel repeatedly, using the
same nonce pair, then he'll have problems -- but if you can do that,
you can probably trick him into closing the channel with old state,
which gives him the same problems by design... Or that's my take.

> It may be worth pointing out that an adaptor signature scheme can not treat
> MuSig2 as a black box as indicated in the "Adaptor Signatures" section [1].

Hmm, you had me panicking that I'd been describing how to combine the
two despite having decided it wasn't necessary to combine them... :)

(I figured doing musig for k ptlcs for every update would get old fast --
if you maxed the channel out with ~400 inflight ptlcs you'd be exchanging
~800 nonces for every update. OTOH, I guess that's the only thing you'd
be saving, and the cost is ~176 bytes of extra witness data per ptlc...
Hmm...)

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

[Jonas Nick]

Hi,

it seems like parts of this proposal rely on deterministic nonces in MuSig.
Generally, this is insecure unless combined with heavy machinery that proves
correctness of the nonce derivation in zero knowledge. If one signer uses
deterministic nonces and another signer uses random nonces, then two signing
sessions will have different challenge hashes which results in nonce reuse by
the first signer [0]. Is there a countermeasure against this attack in the
proposal? What are the inputs to the function that derive DA1, DA2? Is the
assumption that a signer will not sign the same message more than once?

It may be worth pointing out that an adaptor signature scheme can not treat
MuSig2 as a black box as indicated in the "Adaptor Signatures" section [1]. In
particular, generally the secret X must be input to the hash function that
generates nonce coefficient k. Otherwise, an attacker can grind through
challenge hashes by varying X without affecting the aggregate nonce and produce
a forgery. For the same reason, the message m is included in hash function
inputs of k. However, taking X into account when computing k shouldn't be an
issue for protocols making use of adaptor signatures because k does not need to
be determined before signing time and X is required to be known at that point
anyway.

[0] 
https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6
See "The attack works as follows."
[1] MuSig2 adaptor signature issue: 
https://github.com/ElementsProject/scriptless-scripts/issues/23,
PR: https://github.com/ElementsProject/scriptless-scripts/pull/24
___
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 Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
>
> > A transaction is required, but I believe it is not necessary to put it 
> > onchain (at the cost of implementation complexity in the drop-onchain case).
>
> The trick with that is that if you don't put it on chain, you need
> to calculate the fees for it in advance so that they'll be sufficient
> when you do want to put it on chain, and you can't update it without
> going onchain, because there's no way to revoke old off-chain funding
> transactions.

Yes, onchain fees, right?

*Assuming* CPFP is acceptable, then fees for the commitment tx on the new 
scheme (or whatever equivalent in the transitioned-to mechanism is) would pay 
for the transitioning transaction, so fees paying for the transitioning 
transaction can still be adjusted at the transitioned-to updatable mechanism.
This probably assumes that the transaction package relay problem is fixed at 
the base layer though.

>
> > This has the advantage of maintaining the historical longevity of the 
> > channel.
> > Many pathfinding and autopilot heuristics use channel lifetime as a 
> > positive indicator of desirability,
>
> Maybe that's a good reason for routing nodes to do shadow channels as
> a matter of course -- call the currently established channel between
> Alice and Bob "C1", and leave it as bolt#3 based, but establish a new
> taproot based channel C2 also between Alice and Bob. Don't advertise C2
> (making it a shadow channel), just say that C1 now supports PTLCs, but
> secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx
> is buried enough, start advertising C2 instead taking advantage of its
> now sufficiently buried funding transaction, and convert C1 to a shadow
> channel instead.
>
> In particular, that setup allows you to splice funds into or out of the
> shadow channel while retaining the positive longevity heuristics of the
> public channel.

Requires two UTXOs, though, I think?

How about just adding a gossip message "this new short-channel-id is the same 
as this old short-channel-id, use the new-short-channel-id to validate it but 
treat the age as that of the old short-channel-id"?

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 Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
> A transaction is required, but I believe it is not necessary to put it 
> *onchain* (at the cost of implementation complexity in the drop-onchain case).

The trick with that is that if you don't put it on chain, you need
to calculate the fees for it in advance so that they'll be sufficient
when you do want to put it on chain, *and* you can't update it without
going onchain, because there's no way to revoke old off-chain funding
transactions.

> This has the advantage of maintaining the historical longevity of the channel.
> Many pathfinding and autopilot heuristics use channel lifetime as a positive 
> indicator of desirability,

Maybe that's a good reason for routing nodes to do shadow channels as
a matter of course -- call the currently established channel between
Alice and Bob "C1", and leave it as bolt#3 based, but establish a new
taproot based channel C2 also between Alice and Bob. Don't advertise C2
(making it a shadow channel), just say that C1 now supports PTLCs, but
secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx
is buried enough, start advertising C2 instead taking advantage of its
now sufficiently buried funding transaction, and convert C1 to a shadow
channel instead.

In particular, that setup allows you to splice funds into or out of the
shadow channel while retaining the positive longevity heuristics of the
public channel.

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,

> In order to transition from BOLT#3 format to this proposal, an onchain
> transaction is required, as the "revocable signatures" arrangement cannot
> be mimicked via the existing 2-of-2 CHECKMULTISIG output.

A transaction is required, but I believe it is not necessary to put it 
*onchain* (at the cost of implementation complexity in the drop-onchain case).

An existing channel can "simply" sign a transitioning transaction from the 
current BOLT3 to your new scheme, and then invalidate the last valid commitment 
transactions (i.e. exchange revocation secrets) in the BOLT3 scheme.
The transitioning transaction can simply be kept offchain and its output used 
as the funding outpoint of all "internal" (to the two counterparties directly 
in the channel) states.

This general idea would work for all transitions *from* Poon-Dryja, I believe.
It may be possible with Decker-Russell-Osuntokun I think (give the 
transitioning transaction the next sequence `nLockTime` number), but the 
`SIGHASH_NOINPUT`ness and (maybe?) the `CSV` infects the mechanism being 
transitioned to, so this technique may be too complicated for transitioning 
*from* Decker-Russell-Osuntokun to some hypothetical future offchain updatable 
cryptocurrency system that does not need (or want) `SIGHASH_NOINPUT`.

This has the advantage of maintaining the historical longevity of the channel.
Many pathfinding and autopilot heuristics use channel lifetime as a positive 
indicator of desirability, thus an *onchain* transitioning transaction is 
undesirable as that marks a closure of the previous channel.
And the exact scheme of channels between forwarding nodes are not particularly 
the business of anyone else anyway.


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