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 <l...@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.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
