đź“… Original date posted:2015-07-22
đź“ť Original message:> On Jul 22, 2015, at 3:01 PM, Mike Hearn <hearn at vinumeris.com> wrote:
>
> Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.
>
> Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the "merge" process. If they now conflict with other transactions they are dropped and this is "resolving merge conflicts".
>
Blockchain reorgs are part of the consensus rules. We’re talking not about forks caused by network partitions…but forks caused by the use of distinct consensus rules.
> However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.
>
You cannot merge two chains that have incompatible transactions in them without throwing away one of the two conflicting transactions (along with all dependencies). In the reorg process, this occurs naturally…and we allow for it by using confirmation count as a metric of irreversibility. Until one chain wins (by overwhelming consensus) or all chains include a particular transaction in question, we cannot treat that transaction as irreversible. Propose a model in which we can still reliably measure irreversibility in the presence of multiple chains and you might have a point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fbddb23c/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fbddb23c/attachment.sig>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 15:43:04
in reply to nevent1q…venu
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:43:04Event JSON
{
"id": "c7748fd4b3da47f44a2ab8846d5da64771415871c378f8bca0343c06af0a991c",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686152584,
"kind": 1,
"tags": [
[
"e",
"95a36d78d6bf18f4b8ede735f044f5cc9630ae9f0b1198d008835777ff84eede",
"",
"root"
],
[
"e",
"caf2712d853c589d27b7a1a4d08dd042b6b9c96633bfe1db771e34080883ad6a",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-07-22\n📝 Original message:\u003e On Jul 22, 2015, at 3:01 PM, Mike Hearn \u003chearn at vinumeris.com\u003e wrote:\n\u003e \n\u003e Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.\n\u003e \n\u003e Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the \"merge\" process. If they now conflict with other transactions they are dropped and this is \"resolving merge conflicts\".\n\u003e \n\nBlockchain reorgs are part of the consensus rules. We’re talking not about forks caused by network partitions…but forks caused by the use of distinct consensus rules.\n\n\u003e However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.\n\u003e \n\nYou cannot merge two chains that have incompatible transactions in them without throwing away one of the two conflicting transactions (along with all dependencies). In the reorg process, this occurs naturally…and we allow for it by using confirmation count as a metric of irreversibility. Until one chain wins (by overwhelming consensus) or all chains include a particular transaction in question, we cannot treat that transaction as irreversible. Propose a model in which we can still reliably measure irreversibility in the presence of multiple chains and you might have a point.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fbddb23c/attachment.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 using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fbddb23c/attachment.sig\u003e",
"sig": "90617543c9d99f9d23fecd8e78386f47908c216d50fa438c6531dc453402fb2da928c2693682a7e94fb1bfba4331c0d64066a7f35c943392504dc07c62d2e3dd"
}