Re: [Lightning-dev] Eltoo Burst Mode & Continuations

[Anthony Towns]

On Sat, Jul 10, 2021 at 02:07:02PM -0700, Jeremy wrote:
> Let's say you're about to hit your sequence limits on a Eltoo channel... Do 
> you
> have to go on chain?
> No, you could do a continuation where for your *final* update, you sign a move
> to a new update key. E.g.,

That adds an extra tx to the uncooperative path every 2**30 states.

> Doing layers like this inherently adds a bunch of CSV layers, so it increases
> resolution time linearly.

I don't think that's correct -- you should be using the CLTV path for
updating the state, rather than the CSV path; so CSV shouldn't matter.

On Sat, Jul 10, 2021 at 04:25:06PM -0700, Jeremy wrote:
> [...] signing a eltoo "trampoline".
> essentially, begin a burst session at pk1:N under pk2, but always include a
> third branch to go to any pk1:N+1.

I think this is effectively reinventing/special casing channel
factories? That is you start an eltoo channel factory amongst group
{A,B,C,...}, then if {A,B} want an eltoo channel, that's a single update
to the factory; that channel can get updated independently until A and
B get bored and want to close their channel, which is then a single
additional update to the factory. In this case, the factory just doesn't
include the additional members {C,...}.

On Sat, Jul 10, 2021 at 05:02:35PM -0700, Jeremy wrote:
> suppose you make a Taproot tree with N copies (with different keys) of the
> state update protocol.

This feels cleverer/novel to me -- but as you point out it's actually
more costly than the trampoline/factory approach so perhaps it's not
that great.

I think what you'd do is change from a single tapscript of "OP_1
CHECKSIG <500e6+i> CLTV" to a tree of tapscripts:

  " CHECKSIG <500e6+j+1> CLTV"

so if your state is (i*2**30 + j) you're spending using  with a
locktime of 500e6+j, and you're allowing later spends with the above script
filled in with (i,j) or (i',0) for i You can take a random path through which leaf you are using which, if you're
> careful about how you construct your scripts (e.g., keeping the trees the same
> size) you can be more private w.r.t. how many state updates you performed
> throughout the protocol (i.e., you can see the low order bits in the CLTV
> clause, but the high order bits of A, B, C's relationship is not revealed if
> you traverse them in a deterministically permuted order).

Tapscript trees are shuffled randomly based on the hashes of their
scripts, so I think that's a non-issue. You could keep the trees the
same size by adding scripts " CHECKSIG <500e6+j+1> RETURN".

> The space downside of this approach v.s. the approach presented in the prior
> email is that the prior approach achieves 64 bits with 2 txns one of which
> should be like 150 bytes, a similar amount of data for the script leaves may
> only gets you 5 bits of added sequence space. 

You'd get 2**34 states (4 added bits of added sequence space) for
about 161 extra bytes (4 merkle branches at 32B each and revealing the
pubkey for 33B), compared to about 2**60 states (2**30 states for the
second tx, with a different second tx for each of the 2**30 states of
the first tx). Haven't done the math to check the 150 byte estimate,
but it seems the right ballpark.

Cheers,
aj

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

Re: [Lightning-dev] Eltoo Burst Mode & Continuations

[Jeremy]

Last thought:

suppose you make a Taproot tree with N copies (with different keys) of the
state update protocol.

Then what you can do is use the 1st copy  until you hit MAX_STATE, and then
start signing with the 2nd copy back an state 0 but when you sign with the
2nd copy you *remove* the 1st copy from the taproot tree.

e.g.,

{A:0, B:0, C:0} -> {A:1, B:0, C:0} -> {A:MAX, B:0, C:0} -> {B:1, C:0}...

Then the cut-thru transition

{A:0, B:0, C:0} -> {B:1, C:0}

is valid, but the regression:

{B:N, C:0} -> {A:M, B:0, C:0} is not.


You can take a random path through which leaf you are using which, if
you're careful about how you construct your scripts (e.g., keeping the
trees the same size) you can be more private w.r.t. how many state updates
you performed throughout the protocol (i.e., you can see the low order bits
in the CLTV clause, but the high order bits of A, B, C's relationship is
not revealed if you traverse them in a deterministically permuted order).

The space downside of this approach v.s. the approach presented in the
prior email is that the prior approach achieves 64 bits with 2 txns one of
which should be like 150 bytes, a similar amount of data for the script
leaves may only gets you 5 bits of added sequence space.


--
@JeremyRubin 



On Sat, Jul 10, 2021 at 4:25 PM Jeremy  wrote:

> on further reflection, i think you can get around the restriction of CSV
> by signing a eltoo "trampoline".
>
> essentially, begin a burst session at pk1:N under pk2, but always include
> a third branch to go to any pk1:N+1.
>
> The scripts look like:
>
> Eltoo Layer 1 Regular at state i = N<<32:
> Or(And(After(N+1), Key(PK_u1)), And(Older(2016), Key(PK_s_i))
>
> Eltoo Layer 1 During Burst at state i = (N<<32) + M:
> Or(And(After(N+1), Key(PK_u1)), Key(PK_s_burst_N == PK_s_i))
>
> Eltoo Layer 2 During Burst at state i = (N<<32) + M:
> Or(And(After(N+1), Key(PK_u1)), And(After(M+1), Key(PK_u_burst_N)),
> And(Older(2016), Key(PK_s_i))
>
> i represents the 64 bit concatenation of two 32 bit locktimes, where N is
> MSBs and M is LSBs.
>
> During burst mode resolving on chain, either:
> 1) the published Layer 1 tx is at the tip state N
> a) The tip N is at inner tip state M, wait 2016 to close with
> And(Older(2016), Key(PK_s_i))
> b) The tip N is at inner tip state M - c, use path And(After(M+1),
> Key(PK_u_burst_N)) to jump to case 1.a
> 2) published Layer 1 tx is at non tip state N - c
> a) Layer 2 does not get published: use path And(After(N+1),
> Key(PK_u1)) to jump back to newest state known on parent, repeat from top
> b) Layer 2 gets published: use path And(After(N+1), Key(PK_u1)) to
> jump back to newest state known on parent, repeat from top
>
>
> This trampoline pattern should essentially be repeatable as many times as
> needed, although I think 2 layers is likely enough in practice.
>
> In terms of "state management", it grows at O(layers) but is otherwise
> constant. A node must only store:
>
> Key/Sigs for
> PK_s_i: to allow closing at the highest reachable state
> PK_u1
> During burst:
> PK_u_burst_N: to allow getting to current burst
> PK_s_burst_N: the same as PK_s_i just makes sense to think of it's
> distinct purpose from PK_s_i not requiring a sequence lock
>
> Note that the above scripts can be optimized to remove the Older clause as
> it can be a rule that all PK_s_i must sign with a sequence unless entering
> a burst.
> --
> @JeremyRubin 
> 
>
>
> On Sat, Jul 10, 2021 at 2:07 PM Jeremy  wrote:
>
>> Let's say you're about to hit your sequence limits on a Eltoo channel...
>> Do you have to go on chain?
>>
>> No, you could do a continuation where for your *final* update, you sign a
>> move to a new update key. E.g.,
>>
>> start at: IF "N+1" CLTV DROP  CHECKSIG  ELSE 2016 CSV DROP 
>> CHECKSIG ENDIF
>>
>> before N+1 = last, sign a txn with pk_s_last that moves coins to
>>
>> IF "1" CLTV DROP <*pk_u**2*> CHECKSIG  ELSE 2016 CSV DROP 
>> CHECKSIG ENDIF
>>
>> This essentially lets you do 32 bits worth of updates and then fwd to a
>> new contract by paying 1x extra transaction.
>>
>> This is potentially better than just directly closing because we keep it
>> off chain for longer.  However... this also adds an additional CSV.
>>
>> (We can get around this by modifying the script branch which ends a CLTV
>> domain with:
>>  CHECKSIG
>> since any updates past that point are done through the continuation
>> state... but let's ignore that for the next part)
>>
>> What if we *always* used this every update? Then we'd essentially have 64
>> bits of sequence space. Each layer of this trick adds 32 bytes.
>>
>> Doing layers like this inherently adds a bunch of CSV layers, so it
>> increases resolution time linearly.
>>
>> One possibility to mitigate this is to do a "semitrusted burst mode" with
>> a counterparty. Suppose you're at sequence M and it's a 

Re: [Lightning-dev] Eltoo Burst Mode & Continuations

[Jeremy]

on further reflection, i think you can get around the restriction of CSV by
signing a eltoo "trampoline".

essentially, begin a burst session at pk1:N under pk2, but always include a
third branch to go to any pk1:N+1.

The scripts look like:

Eltoo Layer 1 Regular at state i = N<<32:
Or(And(After(N+1), Key(PK_u1)), And(Older(2016), Key(PK_s_i))

Eltoo Layer 1 During Burst at state i = (N<<32) + M:
Or(And(After(N+1), Key(PK_u1)), Key(PK_s_burst_N == PK_s_i))

Eltoo Layer 2 During Burst at state i = (N<<32) + M:
Or(And(After(N+1), Key(PK_u1)), And(After(M+1), Key(PK_u_burst_N)),
And(Older(2016), Key(PK_s_i))

i represents the 64 bit concatenation of two 32 bit locktimes, where N is
MSBs and M is LSBs.

During burst mode resolving on chain, either:
1) the published Layer 1 tx is at the tip state N
a) The tip N is at inner tip state M, wait 2016 to close with
And(Older(2016), Key(PK_s_i))
b) The tip N is at inner tip state M - c, use path And(After(M+1),
Key(PK_u_burst_N)) to jump to case 1.a
2) published Layer 1 tx is at non tip state N - c
a) Layer 2 does not get published: use path And(After(N+1), Key(PK_u1))
to jump back to newest state known on parent, repeat from top
b) Layer 2 gets published: use path And(After(N+1), Key(PK_u1)) to jump
back to newest state known on parent, repeat from top


This trampoline pattern should essentially be repeatable as many times as
needed, although I think 2 layers is likely enough in practice.

In terms of "state management", it grows at O(layers) but is otherwise
constant. A node must only store:

Key/Sigs for
PK_s_i: to allow closing at the highest reachable state
PK_u1
During burst:
PK_u_burst_N: to allow getting to current burst
PK_s_burst_N: the same as PK_s_i just makes sense to think of it's
distinct purpose from PK_s_i not requiring a sequence lock

Note that the above scripts can be optimized to remove the Older clause as
it can be a rule that all PK_s_i must sign with a sequence unless entering
a burst.
--
@JeremyRubin 



On Sat, Jul 10, 2021 at 2:07 PM Jeremy  wrote:

> Let's say you're about to hit your sequence limits on a Eltoo channel...
> Do you have to go on chain?
>
> No, you could do a continuation where for your *final* update, you sign a
> move to a new update key. E.g.,
>
> start at: IF "N+1" CLTV DROP  CHECKSIG  ELSE 2016 CSV DROP 
> CHECKSIG ENDIF
>
> before N+1 = last, sign a txn with pk_s_last that moves coins to
>
> IF "1" CLTV DROP <*pk_u**2*> CHECKSIG  ELSE 2016 CSV DROP 
> CHECKSIG ENDIF
>
> This essentially lets you do 32 bits worth of updates and then fwd to a
> new contract by paying 1x extra transaction.
>
> This is potentially better than just directly closing because we keep it
> off chain for longer.  However... this also adds an additional CSV.
>
> (We can get around this by modifying the script branch which ends a CLTV
> domain with:
>  CHECKSIG
> since any updates past that point are done through the continuation
> state... but let's ignore that for the next part)
>
> What if we *always* used this every update? Then we'd essentially have 64
> bits of sequence space. Each layer of this trick adds 32 bytes.
>
> Doing layers like this inherently adds a bunch of CSV layers, so it
> increases resolution time linearly.
>
> One possibility to mitigate this is to do a "semitrusted burst mode" with
> a counterparty. Suppose you're at sequence M and it's a normal txn.
>
> Party A requests to Party B to initiate burst mode. A and B move to
> sequence M+1 where state M+1 passes through to a 2 step Eltoo update.
>
> This burst now has 32 bits of sequences to blow through.
>
> B or A then indicates to the other party to terminate the burst at
> "internal state number" Q. Then B and A sign M+2 where M+2 reflects the
> last state at internal state number Q. This gets rid of the temporary extra
> locking time for when parties are offline.
>
> This has a benefit for privacy as well because if this protocol is used,
> then top level state numbers do not reflect the # of payments strongly as
> they're more akin to how many burst mode payments were done.
>
> The semi trusted nature of this is that if a malicious peer induces you
> into starting this, you double your funds lockup time. There are some
> mitigations:
>
> 1) Only enter burst mode with long lived peers
> 2) Only enter burst mode when initiator has more funds in the channel than
> you (or has some ratio) which imposes an opportunity cost for attacking.
> 3) Only allow a certain % of liquidity to be moved during a burst -- e.g.,
> any time the delta in balance goes above a threshold, force a higher order
> channel state update.
>
>
>
>
> Best,
>
> Jeremy
>
>
> --
> @JeremyRubin 
> 
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org

[Lightning-dev] Eltoo Burst Mode & Continuations

[Jeremy]

Let's say you're about to hit your sequence limits on a Eltoo channel... Do
you have to go on chain?

No, you could do a continuation where for your *final* update, you sign a
move to a new update key. E.g.,

start at: IF "N+1" CLTV DROP  CHECKSIG  ELSE 2016 CSV DROP 
CHECKSIG ENDIF

before N+1 = last, sign a txn with pk_s_last that moves coins to

IF "1" CLTV DROP <*pk_u**2*> CHECKSIG  ELSE 2016 CSV DROP  CHECKSIG
ENDIF

This essentially lets you do 32 bits worth of updates and then fwd to a new
contract by paying 1x extra transaction.

This is potentially better than just directly closing because we keep it
off chain for longer.  However... this also adds an additional CSV.

(We can get around this by modifying the script branch which ends a CLTV
domain with:
 CHECKSIG
since any updates past that point are done through the continuation
state... but let's ignore that for the next part)

What if we *always* used this every update? Then we'd essentially have 64
bits of sequence space. Each layer of this trick adds 32 bytes.

Doing layers like this inherently adds a bunch of CSV layers, so it
increases resolution time linearly.

One possibility to mitigate this is to do a "semitrusted burst mode" with a
counterparty. Suppose you're at sequence M and it's a normal txn.

Party A requests to Party B to initiate burst mode. A and B move to
sequence M+1 where state M+1 passes through to a 2 step Eltoo update.

This burst now has 32 bits of sequences to blow through.

B or A then indicates to the other party to terminate the burst at
"internal state number" Q. Then B and A sign M+2 where M+2 reflects the
last state at internal state number Q. This gets rid of the temporary extra
locking time for when parties are offline.

This has a benefit for privacy as well because if this protocol is used,
then top level state numbers do not reflect the # of payments strongly as
they're more akin to how many burst mode payments were done.

The semi trusted nature of this is that if a malicious peer induces you
into starting this, you double your funds lockup time. There are some
mitigations:

1) Only enter burst mode with long lived peers
2) Only enter burst mode when initiator has more funds in the channel than
you (or has some ratio) which imposes an opportunity cost for attacking.
3) Only allow a certain % of liquidity to be moved during a burst -- e.g.,
any time the delta in balance goes above a threshold, force a higher order
channel state update.




Best,

Jeremy


--
@JeremyRubin 

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

Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address

[Harsha Goli]

It appears your example is of a bitcoin address embedded in a lighting uri,
not the lighting invoice (unless it's serialized and I'm not seeing it)

On Sat, Jul 10, 2021 at 5:10 AM Bitcoin Error Log 
wrote:

> You can already embed a bitcoin address into an LN invoice. See example by
> clicking “contribute” at https://thebiz.pro
>
> Looks like this:
>
>
> bitcoin:bc1qfzaj2jaqhq7yn9hy3c00ndat4lq9me7sdvgc4q?lightning=lnbc50u1pswjc7ppp5qddlvfgk6j8aj3p9c3r7ql5j40yntv30ydcw77a6r8vvxmpf9uzsdrq235x2gzzd9azcgznv4shxmmwyqcjcgz9wp5hxmmyv5srxzjtwf5hxare94xx26t8dqsy66twv45xzms2yq34g3jnxqc52vpncqzpgfppqfzaj2jaqhq7yn9hy3c00ndat4lq9me7ssp5ftd8uqjrdrycugwmq0v868vk0zyu9gntrlla3chr74d83hkdz78s9qyyssqahk0vjzc0yfd3faevtsg0rx6guyyw6mnjmsyw858xtsqp3l4k763jhct4k7q5ndpc4mkznuskzj00vqql8vxlfp6n54kskkc8qheseqqf38kwg
>
> --
> ~ John Carvalho
>
> Schedule: https://calendly.com/bitcoinerrorlog
> Chat: https://t.me/bitcoinerrorlog
> Social: https://twitter.com/bitcoinerrorlog
> ___
> 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] Proposal for an invoice pattern with an embedded Bitcoin onchain address

[Bitcoin Error Log]

You can already embed a bitcoin address into an LN invoice. See example by
clicking “contribute” at https://thebiz.pro

Looks like this:

bitcoin:bc1qfzaj2jaqhq7yn9hy3c00ndat4lq9me7sdvgc4q?lightning=lnbc50u1pswjc7ppp5qddlvfgk6j8aj3p9c3r7ql5j40yntv30ydcw77a6r8vvxmpf9uzsdrq235x2gzzd9azcgznv4shxmmwyqcjcgz9wp5hxmmyv5srxzjtwf5hxare94xx26t8dqsy66twv45xzms2yq34g3jnxqc52vpncqzpgfppqfzaj2jaqhq7yn9hy3c00ndat4lq9me7ssp5ftd8uqjrdrycugwmq0v868vk0zyu9gntrlla3chr74d83hkdz78s9qyyssqahk0vjzc0yfd3faevtsg0rx6guyyw6mnjmsyw858xtsqp3l4k763jhct4k7q5ndpc4mkznuskzj00vqql8vxlfp6n54kskkc8qheseqqf38kwg

-- 
~ John Carvalho

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address

[René Pickhardt via Lightning-dev]

Hi,

I am sorry to hear you had trouble with payment pathfinding. However if I
understand your suggestion correctly I think the proposed functionality
already exists in a very similar way in today's invoices with a mechanism
called fallback address. The main difference seems to be that the fallback
adress is not a human readable part of the invoice string but encoded with
the other data in the bech32 part of the invoice.

Check bolt 11 [1] on github for more detail but I copied the relevant
snippets from there to this mail.


   - f (9): data_length variable, depending on version. Fallback on-chain
   address: for Bitcoin, this starts with a 5-bit version and contains a
   witness program or P2PKH or P2SH address.

The f field allows on-chain fallback; however, this may not make sense for
tiny or time-sensitive payments. It's possible that new address forms will
appear; thus, multiple f fields (in an implied preferred order) help with
transition, and f fields with versions 19-31 will be ignored by readers.

[1]:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md

With kind regards Rene Pickhardt

 schrieb am Sa., 10. Juli 2021, 07:56:

> Hi,
>
> I propose a new LN invoice pattern that contains a Bitcoin address for
> onchain transfer as backup.
>
> Motivation: My dream is to have an app wallet that works in a totally
> abstract and transparent way onchain and/or LN depending on the situation.
> Phoenix wallet almost achieves this, but there is still a certain
> LN/onchain distinction that confuses users a bit.
>
> I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
> Payment failed in several attempts. It was not clear why. The fact is that
> I managed to transfer to Breeze and then from there I was finally able to
> transfer to the final destination. For some reason it had no liquidity on
> the specific route. These exception cases greatly confuse the most
> non-expert users. If, on the invoice my friend sent to me, I had embedded a
> Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
> want to send it on-chain at XPTO fee rate? It can take a while."
>
> That way, in case of payment failure, there is an immediate onchain backup
> alternative, useful especially when rates are low, like now.
>
> The format could be something like:
>
> :::
>
> Example:
>
> ln:v2:Hi,
>
> I propose a new invoice pattern that contains a Bitcoin address for
> onchain transfer.
>
> Motivation: My dream is to have a portfolio that works in a totally
> abstract and transparent way onchain and/or LN depending on the situation.
> Phoenix wallet almost achieves this, but there is still a certain
> LN/onchain distinction that confuses users a bit.
>
> I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
> Payment failed in several attempts. It was not clear why. The fact is that
> I managed to transfer to Breeze and then from there I was finally able to
> transfer to the final destination. For some reason it had no liquidity on
> the specific route. These exception cases greatly confuse the most
> non-expert users. If, on the invoice my friend sent me, I had embedded a
> Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
> want to send onchain at XPTO rate?"
>
> That way, in case of payment failure, there is an immediate onchain backup
> alternative, useful especially when rates are low, like now.
>
> The format could be something like:
>
> :::
>
> Example:
>
>
> ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqpq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqgq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj
>
> Thank you.
> ___
> 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