My solution to such a problem is to allow miners to replace the 'head block' with a more difficult head and this could even be done without a hard-fork.

Here is how it works. When you receive a new block you check to see if it extends the current head, if so you add it. If not you check to see if it replaces the current head with a more difficult block. In this case you replace it.

A miner who solves a block and fails to broadcast it increases the chance that someone else will solve his same block at a more difficult level (because they have more time). So he starts mining the second block in secret only to discover that an alternative 1st block has been broadcast which is more difficult than his own and so the network starts to build on that block.

Assuming he had less than 50% of the hashing power, then the chances that he could find two blocks before the rest of the network found 1 is very small and he would have a 50% chance of having his first block be higher than the other block found.

There would have to be some rule about not jumping to a 'longer fork' if it is less than 2-3 blocks ahead and the forked chain is based upon a weaker hash.    With this tweak the attacker would have to get 2-3 blocks ahead with their chain before the rest of the network broadcast a single block and the whole time they risk losing all of their blocks.

Dan





On Nov 4, 2013, at 4:56 PM, Sveinn Valfells <sveinn@???> wrote:

>
> Sounds a bit like a Bitcoin mining version of OPEC - or MSFT with hidden APIs, another form of collusion. Mining needs to be transparent and reliable, competing only on efficiency.
>
> Dark Wallet promises to be a great contribution, look forward to seeing the finished version. Hats off and good luck to the developers!
>
> On 04/11/13 21:32, Amir Taaki wrote:
>> Yeah seemed fanciful to me too if you're all talking about that non
>> majority evil miner cooperative attack. Why don't we form a cooperative to
>> rob brute force brain wallets? ... anyone? Yeah didn't think so. Isn't
>> that an economic attack too?
>>
>>> Wouldn't this be cancelled out by the chance that another miner could
>>> "non-selfishly" mine two blocks by themselves?
>>>
>>> Even if selfish miners accounted for more than 50% of the hash power,
>>> everyone else would end up becoming selfish to compete and then it would
>>> equal out among the miners. There would be more orphans created and more
>>> hash power wasted. But blocks would still be created and transactions
>>> would
>>> still be confirmed.
>>>
>>> Maybe I haven't thought about this enough though.
>>>
>>> I see an evil entity/entities gaining a large amount of hash power and
>>> only
>>> mining blocks with the coinbase transaction in, preventing tx being
>>> confirmed as being a more serious threat.
>>>
>>> Along with miners trying to fight among themselves confirming a
>>> transaction
>>> which has a large fee, such as the many 100-200btc fees paid in
>>> transactions due to errors made by a user, events like this could cause a
>>> massive blockchain fork, with each miner trying to build the longest chain
>>> on their own fork. The FBI is currently sat of massive amounts of btc
>>> which
>>> they could use in this way. I think it may be right to introduce a max fee
>>> option along side min fee, where nodes can refuse to relay a transaction
>>> if
>>> it looks like too many fees were paid, possibly by accident and it could
>>> cause a fork.
>>>
>>>
>>> There will be a point soon when the majority of miners act
>>> "intelligently",
>>> rather than just mining whatever bitcoind tells them to. Too much
>>> disruption like this could cause the exchange rate to collapse, or trust
>>> in
>>> the systems ability to confirm transactions dropping.
>>>
>>> Thanks
>>> Bob
>>>
>>>
>>>
>>>
>>> On 4 November 2013 18:32, Adam B. Levine <adam@???> wrote:
>>>
>>>> So crazy idea,
>>>> is it unethical to intentionally test this out on a low volume altcoin,
>>>> document and release the results? Seems like it would be trivial to
>>>> pull
>>>> this off with anything outside the top 30 cryptos, and in a real world
>>>> lab
>>>> we could test away the hypotheticals.
>>>>
>>>> Adam B. Levine
>>>> Editor-in-Chief
>>>> Let's Talk Bitcoin! <http://www.letstalkbitcoin.com>
>>>> 1-855-WETALKBITCOIN Ex.700
>>>> [image: Inline image 2]
>>>> Talk to me on Gli.ph, my preferred communications platform
>>>>
>>>>
>>>> On Mon, Nov 4, 2013 at 10:25 AM, Peter Todd <pete@???> wrote:
>>>>
>>>>> On Mon, Nov 04, 2013 at 07:22:45PM +0100, Pieter Hintjens wrote:
>>>>>> http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/
>>>>> They're right, but there's an easy fix that happens to have other
>>>>> advantages like reducing the work wasted on orphans and making it
>>>>> possible to get quick feedback on whether or not your transactions are
>>>>> being mined:
>>>>>
>>>>>
>>>>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03137.html
>>>>>
>>>>> --
>>>>> 'peter'[:-1]@petertodd.org
>>>>> 00000000000000041b6435c26187eeb950e1f3a0127e2776e82ece2d3c44854c
>>>>>
>>>>> _______________________________________________
>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>
>>>>>
>>>> _______________________________________________
>>>> unSYSTEM mailing list: http://unsystem.net
>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>
>>>>
>>> _______________________________________________
>>> unSYSTEM mailing list: http://unsystem.net
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>
>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem