Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-24 📝 Original message: On 24 August 2015 at ...
📅 Original date posted:2015-08-24
📝 Original message:
On 24 August 2015 at 12:58, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On 24 August 2015 at 02:59, Rusty Russell <rusty at rustcorp.com.au> wrote:
> >> 2) Dave starts the HTLC process, but then times out (doesn't resolve
> >> HTLC in 20*11 seconds, and doesn't send back a blame
> >> packet from Emma, either).
> >> In the latter case, Carol dumps the commit tx to the blockchain, and the
> >> screwed-up HTLC (and any other casualty HTLCs in progress, sorry). She
> >> can include this commit tx + htlc txs in the blame packet back to Bob;
> >> there's no reason to name Dave AFAICT[1].
> >
> > The HTLC txn provides Dave's public key id though (assuming you un-P2SH
> > it, which you need to to prove that it corresponds with the R you
> expect),
> > which is the only name for Dave that matters, isn't it?
>
> There's no reason for the two to be connected. You have a pubkey as
> your ID for network and routing encryption, but you can offer any
> transaction as an anchor, and use any keys you want.
>
Are we talking about different transactions? I'm thinking:
T1: Carol+Dave Anchor(s)
Inputs: whatever
Output: requires Carol + Dave
T2: Channel closure
Inputs: T1
Outputs:
Carol balance
Dave balance
HTLC 1
HTLC 2
HTLC 3
...
T3: Dave cashing in HTLC 2
Input: T2 HTLC 2; R, Dave's key
Outputs: whatever
For Carol to prove to Bob that she closed the channel, she points Bob at
T2/HTLC 3 providing the expanded P2SH as necessary, which reveals Dave's
"lightning" key as well as R. The anchor isn't really relevant.
But maybe Dave could have a different key for each channel, and choose them
independently of his lightning network id as used for routing (and the
corresponding public key used for onion routing)?
But if the key isn't linked, then Carol could construct her own
"Carol-in-a-Dave-suit" set of keys, and make a fake "channel closure"
transaction to convince Bob that Dave was being bad, It would cost a
bitcoin transaction and lock up her bitcoins for the timeout period
(assuming she never finds out R), though -- but I'm not sure that's enough?
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150824/7cdb7201/attachment-0001.html>;
📝 Original message:
On 24 August 2015 at 12:58, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On 24 August 2015 at 02:59, Rusty Russell <rusty at rustcorp.com.au> wrote:
> >> 2) Dave starts the HTLC process, but then times out (doesn't resolve
> >> HTLC in 20*11 seconds, and doesn't send back a blame
> >> packet from Emma, either).
> >> In the latter case, Carol dumps the commit tx to the blockchain, and the
> >> screwed-up HTLC (and any other casualty HTLCs in progress, sorry). She
> >> can include this commit tx + htlc txs in the blame packet back to Bob;
> >> there's no reason to name Dave AFAICT[1].
> >
> > The HTLC txn provides Dave's public key id though (assuming you un-P2SH
> > it, which you need to to prove that it corresponds with the R you
> expect),
> > which is the only name for Dave that matters, isn't it?
>
> There's no reason for the two to be connected. You have a pubkey as
> your ID for network and routing encryption, but you can offer any
> transaction as an anchor, and use any keys you want.
>
Are we talking about different transactions? I'm thinking:
T1: Carol+Dave Anchor(s)
Inputs: whatever
Output: requires Carol + Dave
T2: Channel closure
Inputs: T1
Outputs:
Carol balance
Dave balance
HTLC 1
HTLC 2
HTLC 3
...
T3: Dave cashing in HTLC 2
Input: T2 HTLC 2; R, Dave's key
Outputs: whatever
For Carol to prove to Bob that she closed the channel, she points Bob at
T2/HTLC 3 providing the expanded P2SH as necessary, which reveals Dave's
"lightning" key as well as R. The anchor isn't really relevant.
But maybe Dave could have a different key for each channel, and choose them
independently of his lightning network id as used for routing (and the
corresponding public key used for onion routing)?
But if the key isn't linked, then Carol could construct her own
"Carol-in-a-Dave-suit" set of keys, and make a fake "channel closure"
transaction to convince Bob that Dave was being bad, It would cost a
bitcoin transaction and lock up her bitcoins for the timeout period
(assuming she never finds out R), though -- but I'm not sure that's enough?
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150824/7cdb7201/attachment-0001.html>;