📅 Original date posted:2017-08-17
📝 Original message:Couldn't scripts like this have a standardized "hardfork unroll" mechanism,
where if a hardfork is activated and signaled to its clients, then those
commitments that are only meant for their original chain can be reversed
and undone just on the hardfork? Then the users involved would just send an
unroll transaction which is only valid on the hardfork.
- Sent from my phone
Den 17 aug. 2017 14:52 skrev "Conrad Burchert via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
> Some notes:
>
> Hardforks like Bitcoin ABC without a malleability fix are very unlikely to
> have payment channels, so the problem does not exist for those.
>
> The designers of a hardfork which does have a malleability fix will
> probably know about payment channels, so they can just build a replay
> protection that allows the execution of old commitments. That needs some
> kind of timestamping of commitments, which would have to be integrated in
> the channel design. The easiest way would be to just write the time of
> signing the commitment in the transaction and the replay protection accepts
> old commitments, but rejects one's which were signed after the hardfork.
> These timestamps can essentially be one bit (before or after a hardfork)
> and if the replay protection in the hardfork only accepts old commitments
> for something like a year, then it can be reused for more hardforks later
> on. Maybe someone comes up with an interesting way of doing this without
> using space.
>
> Nevertheless hardforking while having channels open will always be a mess
> as an open channel requires you to watch the blockchain. Anybody who is
> just not aware of the hardfork or is updating his client a few days too
> late, can get his money stolen by an old commitment transaction where he
> forgets to retaliate on the new chain. As other's can likely figure out
> your client version the risk of retaliation is not too big for an attacker.
>
>
>
> 2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>>
>> ---------- Forwarded message ----------
>> From: Christian Decker <decker.christian at gmail.com>
>> Date: Thu, Aug 17, 2017 at 5:39 AM
>> Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
>> hardforks
>> To: Martin Schwarz <martin.schwarz at gmail.com>,
>> lightning-dev at lists.linuxfoundation.org
>>
>>
>> Hi Martin,
>>
>> this is the perfect venue to discuss this, welcome to the mailing list :-)
>> Like you I think that using the first forked block as the forkchain's
>> genesis block is the way to go, keeping the non-forked blockchain on the
>> original genesis hash, to avoid disruption. It may become more difficult in
>> the case one chain doesn't declare itself to be the forked chain.
>>
>> Even more interesting are channels that are open during the fork. In
>> these cases we open a single channel, and will have to settle two. If no
>> replay protection was implemented on the fork, then we can use the last
>> commitment to close the channel (updates should be avoided since they now
>> double any intended effect), if replay protection was implemented then
>> commitments become invalid on the fork, and people will lose money.
>>
>> Fun times ahead :-)
>>
>> Cheers,
>> Christian
>>
>> On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz at gmail.com>
>> wrote:
>>
>>> Dear all,
>>>
>>> currently the chain_id allows to distinguish blockchains by the hash of
>>> their genesis block.
>>>
>>> With hardforks branching off of the Bitcoin blockchain, how can
>>> Lightning work on (or across)
>>> distinct, permanent forks of a parent blockchain that share the same
>>> genesis block?
>>>
>>> I suppose changing the definition of chain_id to the hash of the first
>>> block of the new
>>> branch and requiring replay and wipe-out protection should be
>>> sufficient. But can we
>>> relax these requirements? Are slow block times an issue? Can we use
>>> Lightning to transact
>>> on "almost frozen" block chains suffering from a sudden loss of
>>> hashpower?
>>>
>>> Has there been any previous discussion or study of Lightning in the
>>> setting of hardforks?
>>> (Is this the right place to discuss this? If not, where would be the
>>> right place?)
>>>
>>> thanks,
>>> Martin
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>>
>> --
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507 <(512)%20203-0507>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170817/95edf34c/attachment-0001.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 18:04:50
in reply to nevent1q…88cw
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 18:04:50Event JSON
{
"id": "8ad7aeb43fa2a2c8e0ecfdbf05549d3bd147ff90cb3b1184f838d67f17bd34aa",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686161090,
"kind": 1,
"tags": [
[
"e",
"35482f0ea481658d6e9a2b61acf421024aeb96b442d1f61b5afbe51aa7a164a2",
"",
"root"
],
[
"e",
"d4d11fc15b4e527327cc4a66ff6cdff7c47d97bfd3a80b80c66e82877ebadf26",
"",
"reply"
],
[
"p",
"0e1ae262da6f7b79aa0cd5f6670663dc72886d3594110c08e7ec0f1c3f58a8dc"
]
],
"content": "📅 Original date posted:2017-08-17\n📝 Original message:Couldn't scripts like this have a standardized \"hardfork unroll\" mechanism,\nwhere if a hardfork is activated and signaled to its clients, then those\ncommitments that are only meant for their original chain can be reversed\nand undone just on the hardfork? Then the users involved would just send an\nunroll transaction which is only valid on the hardfork.\n\n- Sent from my phone\n\nDen 17 aug. 2017 14:52 skrev \"Conrad Burchert via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e Some notes:\n\u003e\n\u003e Hardforks like Bitcoin ABC without a malleability fix are very unlikely to\n\u003e have payment channels, so the problem does not exist for those.\n\u003e\n\u003e The designers of a hardfork which does have a malleability fix will\n\u003e probably know about payment channels, so they can just build a replay\n\u003e protection that allows the execution of old commitments. That needs some\n\u003e kind of timestamping of commitments, which would have to be integrated in\n\u003e the channel design. The easiest way would be to just write the time of\n\u003e signing the commitment in the transaction and the replay protection accepts\n\u003e old commitments, but rejects one's which were signed after the hardfork.\n\u003e These timestamps can essentially be one bit (before or after a hardfork)\n\u003e and if the replay protection in the hardfork only accepts old commitments\n\u003e for something like a year, then it can be reused for more hardforks later\n\u003e on. Maybe someone comes up with an interesting way of doing this without\n\u003e using space.\n\u003e\n\u003e Nevertheless hardforking while having channels open will always be a mess\n\u003e as an open channel requires you to watch the blockchain. Anybody who is\n\u003e just not aware of the hardfork or is updating his client a few days too\n\u003e late, can get his money stolen by an old commitment transaction where he\n\u003e forgets to retaliate on the new chain. As other's can likely figure out\n\u003e your client version the risk of retaliation is not too big for an attacker.\n\u003e\n\u003e\n\u003e\n\u003e 2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\n\u003e\u003e\n\u003e\u003e ---------- Forwarded message ----------\n\u003e\u003e From: Christian Decker \u003cdecker.christian at gmail.com\u003e\n\u003e\u003e Date: Thu, Aug 17, 2017 at 5:39 AM\n\u003e\u003e Subject: Re: [Lightning-dev] Lightning in the setting of blockchain\n\u003e\u003e hardforks\n\u003e\u003e To: Martin Schwarz \u003cmartin.schwarz at gmail.com\u003e,\n\u003e\u003e lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Hi Martin,\n\u003e\u003e\n\u003e\u003e this is the perfect venue to discuss this, welcome to the mailing list :-)\n\u003e\u003e Like you I think that using the first forked block as the forkchain's\n\u003e\u003e genesis block is the way to go, keeping the non-forked blockchain on the\n\u003e\u003e original genesis hash, to avoid disruption. It may become more difficult in\n\u003e\u003e the case one chain doesn't declare itself to be the forked chain.\n\u003e\u003e\n\u003e\u003e Even more interesting are channels that are open during the fork. In\n\u003e\u003e these cases we open a single channel, and will have to settle two. If no\n\u003e\u003e replay protection was implemented on the fork, then we can use the last\n\u003e\u003e commitment to close the channel (updates should be avoided since they now\n\u003e\u003e double any intended effect), if replay protection was implemented then\n\u003e\u003e commitments become invalid on the fork, and people will lose money.\n\u003e\u003e\n\u003e\u003e Fun times ahead :-)\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Christian\n\u003e\u003e\n\u003e\u003e On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz \u003cmartin.schwarz at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Dear all,\n\u003e\u003e\u003e\n\u003e\u003e\u003e currently the chain_id allows to distinguish blockchains by the hash of\n\u003e\u003e\u003e their genesis block.\n\u003e\u003e\u003e\n\u003e\u003e\u003e With hardforks branching off of the Bitcoin blockchain, how can\n\u003e\u003e\u003e Lightning work on (or across)\n\u003e\u003e\u003e distinct, permanent forks of a parent blockchain that share the same\n\u003e\u003e\u003e genesis block?\n\u003e\u003e\u003e\n\u003e\u003e\u003e I suppose changing the definition of chain_id to the hash of the first\n\u003e\u003e\u003e block of the new\n\u003e\u003e\u003e branch and requiring replay and wipe-out protection should be\n\u003e\u003e\u003e sufficient. But can we\n\u003e\u003e\u003e relax these requirements? Are slow block times an issue? Can we use\n\u003e\u003e\u003e Lightning to transact\n\u003e\u003e\u003e on \"almost frozen\" block chains suffering from a sudden loss of\n\u003e\u003e\u003e hashpower?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Has there been any previous discussion or study of Lightning in the\n\u003e\u003e\u003e setting of hardforks?\n\u003e\u003e\u003e (Is this the right place to discuss this? If not, where would be the\n\u003e\u003e\u003e right place?)\n\u003e\u003e\u003e\n\u003e\u003e\u003e thanks,\n\u003e\u003e\u003e Martin\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e - Bryan\n\u003e\u003e http://heybryan.org/\n\u003e\u003e 1 512 203 0507 \u003c(512)%20203-0507\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170817/95edf34c/attachment-0001.html\u003e",
"sig": "87ffa78672994eef0484bff149c0f77007a677a12f7776e844b17f65da0d7d4bb8c4149d1f642723faad23ffecdd3dfa9e789f399318ac34bbd26f334b69e15c"
}