An idea on how to reduce the risk of a 51 % attack

[Sword Smith]

Building upon the idea of green addresses, I believe one can significantly lower the risk of a 51 % attack and also decrease the likelihood that a March 11th type problem would go unnoticed for as long as it did (into a hardfork with +6 false confirmations on at least one large transaction).


It works like this: Trusted parties could send some kind of random amounts of bitcoins from one seemingly random address to another both controlled by the same party or one controlled by another trusted party. Then n blocks later (n=3?) a green address could send out a message(d transaction) through the block chain containing the information on the transaction with a time stamp, a sender, and a receiver address or perhaps just the firstbits of these addresses. A 51 % attacker is unlikely to include the first of these transactions in his blocks since he would have to include all transactions to insure that he did not miss the special transaction used to check the integrity of the blocks created and if he includes all transactions, it is no longer an attack. And the attacker cannot send a signed message from a green address since he does not hold the private key of this address.

If this system was abused by an owner of a green address, the checks on this would be similar to the checks on the green addresses themselves: the economic majority would reject this particular green address.

I do not even think that this system would involve any changes to the blockchain or the bitcoin system. It is an independent system which mining pool operators could implement to check the integrity of the block chain and the mining pool operators could also be the ones paying the (small) transaction fees required to make this system work since increasing the trust in bitcoins is in their economic interest. The mining pool operator then checks whether block x+n contains a message from a green address to another address about a transaction occurring in block number x. If it does not, some kind of alarm should go off and actions can be taken from there. The messaged transaction does not even have to be included in a block but it could just be transmitted as a 0 confirmation transaction for the mining pool operator to check the validity of the previously mined blocks.

One probing transaction per block or perhaps even fewer would suffice since a random transaction's entropy is very high.

Some concern could be raised that this idea is not aligned with the decentralized idea of bitcoins and that the operator of a green address could be compromised or be part of the attack but I believe this issue is not much different than the issue of green addresses themselves. If the economic majority deems this green address to be unreliable, the alarm can be ignored.

[Zeilap]

It's an interesting idea, but you've made too many assumptions on the actions of a 51% attacker. Why is it required that they do not include most transactions into their chain? Their competing chain could include every transaction in the honest chain except one (unspending their own coins) and defeat this protection. A 51% attacker cannot spend coins which are not his, all he can do unspend recently spent coins, in particular his own, allowing double spending. If he only ever changes his own transactions, then these canary transactions will never die and no alarm will sound.

[🏰 TradeFortress 🏰]

This pretty much just shifts from trusting the network to trusting arbitrary green addresses.

Not a good idea.

[Sword Smith]

It's an interesting idea, but you've made too many assumptions on the actions of a 51% attacker. Why is it required that they do not include most transactions into their chain? Their competing chain could include every transaction in the honest chain except one (unspending their own coins) and defeat this protection. A 51% attacker cannot spend coins which are not his, all he can do unspend recently spent coins, in particular his own, allowing double spending. If he only ever changes his own transactions, then these canary transactions will never die and no alarm will sound.

Sure but this limits the scope of the destruction that the attacker can wreak plus it protects the network from March 11th style problems. Additionally, it is rather expensive to make a 51% attack so being able to unspend your own coins is likely worth less than it costs to make a 51% attack.

[Sword Smith]

This pretty much just shifts from trusting the network to trusting arbitrary green addresses.

Not a good idea.

This reply does not pass the Turing test. Please read OP if you wish to participate in the discussion.

[jgarzik]

51% attack is the most talked about... the most useless, the most unlikely attack.

The cost of attacking the network, and other attacks, are far less costly and far more damaging.

[astor]

Isn't this more like an continuous integration test?

[Luke-Jr]

Quick assessment IMO:

This sounds similar something the (new) Ripple.com is doing, which creates practical problems with coming to a consensus on their system.

Its dependency on "green addresses" is, as you note, problematic as well, for the same reasons green addresses are themselves flawed.

Finally, it's also incompatible with miners rights to decline processing of any given transaction.

[ChristianK]

It works like this: Trusted parties could send some kind of random amounts of bitcoins from one seemingly random address to another both controlled by the same party or one controlled by another trusted party.

How do the parties establish their trust?

[Sword Smith]

It works like this: Trusted parties could send some kind of random amounts of bitcoins from one seemingly random address to another both controlled by the same party or one controlled by another trusted party.

How do the parties establish their trust?

Have you read about green addresses? Green addresses are owned by entities which have a large interest in being trusted to not double spend their coins. In this way, a dealer can choose to trust the received funds from a green address to not be double spent and he does thus not need to wait for the six confirmations to deliver the purchased product to the customer. Green addresses are owned by the largest bitcoin companies in the community like Mt. Gox.

[Sword Smith]

Its dependency on "green addresses" is, as you note, problematic as well, for the same reasons green addresses are themselves flawed.

Thank you for your answer, Luke.

As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?

Finally, it's also incompatible with miners rights to decline processing of any given transaction.

That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.

[Luke-Jr]

As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?

I don't think it is theoretically possible to get warning prior to 0.6.x and 0.8.x diverging - what would have helped would have been a way to contact people faster (including having the poolserver contact me instead of just logging it and taking a while before I noticed).
As a result of the March 11th events, the major pools have exchanged direct contact information with each other and that information is (I'm pretty sure) available to core developers as well.

Finally, it's also incompatible with miners rights to decline processing of any given transaction.

That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.

That doesn't make sense. The point here is that miners have the right to refuse even transactions from/to widely-trusted parties.
This is an important component to the Bitcoin system.

[Sword Smith]

As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?

I don't think it is theoretically possible to get warning prior to 0.6.x and 0.8.x diverging - what would have helped would have been a way to contact people faster (including having the poolserver contact me instead of just logging it and taking a while before I noticed).
As a result of the March 11th events, the major pools have exchanged direct contact information with each other and that information is (I'm pretty sure) available to core developers as well.

When were you informed about the fork, after or before it became a hard fork (that means +6 confirmations, right?)?

Finally, it's also incompatible with miners rights to decline processing of any given transaction.

That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.

That doesn't make sense. The point here is that miners have the right to refuse even transactions from/to widely-trusted parties.
This is an important component to the Bitcoin system.

Sure, but when you receive some kind of message from a green address though the network you can go back in the block chain and see if it is there. It does not have to be in one specific block it can also be in a block one or two after. Does that make sense?

[Luke-Jr]

As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?

I don't think it is theoretically possible to get warning prior to 0.6.x and 0.8.x diverging - what would have helped would have been a way to contact people faster (including having the poolserver contact me instead of just logging it and taking a while before I noticed).
As a result of the March 11th events, the major pools have exchanged direct contact information with each other and that information is (I'm pretty sure) available to core developers as well.

When were you informed about the fork, after or before it became a hard fork (that means +6 confirmations, right?)?

No, a hardfork occurs the moment an older client rejects a block accepted by newer clients.
Eligius detected it immediately, but it wasn't until sipa was helping some other user experiencing the problem that I thought to check it.

Finally, it's also incompatible with miners rights to decline processing of any given transaction.

That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.

That doesn't make sense. The point here is that miners have the right to refuse even transactions from/to widely-trusted parties.
This is an important component to the Bitcoin system.

Sure, but when you receive some kind of message from a green address though the network you can go back in the block chain and see if it is there. It does not have to be in one specific block it can also be in a block one or two after. Does that make sense?

So what if all miners decide the transaction in question should not be mined?

[TierNolan]

When were you informed about the fork, after or before it became a hard fork (that means +6 confirmations, right?)?

No, hard fork means that the new rules are more lax than the old rules.

So, if the max block size was increased, that is a hard fork, since it allows blocks that were previously disallowed.

A soft fork bans something that was previously allowed.  So, if the max block size was decreased that would be a soft fork.

The difference is how very old clients are handled.

Hard fork
Old clients: Old rules only
New clients: New rules and old rules

This means that if the majority of the hashing power is creating blocks under the new rules, you get a split.  

The new clients follow the new chain, since it has higher POW and the old clients follow the old chain since the new chain has illegal (under the old rules) blocks.

Soft fork
Old clients: New rules and old rules
New clients: New rules only

This means that if the majority of the hashing power is creating blocks under the new rules, you won't get a split.  

Sometimes miners using the old software would create blocks that are illegal under the new rules.  The new clients won't build on them.  Since they have the majority of the hashing power, they will cause the new block to be orphaned.

Old clients would just follow the chain as normal and see a larger orphan rate.

This means that if you propose a soft fork, you can make the change by convincing the majority of the hashing power to accept that change.  All clients can follow the new chain.  Only miners need to update.

The pay to script change was a soft fork.  It had a voting system built in.  If > 55% of miners agreed, the change activated.  This was probably a little low for the majority.  If support subsequently dropped to 45%, then it could cause a fully fledged fork.

[Sword Smith]

As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?

I don't think it is theoretically possible to get warning prior to 0.6.x and 0.8.x diverging - what would have helped would have been a way to contact people faster (including having the poolserver contact me instead of just logging it and taking a while before I noticed).
As a result of the March 11th events, the major pools have exchanged direct contact information with each other and that information is (I'm pretty sure) available to core developers as well.

When were you informed about the fork, after or before it became a hard fork (that means +6 confirmations, right?)?

No, a hardfork occurs the moment an older client rejects a block accepted by newer clients.
Eligius detected it immediately, but it wasn't until sipa was helping some other user experiencing the problem that I thought to check it.

Finally, it's also incompatible with miners rights to decline processing of any given transaction.

That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.

That doesn't make sense. The point here is that miners have the right to refuse even transactions from/to widely-trusted parties.
This is an important component to the Bitcoin system.

Sure, but when you receive some kind of message from a green address though the network you can go back in the block chain and see if it is there. It does not have to be in one specific block it can also be in a block one or two after. Does that make sense?

So what if all miners decide the transaction in question should not be mined?

The alarm is ignored, I guess. But it seems quite unlikely to me that the transaction whould not be included so the warning system should give very few (if any) false alarms thus being of high value.

As I noted, this system is not supposed to be a part of the direct verification of a mined block but instead a separate system used only as an extra warning system that something might be wrong.