Mike Koss [ARCHIVE] on Nostr: š Original date posted:2012-06-04 š Original message:I don't understand how ...
š
Original date posted:2012-06-04
š Original message:I don't understand how your proposal will work for decentralized pools -
can you explain it more concretely?
What would the new block header look like?
What is required for a share to to be earned?
What is required for a block to be valid (added to Block Chain)?
I don't think I understand what you mean by NextBlockCandidate. Perhaps a
concrete example using difficulty 1.7 million would be instructive.
On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr <luke at dashjr.org> wrote:
> 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.
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf>; - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120604/2e959c8a/attachment.html>;
š Original message:I don't understand how your proposal will work for decentralized pools -
can you explain it more concretely?
What would the new block header look like?
What is required for a share to to be earned?
What is required for a block to be valid (added to Block Chain)?
I don't think I understand what you mean by NextBlockCandidate. Perhaps a
concrete example using difficulty 1.7 million would be instructive.
On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr <luke at dashjr.org> wrote:
> 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.
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf>; - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120604/2e959c8a/attachment.html>;