Christopher Jamthagen [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-25 to 2015-08-02
💬 Posted a total of 7 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:43:54

- reply

📅 Original date posted:2015-08-01
📝 Original message:
> Sent: Saturday, August 01, 2015 at 12:41 PM
> From: "Eric Lombrozo" <elombrozo at gmail.com>
> To: "Christopher Jamthagen" <cjamthagen at gmx.com>
> Cc: "Rusty Russell" <rusty at rustcorp.com.au>, "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Stealing money from a hub?
>> On Aug 1, 2015, at 3:30 AM, Christopher Jamthagen <cjamthagen at gmx.com> wrote:
>>
>>> Sent: Saturday, August 01, 2015 at 11:57 AM
>>> From: "Eric Lombrozo" <elombrozo at gmail.com>
>>> To: "Rusty Russell" <rusty at rustcorp.com.au>
>>> Cc: "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?
>>
>>
>>
>>> On Jul 30, 2015, at 4:48 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>> But I realized yesterday, outsourcing needs a new sighash op mode (or
>>> normalized txids), so it's not really something to design a deployable
>>> system around today.
>>> Can you elaborate on this, Rusty?
>>
>> We wont know the txid of the revoked commitment transaction until the cheater signs and broadcasts it, thus we cannot pre-sign the stealing transaction for the third party.
> Got it. I suppose it would still be possible to have the third party notify you and request a signature when it occurs so that your device doesn’t have to sit and monitor the network and do the > filtering, etc...
Once notified I could just sign the stealing transaction and take all the money myself.

2023-06-09 12:43:53

- reply

📅 Original date posted:2015-08-01
📝 Original message:
> Sent: Saturday, August 01, 2015 at 11:57 AM
> From: "Eric Lombrozo" <elombrozo at gmail.com>
> To: "Rusty Russell" <rusty at rustcorp.com.au>
> Cc: "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?
> On Jul 30, 2015, at 4:48 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> But I realized yesterday, outsourcing needs a new sighash op mode (or
> normalized txids), so it's not really something to design a deployable
> system around today.
> Can you elaborate on this, Rusty?
We wont know the txid of the revoked commitment transaction until the cheater signs and broadcasts it, thus we cannot pre-sign the stealing transaction for the third party.

2023-06-09 12:43:53

- reply

📅 Original date posted:2015-08-02
📝 Original message:
>> If the timestop feature would activate only when the CLTV transaction
>> is included in a block, it would allow for a pretty serious DoS attack
>> vector where hubs can be forced to close channels with other hubs by
>> having the attacker, as the receiver, never reveal R and create a
>> block-filling attack.
> I don't think so. Let's say the rule is "time doesn't pass if a block
> is full".
But it would be necessary to explicitly supply the block-height at which the transaction that includes the CLTV was signed. Otherwise miners would have no other info but the block it is included in from which to count the number of full blocks to add to the expiration time of the CLTV.
>> This would force the hub connected to the receiver to broadcast the
>> commitment transaction
> Why? The HTLC wouldn't expire, which would be a pain, but there's no
> reason to panic and dump transactions. By definition, during a block
> filling attack you've got all the time in the world.
Right, the HTLC in the broadcasted commitment transaction between receiver and closest hub wouldn't expire, but the HTLC between the closest and second-closest hub would expire in a block-filling attack. Just to clarify, my example was with the timestop feature, but a CLTV implementation without announcement of explicit block at which the transaction was signed.
> Now, preventing HTLCs from expiring is a DoS, but a lesser one.
> What am I missing?
Probably me who is missing something :)
>> CLTV transactions would need to include the current block-height
>> immediately when a commitment transaction is signed, so that miners
>> can know where to start counting full blocks from as soon as it is
>> broadcast. So my question is: Is such an upgrade for CLTV, as it is
>> now, soft-forkable as it requires additional arguments? I am not
>> totally clear on when upgrades are soft-forkable vs. hard-forkable.
> Anything which is a furthur restriction (as in "this used to be valid,
> and no longer is") is soft-forkable. So delaying timeouts is a soft-fork.
Got it. Thanks.
>>> Outsourcability scales really well; once you're full-time monitoring the
>>> blockchain, might as well get as many clients as possible. You can also
>>> automate the outsourcee's fee, by including it in the "steal" tx.
>>
>> Does it scale that well? I guess looking up pre-images in the shachain is fast, but what about R values in HTLCs? Would the third party have to store all those values or is there a nice optimization I have missed?
> Indeed, there's a separate thread where Anthony Towns points out that
> remembering R values and timeouts is an issue.
Ok, will have to find time to plow through the mailing list.
> I was referring to the part where you watch the chain for spends on the
> anchor outputs. You only need to do work to check what happened when
> one of them gets spent, should almost never happen (since the client
> should tell you they're going to close the channel cooperatively).
> Cheers,
> Rusty.
Am I missing something when I claim that another input is necessary for the CLTV to make timestop work properly?

2023-06-09 12:43:52

- reply

📅 Original date posted:2015-08-01
📝 Original message:
> Sent: Friday, July 31, 2015 at 1:48 AM
> From: "Rusty Russell" <rusty at rustcorp.com.au>
> To: "Christopher Jamthagen" <cjamthagen at gmx.com>
> Cc: "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:
>> 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.
> Yes, timestop would logically be a softfork add, and it should apply to
> both (same logic applies).
If the timestop feature would activate only when the CLTV transaction is included in a block, it would allow for a pretty serious DoS attack vector where hubs can be forced to close channels with other hubs by having the attacker, as the receiver, never reveal R and create a block-filling attack. This would force the hub connected to the receiver to broadcast the commitment transaction, but since there is a block-filling attack going on, the hub can't settle with the next hub because the first hubs CSV and CLTV are being pushed beyond the second hubs CLTV (which isn't broadcasted or included in a block yet, so the timestop feature doesn't apply) and so it goes on forcing every hub along the payment path back to the sender to broadcast their commitment transactions and closing the channels. It would be cheap to amplify this attack since the attacker only need to make enough HTLC transactions including as many hubs in LN as possible to take out a large portion of the network for a while.
CLTV transactions would need to include the current block-height immediately when a commitment transaction is signed, so that miners can know where to start counting full blocks from as soon as it is broadcast. So my question is: Is such an upgrade for CLTV, as it is now, soft-forkable as it requires additional arguments? I am not totally clear on when upgrades are soft-forkable vs. hard-forkable.
>> 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.
> Outsourcability scales really well; once you're full-time monitoring the
> blockchain, might as well get as many clients as possible. You can also
> automate the outsourcee's fee, by including it in the "steal" tx.
Does it scale that well? I guess looking up pre-images in the shachain is fast, but what about R values in HTLCs? Would the third party have to store all those values or is there a nice optimization I have missed?
> But I realized yesterday, outsourcing needs a new sighash op mode (or
> normalized txids), so it's not really something to design a deployable
> system around today.
So it is. What a shame.
> Cheers,
> Rusty.

2023-06-09 12:43:50

- reply

📅 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.

2023-06-09 12:43:50

- reply

📅 Original date posted:2015-07-29
📝 Original message:
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150729/b0b4c34c/attachment.html>

2023-06-09 12:43:45

- reply

📅 Original date posted:2015-07-25
📝 Original message:
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150725/ebfeffe0/attachment.html>