📅 Original date posted:2015-12-19
📝 Original message: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.
---------------
ok, back to topic. Do you mean this?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html
Peter Todd via bitcoin-dev 於 2015-12-19 13:42 寫到:
> At the recent Scaling Bitcoin conference in Hong Kong we had a chatham
> house rules workshop session attending by representitives of a super
> majority of the Bitcoin hashing power.
>
> One of the issues raised by the pools present was block withholding
> attacks, which they said are a real issue for them. In particular,
> pools
> are receiving legitimate threats by bad actors threatening to use block
> withholding attacks against them. Pools offering their services to the
> general public without anti-privacy Know-Your-Customer have little
> defense against such attacks, which in turn is a threat to the
> decentralization of hashing power: without pools only fairly large
> hashing power installations are profitable as variance is a very real
> business expense. P2Pool is often brought up as a replacement for
> pools,
> but it itself is still relatively vulnerable to block withholding, and
> in any case has many other vulnerabilities and technical issues that
> has
> prevented widespread adoption of P2Pool.
>
> 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.
>
>
> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
> witholding attacks are a good thing, as in their model they can be used
> by small pools against larger pools, disincentivising large pools.
> However this argument is academic and not applicable to the real world,
> as a much simpler defense against block withholding attacks is to use
> anti-privacy KYC and the legal system combined with the variety of
> withholding detection mechanisms only practical for large pools.
> Equally, large hashing power installations - a dangerous thing for
> decentralization - have no block withholding attack vulnerabilities.
>
> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 [ARCHIVE] /
npub14v…jyksm
2023-06-07 17:46:55
in reply to nevent1q…uncz
Author Public Key
npub14vwgt02663pkxx54kg5t693shaavmvnldhsp49sve7asw7p36lkqljyksmPublished at
2023-06-07 17:46:55Event JSON
{
"id": "cdced2d8acd436bfc2fcd878b7543cab892ee2a55c2ec2b54aa5d7a8e432771b",
"pubkey": "ab1c85bd5ad443631a95b228bd1630bf7acdb27f6de01a960ccfbb077831d7ec",
"created_at": 1686160015,
"kind": 1,
"tags": [
[
"e",
"29b7621364af8f1f611558ed33ab90fd2b7daff5f620fc02b9ca3019fe1123e5",
"",
"root"
],
[
"e",
"39dd85248c3e15491fe34c3fce2728bfeb1d31b9dcd90ca8105ae1f6db044132",
"",
"reply"
],
[
"p",
"a4fc2fc2bfc061e75a1b6e17dfc4b3c93b85fab2fc91001f44fd8499d672b169"
]
],
"content": "📅 Original date posted:2015-12-19\n📝 Original message:After the meeting I find a softfork solution. It is very inefficient and \nI am leaving it here just for record.\n\n1. In the first output of the second transaction of a block, mining pool \nwill commit a random nonce with an OP_RETURN.\n\n2. Mine as normal. When a block is found, the hash is concatenated with \nthe committed random nonce and hashed.\n\n3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the block \nis invalid. That means about 1% of blocks are discarded.\n\n4. For each difficulty retarget, the secondary target is decreased by 2 \n^ 1/64.\n\n5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ \n252. Therefore only 1 in 16 hash returned by hasher is really valid. \nThis should make the detection of block withholding attack much easier.\n\nAll miners have to sacrifice 1% reward for 10 years. Confirmation will \nalso be 1% slower than it should be.\n\nIf a node (full or SPV) is not updated, it becomes more vulnerable as an \nattacker could mine a chain much faster without following the new rules. \nBut this is still a softfork, by definition.\n\n---------------\n\nok, back to topic. Do you mean this? \nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html\n\n\n\nPeter Todd via bitcoin-dev 於 2015-12-19 13:42 寫到:\n\u003e At the recent Scaling Bitcoin conference in Hong Kong we had a chatham\n\u003e house rules workshop session attending by representitives of a super\n\u003e majority of the Bitcoin hashing power.\n\u003e \n\u003e One of the issues raised by the pools present was block withholding\n\u003e attacks, which they said are a real issue for them. In particular, \n\u003e pools\n\u003e are receiving legitimate threats by bad actors threatening to use block\n\u003e withholding attacks against them. Pools offering their services to the\n\u003e general public without anti-privacy Know-Your-Customer have little\n\u003e defense against such attacks, which in turn is a threat to the\n\u003e decentralization of hashing power: without pools only fairly large\n\u003e hashing power installations are profitable as variance is a very real\n\u003e business expense. P2Pool is often brought up as a replacement for \n\u003e pools,\n\u003e but it itself is still relatively vulnerable to block withholding, and\n\u003e in any case has many other vulnerabilities and technical issues that \n\u003e has\n\u003e prevented widespread adoption of P2Pool.\n\u003e \n\u003e Fixing block withholding is relatively simple, but (so far) requires a\n\u003e SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should\n\u003e do this hard-fork in conjunction with any blocksize increase, which \n\u003e will\n\u003e have the desirable side effect of clearly show consent by the entire\n\u003e ecosystem, SPV clients included.\n\u003e \n\u003e \n\u003e Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block\n\u003e witholding attacks are a good thing, as in their model they can be used\n\u003e by small pools against larger pools, disincentivising large pools.\n\u003e However this argument is academic and not applicable to the real world,\n\u003e as a much simpler defense against block withholding attacks is to use\n\u003e anti-privacy KYC and the legal system combined with the variety of\n\u003e withholding detection mechanisms only practical for large pools.\n\u003e Equally, large hashing power installations - a dangerous thing for\n\u003e decentralization - have no block withholding attack vulnerabilities.\n\u003e \n\u003e 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "ee7ee04556ce62f68ef52aaa628dddad7ce016a6852e3274ff614beb14528d030833c490411e873fd85f372d27d3e679de958c661ed09f13062068cbf495b574"
}