📅 Original date posted:2015-09-11
📝 Original message:> How do you know which of 2 blocks with the same height is "newer"?
>From the particular node's perspective. I'm aware there is no
possibility of consistent global ordering.
Dave's code is about switching blocks (instead of continuing on the
existing one), and, in that context, "old" means the first sibling the
node saw, and "new" is any subsequent block. I will disambiguate this
in the future, because I'm clearly confusing at least 1 person.
> I don't see how miners would benefit from running this policy so I would not expect them to run it in the long run (like the "first seen" spend conflict tx replacement policy).
There's always a default, and if miners don't have any overriding
reason to change, they'll likely stick to it. Which is why Dave
started his statement with:
> Rather than (promising to, and when they don't actually, at least pretending to) use the first-seen block
Clearly recognizing that any changed logic is non-binding.
On 11 September 2015 at 14:37, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
> wrote:
>>
>> It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be just
> a policy validation that everybody would be free to ignore (like the "first
> seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would not
> expect them to run it in the long run (like the "first seen" spend conflict
> tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running that
> policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
>> Mind you, that risk doesn't apply if we prefer non-empty blocks to
>> empty blocks and leave it at that, or only switch if the new block
>> doesn't double spend transactions in the old one, so it's a fixable
>> issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
>> On 11 September 2015 at 12:32, Jorge Timón
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> Rather than (promising to, and when they don't actually, at least
>> >> pretending to) use the first-seen block, I propose that a more
>> >> sophisticated
>> >> method of choosing which of two block solutions to accept.
>> >
>> > There's already a criterion to chose: the one with more work (in valid
>> > blocks) on top of it.
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
Christophe Biocca [ARCHIVE] /
npub1mt…9g5zm
2023-06-07 17:40:00
in reply to nevent1q…74fp
Author Public Key
npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zmSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:40:00Event JSON
{
"id": "3dea9a2541e592adfbcfb44c86c68d36bf2d31ee0cff04ee9a74263b24e41c81",
"pubkey": "dacd0f484b9bd5e69704fe6452dfeb000ac01ebc36cef17eb3e9ba9696e1301d",
"created_at": 1686159600,
"kind": 1,
"tags": [
[
"e",
"bee230636d5a0aeeccf828724d12ca5f6974687c108bdd4ce8c580b2b365b208",
"",
"root"
],
[
"e",
"02aefcf1453d2be17f8cafca419162f4ef2d4e218b2e2cbdd5b59a1b4ab29582",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-09-11\n📝 Original message:\u003e How do you know which of 2 blocks with the same height is \"newer\"?\n\n\u003eFrom the particular node's perspective. I'm aware there is no\npossibility of consistent global ordering.\n\nDave's code is about switching blocks (instead of continuing on the\nexisting one), and, in that context, \"old\" means the first sibling the\nnode saw, and \"new\" is any subsequent block. I will disambiguate this\nin the future, because I'm clearly confusing at least 1 person.\n\n\u003e I don't see how miners would benefit from running this policy so I would not expect them to run it in the long run (like the \"first seen\" spend conflict tx replacement policy).\n\nThere's always a default, and if miners don't have any overriding\nreason to change, they'll likely stick to it. Which is why Dave\nstarted his statement with:\n\n\u003e Rather than (promising to, and when they don't actually, at least pretending to) use the first-seen block\n\nClearly recognizing that any changed logic is non-binding.\n\nOn 11 September 2015 at 14:37, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\n\u003e On Sep 11, 2015 1:18 PM, \"Christophe Biocca\" \u003cchristophe.biocca at gmail.com\u003e\n\u003e wrote:\n\u003e\u003e\n\u003e\u003e It's pretty obvious that Dave is suggesting an alternate tie-breaker:\n\u003e\n\u003e I thought he was proposing a new consesnsus rule. I see, this would be just\n\u003e a policy validation that everybody would be free to ignore (like the \"first\n\u003e seen\" spend conflict tx replacement policy).\n\u003e\n\u003e I don't see how miners would benefit from running this policy so I would not\n\u003e expect them to run it in the long run (like the \"first seen\" spend conflict\n\u003e tx replacement policy).\n\u003e If miners don't use it, I don't see how users can benefit from running that\n\u003e policy themselves.\n\u003e They will still have to keep waiting some block confirmation to\n\u003e exponentially reduce the chances of a successful double-spend attack with\n\u003e each new confirmation (as explained in the bitcoin white paper).\n\u003e\n\u003e\u003e Mind you, that risk doesn't apply if we prefer non-empty blocks to\n\u003e\u003e empty blocks and leave it at that, or only switch if the new block\n\u003e\u003e doesn't double spend transactions in the old one, so it's a fixable\n\u003e\u003e issue.\n\u003e\n\u003e How do you know which of 2 blocks with the same height is \"newer\"?\n\u003e\n\u003e\u003e On 11 September 2015 at 12:32, Jorge Timón\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e On Sep 11, 2015 12:27 PM, \"Dave Scotese via bitcoin-dev\"\n\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Rather than (promising to, and when they don't actually, at least\n\u003e\u003e \u003e\u003e pretending to) use the first-seen block, I propose that a more\n\u003e\u003e \u003e\u003e sophisticated\n\u003e\u003e \u003e\u003e method of choosing which of two block solutions to accept.\n\u003e\u003e \u003e\n\u003e\u003e \u003e There's already a criterion to chose: the one with more work (in valid\n\u003e\u003e \u003e blocks) on top of it.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003e",
"sig": "c52c995160b68f84f0f263e24fa568c0955069de6dbbcf08b474c91dc5ba1804aca65bad78af38681a61bcd5c7f469203ddb15c45a9fcc674424a9b6f7adfe18"
}