đ
Original date posted:2016-02-12
đ Original message:Here's a method of fixing block withholding attacks with a soft fork:
We require blocks to choose an arbitrary target, e.g. two bytes. We
redefine the block PoW target to be "less than the difficulty, with the
last two bytes being the target".
We require blocks to include a blinded hash of the target plus some junk
(which blinds it) in the coinbase. The miner cannot arbitrarily switch
targets.
The miner can now send the block header to hashers. Hashers do not know the
target, and hence must submit all shares that matches the first PoW
criteria (below difficulty) and delegate secondary verification to the
miner. With two bytes as the target, there are 65335 false positives for
every valid block.
Finally, we require miners to communicate a proof of their target hash (ie,
the junk they generated) in a non-hashed area of the block. This can be a
protocol extension. The target is already included in the hash as the last
two bytes.
This can be deployed as a soft fork with miner opt in, triggering across
many difficulty cycles. Initially, we soft fork to require the last bit of
the block hash to be zero. The next difficulty cycle, we require the last
two bits to be zero. We do this 16 times to get 2 bytes, and then we
actually activate targets.
By then, nominal difficulty would have been cut by 2^16 (65536), but the
block target makes mining each block 65536 times as hard. We do the
progression over 16 difficulty cycles to minimise increases in block
timings. We can be more specific and progress over even more difficulty
cycles through more clever soft fork rules.
For example, Vitalik detailed "timewalking" attacks that allow effective
granular lowering of the nominal difficulty.
Critique welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160212/b16be954/attachment.html>;
gladoscc [ARCHIVE] /
npub138âŚ4h7my
2023-06-07 17:49:10
in reply to nevent1qâŚgjjg
Author Public Key
npub138yeqaf7leywengpmjy44kcv08cers44gu784mhum2h7u8yw8sns74h7mySeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:49:10Event JSON
{
"id": "2e2438bf8173574ed2b6324053b37d8c8c64c70400b48e713e5a937233eaf457",
"pubkey": "89c990753efe48eccd01dc895adb0c79f191c2b5473c7aeefcdaafee1c8e3c27",
"created_at": 1686160150,
"kind": 1,
"tags": [
[
"e",
"3468bf5fbe73f11e946413b9b9e5dabd38e7918263433e499f3a9567ddebc7f4",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "đ
Original date posted:2016-02-12\nđ Original message:Here's a method of fixing block withholding attacks with a soft fork:\n\nWe require blocks to choose an arbitrary target, e.g. two bytes. We\nredefine the block PoW target to be \"less than the difficulty, with the\nlast two bytes being the target\".\n\nWe require blocks to include a blinded hash of the target plus some junk\n(which blinds it) in the coinbase. The miner cannot arbitrarily switch\ntargets.\n\nThe miner can now send the block header to hashers. Hashers do not know the\ntarget, and hence must submit all shares that matches the first PoW\ncriteria (below difficulty) and delegate secondary verification to the\nminer. With two bytes as the target, there are 65335 false positives for\nevery valid block.\n\nFinally, we require miners to communicate a proof of their target hash (ie,\nthe junk they generated) in a non-hashed area of the block. This can be a\nprotocol extension. The target is already included in the hash as the last\ntwo bytes.\n\nThis can be deployed as a soft fork with miner opt in, triggering across\nmany difficulty cycles. Initially, we soft fork to require the last bit of\nthe block hash to be zero. The next difficulty cycle, we require the last\ntwo bits to be zero. We do this 16 times to get 2 bytes, and then we\nactually activate targets.\n\nBy then, nominal difficulty would have been cut by 2^16 (65536), but the\nblock target makes mining each block 65536 times as hard. We do the\nprogression over 16 difficulty cycles to minimise increases in block\ntimings. We can be more specific and progress over even more difficulty\ncycles through more clever soft fork rules.\n\nFor example, Vitalik detailed \"timewalking\" attacks that allow effective\ngranular lowering of the nominal difficulty.\n\nCritique welcome.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160212/b16be954/attachment.html\u003e",
"sig": "b0689219bca2e9c4d7a4e1eff34097239322e93f78fe4c4dee766f80b3f4f02da877ba120120fa588de92a22a4387c311237efd45df4a4f6584d535cd4985b4a"
}