On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr <l...@dashjr.org> wrote: > Analysis, comments, constructive criticism, etc welcome for the following: > > ==Background== > At present, an attacker can harm a pool by intentionally NOT submitting shares > that are also valid blocks. All pools are vulnerable to this attack, whether > centralized or decentralized and regardless of reward system used. The > attack's effectiveness is proportional to ratio of the attacker's hashrate to > the rest of the pool. This attack has an obvious signature: getting outworked on the same block as the pool was trying to verify, and always by the same person. > > There are obvious solutions that can be used to defeat this attack on > centralized pools. For example, including a secret in the coinbase transaction > that is accepted by the network as a partial preimage proof-of-work. All these > solutions require changes to Bitcoin's proof-of-work acceptance terms, and > since centralized pools can be harmful to the network's security, these rule > changes are not likely to gain enough acceptance among the greater Bitcoin > community. > > ==Proposed Solution== > Please comment on the viability of this new proof-of-work algorithm, which I > think should be viable for even decentralized pools: > > Blocks are accepted at a lower difficulty N (choosable by the pool; eg, the > share difficulty) iff they are submitted with a candidate for the next block > and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficulty M. > The relationship between M and N must be comparable to the normal network > difficulty; details on the specifics of this can be figured out later, ideally > by someone more qualified than me. M and N must be chosen prior to searching > for the block: it should be safe to steal some always-zero bytes from the > prevblock header for this. So the goal is to prevent the attacker double-dipping by submitting cycles to the pool, which if he found a correct answer he could submit himself. I don't see how this does that: if he finds a valid block he finds a valid block. Only if the operator has a secret is this prevented. > > This algorithm should guarantee that every share has an equal chance of being > a valid block at the time it is found, and that which ones are actually blocks > cannot be known until the subsequent block is found. Thus, attackers have no > way to identify which shares to withhold even while they have full knowledge > of the shares/blocks themselves. This further delays the finalization of a transaction. That's not a good thing. > > ==Backward Compatibility== > Obviously, this change creates a hard-fork in the blockchain. I propose that > if it solves the block withholding risk, the gain is sufficient that the > community may approve a hard-fork to take place 1-2 years from consensus. > > Since mining continues to use a double-SHA256 on a fixed 80 byte header, > existing miners, FPGAs, etc should work unmodified. Poolservers will need to > adapt significantly. > > ------------------------------------------------------------------------------ > 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
-- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin ------------------------------------------------------------------------------ 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
