📅 Original date posted:2015-12-26
📝 Original message:Note: my stupid email client didn't indent Peter Todd's quote correctly.
The first paragraph is his, the second is my response.
------ Original Message ------
From: "Eric Lombrozo" <elombrozo at gmail.com>
To: "Peter Todd" <pete at petertodd.org>; "Emin Gün Sirer"
<el33th4x0r at gmail.com>
Cc: nbvfour at gmail.com; "Bitcoin Dev"
<bitcoin-dev at lists.linuxfoundation.org>
Sent: 12/26/2015 12:23:38 AM
Subject: Re[2]: [bitcoin-dev] We need to fix the block withholding
attack
>Peter Todd wrote:
> Fixing block withholding is relatively simple, but (so far) requires a
>SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
>do this hard-fork in conjunction with any blocksize increase, which
>will
>have the desirable side effect of clearly show consent by the entire
>ecosystem, SPV clients included.
>
>I think we can generalize this and argue that it is impossible fix this
>without reducing the visible difficulty and blinding the hasher to an
>invisible difficulty. Unfortunately, changing the retargeting algo to
>compute lower visible difficulty (leaving all else the same) or
>interpreting the bits field in a way that yields a lower visible
>difficulty is a hard fork by definition - blocks that didn't meet the
>visible difficulty requirement before will now meet it.
>
>jl2012 wrote:
>>After the meeting I find a softfork solution. It is very inefficient
>>and I am leaving it here just for record.
>>
>>1. In the first output of the second transaction of a block, mining
>>pool will commit a random nonce with an OP_RETURN.
>>
>>2. Mine as normal. When a block is found, the hash is concatenated
>>with the committed random nonce and hashed.
>>
>>3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the
>>block is invalid. That means about 1% of blocks are discarded.
>>
>>4. For each difficulty retarget, the secondary target is decreased by
>>2 ^ 1/64.
>>
>>5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
>>252. Therefore only 1 in 16 hash returned by hasher is really valid.
>>This should make the detection of block withholding attack much
>>easier.
>>
>>All miners have to sacrifice 1% reward for 10 years. Confirmation will
>>also be 1% slower than it should be.
>>
>>If a node (full or SPV) is not updated, it becomes more vulnerable as
>>an attacker could mine a chain much faster without following the new
>>rules. But this is still a softfork, by definition.
>jl2012's key discovery here is that if we add an invisible difficulty
>while keeping the retarget algo and bits semantics the same, the
>visible difficulty will decrease automatically to compensate. In other
>words, we can artificially increase the block time interval, allowing
>us to force a lower visible difficulty at the next retarget without
>changing the retarget algo nor the bits semantics. There are no other
>free parameters we can tweak, so it seems this is really the best we
>can do.
>
>Unfortunately, this also means longer confirmation times, lower
>throughput, and lower miner revenue. Note, however, that confirmations
>would (on average) represent more PoW, so fewer confirmations would be
>required to achieve the same level of security.
>
>We can compensate for lower throughput and lower miner revenue by
>increasing block size and increasing block rewards. Interestingly, it
>turns out we *can* do these things with soft forks by embedding new
>structures into blocks and nesting their hash trees into existing
>structures. Ideas such as extension blocks
>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html]
>have been proposed before...but they add significant complications to
>the protocol and require nontrivial app migration efforts. Old nodes
>would not get forked off the network but backwards compatibility would
>still be a problem as they would not be able to see at least some of
>the transactions and some of the bitcoins in blocks. But if we're
>willing to accept this, even the "sacred" 21 million asymptotic limit
>can be raised via soft fork!
>
>So in conclusion, it *is* possible to fix this attack with a soft fork
>and without altering the basic economics...but it's almost surely a lot
>more trouble than it's worth. Luke-Jr's solution is far simpler and
>more elegant and is perhaps one of the few examples of a new feature
>(as opposed to merely a structure cleanup) that would be better to
>deploy as a hard fork since it's simple to implement and seems to stand
>a reasonable chance of near universal support...and soft fork
>alternatives are very, very ugly and significantly impact system
>usability...and I think theory tells us we can't do any better.
>
>- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/381a45ab/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:47:07
in reply to nevent1q…hsva
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:47:07Event JSON
{
"id": "300309314fdd88ca1fff8da8f59329dfa95b90eddf885e289d0a86348acdcb51",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686160027,
"kind": 1,
"tags": [
[
"e",
"29b7621364af8f1f611558ed33ab90fd2b7daff5f620fc02b9ca3019fe1123e5",
"",
"root"
],
[
"e",
"18d722287a53db623cd5de543a03480774ed70e6cef5cb9fd2b6284f4db17eed",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-12-26\n📝 Original message:Note: my stupid email client didn't indent Peter Todd's quote correctly. \nThe first paragraph is his, the second is my response.\n\n------ Original Message ------\nFrom: \"Eric Lombrozo\" \u003celombrozo at gmail.com\u003e\nTo: \"Peter Todd\" \u003cpete at petertodd.org\u003e; \"Emin Gün Sirer\" \n\u003cel33th4x0r at gmail.com\u003e\nCc: nbvfour at gmail.com; \"Bitcoin Dev\" \n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSent: 12/26/2015 12:23:38 AM\nSubject: Re[2]: [bitcoin-dev] We need to fix the block withholding \nattack\n\n\u003ePeter Todd wrote:\n\u003e Fixing block withholding is relatively simple, but (so far) requires a\n\u003eSPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should\n\u003edo this hard-fork in conjunction with any blocksize increase, which \n\u003ewill\n\u003ehave the desirable side effect of clearly show consent by the entire\n\u003eecosystem, SPV clients included.\n\u003e\n\u003eI think we can generalize this and argue that it is impossible fix this \n\u003ewithout reducing the visible difficulty and blinding the hasher to an \n\u003einvisible difficulty. Unfortunately, changing the retargeting algo to \n\u003ecompute lower visible difficulty (leaving all else the same) or \n\u003einterpreting the bits field in a way that yields a lower visible \n\u003edifficulty is a hard fork by definition - blocks that didn't meet the \n\u003evisible difficulty requirement before will now meet it.\n\u003e\n\u003ejl2012 wrote:\n\u003e\u003eAfter the meeting I find a softfork solution. It is very inefficient \n\u003e\u003eand I am leaving it here just for record.\n\u003e\u003e\n\u003e\u003e1. In the first output of the second transaction of a block, mining \n\u003e\u003epool will commit a random nonce with an OP_RETURN.\n\u003e\u003e\n\u003e\u003e2. Mine as normal. When a block is found, the hash is concatenated \n\u003e\u003ewith the committed random nonce and hashed.\n\u003e\u003e\n\u003e\u003e3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the \n\u003e\u003eblock is invalid. That means about 1% of blocks are discarded.\n\u003e\u003e\n\u003e\u003e4. For each difficulty retarget, the secondary target is decreased by \n\u003e\u003e2 ^ 1/64.\n\u003e\u003e\n\u003e\u003e5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ \n\u003e\u003e252. Therefore only 1 in 16 hash returned by hasher is really valid. \n\u003e\u003eThis should make the detection of block withholding attack much \n\u003e\u003eeasier.\n\u003e\u003e\n\u003e\u003eAll miners have to sacrifice 1% reward for 10 years. Confirmation will \n\u003e\u003ealso be 1% slower than it should be.\n\u003e\u003e\n\u003e\u003eIf a node (full or SPV) is not updated, it becomes more vulnerable as \n\u003e\u003ean attacker could mine a chain much faster without following the new \n\u003e\u003erules. But this is still a softfork, by definition.\n\u003ejl2012's key discovery here is that if we add an invisible difficulty \n\u003ewhile keeping the retarget algo and bits semantics the same, the \n\u003evisible difficulty will decrease automatically to compensate. In other \n\u003ewords, we can artificially increase the block time interval, allowing \n\u003eus to force a lower visible difficulty at the next retarget without \n\u003echanging the retarget algo nor the bits semantics. There are no other \n\u003efree parameters we can tweak, so it seems this is really the best we \n\u003ecan do.\n\u003e\n\u003eUnfortunately, this also means longer confirmation times, lower \n\u003ethroughput, and lower miner revenue. Note, however, that confirmations \n\u003ewould (on average) represent more PoW, so fewer confirmations would be \n\u003erequired to achieve the same level of security.\n\u003e\n\u003eWe can compensate for lower throughput and lower miner revenue by \n\u003eincreasing block size and increasing block rewards. Interestingly, it \n\u003eturns out we *can* do these things with soft forks by embedding new \n\u003estructures into blocks and nesting their hash trees into existing \n\u003estructures. Ideas such as extension blocks \n\u003e[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html] \n\u003ehave been proposed before...but they add significant complications to \n\u003ethe protocol and require nontrivial app migration efforts. Old nodes \n\u003ewould not get forked off the network but backwards compatibility would \n\u003estill be a problem as they would not be able to see at least some of \n\u003ethe transactions and some of the bitcoins in blocks. But if we're \n\u003ewilling to accept this, even the \"sacred\" 21 million asymptotic limit \n\u003ecan be raised via soft fork!\n\u003e\n\u003eSo in conclusion, it *is* possible to fix this attack with a soft fork \n\u003eand without altering the basic economics...but it's almost surely a lot \n\u003emore trouble than it's worth. Luke-Jr's solution is far simpler and \n\u003emore elegant and is perhaps one of the few examples of a new feature \n\u003e(as opposed to merely a structure cleanup) that would be better to \n\u003edeploy as a hard fork since it's simple to implement and seems to stand \n\u003ea reasonable chance of near universal support...and soft fork \n\u003ealternatives are very, very ugly and significantly impact system \n\u003eusability...and I think theory tells us we can't do any better.\n\u003e\n\u003e- Eric\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/381a45ab/attachment.html\u003e",
"sig": "d0f1ff6c4f556b240d79e01f77dbfcce951c5d29858d547455a418346b4b5f72ba9c74d0c58b95b610d703caf96ee60a87bdbdd13870c3571921e38666fef345"
}