š
Original date posted:2017-11-10
š Original message:I guess I wasn't clear on the wildcard, `nForkId=0`
This proposal puts Bitcoin at `nForkId=1`, with the purpose of having `nForkId=0` valid on *all* future forks. This means you can create a `nLockTime` transaction, delete the private key and still be assured to not lose potential future tokens.
In theory `nForkId=0` could be used for an address too, the sending wallet should display a warning message about unknown side effects though. This address would be future-safe, and you can put it into a safe-deposit box (even though I see little reason to back up an _address_. You would always back up a _private key_, which translates into funds on any fork.)
Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice and Bob open a payment channel. One week later, project X decides to fork the network into a new token, implementing a custom way of providing strong two-way replay protection. The protocol Alice and Bob use for the payment channel has not implemented this new form of replay protection. Alice and Bob now have to make a choice:
(1) Ignore this new token. This comes with an evaluation of how much this new token could be worth in the future. They will continue normal channel operation, knowing that their funds on the other branch will be locked up until eternity. When they close their payment channel, the closing transaction will get rejected from the other network, because it's not following the format for replay protected transactions.
(2) Close the payment channel before the fork. The transaction, which closes the payment channel has to be mined before the fork, potentially paying a higher-than-normal fee.
With this proposal implemented, there are two additional choices
(3) Create the commitment transactions with `nForkId=0`. This ensures that when the channel gets closed, funds on other chains are released accordingly. This also means that after the fork, payments on the channel move both, the original token and the new token. Potentially, Alice and Bob want to wait before further transacting on the channel, to see if the token has substantial value. If it has, they can *then* close the channel and open a new channel again. (Note: The funding transaction can use a specific `nForkId`, preventing you from locking up multiple coins when funding the channel, but you can choose to settle with `nForkId=0` to not lock up future coins)
(4) Make the protocol aware of different `nForkId`. After the fork, the participants can chose to *only* close the payment channel on the new token, making the payment channel Bitcoin-only again. This is the preferred option, as it means no disruption to the original network.
> I like the idea of specifying the fork in bech32 [0]. On the other hand, the standard already has a human readable part. Perhaps the human readable part can be used as the fork id?
I was considering this too. On the other hand, it's only _human readable_ because thy bytes used currently encode 'bc'. For future forks, this would just be two random letters than, but potentially acceptable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171110/ada18c4a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171110/ada18c4a/attachment-0001.sig>;
Mats Jerratsch [ARCHIVE] /
npub1hzā¦q5x8w
2023-06-07 18:07:36
in reply to nevent1qā¦vx8z
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-07 18:07:36Event JSON
{
"id": "16e3719984db246d736094c5245105733d7ebedb89b4dc1fd2b316c44cea758b",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686161256,
"kind": 1,
"tags": [
[
"e",
"d0daeb8199b756e145149a8bfc51c2a5ebb412995a4c001676e8f12b1a7c8b95",
"",
"root"
],
[
"e",
"fd94e76353777156b671c42558920c03967604708c35972c3efbbfc4d3fc7237",
"",
"reply"
],
[
"p",
"e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e"
]
],
"content": "š
Original date posted:2017-11-10\nš Original message:I guess I wasn't clear on the wildcard, `nForkId=0`\n\nThis proposal puts Bitcoin at `nForkId=1`, with the purpose of having `nForkId=0` valid on *all* future forks. This means you can create a `nLockTime` transaction, delete the private key and still be assured to not lose potential future tokens.\n\nIn theory `nForkId=0` could be used for an address too, the sending wallet should display a warning message about unknown side effects though. This address would be future-safe, and you can put it into a safe-deposit box (even though I see little reason to back up an _address_. You would always back up a _private key_, which translates into funds on any fork.)\n\nFurthermore, `nForkId=0` can be used for L2 applications. Let's say Alice and Bob open a payment channel. One week later, project X decides to fork the network into a new token, implementing a custom way of providing strong two-way replay protection. The protocol Alice and Bob use for the payment channel has not implemented this new form of replay protection. Alice and Bob now have to make a choice:\n\n(1) Ignore this new token. This comes with an evaluation of how much this new token could be worth in the future. They will continue normal channel operation, knowing that their funds on the other branch will be locked up until eternity. When they close their payment channel, the closing transaction will get rejected from the other network, because it's not following the format for replay protected transactions.\n\n(2) Close the payment channel before the fork. The transaction, which closes the payment channel has to be mined before the fork, potentially paying a higher-than-normal fee.\n\nWith this proposal implemented, there are two additional choices\n\n(3) Create the commitment transactions with `nForkId=0`. This ensures that when the channel gets closed, funds on other chains are released accordingly. This also means that after the fork, payments on the channel move both, the original token and the new token. Potentially, Alice and Bob want to wait before further transacting on the channel, to see if the token has substantial value. If it has, they can *then* close the channel and open a new channel again. (Note: The funding transaction can use a specific `nForkId`, preventing you from locking up multiple coins when funding the channel, but you can choose to settle with `nForkId=0` to not lock up future coins)\n\n(4) Make the protocol aware of different `nForkId`. After the fork, the participants can chose to *only* close the payment channel on the new token, making the payment channel Bitcoin-only again. This is the preferred option, as it means no disruption to the original network.\n\n\u003e I like the idea of specifying the fork in bech32 [0]. On the other hand, the standard already has a human readable part. Perhaps the human readable part can be used as the fork id?\n\nI was considering this too. On the other hand, it's only _human readable_ because thy bytes used currently encode 'bc'. For future forks, this would just be two random letters than, but potentially acceptable.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171110/ada18c4a/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171110/ada18c4a/attachment-0001.sig\u003e",
"sig": "b32f6800fe076bb96745cac170c1e1f8b5e6cfd19429a126e1d4dd1f17216c20c161502b28f84d360cc0fb82e4524a36cbb5f041848335e0676bea6d643a8854"
}