馃搮 Original date posted:2015-09-11
馃摑 Original message: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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/953bcc1b/attachment.html>;
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 17:40:00
in reply to nevent1q鈥d7t
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:40:00Event JSON
{
"id": "02aefcf1453d2be17f8cafca419162f4ef2d4e218b2e2cbdd5b59a1b4ab29582",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159600,
"kind": 1,
"tags": [
[
"e",
"bee230636d5a0aeeccf828724d12ca5f6974687c108bdd4ce8c580b2b365b208",
"",
"root"
],
[
"e",
"6ef85f959bdce2ca764d1d698efc722a3eed22d6defbc454becc1cf1d7521726",
"",
"reply"
],
[
"p",
"dacd0f484b9bd5e69704fe6452dfeb000ac01ebc36cef17eb3e9ba9696e1301d"
]
],
"content": "馃搮 Original date posted:2015-09-11\n馃摑 Original message:On Sep 11, 2015 1:18 PM, \"Christophe Biocca\" \u003cchristophe.biocca at gmail.com\u003e\nwrote:\n\u003e\n\u003e It's pretty obvious that Dave is suggesting an alternate tie-breaker:\n\nI thought he was proposing a new consesnsus rule. I see, this would be just\na policy validation that everybody would be free to ignore (like the \"first\nseen\" spend conflict tx replacement policy).\n\nI don't see how miners would benefit from running this policy so I would\nnot expect them to run it in the long run (like the \"first seen\" spend\nconflict tx replacement policy).\nIf miners don't use it, I don't see how users can benefit from running that\npolicy themselves.\nThey will still have to keep waiting some block confirmation to\nexponentially reduce the chances of a successful double-spend attack with\neach new confirmation (as explained in the bitcoin white paper).\n\n\u003e Mind you, that risk doesn't apply if we prefer non-empty blocks to\n\u003e empty blocks and leave it at that, or only switch if the new block\n\u003e doesn't double spend transactions in the old one, so it's a fixable\n\u003e issue.\n\nHow do you know which of 2 blocks with the same height is \"newer\"?\n\n\u003e On 11 September 2015 at 12:32, Jorge Tim贸n\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e On Sep 11, 2015 12:27 PM, \"Dave Scotese via bitcoin-dev\"\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e Rather than (promising to, and when they don't actually, at least\n\u003e \u003e\u003e pretending to) use the first-seen block, I propose that a more\nsophisticated\n\u003e \u003e\u003e method of choosing which of two block solutions to accept.\n\u003e \u003e\n\u003e \u003e There's already a criterion to chose: the one with more work (in valid\n\u003e \u003e blocks) on top of it.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/953bcc1b/attachment.html\u003e",
"sig": "59f1d3f899697b2cc9dd829feb7743855ea4aed1e99534e142e1255b44858e597f80fb23f10f3624fdbdd5e91fa59430556a989bc85ba736f909b38b36b77ca7"
}