📅 Original date posted:2017-11-13
📝 Original message:Totally agree something like this required..
I've been burned.
But I like the 'old' idea of putting the hash of a block that MUST be on
the chain that this txn can eventually be added to. If the hash is not a
valid block on the chain, the txn can't be added.
It means you can choose exactly which forks you want to allow your txn on,
pre-fork for both, post-fork for only one, and gets round the issue of who
gets to decide the nForkid value.. since you don't need one. Also, all the
old outputs work fine, and LN not an issue.
I'm missing why this scheme would be better ?
On Nov 13, 2017 15:35, "Jacob Eliosoff via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is actually incorrect. There are two transactions involved in LN. The
>> funding transaction, which opens a payment channel, and a commitment
>> transaction, which closes the channel when broadcasted to the network (the
>> cooperative closing transaction can be considered a commitment transaction
>> in a loose sense).
>>
>> Now you want to protect the funding transaction, as otherwise you would
>> be subject to a replay-attack on all *past* forks. So you will set
>> `nForkId>=1` for the funding transaction, making this payment channel
>> non-existent on any *past* forks. However, if during the lifetime of the
>> payment channel another fork happens, the payment channel exists for both
>> tokens. So for the commitment transaction, you will have `nForkId=0`,
>> making it valid on both of these chains. While this `nForkId` is valid on
>> all chains, the parent transaction it tries to spend (the funding
>> transaction) does only exist on two chains, the original one you created
>> the channel for and the one that forked away.
>>
>
> Thanks for the clarification. How would a tx specify a constraint like
> "nForkId>=1"? I was thinking of it just as a number set on the tx.
>
> Also note that since forks form a partial order, but IDs (numbers) form a
> total order, ">=" will miss some cases. Eg, suppose BCH had forked with
> nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
> then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would
> be valid on Segwit2x. This is more of a fundamental problem than a bug -
> to avoid it you'd have to get into stuff like making each fork reference
> its parent-fork's first block or something, someone has written about
> this...
>
>
> On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <mats at blockchain.com>
> wrote:
>
>>
>> OK, so nForkId 0 is exactly the "valid on all chains" specifier I was
>> asking about, cool. And your LN example (and nLockTime txs in general)
>> illustrate why it's preferable to implement a generic replay protection
>> scheme like yours *in advance*, rather than before each fork: all ad hoc
>> RP schemes I know of break old txs on one of the chains, even when that's
>> not desirable - ie, they offer no wildcard like nForkId 0.
>>
>>
>> Exactly!
>>
>> One comment on your LN example: users would have to take note that
>> nForkId 0 txs would be valid not only on future forks, but on *past*
>> forks too. Eg, if BCH had been deployed with nForkId 2, then a user
>> setting up BTC LN txs now with nForkId 0 would have to be aware that those
>> txs would be valid for BCH too. Of course the user could avoid this by
>> funding from a BTC-only address, but it is a potential minor pitfall of
>> nForkId 0. (Which I don't see any clean way around.)
>>
>>
>> This is actually incorrect. There are two transactions involved in LN.
>> The funding transaction, which opens a payment channel, and a commitment
>> transaction, which closes the channel when broadcasted to the network (the
>> cooperative closing transaction can be considered a commitment transaction
>> in a loose sense).
>>
>> Now you want to protect the funding transaction, as otherwise you would
>> be subject to a replay-attack on all *past* forks. So you will set
>> `nForkId>=1` for the funding transaction, making this payment channel
>> non-existent on any *past* forks. However, if during the lifetime of the
>> payment channel another fork happens, the payment channel exists for both
>> tokens. So for the commitment transaction, you will have `nForkId=0`,
>> making it valid on both of these chains. While this `nForkId` is valid on
>> all chains, the parent transaction it tries to spend (the funding
>> transaction) does only exist on two chains, the original one you created
>> the channel for and the one that forked away.
>>
>
>
> _______________________________________________
> 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/20171113/452ebe4c/attachment-0001.html>;
Spartacus Rex [ARCHIVE] /
npub10d…t2fnk
2023-06-07 18:07:37
in reply to nevent1q…yavw
Author Public Key
npub10dtvayys2r7qj8vkzer6nlqm250e7hnmzk5mdkdwdrmfavm72ypqvt2fnkPublished at
2023-06-07 18:07:37Event JSON
{
"id": "f3b8abc070e6bb57257e10d4c88e56b60ed5ee4e01961c9e4048c269a16a700b",
"pubkey": "7b56ce909050fc091d961647a9fc1b551f9f5e7b15a9b6d9ae68f69eb37e5102",
"created_at": 1686161257,
"kind": 1,
"tags": [
[
"e",
"d0daeb8199b756e145149a8bfc51c2a5ebb412995a4c001676e8f12b1a7c8b95",
"",
"root"
],
[
"e",
"6abdba68f90f41b843f17bab9a6ce873435569f902101761c9e4d9847731d611",
"",
"reply"
],
[
"p",
"dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b"
]
],
"content": "📅 Original date posted:2017-11-13\n📝 Original message:Totally agree something like this required..\n\nI've been burned.\n\nBut I like the 'old' idea of putting the hash of a block that MUST be on\nthe chain that this txn can eventually be added to. If the hash is not a\nvalid block on the chain, the txn can't be added.\n\nIt means you can choose exactly which forks you want to allow your txn on,\npre-fork for both, post-fork for only one, and gets round the issue of who\ngets to decide the nForkid value.. since you don't need one. Also, all the\nold outputs work fine, and LN not an issue.\n\nI'm missing why this scheme would be better ?\n\n\nOn Nov 13, 2017 15:35, \"Jacob Eliosoff via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e This is actually incorrect. There are two transactions involved in LN. The\n\u003e\u003e funding transaction, which opens a payment channel, and a commitment\n\u003e\u003e transaction, which closes the channel when broadcasted to the network (the\n\u003e\u003e cooperative closing transaction can be considered a commitment transaction\n\u003e\u003e in a loose sense).\n\u003e\u003e\n\u003e\u003e Now you want to protect the funding transaction, as otherwise you would\n\u003e\u003e be subject to a replay-attack on all *past* forks. So you will set\n\u003e\u003e `nForkId\u003e=1` for the funding transaction, making this payment channel\n\u003e\u003e non-existent on any *past* forks. However, if during the lifetime of the\n\u003e\u003e payment channel another fork happens, the payment channel exists for both\n\u003e\u003e tokens. So for the commitment transaction, you will have `nForkId=0`,\n\u003e\u003e making it valid on both of these chains. While this `nForkId` is valid on\n\u003e\u003e all chains, the parent transaction it tries to spend (the funding\n\u003e\u003e transaction) does only exist on two chains, the original one you created\n\u003e\u003e the channel for and the one that forked away.\n\u003e\u003e\n\u003e\n\u003e Thanks for the clarification. How would a tx specify a constraint like\n\u003e \"nForkId\u003e=1\"? I was thinking of it just as a number set on the tx.\n\u003e\n\u003e Also note that since forks form a partial order, but IDs (numbers) form a\n\u003e total order, \"\u003e=\" will miss some cases. Eg, suppose BCH had forked with\n\u003e nForkId 2, and then you set up a LN funding tx on BCH with nForkId\u003e=2, and\n\u003e then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would\n\u003e be valid on Segwit2x. This is more of a fundamental problem than a bug -\n\u003e to avoid it you'd have to get into stuff like making each fork reference\n\u003e its parent-fork's first block or something, someone has written about\n\u003e this...\n\u003e\n\u003e\n\u003e On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch \u003cmats at blockchain.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e OK, so nForkId 0 is exactly the \"valid on all chains\" specifier I was\n\u003e\u003e asking about, cool. And your LN example (and nLockTime txs in general)\n\u003e\u003e illustrate why it's preferable to implement a generic replay protection\n\u003e\u003e scheme like yours *in advance*, rather than before each fork: all ad hoc\n\u003e\u003e RP schemes I know of break old txs on one of the chains, even when that's\n\u003e\u003e not desirable - ie, they offer no wildcard like nForkId 0.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Exactly!\n\u003e\u003e\n\u003e\u003e One comment on your LN example: users would have to take note that\n\u003e\u003e nForkId 0 txs would be valid not only on future forks, but on *past*\n\u003e\u003e forks too. Eg, if BCH had been deployed with nForkId 2, then a user\n\u003e\u003e setting up BTC LN txs now with nForkId 0 would have to be aware that those\n\u003e\u003e txs would be valid for BCH too. Of course the user could avoid this by\n\u003e\u003e funding from a BTC-only address, but it is a potential minor pitfall of\n\u003e\u003e nForkId 0. (Which I don't see any clean way around.)\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e This is actually incorrect. There are two transactions involved in LN.\n\u003e\u003e The funding transaction, which opens a payment channel, and a commitment\n\u003e\u003e transaction, which closes the channel when broadcasted to the network (the\n\u003e\u003e cooperative closing transaction can be considered a commitment transaction\n\u003e\u003e in a loose sense).\n\u003e\u003e\n\u003e\u003e Now you want to protect the funding transaction, as otherwise you would\n\u003e\u003e be subject to a replay-attack on all *past* forks. So you will set\n\u003e\u003e `nForkId\u003e=1` for the funding transaction, making this payment channel\n\u003e\u003e non-existent on any *past* forks. However, if during the lifetime of the\n\u003e\u003e payment channel another fork happens, the payment channel exists for both\n\u003e\u003e tokens. So for the commitment transaction, you will have `nForkId=0`,\n\u003e\u003e making it valid on both of these chains. While this `nForkId` is valid on\n\u003e\u003e all chains, the parent transaction it tries to spend (the funding\n\u003e\u003e transaction) does only exist on two chains, the original one you created\n\u003e\u003e the channel for and the one that forked away.\n\u003e\u003e\n\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/20171113/452ebe4c/attachment-0001.html\u003e",
"sig": "32dba2944a08744a02c0cb84c31b140457e49c1733cce04ede40346171a9d8167aab2ed9824668d154144b5c78b98662b2099ae59c08dc89d8987ed52bf1a1ed"
}