Re: [Lightning-dev] PTLCs early draft specification

[Anthony Towns]

On Thu, Dec 09, 2021 at 12:34:00PM +1100, Lloyd Fournier wrote:
> I wanted to add a theoretical note that you might be aware of. The final
> message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
> does not care about Bob revoking a commit tx that gives her strictly more
> coins.

That's true if Alice is only sending new tx's paying Bob; and Rusty's
examples in the `option_simplified_update` proposal do only include new
HTLCs...

But I think it's intended to cover *all* update messages, and if Alice is
also including any `update_fulfill_htlc` or `update_fail_htlc` messages in
the commitment, she's potentially gaining funds, both for the amount of
fees she saves by avoiding extra transactions, but for the fulfill case,
potentially also because she doesn't need to worry about the fulfilled
htlc reaching its timeout.

Actually, as an alternative to the `option_simplified_update` approach,
has anyone considered an approach more like this:

 * each node can unilaterally send various messages that always update
   the state, eg:
 + new htlc/ptlc paying the other node (update_add_htlc)
 + secret reveal of htlc/ptlc paying self (update_fulfil_htlc)
 + rejection of htlc/ptlc paying self (update_fail_htlc)
 + timeout of htlc/ptlc paying the other node (not currently allowed?)
 + update the channel fee rate (update_fee)

 * continue to allow these to occur at any time, asynchronously, but
   to make it easier to keep track of them, add a uint64_t counter
   to each message, that each peer increments by 1 for each message.

 * each channel state (n) then corresponds to the accumulation of
   updates from each each peer, up to message (a) for Alice, and message
   (b) for Bob.

 * so when updating to a new commitment (n+1), the proposal message
   should just include both update values (a') and (b')

 * nodes can then track the state by having a list of
   htlcs/ptlcs/balances, etc for state (n), and a list of unapplied
   update messages for themselves and the other party (a+1,...,a') and
   (b+1,...,b'), and apply them in order when constructing the new state
   (n+1) for a new commitment signing round

I think that retains both the interesting async bits (anyone can queue
state updates immediately) but also makes it fairly simple to maintain
the state?

> Bob's new commit tx can use the same revocation key as the previous
> one

That's a neat idea, but I think the fail/fulfill messages break it.
_But_ I think that means it would still be an interesting technique to
use for fast forwards which get updated for every add message...

> Not sending messages you don't need to is usually
> both more performant and simpler 

The extra message from Bob allows Alice to discard the adaptor sigs
associated with the old state, which I think is probably worthwhile
anyway?

Cheers,
aj

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

Re: [Lightning-dev] PTLCs early draft specification

[Lloyd Fournier]

Hi thread,

I was indeed mistaken. It does require four rounds for both parties to
fully transition to the next comimit tx and I don't think there is any easy
way around this. As you've pointed out there it's still only three rounds
before the message is forwarded so no performance decrease for forwarding.

I wanted to add a theoretical note that you might be aware of. The final
message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
does not care about Bob revoking a commit tx that gives her strictly more
coins. Bob's new commit tx can use the same revocation key as the previous
one i.e. only the offerer of the PTLC/HTLC does a revocation and increments
their revocation key. Not sending messages you don't need to is usually
both more performant and simpler but given that it introduces some
asymmetry so I'm not sure if it's worth it. It's also worth noting that
with fast forwards + symmetric commit tx you will need to do the full four
rounds always I think.

Cheers,

LL

On Thu, 9 Dec 2021 at 02:03, Bastien TEINTURIER  wrote:

> Hi again AJ and list,
>
> I have slightly re-worked your proposal, and came up with the following
> (I also added the musig2 nonces for completeness):
>
> Alice -> Bob: commitment_proposed
> channel id
> adaptor sigs for PTLCs to Bob in Alice's next commitment
> musig nonces for Alice to spend funding tx
> musig nonces for Bob to spend funding tx
>
> Bob -> Alice: commitment_proposed
> channel id
> adaptor sigs for PTLCs to Alice in Bob's next commitment
> musig nonces for Alice to spend funding tx
> musig nonces for Bob to spend funding tx
>
> Bob -> Alice: commitment_signed
> channel id
> signature for Alice to spend funding tx
> sigs for Alice to spend HTLCs and PTLCs from her next commitment
>
> Alice -> Bob: revoke_and_ack
> channel id
> reveal previous commitment secret
> next commitment point
>
> Alice -> Bob: commitment_signed
> channel id
> signature for Bob to spend funding tx
> sigs for Bob to spend HTLCs and PTLCs from his next commitment
>
> Bob -> Alice: revoke_and_ack
> channel id
> reveal previous commitment secret
> next commitment point
>
> I believe it's exactly the same flow of data between peers as your
> proposal, but I simply split the data into several messages. Let me
> know if that's incorrect or if I missed a subtlety in your proposal.
>
> This has some small advantages:
>
> * commitment_signed and revoke_and_ack are mostly unchanged, we just
> add a new message before the commit / revoke dance. The only change
> happens in commitment_signed, where the signatures for PTLC-success
> transactions will actually become adaptor signatures.
> * the new adaptor signatures are in commitment_proposed instead of being
> in commitment_signed, which ensures that we can still have 2*483
> pending (H|P)TLCs: since the message size is limited to 65kB, we would
> otherwise decrease our maximum to ~2*335 with your proposal (very rough
> calculation)
> * the messages are now symmetrical, which may be easier to reason about
>
> One thing to note is that we reversed the order in which participants
> sign new commitments. We previously had Alice sign first, whereas now
> if Alice initiates, Bob will sign the updated commitment first. This is
> why we add only 0.5 RTT instead of 1 RTT compared to the current protocol.
> I don't think this is an issue, but if someone sees a way to maliciously
> exploit this, please share it!
>
> I updated my article [0], people jumping on the thread now may find it
> helpful to better understand this discussion.
>
> Thanks,
> Bastien
>
> [0] https://github.com/t-bast/lightning-docs/pull/16
>
> Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER  a
> écrit :
>
>> Hi AJ,
>>
>> I think the problem t-bast describes comes up here as well when you
>>> collapse the fast-forwards (or, anytime you update the commitment
>>> transaction even if you don't collapse them).
>>
>>
>> Yes, exactly.
>>
>> I think doing a synchronous update of commitments to the channel state,
>>> something like:
>>
>>
>>
>> Alice -> Bob: propose_new_commitment
>>> channel id
>>> adaptor sigs for PTLCs to Bob
>>
>>
>>> Bob -> Alice: agree_new_commitment
>>> channel id
>>> adaptor sigs for PTLCs to Alice
>>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>>> commitment tx
>>> signature for Alice to spend funding tx
>>>
>>> Alice -> Bob: finish_new_commitment_1
>>> channel id
>>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>>> commitment tx
>>> signature for Bob to spend funding tx
>>> reveal old prior commitment secret
>>> new commitment nonce
>>>
>>> Bob -> Alice: finish_new_commitment_2
>>> reveal old prior commitment secret
>>> new commitment nonce
>>>
>>> would work pretty well.
>>
>>
>> I agree, this is better than my naive addition of a `remote_ptlcs_signed`
>> message in both directions, and even though it changes the protocol
>> messages
>> it stays very

Re: [Lightning-dev] [bitcoin-dev] Take 2: Removing the Dust Limit

[Ruben Somsen]

Hi Jeremy,

Thanks for sharing your thoughts.

To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may still be valid (as long as none of its inputs get
spent elsewhere) and could eventually get confirmed.

I think those are good points. I do still see a possibility where a user
non-maliciously happens to behave in a way that causes all of the above to
happen, but it does seem somewhat unlikely.

It could happen if all of the following occurs:
1. Another output happens to get spent at a higher feerate (e.g. because an
absolute timelock expires and the output gets used)
2. The tx spending the 0 sat output then happens to not make it into the
block due to the lower fees
3. The user then happens to invalidate the tx that was spending from the 0
sat output (seems rational at that point)

Assuming this is the only scenario (I am at least not currently aware of
others), the question then becomes whether the above is acceptable in order
to avoid a soft fork.

Cheers,
Ruben


On Wed, Dec 8, 2021 at 6:41 PM Jeremy  wrote:

> IMO this is not a big problem. The problem is not if a 0 value ever enters
> the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
> can be spent. In fact, it increases it's feerate with P1's confirmation so
> it's somewhat likely it would go in. C2 further has to be pretty expensive
> compared to C1 in order to be mined when C2 would not be, so the user
> trying to do this has to pay for it.
>
> If we're worried it might never be spent again since no incentive, it's
> rational for miners *and users who care about bloat* to save to disk the
> transaction spending it to resurrect it. The way this can be broken is if
> the txn has two inputs and that input gets spent separately.
>
> That said, I think if we can say that taking advantage of keeping the 0
> value output will cost you more than if you just made it above dust
> threshold, it shouldn't be economically rational to not just do a dust
> threshold value output instead.
>
> So I'm not sure the extent to which we should bend backwards to make 0
> value outputs impossible v.s. making them inconvenient enough to not be
> popular.
>
>
>
> -
> Consensus changes below:
> -
>
> Another possibility is to have a utxo with drop semantics; if UTXO X with
> some flag on it is not spent in the block it is created, it expires and can
> never be spent. This is essentially an inverse timelock, but severely
> limited to one block and mempool evictions can be handled as if a conflict
> were mined.
>
> These types of 0 value outputs could be present just for attaching fee in
> the mempool but be treated like an op_return otherwise. We could add two
> cases for this: one bare segwit version (just the number, no data) and one
> that's equivalent to taproot. This covers OP_TRUE anchors very efficiently
> and ones that require a signature as well.
>
> This is relatively similar to how Transaction Sponsors works, but without
> full tx graph de-linkage... obviously I think if we'll entertain a
> consensus change, sponsors makes more sense, but expiring utxos doesn't
> change as many properties of the tx-graph validation so might be simpler.
>
>
>
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Take 2: Removing the Dust Limit

[Jeremy]

IMO this is not a big problem. The problem is not if a 0 value ever enters
the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
can be spent. In fact, it increases it's feerate with P1's confirmation so
it's somewhat likely it would go in. C2 further has to be pretty expensive
compared to C1 in order to be mined when C2 would not be, so the user
trying to do this has to pay for it.

If we're worried it might never be spent again since no incentive, it's
rational for miners *and users who care about bloat* to save to disk the
transaction spending it to resurrect it. The way this can be broken is if
the txn has two inputs and that input gets spent separately.

That said, I think if we can say that taking advantage of keeping the 0
value output will cost you more than if you just made it above dust
threshold, it shouldn't be economically rational to not just do a dust
threshold value output instead.

So I'm not sure the extent to which we should bend backwards to make 0
value outputs impossible v.s. making them inconvenient enough to not be
popular.



-
Consensus changes below:
-

Another possibility is to have a utxo with drop semantics; if UTXO X with
some flag on it is not spent in the block it is created, it expires and can
never be spent. This is essentially an inverse timelock, but severely
limited to one block and mempool evictions can be handled as if a conflict
were mined.

These types of 0 value outputs could be present just for attaching fee in
the mempool but be treated like an op_return otherwise. We could add two
cases for this: one bare segwit version (just the number, no data) and one
that's equivalent to taproot. This covers OP_TRUE anchors very efficiently
and ones that require a signature as well.

This is relatively similar to how Transaction Sponsors works, but without
full tx graph de-linkage... obviously I think if we'll entertain a
consensus change, sponsors makes more sense, but expiring utxos doesn't
change as many properties of the tx-graph validation so might be simpler.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Take 2: Removing the Dust Limit

[Jeremy]

Bastien,

The issue is that with Decker Channels you either use SIGHASH_ALL / APO and
don't allow adding outs (this protects against certain RBF pinning on the
root with bloated wtxid data) and have anchor outputs or you do allow them
and then are RBF pinnable (but can have change).

Assuming you use anchor outs, then you really can't use dust-threshold
outputs as it either breaks the ratcheting update validity (if the specific
amount paid to output matters) OR it allows many non-latest updates to
fully drain the UTXO of any value.

You can get around the needing for N of them by having a congestion-control
tree setup in theory; then you only need log(n) data for one bumper, and
(say) 1.25x the data if all N want to bump. This can be a nice trade-off
between letting everyone bump and not. Since these could be chains of
IUTXO, they don't need to carry any weight directly.

The carve out would just be to ensure that CPFP 0 values are known how to
be spent.





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

Re: [Lightning-dev] PTLCs early draft specification

[Bastien TEINTURIER]

Hi again AJ and list,

I have slightly re-worked your proposal, and came up with the following
(I also added the musig2 nonces for completeness):

Alice -> Bob: commitment_proposed
channel id
adaptor sigs for PTLCs to Bob in Alice's next commitment
musig nonces for Alice to spend funding tx
musig nonces for Bob to spend funding tx

Bob -> Alice: commitment_proposed
channel id
adaptor sigs for PTLCs to Alice in Bob's next commitment
musig nonces for Alice to spend funding tx
musig nonces for Bob to spend funding tx

Bob -> Alice: commitment_signed
channel id
signature for Alice to spend funding tx
sigs for Alice to spend HTLCs and PTLCs from her next commitment

Alice -> Bob: revoke_and_ack
channel id
reveal previous commitment secret
next commitment point

Alice -> Bob: commitment_signed
channel id
signature for Bob to spend funding tx
sigs for Bob to spend HTLCs and PTLCs from his next commitment

Bob -> Alice: revoke_and_ack
channel id
reveal previous commitment secret
next commitment point

I believe it's exactly the same flow of data between peers as your
proposal, but I simply split the data into several messages. Let me
know if that's incorrect or if I missed a subtlety in your proposal.

This has some small advantages:

* commitment_signed and revoke_and_ack are mostly unchanged, we just
add a new message before the commit / revoke dance. The only change
happens in commitment_signed, where the signatures for PTLC-success
transactions will actually become adaptor signatures.
* the new adaptor signatures are in commitment_proposed instead of being
in commitment_signed, which ensures that we can still have 2*483
pending (H|P)TLCs: since the message size is limited to 65kB, we would
otherwise decrease our maximum to ~2*335 with your proposal (very rough
calculation)
* the messages are now symmetrical, which may be easier to reason about

One thing to note is that we reversed the order in which participants
sign new commitments. We previously had Alice sign first, whereas now
if Alice initiates, Bob will sign the updated commitment first. This is
why we add only 0.5 RTT instead of 1 RTT compared to the current protocol.
I don't think this is an issue, but if someone sees a way to maliciously
exploit this, please share it!

I updated my article [0], people jumping on the thread now may find it
helpful to better understand this discussion.

Thanks,
Bastien

[0] https://github.com/t-bast/lightning-docs/pull/16

Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER  a écrit :

> Hi AJ,
>
> I think the problem t-bast describes comes up here as well when you
>> collapse the fast-forwards (or, anytime you update the commitment
>> transaction even if you don't collapse them).
>
>
> Yes, exactly.
>
> I think doing a synchronous update of commitments to the channel state,
>> something like:
>
>
>
> Alice -> Bob: propose_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Bob
>
>
>> Bob -> Alice: agree_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Alice
>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>> commitment tx
>> signature for Alice to spend funding tx
>>
>> Alice -> Bob: finish_new_commitment_1
>> channel id
>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>> commitment tx
>> signature for Bob to spend funding tx
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> Bob -> Alice: finish_new_commitment_2
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> would work pretty well.
>
>
> I agree, this is better than my naive addition of a `remote_ptlcs_signed`
> message in both directions, and even though it changes the protocol
> messages
> it stays very close to the mechanisms we currently have.
>
> I'll spend some time specifying this in more details, to verify that we're
> not missing anything. What I really like about this proposal is that we
> can probably bundle that protocol change with `option_simplified_update`
> [0]
> without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
> do PTLCs. That lets us deploy this new update protocol separately from
> PTLCs
> and ensure it also simplifies the state machine and makes other features
> such as splicing [1] and dynamic channel upgrades [2] easier.
>
> Thanks,
> Bastien
>
> [0] https://github.com/lightning/bolts/pull/867
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://github.com/lightning/bolts/pull/868
>
> Le mer. 8 déc. 2021 à 10:29, Anthony Towns  a écrit :
>
>> On Tue, Dec 07, 2021 at 11:52:04PM +, ZmnSCPxj via Lightning-dev
>> wrote:
>> > Alternately, fast-forwards, which avoid this because it does not change
>> commitment transactions on the payment-forwarding path.
>> > You only change commitment transactions once you have enough changes to
>> justify collapsing them.
>>
>> I think the problem t-bast describes comes up here as well when you
>> collapse the fast-forwar

Re: [Lightning-dev] [bitcoin-dev] Take 2: Removing the Dust Limit

[Ruben Somsen]

Hi Jeremy,

I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:

- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat per byte
and they enter the mempool as a package
- Child C2 spends the other output of P1 with a really high feerate and
enters the mempool
- Fees rise and child C1 falls out of the mempool, leaving the 0 sat output
unspent

For this to not be a problem, the 0 sat output needs to provably be the
only spendable output. As you pointed out to me a few days ago, having a
relative timelock on the other outputs would do the trick (and this happens
to be true for spacechains), but that will only be provable if all script
conditions are visible prior to spending time (ruling out p2sh and taproot,
and conflicting with standardness rules for transactions).

It's worth noting out that you can't really make a policy rule that says
the 0 sat output can't be left unspent (i.e. C1 can't be evicted without
also evicting P1), as this would not mirror economically rational behavior
for miners (they would get more fees if they evicted C1, so we must assume
they will, if the transaction ever reaches them).

This last example really points out the tricky situation we're dealing
with. In my opinion, we'd only want to relay 0 sat outputs if we can
guarantee that it's never economically profitable to mine them without them
getting spent in the same block.

Finally, here's a timestamped link to a diagram that shows where 0 sat
outputs would be helpful for spacechains (otherwise someone would have to
pay the dust up front for countless outputs):
https://youtu.be/N2ow4Q34Jeg?t=2556

Cheers,
Ruben




On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER  wrote:

> Hi Jeremy,
>
> Right now, lightning anchor outputs use a 330 sats amount. Each commitment
> transaction has two such outputs, and only one of them is spent to help the
> transaction get confirmed, so the other stays there and bloats the utxo
> set.
> We allow anyone to spend them after a csv of 16 blocks, in the hope that
> someone will claim a batch of them when the fees are low and remove them
> from the utxo set. However, that trick wouldn't work with 0-value outputs,
> as
> no-one would ever claim them (doesn't make economical sense).
>
> We actually need to have two of them to avoid pinning: each participant is
> able to spend only one of these outputs while the parent tx is unconfirmed.
> I believe N-party protocols would likely need N such outputs (not sure).
>
> You mention a change to the carve-out rule, can you explain it further?
> I believe it would be a necessary step, otherwise 0-value outputs for
> CPFP actually seem worse than low-value ones...
>
> Thanks,
> Bastien
>
> Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev <
> bitcoin-...@lists.linuxfoundation.org> a écrit :
>
>> Bitcoin Devs (+cc lightning-dev),
>>
>> Earlier this year I proposed allowing 0 value outputs and that was shot
>> down for various reasons, see
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>>
>> I think that there can be a simple carve out now that package relay is
>> being launched based on my research into covenants from 2017
>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>>
>> Essentially, if we allow 0 value outputs BUT require as a matter of
>> policy (or consensus, but policy has major advantages) that the output be
>> used as an Intermediate Output (that is, in order for the transaction to be
>> creating it to be in the mempool it must be spent by another tx)  with the
>> additional rule that the parent must have a higher feerate after CPFP'ing
>> the parent than the parent alone we can both:
>>
>> 1) Allow 0 value outputs for things like Anchor Outputs (very good for
>> not getting your eltoo/Decker channels pinned by junk witness data using
>> Anchor Inputs, very good for not getting your channels drained by at-dust
>> outputs)
>> 2) Not allow 0 value utxos to proliferate long
>> 3) It still being valid for a 0 value that somehow gets created to be
>> spent by the fee paying txn later
>>
>> Just doing this as a mempool policy also has the benefits of not
>> introducing any new validation rules. Although in general the IUTXO concept
>> is very attractive, it complicates mempool :(
>>
>> I understand this may also be really helpful for CTV based contracts
>> (like vault continuation hooks) as well as things like spacechains.
>>
>> Such a rule -- if it's not clear -- presupposes a fully working package
>> relay system.
>>
>> I believe that this addresses all the issues with allowing 0 value
>> outputs to be created for the narrow case of immediately spendable outputs.
>>
>> Cheers,
>>
>> Jeremy
>>
>> p.s. why another post today? Thank Greg
>> https://twitter.com/JeremyRubin/status/1468390561417547780
>>
>>
>> --
>> @JeremyRubin 

Re: [Lightning-dev] PTLCs early draft specification

[Bastien TEINTURIER]

Hi AJ,

I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).


Yes, exactly.

I think doing a synchronous update of commitments to the channel state,
> something like:



Alice -> Bob: propose_new_commitment
> channel id
> adaptor sigs for PTLCs to Bob


> Bob -> Alice: agree_new_commitment
> channel id
> adaptor sigs for PTLCs to Alice
> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
> commitment tx
> signature for Alice to spend funding tx
>
> Alice -> Bob: finish_new_commitment_1
> channel id
> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
> commitment tx
> signature for Bob to spend funding tx
> reveal old prior commitment secret
> new commitment nonce
>
> Bob -> Alice: finish_new_commitment_2
> reveal old prior commitment secret
> new commitment nonce
>
> would work pretty well.


I agree, this is better than my naive addition of a `remote_ptlcs_signed`
message in both directions, and even though it changes the protocol messages
it stays very close to the mechanisms we currently have.

I'll spend some time specifying this in more details, to verify that we're
not missing anything. What I really like about this proposal is that we
can probably bundle that protocol change with `option_simplified_update` [0]
without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
do PTLCs. That lets us deploy this new update protocol separately from PTLCs
and ensure it also simplifies the state machine and makes other features
such as splicing [1] and dynamic channel upgrades [2] easier.

Thanks,
Bastien

[0] https://github.com/lightning/bolts/pull/867
[1] https://github.com/lightning/bolts/pull/863
[2] https://github.com/lightning/bolts/pull/868

Le mer. 8 déc. 2021 à 10:29, Anthony Towns  a écrit :

> On Tue, Dec 07, 2021 at 11:52:04PM +, ZmnSCPxj via Lightning-dev wrote:
> > Alternately, fast-forwards, which avoid this because it does not change
> commitment transactions on the payment-forwarding path.
> > You only change commitment transactions once you have enough changes to
> justify collapsing them.
>
> I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
>
> That is, if you have two PTLCs, one from A->B conditional on X, one
> from B->A conditional on Y. Then if A wants to update the commitment tx,
> she needs to
>
>   1) produce a signature to give to B to spend the funding tx
>   2) produce an adaptor signature to authorise B to spend via X from his
>  commitment tx
>   3) produce a signature to allow B to recover Y after timeout from his
>  commitment tx spending to an output she can claim if he cheats
>   4) *receive* an adaptor signature from B to be able to spend the Y output
>  if B posts his commitment tx using A's signature in (1)
>
> The problem is, she can't give B the result of (1) until she's received
> (4) from B.
>
> It doesn't matter if the B->A PTLC conditional on Y is in the commitment
> tx itself or within a fast-forward child-transaction -- any previous
> adaptor sig will be invalidated because there's a new commitment
> transaction, and if you allowed any way of spending without an adaptor
> sig, B wouldn't be able to recover the secret and would lose funds.
>
> It also doesn't matter if the commitment transaction that A and B will
> publish is the same or different, only that it's different from the
> commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
> would fix this if it were available)
>
> So I think this is still a relevant question, even if fast-forwards
> make it a rare problem, that perhaps is only applicable to very heavily
> used channels.
>
> (I said the following in email to t-bast already)
>
> I think doing a synchronous update of commitments to the channel state,
> something like:
>
>Alice -> Bob: propose_new_commitment
>channel id
>adaptor sigs for PTLCs to Bob
>
>Bob -> Alice: agree_new_commitment
>channel id
>adaptor sigs for PTLCs to Alice
>sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>  commitment tx
>signature for Alice to spend funding tx
>
>Alice -> Bob: finish_new_commitment_1
>channel id
>sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>  commitment tx
>signature for Bob to spend funding tx
>reveal old prior commitment secret
>new commitment nonce
>
>Bob -> Alice: finish_new_commitment_2
>reveal old prior commitment secret
>new commitment nonce
>
> would work pretty well.
>
> This adds half a round-trip compared to now:
>
>Alice -> Bob: commitment_signed
>Bob -> Alice: revoke_and_ack, commitment_signed
>Alice -> Bob: revoke_and_ack
>
> The timings change like s

Re: [Lightning-dev] PTLCs early draft specification

[Anthony Towns]

On Tue, Dec 07, 2021 at 11:52:04PM +, ZmnSCPxj via Lightning-dev wrote:
> Alternately, fast-forwards, which avoid this because it does not change 
> commitment transactions on the payment-forwarding path.
> You only change commitment transactions once you have enough changes to 
> justify collapsing them.

I think the problem t-bast describes comes up here as well when you
collapse the fast-forwards (or, anytime you update the commitment
transaction even if you don't collapse them).

That is, if you have two PTLCs, one from A->B conditional on X, one
from B->A conditional on Y. Then if A wants to update the commitment tx,
she needs to

  1) produce a signature to give to B to spend the funding tx
  2) produce an adaptor signature to authorise B to spend via X from his
 commitment tx
  3) produce a signature to allow B to recover Y after timeout from his
 commitment tx spending to an output she can claim if he cheats
  4) *receive* an adaptor signature from B to be able to spend the Y output
 if B posts his commitment tx using A's signature in (1)

The problem is, she can't give B the result of (1) until she's received
(4) from B.

It doesn't matter if the B->A PTLC conditional on Y is in the commitment
tx itself or within a fast-forward child-transaction -- any previous
adaptor sig will be invalidated because there's a new commitment
transaction, and if you allowed any way of spending without an adaptor
sig, B wouldn't be able to recover the secret and would lose funds.

It also doesn't matter if the commitment transaction that A and B will
publish is the same or different, only that it's different from the
commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
would fix this if it were available)

So I think this is still a relevant question, even if fast-forwards
make it a rare problem, that perhaps is only applicable to very heavily
used channels.

(I said the following in email to t-bast already)

I think doing a synchronous update of commitments to the channel state,
something like:

   Alice -> Bob: propose_new_commitment
   channel id
   adaptor sigs for PTLCs to Bob

   Bob -> Alice: agree_new_commitment
   channel id
   adaptor sigs for PTLCs to Alice
   sigs for Alice to spend HTLCs and PTLCs to Bob from her own
 commitment tx
   signature for Alice to spend funding tx

   Alice -> Bob: finish_new_commitment_1
   channel id
   sigs for Bob to spend HTLCs and PTLCs to Alice from his own
 commitment tx
   signature for Bob to spend funding tx
   reveal old prior commitment secret
   new commitment nonce

   Bob -> Alice: finish_new_commitment_2
   reveal old prior commitment secret
   new commitment nonce

would work pretty well.

This adds half a round-trip compared to now:

   Alice -> Bob: commitment_signed
   Bob -> Alice: revoke_and_ack, commitment_signed
   Alice -> Bob: revoke_and_ack

The timings change like so:

  Bob can use the new commitment after 1.5 round-trips (previously 0.5)

  Alice can be sure Bob won't use the old commitment after 2 round-trips
  (previously 1)

  Alice can use the new commitment after 1 round-trip (unchanged)

  Bob can be sure Alice won't use the old commitment after 1.5 round-trips
  (unchanged -- note: this is what's relevant for forwarding)

Making the funding tx a musig setup would mean also supplying 64B
of musig2 nonces along with the "adaptor sigs" in one direction,
and providing the other side's 64B of musig2 nonces back along with the
(now partial) signature for spending the funding tx (a total of 256B of
nonce data, not 128B).

Because it keeps both peers' commitments synchronised to a single channel
state, I think the same protocol should work fine with the revocable
signatures on a single tx approach too, though I haven't tried working
through the details.

Fast forwards would then be reducing the 2 round-trip protocol to
update the state commitment to a 0.5 round-trip update, to reduce
latency when forwarding by the same amount as before (1.5 round-trips
to 0.5 round-trips).

Cheers,
aj

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

Re: [Lightning-dev] PTLCs early draft specification

[Bastien TEINTURIER]

Hi Z,

`SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four
> years?) or a similar "covenant" opcode,

such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an
> `OP_CHECKSIGFROMSTACK` on an empty message.
> All you really need is a signature for an empty message, really...
>

That fails my requirement of "deployable in 2022" :)

Same thing applies to fast-forwards: I do see their value, but I'd like to
focus on a first version with minimal changes to the transaction structure
and the update protocol, to ensure we can actually get agreement on it
somewhat quickly and ship it in 2022. Then we can start working on a
more ambitious rework of the protocol that adds a lot of cool features,
such as what AJ proposed recently.

Cheers,
Bastien

Le mer. 8 déc. 2021 à 00:52, ZmnSCPxj  a écrit :

> Good morning t-bast,
>
>
> > I believe these new transactions may require an additional round-trip.
> > Let's take a very simple example, where we have one pending PTLC in each
> > direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to
> A.
> >
> > Now A makes some unrelated updates and wants to sign a new commitment.
> > A cannot immediately send her `commitment_signed` to B.
> > If she did, B would be able to broadcast this new commitment, and A would
> > not be able to claim PTLC_BA from B's new commitment (even if she knew
> > the payment secret) because she wouldn't have B's signature for the new
> > PTLC-remote-success transaction.
> >
> > So we first need B to send a new message `remote_ptlcs_signed` to A that
> > contains B's adaptor signatures for the PTLC-remote-success transactions
> > that would spend B's future commitment. After that A can safely send her
> > `commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B
> > before B can send its `commitment_signed`.
> >
> > It's actually not that bad, we're only adding one message in each
> direction,
> > and we're not adding more data (apart from nonces) to existing messages.
> >
> > If you have ideas on how to avoid this new message, I'd be glad to hear
> > them, hopefully I missed something again and we can make it better!
>
> `SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four
> years?) or a similar "covenant" opcode, such as `OP_CHECKTEMPLATEVERIFY`
> without any commitments or an `OP_CHECKSIGFROMSTACK` on an empty message.
> All you really need is a signature for an empty message, really...
>
> Alternately, fast-forwards, which avoid this because it does not change
> commitment transactions on the payment-forwarding path.
> You only change commitment transactions once you have enough changes to
> justify collapsing them.
> Even in the aj formulation, when A adds a PTLC it only changes the
> transaction that hosts **only** A->B PTLCs as well as the A main output,
> all of which can be sent outright by A without changing any B->A PTLCs.
>
> Basically... instead of a commitment tx like this:
>
> +---+
> funding outpoint -->|   |--> A main
> |   |--> B main
> |   |--> A->B PTLC
> |   |--> B->A PTLC
> +---+
>
> We could do this instead:
>
> +---+2of2  +-+
> funding outpoint -->|   |->| |--> A main
> |   |  | |--> A->B PTLC
> |   |  +-+
> |   |2or2  +-+
> |   |->| |--> B main
> |   |  | |--> B->A PTLC
> +---+  +-+
>
> Then whenever A wants to add a new A->B PTLC it only changes the tx inputs
> of the *other* A->B PTLCs without affecting the B->A PTLCs.
> Payment forwarding is fast, and you only change the "big" commitment tx
> rarely to clean up claimed and failed PTLCs, moving the extra messages out
> of the forwarding hot path.
>
> But this is basically highly similar to what aj designed anyway, so...
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Take 2: Removing the Dust Limit

[Bastien TEINTURIER]

Hi Jeremy,

Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in the hope that
someone will claim a batch of them when the fees are low and remove them
from the utxo set. However, that trick wouldn't work with 0-value outputs,
as
no-one would ever claim them (doesn't make economical sense).

We actually need to have two of them to avoid pinning: each participant is
able to spend only one of these outputs while the parent tx is unconfirmed.
I believe N-party protocols would likely need N such outputs (not sure).

You mention a change to the carve-out rule, can you explain it further?
I believe it would be a necessary step, otherwise 0-value outputs for
CPFP actually seem worse than low-value ones...

Thanks,
Bastien

Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev <
bitcoin-...@lists.linuxfoundation.org> a écrit :

> Bitcoin Devs (+cc lightning-dev),
>
> Earlier this year I proposed allowing 0 value outputs and that was shot
> down for various reasons, see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>
> I think that there can be a simple carve out now that package relay is
> being launched based on my research into covenants from 2017
> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>
> Essentially, if we allow 0 value outputs BUT require as a matter of policy
> (or consensus, but policy has major advantages) that the output be used as
> an Intermediate Output (that is, in order for the transaction to be
> creating it to be in the mempool it must be spent by another tx)  with the
> additional rule that the parent must have a higher feerate after CPFP'ing
> the parent than the parent alone we can both:
>
> 1) Allow 0 value outputs for things like Anchor Outputs (very good for not
> getting your eltoo/Decker channels pinned by junk witness data using Anchor
> Inputs, very good for not getting your channels drained by at-dust outputs)
> 2) Not allow 0 value utxos to proliferate long
> 3) It still being valid for a 0 value that somehow gets created to be
> spent by the fee paying txn later
>
> Just doing this as a mempool policy also has the benefits of not
> introducing any new validation rules. Although in general the IUTXO concept
> is very attractive, it complicates mempool :(
>
> I understand this may also be really helpful for CTV based contracts (like
> vault continuation hooks) as well as things like spacechains.
>
> Such a rule -- if it's not clear -- presupposes a fully working package
> relay system.
>
> I believe that this addresses all the issues with allowing 0 value outputs
> to be created for the narrow case of immediately spendable outputs.
>
> Cheers,
>
> Jeremy
>
> p.s. why another post today? Thank Greg
> https://twitter.com/JeremyRubin/status/1468390561417547780
>
>
> --
> @JeremyRubin 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev