📅 Original date posted:2014-07-06
📝 Original message:Thanks Mike.
Indeed, I am aware of current approach, which is why I was suggesting
this as an alternative.
I haven't thought about it enough, and perhaps it was too radical a
rethinking - just wanted to see what the smarter minds thought.
Thanks again.
-Randi
On 7/5/14, 4:43 AM, Mike Hearn wrote:
>
> Is it possible instead to allocate a portion of the reward to " a # of
> runner up(s)" even though the runner-up(s) block will be orphaned?
>
>
> There's really no concept of a "runner up" because hashing is progress
> free. It's unintuitive and often trips people up. There's no concept
> that everyone is 95% of the way to finding a solution and then someone
> pips you to the post. It's more like playing the lottery over and over
> again. Doesn't matter how many times you did it before, the next time
> your chances are the same.
>
> A better concept is of rewarding "near miss" solutions which is what
> we already do of course, via pools, which pay you for shares which
> don't quite meet the difficulty target but almost do. So the question
> is how can we implement pools which have this reward structure (which
> obviously works well) without miners simultaneously giving up their
> right to block creation either due to technical problems or sheer
> lazyness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140706/1936adfc/attachment.html>;
Randi Joseph [ARCHIVE] /
npub1wz…rnuay
2023-06-07 15:23:38
in reply to nevent1q…fcxh
Author Public Key
npub1wz8zfl8azn6qfnx5t5d479wwnf69keeq4amvsp590nvzrunqumrqurnuaySeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:23:38Event JSON
{
"id": "6d937fa872906e4f73e7fb197aa8da800fae2359423a4b3b09807f79807f9db7",
"pubkey": "708e24fcfd14f404ccd45d1b5f15ce9a745b6720af76c806857cd821f260e6c6",
"created_at": 1686151418,
"kind": 1,
"tags": [
[
"e",
"a9e20ae1b6e168ee862b71e56f89b4ed7603371912b3a24e648d19074482f62c",
"",
"root"
],
[
"e",
"87ba9d3dabaa0efe8ea3e594f87840504ff2713d85570d59d6222239106c62fd",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-07-06\n📝 Original message:Thanks Mike.\n\nIndeed, I am aware of current approach, which is why I was suggesting \nthis as an alternative.\nI haven't thought about it enough, and perhaps it was too radical a \nrethinking - just wanted to see what the smarter minds thought.\n\nThanks again.\n\n-Randi\n\nOn 7/5/14, 4:43 AM, Mike Hearn wrote:\n\u003e\n\u003e Is it possible instead to allocate a portion of the reward to \" a # of\n\u003e runner up(s)\" even though the runner-up(s) block will be orphaned?\n\u003e\n\u003e\n\u003e There's really no concept of a \"runner up\" because hashing is progress \n\u003e free. It's unintuitive and often trips people up. There's no concept \n\u003e that everyone is 95% of the way to finding a solution and then someone \n\u003e pips you to the post. It's more like playing the lottery over and over \n\u003e again. Doesn't matter how many times you did it before, the next time \n\u003e your chances are the same.\n\u003e\n\u003e A better concept is of rewarding \"near miss\" solutions which is what \n\u003e we already do of course, via pools, which pay you for shares which \n\u003e don't quite meet the difficulty target but almost do. So the question \n\u003e is how can we implement pools which have this reward structure (which \n\u003e obviously works well) without miners simultaneously giving up their \n\u003e right to block creation either due to technical problems or sheer \n\u003e lazyness.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140706/1936adfc/attachment.html\u003e",
"sig": "2204f906467540ec9bff3ddb6f94712d6f1916f59a20812f6fbe05ce924e1759d7800e1a7e8e3b238e874c769f4779619d49cf7273028552d5e4ec3289a54063"
}