📅 Original date posted:2012-06-04
📝 Original message:On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> As I understand the attack, the attacker gets compensated for the shares
> they earn, but the pool will be denied any valid blocks found. The
> attacker DOES NOT have access to the Bitcoins earned in the unreported
> block (only the mining pool has access to the Coinbase address and
> transactions in the block).
With decentralized pools, the attacker does have access to the block, and can
potentially submit it to the Bitcoin network directly bypassing the pool if it
benefits them to do so.
> So it's a zero-net-cost attack for the attacker (but no chance of making a
> profit) to hurt the pool operator.
Because of the above, there is a possibility an attacker can make a profit.
> The only way to detect such an attack now is to look for "unlucky" miners;
> at the current difficulty, you can't detect this cheat until many millions
> of shares have been earned w/o a qualifying block. Since an attacker can
> also create many fake identities, they can avoid detection indefinitely by
> abandoning each account after a million earned shares.
There are other modes of detection, but nobody has bothered to implement them
since attackers can easily do a simple workaround in an arms race.
> I don't understand your proposal for fixing this. You would have to come
> up with a scheme where:
>
> - The miner can detect a qualifying hash to earn a share.
> - Not be able to tell if the hash is for a valid block.
With my proposal, miners can find shares, but won't know if it's a valid block
until the subsequent block is also found (that subsequent block might not end
up being a real block in the big picture).
> The way I would do this is to have a secret part (not shared with the
> miners) of a block that is part of the merkle hash, which is also used in a
> secondary hash. Difficulty is then divide into two parts: the first,
> solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes). And
> a second, solved by the pool (1 in Difficulty shares). A valid block would
> have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
> accepted.
This only works for centralized pools, which are contrary to the health of the
Bitcoin network. Decentralized pools cannot have a secret.
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 10:11:41
in reply to nevent1q…t39e
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsPublished at
2023-06-07 10:11:41Event JSON
{
"id": "d39c3c8deea292acad3fe07fad714bca0b1d21522ba78c0ab8f5428704995d30",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686132701,
"kind": 1,
"tags": [
[
"e",
"a41c266ea909ede278d0ffa091090bff630df3ebf392d5fdee34cf65c8588463",
"",
"root"
],
[
"e",
"c86e2cd61aace124b17300ee61aa910f2acc7603266a98759cb487577a35f751",
"",
"reply"
],
[
"p",
"6c35cbce1572019d239813b345be98c18b740a50728c6e7191def884ca18a058"
]
],
"content": "📅 Original date posted:2012-06-04\n📝 Original message:On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:\n\u003e As I understand the attack, the attacker gets compensated for the shares\n\u003e they earn, but the pool will be denied any valid blocks found. The\n\u003e attacker DOES NOT have access to the Bitcoins earned in the unreported\n\u003e block (only the mining pool has access to the Coinbase address and\n\u003e transactions in the block).\n\nWith decentralized pools, the attacker does have access to the block, and can \npotentially submit it to the Bitcoin network directly bypassing the pool if it \nbenefits them to do so.\n\n\u003e So it's a zero-net-cost attack for the attacker (but no chance of making a\n\u003e profit) to hurt the pool operator. \n\nBecause of the above, there is a possibility an attacker can make a profit.\n\n\u003e The only way to detect such an attack now is to look for \"unlucky\" miners;\n\u003e at the current difficulty, you can't detect this cheat until many millions\n\u003e of shares have been earned w/o a qualifying block. Since an attacker can\n\u003e also create many fake identities, they can avoid detection indefinitely by\n\u003e abandoning each account after a million earned shares.\n\nThere are other modes of detection, but nobody has bothered to implement them \nsince attackers can easily do a simple workaround in an arms race.\n\n\u003e I don't understand your proposal for fixing this. You would have to come\n\u003e up with a scheme where:\n\u003e \n\u003e - The miner can detect a qualifying hash to earn a share.\n\u003e - Not be able to tell if the hash is for a valid block.\n\nWith my proposal, miners can find shares, but won't know if it's a valid block \nuntil the subsequent block is also found (that subsequent block might not end \nup being a real block in the big picture).\n\n\u003e The way I would do this is to have a secret part (not shared with the\n\u003e miners) of a block that is part of the merkle hash, which is also used in a\n\u003e secondary hash. Difficulty is then divide into two parts: the first,\n\u003e solved by the miner (earning a \"share\" - e.g., 1 in 4 Billion hashes). And\n\u003e a second, solved by the pool (1 in Difficulty shares). A valid block would\n\u003e have to exhibit a valid Share Hash AND a valid Pool Hash in order to be\n\u003e accepted.\n\nThis only works for centralized pools, which are contrary to the health of the \nBitcoin network. Decentralized pools cannot have a secret.",
"sig": "1065b588aa5d670397247a1771ed6a8ae38515c9f98b5703593340119566a9cb19f153e5a3ed66beb2ccc8ac4fde5048bf4e9edd77b176c92584bc7fddc4e854"
}