đ
Original date posted:2017-11-15
đ Original message:>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
OK, but then it seems to me you have a dilemma for, eg, your LN commitment
tx. You either give it the specific nForkId of the fork it's created on -
making it invalid on *all* other forks (eg, any future "non-contentious
upgrade" HF that replaces that fork). Or you give it nForkId 0 - which has
the "BCH tx valid on Segwit2x (& vice versa)" flaw.
It may make sense to revise your proposal to incorporate Luke's
OP_CHECKBLOCKATHEIGHT
<https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki>;, and make
the fork ID a (block height, hash) pair rather than just a number. But I
still think the idea of fork-specific addresses is a keeper!
On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <mats at blockchain.com> wrote:
>
> 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 ?
>
>
> I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the
> sense that they are very difficult to circumvent. However, a fork could
> also follow the original chain in SPV mode and allow transactions protected
> with these mechanism. Since it's fundamentally impossible to disallow
> transactions in future projects, the goal shouldn't be to make this overly
> complicated.
>
> Furthermore, this schema is not just adding replay protection. It makes
> transacting safer overall (due to a dedicated address format per fork) and
> allows light clients to differentiate between multiple forks. In the past
> three months, at least $600k has been lost by users sending BCH to a BTC
> address [1].
>
> 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.
>>
>
> Whether the transaction is replay protected or not is specified by setting
> a bit in the `SigHashId`. If this bit is set, then the signature *preimage*
> MUST have `nForkId` appended. `nForkId` is not part of the final
> transaction, someone who wants to verify the transaction must know which
> `nForkId` it was created with.
>
> If the bit isn't set, it means `nForkId=0`, which allows other forks to
> validate the signature.
>
> 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...
>>
>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
> [1]
> https://twitter.com/khannib/status/930223617744437253
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171115/83057847/attachment.html>;
Jacob Eliosoff [ARCHIVE] /
npub1mlâŚ4yf8d
2023-06-07 18:07:38
in reply to nevent1qâŚ90wz
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:07:38Event JSON
{
"id": "3c13a0dadb90be212492e3d75c62ce7845721c3fc8229e191b3ff1ef6a6dc35e",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686161258,
"kind": 1,
"tags": [
[
"e",
"d0daeb8199b756e145149a8bfc51c2a5ebb412995a4c001676e8f12b1a7c8b95",
"",
"root"
],
[
"e",
"f812d4f7564616faf0e89fb098fefd82700b581521e1980395324f4ffe4aa9f8",
"",
"reply"
],
[
"p",
"b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528"
]
],
"content": "đ
Original date posted:2017-11-15\nđ Original message:\u003e\n\u003e Sorry, I was careless with the use of `\u003e=` there. You are correct, forks\n\u003e form a tree. For this proposal, every leaf must be assigned a unique\n\u003e `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which\n\u003e number is bigger), as long as they are unique. Transactions are only valid\n\u003e IFF `nForkId` matches exactly the `nForkId` of the software validating it.\n\u003e As described above, the transaction doesn't even contain `nForkId`, and the\n\u003e node surely is not starting to guess which one it could be.\n\u003e\n\nOK, but then it seems to me you have a dilemma for, eg, your LN commitment\ntx. You either give it the specific nForkId of the fork it's created on -\nmaking it invalid on *all* other forks (eg, any future \"non-contentious\nupgrade\" HF that replaces that fork). Or you give it nForkId 0 - which has\nthe \"BCH tx valid on Segwit2x (\u0026 vice versa)\" flaw.\n\nIt may make sense to revise your proposal to incorporate Luke's\nOP_CHECKBLOCKATHEIGHT\n\u003chttps://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki\u003e, and make\nthe fork ID a (block height, hash) pair rather than just a number. But I\nstill think the idea of fork-specific addresses is a keeper!\n\n\nOn Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch \u003cmats at blockchain.com\u003e wrote:\n\n\u003e\n\u003e But I like the 'old' idea of putting the hash of a block that MUST be on\n\u003e the chain that this txn can eventually be added to. If the hash is not a\n\u003e valid block on the chain, the txn can't be added.\n\u003e\n\u003e It means you can choose exactly which forks you want to allow your txn on,\n\u003e pre-fork for both, post-fork for only one, and gets round the issue of who\n\u003e gets to decide the nForkid value.. since you don't need one. Also, all the\n\u003e old outputs work fine, and LN not an issue.\n\u003e\n\u003e I'm missing why this scheme would be better ?\n\u003e\n\u003e\n\u003e I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the\n\u003e sense that they are very difficult to circumvent. However, a fork could\n\u003e also follow the original chain in SPV mode and allow transactions protected\n\u003e with these mechanism. Since it's fundamentally impossible to disallow\n\u003e transactions in future projects, the goal shouldn't be to make this overly\n\u003e complicated.\n\u003e\n\u003e Furthermore, this schema is not just adding replay protection. It makes\n\u003e transacting safer overall (due to a dedicated address format per fork) and\n\u003e allows light clients to differentiate between multiple forks. In the past\n\u003e three months, at least $600k has been lost by users sending BCH to a BTC\n\u003e address [1].\n\u003e\n\u003e Thanks for the clarification. How would a tx specify a constraint like\n\u003e\u003e \"nForkId\u003e=1\"? I was thinking of it just as a number set on the tx.\n\u003e\u003e\n\u003e\n\u003e Whether the transaction is replay protected or not is specified by setting\n\u003e a bit in the `SigHashId`. If this bit is set, then the signature *preimage*\n\u003e MUST have `nForkId` appended. `nForkId` is not part of the final\n\u003e transaction, someone who wants to verify the transaction must know which\n\u003e `nForkId` it was created with.\n\u003e\n\u003e If the bit isn't set, it means `nForkId=0`, which allows other forks to\n\u003e validate the signature.\n\u003e\n\u003e Also note that since forks form a partial order, but IDs (numbers) form a\n\u003e\u003e total order, \"\u003e=\" will miss some cases. Eg, suppose BCH had forked with\n\u003e\u003e nForkId 2, and then you set up a LN funding tx on BCH with nForkId\u003e=2, and\n\u003e\u003e then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would\n\u003e\u003e be valid on Segwit2x. This is more of a fundamental problem than a bug -\n\u003e\u003e to avoid it you'd have to get into stuff like making each fork reference\n\u003e\u003e its parent-fork's first block or something, someone has written about\n\u003e\u003e this...\n\u003e\u003e\n\u003e\n\u003e Sorry, I was careless with the use of `\u003e=` there. You are correct, forks\n\u003e form a tree. For this proposal, every leaf must be assigned a unique\n\u003e `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which\n\u003e number is bigger), as long as they are unique. Transactions are only valid\n\u003e IFF `nForkId` matches exactly the `nForkId` of the software validating it.\n\u003e As described above, the transaction doesn't even contain `nForkId`, and the\n\u003e node surely is not starting to guess which one it could be.\n\u003e\n\u003e [1]\n\u003e https://twitter.com/khannib/status/930223617744437253\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171115/83057847/attachment.html\u003e",
"sig": "9f48cef977e4d86b38e955c86ace43e57a35876b4d582444c49e1694eb1691ba355a663032fdf5e01ac00142f7540df77b518e8a3dfac1adbbbf30439f2246ea"
}