đź“… Original date posted:2015-09-11
đź“ť Original message:Yes, this proposal is a policy that everyone would be free to ignore. I
should have introduced the situation in which this *unenforceable* policy
makes sense to me. Here it is:
Every miner is listening for valid block solutions but might receive two
valid blocks and then they have to decide which one to use. Choosing the
one you saw first is the default behavior. In that situation, we'd all
like everyone to choose the same block. I propose that a better heuristic
than "first seen" is to compare the BTCDD, *but only of transactions you
already have in your mempool*, and
*weight the BTCDD so that txns you got earlier are more important.*
The heuristic is most useful when the two blocks are received within a
small window of time, opting for the first-seen rule otherwise. I assume
many miners have an idea of how long it takes for anyone's new block to get
across the network, and more specifically, the range of times it takes for
new solutions to get to themselves. During this little time window, the
chances are 50/50 that they'll choose the right block. If the default
behavior were to use BTCDD during that time window (one second? I have no
idea!), then the chances would be significantly better.
I think Jorge is right that it doesn't benefit miners. It doesn't hurt
them either, unless they are trying to do selfish mining. Well, it
benefits them in terms of increased bitcoin stability by A) making it
easier for clients to decide which block is valid when they see two
competing with each other, B) motivating miners to add transactions instead
of mining empty blocks, C) severely decreasing the utility of any global
private network of nodes intended to spread selfishly-mined blocks, and D)
motivating miners to stay well-connected so that they get transactions
quickly.
I sent this to the list because it is only useful if it is set as default
behavior since most miners leave the defaults alone, and the benefits don't
materialize unless a majority follows the policy.
On Fri, Sep 11, 2015 at 11:37 AM, 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
> > >
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com>; and Meme Racing
<http://www.memeracing.net>; (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>; which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>;.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/5d843513/attachment.html>;
Dave Scotese [ARCHIVE] /
npub15w…maru8
2023-06-07 17:40:00
in reply to nevent1q…35n3
Author Public Key
npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:40:00Event JSON
{
"id": "1887143ee1d351e3e07231ca74b671e2d4b101250b3113c5398d9a519970a84a",
"pubkey": "a384795310cea1937dda4d01ee8f14ca734b9a7ab60c62114a5656706e15e47f",
"created_at": 1686159600,
"kind": 1,
"tags": [
[
"e",
"bee230636d5a0aeeccf828724d12ca5f6974687c108bdd4ce8c580b2b365b208",
"",
"root"
],
[
"e",
"3dea9a2541e592adfbcfb44c86c68d36bf2d31ee0cff04ee9a74263b24e41c81",
"",
"reply"
],
[
"p",
"dacd0f484b9bd5e69704fe6452dfeb000ac01ebc36cef17eb3e9ba9696e1301d"
]
],
"content": "đź“… Original date posted:2015-09-11\nđź“ť Original message:Yes, this proposal is a policy that everyone would be free to ignore. I\nshould have introduced the situation in which this *unenforceable* policy\nmakes sense to me. Here it is:\n\nEvery miner is listening for valid block solutions but might receive two\nvalid blocks and then they have to decide which one to use. Choosing the\none you saw first is the default behavior. In that situation, we'd all\nlike everyone to choose the same block. I propose that a better heuristic\nthan \"first seen\" is to compare the BTCDD, *but only of transactions you\nalready have in your mempool*, and\n\n*weight the BTCDD so that txns you got earlier are more important.*\nThe heuristic is most useful when the two blocks are received within a\nsmall window of time, opting for the first-seen rule otherwise. I assume\nmany miners have an idea of how long it takes for anyone's new block to get\nacross the network, and more specifically, the range of times it takes for\nnew solutions to get to themselves. During this little time window, the\nchances are 50/50 that they'll choose the right block. If the default\nbehavior were to use BTCDD during that time window (one second? I have no\nidea!), then the chances would be significantly better.\n\nI think Jorge is right that it doesn't benefit miners. It doesn't hurt\nthem either, unless they are trying to do selfish mining. Well, it\nbenefits them in terms of increased bitcoin stability by A) making it\neasier for clients to decide which block is valid when they see two\ncompeting with each other, B) motivating miners to add transactions instead\nof mining empty blocks, C) severely decreasing the utility of any global\nprivate network of nodes intended to spread selfishly-mined blocks, and D)\nmotivating miners to stay well-connected so that they get transactions\nquickly.\n\nI sent this to the list because it is only useful if it is set as default\nbehavior since most miners leave the defaults alone, and the benefits don't\nmaterialize unless a majority follows the policy.\n\nOn Fri, Sep 11, 2015 at 11:37 AM, Jorge TimĂłn \u003cjtimon at jtimon.cc\u003e wrote:\n\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\n\u003e just a policy validation that everybody would be free to ignore (like the\n\u003e \"first 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\n\u003e not expect them to run it in the long run (like the \"first seen\" spend\n\u003e conflict tx replacement policy).\n\u003e If miners don't use it, I don't see how users can benefit from running\n\u003e that 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 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\n\u003e\n\n\n\n-- \nI like to provide some work at no charge to prove my value. Do you need a\ntechie?\nI own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003chttp://www.memeracing.net\u003e (in alpha).\nI'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e which\nnow accepts Bitcoin.\nI also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\"He ought to find it more profitable to play by the rules\" - Satoshi\nNakamoto\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/5d843513/attachment.html\u003e",
"sig": "db985226843c8565f69134039f0164080bf3d81699bdc5556a79784b7a34406f07a60a4f8eb6c5d5653ed7162962595cb0ee10bc56d1bac676e349d584636e33"
}