📅 Original date posted:2013-11-05
📝 Original message:On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> I think it's a stretch to say 'y' is 0 with good connectivity. Even the
> best connected mining pools today are concerned with this 'y' factor.
>
Check out the following paper for the effect a single node can have on
propagation, and on the relation between block size and propagation speed.
This strongly supports our assumption.
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
>
> Here's a probably very dumb idea... to throw out one possible "solution"...
>
> You want a way to fake-out the 'selfish miner' into disclosing their
> blocks -- how can your force their hand to prevent them from accumulating
> longer private chains?
>
> What if you propagate (and relay) an encrypted block header which honest
> miners will timestamp when they receive it, then 10 seconds later propagate
> the decryption key to unblind it. But here's the catch - maybe the
> decryption results in junk, maybe it results a new longer block. If it's a
> real block then it gets priority based on when the ciphertext was received
> instead of when the decryption key was received. Now 'selfish miner' can't
> race the network anymore, because they are always in state 0' and can't
> tell if they are up against a ghost, or a real competing block. If they
> wait for the decryption key to check, it's too late, and they are
> guaranteed to lose unless they can out-race the network, e.g. back at
> t=50%. Of course there would need to be some way to anti-DDoS this which
> allows for some amount of these fake-outs without letting them get out of
> hand.
>
That's a dangerous way to go, opening the door to DoS attacks, as you
mention. Besides, it makes a simple algorithm complicated, and doing such
changes may lead to different vulnerabilities that are difficult to cover.
Best,
Ittay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/96e0df01/attachment.html>;
Ittay [ARCHIVE] /
npub1n8…637cg
2023-06-07 15:08:55
in reply to nevent1q…za9m
Author Public Key
npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cgPublished at
2023-06-07 15:08:55Event JSON
{
"id": "c3bdeeaea8b3fc12af22511102a1d5a9274f60f53fc6f235a74e4b36fcd51605",
"pubkey": "99c8b0a6b21759bf5fe55d05687329c239cd5a291b04b00315b230db39bc0660",
"created_at": 1686150535,
"kind": 1,
"tags": [
[
"e",
"6d3f2b033dee2609b17c739a2c08a8dad9f58ca1e382056f88a3fdcc51c33a75",
"",
"root"
],
[
"e",
"a97a41646f38cba2440a7e63e392b0d23df191b7562b61eb8c6ab2a69aa870c4",
"",
"reply"
],
[
"p",
"7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3"
]
],
"content": "📅 Original date posted:2013-11-05\n📝 Original message:On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman \u003cjeremy at taplink.co\u003e wrote:\n\n\n\u003e I think it's a stretch to say 'y' is 0 with good connectivity. Even the\n\u003e best connected mining pools today are concerned with this 'y' factor.\n\u003e\n\nCheck out the following paper for the effect a single node can have on\npropagation, and on the relation between block size and propagation speed.\nThis strongly supports our assumption.\nhttp://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf\n\n\n\u003e\n\u003e Here's a probably very dumb idea... to throw out one possible \"solution\"...\n\u003e\n\u003e You want a way to fake-out the 'selfish miner' into disclosing their\n\u003e blocks -- how can your force their hand to prevent them from accumulating\n\u003e longer private chains?\n\u003e\n\u003e What if you propagate (and relay) an encrypted block header which honest\n\u003e miners will timestamp when they receive it, then 10 seconds later propagate\n\u003e the decryption key to unblind it. But here's the catch - maybe the\n\u003e decryption results in junk, maybe it results a new longer block. If it's a\n\u003e real block then it gets priority based on when the ciphertext was received\n\u003e instead of when the decryption key was received. Now 'selfish miner' can't\n\u003e race the network anymore, because they are always in state 0' and can't\n\u003e tell if they are up against a ghost, or a real competing block. If they\n\u003e wait for the decryption key to check, it's too late, and they are\n\u003e guaranteed to lose unless they can out-race the network, e.g. back at\n\u003e t=50%. Of course there would need to be some way to anti-DDoS this which\n\u003e allows for some amount of these fake-outs without letting them get out of\n\u003e hand.\n\u003e\n\nThat's a dangerous way to go, opening the door to DoS attacks, as you\nmention. Besides, it makes a simple algorithm complicated, and doing such\nchanges may lead to different vulnerabilities that are difficult to cover.\n\nBest,\nIttay\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/96e0df01/attachment.html\u003e",
"sig": "cc418fc40f7e4c08473f55cd5484f14ea0112cb4f80b9101e0c94b4cf84e4a61c5693b6a22f11fcc1acba7e35f56e4d853972ca7355097e6185a8f9a12752b11"
}