Michael Gronager [ARCHIVE] on Nostr: 📅 Original date posted:2013-11-04 📝 Original message:"We propose a simple, ...
📅 Original date posted:2013-11-04
📝 Original message:"We propose a simple, backwards-compatible change to the Bitcoin
protocol to address this problem and raise the threshold. Specifically,
when a miner learns of competing branches of the same length, it should
propagate all of them, and choose which one to mine on uniformly at random."
So only in the case of two competing chains... The "Selfish Miner" today
has an advantage knowing which chain the other will work on, and by
simply choosing the other they get their advantage making it likely that
it is the other that will waste their effort. By using the random scheme
this advantage is gone.
Note again that it is only in the case of two competing chains, which
will happen on average every 60 blocks. So it is only roughly once every
60 block that you change from choosing one chain to doing a 50% random.
A rough calculation on earnings will be that you loose roughly 1/(2*60)
~ 1% of your blocks using this scheme. But at the same time you make it
harder for such an attack to happen. (This number might be slightly
higher, as working in parallel on both chains will make the two chains
last longer, so agree that we need a bit more analysis...)
I also agree that it is a kind of a Sybil attack, but I think we should
accept the risk of a Sybil attack but of course minimize it, rather than
introducing various social network (ip addresses) solutions, which in
one way or the other always have some central auth / oracle assumption.
On 4/11/13, 13:03 , Mike Hearn wrote:
> The suggested change is actually very simple (minutes of coding) and
> elegant and addresses precisely the identified problem.
>
>
> Disagree. Unless I'm misunderstanding what they propose, their suggested
> change would mean anyone could broadcast a newly discovered block at any
> point and have a 50% chance of being the winner. That is a fundamental
> change to the dynamics of how Bitcoin works that would require careful
> thought and study.
>
> Also, their solution doesn't really address the problem they bring up,
> it just changes the size of the threshold required.
>
> Fundamentally, their attack is a sybil attack. It doesn't work if they
> can't delay or block a pools competitors because mostly their block will
> come in second place and they'll lose the race. Thus the solution should
> be a solution to sybil attacks.
Published at
2023-06-07 15:08:38Event JSON
{
"id": "4febaaa11d69d22395775f32d65ade12cb6b1632d09dc2d8f86cc3a76b24cb33",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686150518,
"kind": 1,
"tags": [
[
"e",
"765fed6c29fdbe34a8d684f2c378c7af27425335b84117da7738480c60386dd8",
"",
"root"
],
[
"e",
"3686be122265011e7dfb950f30f7643674f8540e4e31301ee0ff899008dcde80",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-11-04\n📝 Original message:\"We propose a simple, backwards-compatible change to the Bitcoin\nprotocol to address this problem and raise the threshold. Specifically,\nwhen a miner learns of competing branches of the same length, it should\npropagate all of them, and choose which one to mine on uniformly at random.\"\n\nSo only in the case of two competing chains... The \"Selfish Miner\" today\nhas an advantage knowing which chain the other will work on, and by\nsimply choosing the other they get their advantage making it likely that\nit is the other that will waste their effort. By using the random scheme\nthis advantage is gone.\n\nNote again that it is only in the case of two competing chains, which\nwill happen on average every 60 blocks. So it is only roughly once every\n60 block that you change from choosing one chain to doing a 50% random.\n\nA rough calculation on earnings will be that you loose roughly 1/(2*60)\n~ 1% of your blocks using this scheme. But at the same time you make it\nharder for such an attack to happen. (This number might be slightly\nhigher, as working in parallel on both chains will make the two chains\nlast longer, so agree that we need a bit more analysis...)\n\nI also agree that it is a kind of a Sybil attack, but I think we should\naccept the risk of a Sybil attack but of course minimize it, rather than\nintroducing various social network (ip addresses) solutions, which in\none way or the other always have some central auth / oracle assumption.\n\n\n\nOn 4/11/13, 13:03 , Mike Hearn wrote:\n\u003e The suggested change is actually very simple (minutes of coding) and\n\u003e elegant and addresses precisely the identified problem.\n\u003e \n\u003e \n\u003e Disagree. Unless I'm misunderstanding what they propose, their suggested\n\u003e change would mean anyone could broadcast a newly discovered block at any\n\u003e point and have a 50% chance of being the winner. That is a fundamental\n\u003e change to the dynamics of how Bitcoin works that would require careful\n\u003e thought and study.\n\u003e \n\u003e Also, their solution doesn't really address the problem they bring up,\n\u003e it just changes the size of the threshold required. \n\u003e \n\u003e Fundamentally, their attack is a sybil attack. It doesn't work if they\n\u003e can't delay or block a pools competitors because mostly their block will\n\u003e come in second place and they'll lose the race. Thus the solution should\n\u003e be a solution to sybil attacks.",
"sig": "d0184a0563c0e9661d169595697ec0afaf282e934e0de8fadb9a210811588c2faba8b0bf4c34cffc0f41bdfe88cb2326363b73936ab92a0034adbd26bba81a43"
}