Christopher Jamthagen [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-30 📝 Original message: Sent: Thursday, July 30, ...
📅 Original date posted:2015-07-30
📝 Original message:
Sent: Thursday, July 30, 2015 at 4:41 AM
From: "Rusty Russell" <rusty at rustcorp.com.au>
To: "Christopher Jamthagen" <cjamthagen at gmx.com>, "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Stealing money from a hub?
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>> Still trying to get the details right of this protocol. Please correct
>> me if I am wrong in any of my assumptions below.
>> Assume a payment route: Alice<>Bob<>Carol
>> Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice
>> updates her commitment tx with Bob including the HTLC output and Bob
>> does the same with Carol.
> OK.
>> Carol witholds R, forcing Bob to broadcast the commitment tx between
>> Bob and Carol.
> Yep, Carol goes non-responsive. Got it.
>> Carol can now spend the HTLC output because she knows R and thus
>> revealing it to the world. Alice now also refuses to update the
>> commitment tx with Bob, forcing Bob to broadcast that commitment tx.
> Poor Bob. Yep.
>> This commitment tx is putting a delay on
>> Bobs ability to spend the HTLC output (as well as all other outputs to
>> him), but Alice can spend the HTLC output if the CLTV has expired.
> Indeed, don't ever offer an HTLC less than your delay!
Yes, now that you mention it :)
If we assume that Gregory Maxwell's timestop feature is in use to further delay the expiration of a CSV in the case of full (or near-full) blocks. If this is used, the counterparty can just fill the blocks for a limited amount of time until his CLTV has expired and then take the HTLC output. I guess the time between CSV expiration and CLTV expiration can be adjusted depending on the value being transferred.
Would it be desirable/possible to implement the timestop feature for CLTV as well? That would make the difference between the number of blocks until either expiration the same in case of a block-filling attack. If I'm not mistaken Peter Todds BIP is already merged, but this feature could be implemented with another soft fork.
>> In most examples I have seen, the CLTV is 2 days between Alice and Bob
>> and 1 day between Bob and Carol, and all CSV delays are 3 days.
> I haven't seen an example which included a CSV delay amount.
> As the discussion with Joseph is establishing, the minimum CSV you allow
> controls the worst-case HTLC you can accept. CSV of a few hours should
> be OK if you're online all the time. I think...
Speaking of being online all the time, checking the blockchain is outsourceable, right? So it seems that miners would be the perfect third party to check for cheaters in LN. By offering them a nice chunk of our counterparty's funds as fees, they should be incentiviced enough to keep an extra eye for us on the blockchain.
> Anyone want to do some stats on that? CSV uses the median time of last
> 11 blocks, so to some extent you can tell the worst case...
> Cheers,
> Rusty.
📝 Original message:
Sent: Thursday, July 30, 2015 at 4:41 AM
From: "Rusty Russell" <rusty at rustcorp.com.au>
To: "Christopher Jamthagen" <cjamthagen at gmx.com>, "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Stealing money from a hub?
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>> Still trying to get the details right of this protocol. Please correct
>> me if I am wrong in any of my assumptions below.
>> Assume a payment route: Alice<>Bob<>Carol
>> Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice
>> updates her commitment tx with Bob including the HTLC output and Bob
>> does the same with Carol.
> OK.
>> Carol witholds R, forcing Bob to broadcast the commitment tx between
>> Bob and Carol.
> Yep, Carol goes non-responsive. Got it.
>> Carol can now spend the HTLC output because she knows R and thus
>> revealing it to the world. Alice now also refuses to update the
>> commitment tx with Bob, forcing Bob to broadcast that commitment tx.
> Poor Bob. Yep.
>> This commitment tx is putting a delay on
>> Bobs ability to spend the HTLC output (as well as all other outputs to
>> him), but Alice can spend the HTLC output if the CLTV has expired.
> Indeed, don't ever offer an HTLC less than your delay!
Yes, now that you mention it :)
If we assume that Gregory Maxwell's timestop feature is in use to further delay the expiration of a CSV in the case of full (or near-full) blocks. If this is used, the counterparty can just fill the blocks for a limited amount of time until his CLTV has expired and then take the HTLC output. I guess the time between CSV expiration and CLTV expiration can be adjusted depending on the value being transferred.
Would it be desirable/possible to implement the timestop feature for CLTV as well? That would make the difference between the number of blocks until either expiration the same in case of a block-filling attack. If I'm not mistaken Peter Todds BIP is already merged, but this feature could be implemented with another soft fork.
>> In most examples I have seen, the CLTV is 2 days between Alice and Bob
>> and 1 day between Bob and Carol, and all CSV delays are 3 days.
> I haven't seen an example which included a CSV delay amount.
> As the discussion with Joseph is establishing, the minimum CSV you allow
> controls the worst-case HTLC you can accept. CSV of a few hours should
> be OK if you're online all the time. I think...
Speaking of being online all the time, checking the blockchain is outsourceable, right? So it seems that miners would be the perfect third party to check for cheaters in LN. By offering them a nice chunk of our counterparty's funds as fees, they should be incentiviced enough to keep an extra eye for us on the blockchain.
> Anyone want to do some stats on that? CSV uses the median time of last
> 11 blocks, so to some extent you can tell the worst case...
> Cheers,
> Rusty.