Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-16 📝 Original message: On 16 January 2017 at ...
đź“… Original date posted:2017-01-16
đź“ť Original message:
On 16 January 2017 at 15:32, Anthony Towns <aj at erisian.com.au> wrote:
> On Mon, Jan 16, 2017 at 02:44:43PM +0800, Andrés G. Aragoneses wrote:
> > But I thought this problem was already solved by using OP_CLTV/OP_CSV
> -style
> > channels instead of Spillman-style ones?
> > See:
> > http://bitcoin.stackexchange.com/a/48546/2751
>
> The approach described there is to have a channel timeout (adding the
> "customer signs, but locktime greater than refund time" alternative to
> the P2SH address). The lightning spec doesn't currently do that (see the
> "Funding Transaction Output" section of [0]). Lightning uses CLTV and CSV
> to make the HTLC steps work, that is to make the channel bidirectional,
> rather than being limited to having one end take the role of customer
> sending money to the merchant on the other end.
>
Ok but I also read the last paragraph of the last version of the Lightning
paper which I quote:
"A further stop-gap solution using OP CHECKSEQUENCEVERIFY
57or a less-optimal use of OP CHECKLOCKTIMEVERIFY will be described
in a future paper by Rusty Russell. An updated version of this paper will
also include these constructions."
So I guess I was confused by thinking that Lightning Level1 and Level2 was
referring to this, and maybe someone forgot to update the paper to include
L1&L2.
But no, we're talking about using CLTV (or CSV, I guess?) for the refund
transaction instead of for the HTLC. Would we be able to call this an
hypothetical Level2.5 of LN? (Level 3 being the one requiring SeqWit).
>
> [0] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-
> transactions.md
>
> It's not a 100% solution on its own though -- the "merchant" in this
> scenario can choose not to provide the second signature back to the
> customer ever, in which case the customer can't access their funds
> again until the refund time arrives. Better than being never able to
> access their funds again, of course, which is what you get if you use
> the current method, without segwit, and get malleated.
>
Exactly, that's why I think L2.5 would be the only feasible solution in
lack of L3.
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/44b73efd/attachment.html>;
đź“ť Original message:
On 16 January 2017 at 15:32, Anthony Towns <aj at erisian.com.au> wrote:
> On Mon, Jan 16, 2017 at 02:44:43PM +0800, Andrés G. Aragoneses wrote:
> > But I thought this problem was already solved by using OP_CLTV/OP_CSV
> -style
> > channels instead of Spillman-style ones?
> > See:
> > http://bitcoin.stackexchange.com/a/48546/2751
>
> The approach described there is to have a channel timeout (adding the
> "customer signs, but locktime greater than refund time" alternative to
> the P2SH address). The lightning spec doesn't currently do that (see the
> "Funding Transaction Output" section of [0]). Lightning uses CLTV and CSV
> to make the HTLC steps work, that is to make the channel bidirectional,
> rather than being limited to having one end take the role of customer
> sending money to the merchant on the other end.
>
Ok but I also read the last paragraph of the last version of the Lightning
paper which I quote:
"A further stop-gap solution using OP CHECKSEQUENCEVERIFY
57or a less-optimal use of OP CHECKLOCKTIMEVERIFY will be described
in a future paper by Rusty Russell. An updated version of this paper will
also include these constructions."
So I guess I was confused by thinking that Lightning Level1 and Level2 was
referring to this, and maybe someone forgot to update the paper to include
L1&L2.
But no, we're talking about using CLTV (or CSV, I guess?) for the refund
transaction instead of for the HTLC. Would we be able to call this an
hypothetical Level2.5 of LN? (Level 3 being the one requiring SeqWit).
>
> [0] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-
> transactions.md
>
> It's not a 100% solution on its own though -- the "merchant" in this
> scenario can choose not to provide the second signature back to the
> customer ever, in which case the customer can't access their funds
> again until the refund time arrives. Better than being never able to
> access their funds again, of course, which is what you get if you use
> the current method, without segwit, and get malleated.
>
Exactly, that's why I think L2.5 would be the only feasible solution in
lack of L3.
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/44b73efd/attachment.html>;