Author

Topic: How to frustrate a miner. (Read 5546 times)

legendary
Activity: 3766
Merit: 1364
Armory Developer
October 18, 2013, 05:14:14 AM
#20
The attack works by bribing miner to orphan certain blocks, it is not A against B but building coalitions to claim the bribe.

I think that the attack is technically valid but participating in it by any of the miner depends on if they are  greedy, especially short term greedy. Accepting the bribe brings higher profit in short term, but diminishes the value of their coins and investment on the longer term, since it hurts credibility of the entire system.

I listed A against B scenarios because they are realistic. Your point is that if A wants to harass B, he can bribe third parties to his cause. My point is if A and B have equivalent resources, both A and B can perform the same bribe attack onto each other, which will nullify the attack and just cost each some extra BTC.

Stepping out of that scenario, if A is huge compared to the network, A won't need to bribe any of the third parties to harass B. If A only has a small fraction of the hashing power within the network, then the attack can be mitigated in a way that it would increase its cost, which will most likely deter an attacker of such small size.

Bottom line, the attack is technically feasible and but not economically viable.
hero member
Activity: 836
Merit: 1030
bits of proof
October 18, 2013, 12:47:59 AM
#19
The attack works by bribing miner to orphan certain blocks, it is not A against B but building coalitions to claim the bribe.

I think that the attack is technically valid but participating in it by any of the miner depends on if they are  greedy, especially short term greedy. Accepting the bribe brings higher profit in short term, but diminishes the value of their coins and investment on the longer term, since it hurts credibility of the entire system.
legendary
Activity: 3766
Merit: 1364
Armory Developer
October 17, 2013, 04:25:52 PM
#18
This looks overkill to me. What realistic scenario is there that would implement this attack? Assume miner A is going after miner B:

1) If A and B have about the same hashing power (thus the same funds available to them), if A attacks B this way, B can simply return the attack in kind, nullifying it.

2) If A is a huge miner and thus dwarfs B, they don't need such sophistication. They can just refuse B's blocks at a lower cost (without implementing the attack) and simply overwhelm them by chaining a couple blocks. It is safe to assume the rest of the network doesn't want to be involved in such a feud and will quickly side with the big miner as they'd rather not waste processing power over a block they know has a high chance of being orphaned. At this point a monetary incentive is overkill, the big miner can simply rule by terror. This is why hash rate distribution is so important to the Bitcoin network.

3) If A has lots of funds but low hashing power, they're better off just purchasing hashing power that trying this move.

4) Leaves the last situation where A overpowers B, but isn't strong enough to sway the whole network their way. It then becomes a matter of endurance. How long can an attacker last, and how much is it going to cost in fees, realistically?

If I was a miner being attacked in this fashion, I'd make a list of all their coinbase addresses and simply ban all coins finding their origin in those coinbase txn. I will then gradually ban txn that are linked to this user, eventually compiling a black list of attacker controlled coins, mitigating the attack.

In return the attacker will use a large amount of txns to try and squeeze one in the blocks I'm mining. As long as I have not mined a block, they would have no way to know which of their txns have gone through my ban list, forcing them to maintain this approach for the rest of the attack, which would end in a drawn out, long term battle, with easily identifiable parties, which would further allow me to ban txns based on the node they originated from.

The more I mitigate the attack, the more expensive it gets on the attacker. This cost needs to be compared to the projected profitability to the attacker.
member
Activity: 68
Merit: 10
October 17, 2013, 09:10:15 AM
#17
yes right, even noticing it would give no chance in preventing it, as the "legit" block is not recognisable.
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 09:03:36 AM
#16
Anyone-Can-Spend outputs may look like an ordinary transaction, just use the address of an easy to guess brain wallet.

Or even hard to guess, and it would be spread only to some pools with a decent share of the hash rate, building a network of invisible corruption.

Could this be observed by searching blocks with same block-hight for suspicious outputs.
The observable sign would be transaction replacement at re-org. They could be the bribe paid to make the other block orphan.
If I wasn't busy or there would be an upside to it I'd scan if this is already happening.
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 09:01:44 AM
#15
Anyone-Can-Spend outputs may look like an ordinary transaction, just use the address of an easy to guess brain wallet.

Or even hard to guess, and it would be spread only to some pools with a decent share of the hash rate, building a network of invisible corruption.

Could this be observed by searching blocks with same block-hight for suspicious outputs.
The observable sign would be transaction replacement at re-org. They could be the bribe paid to make the other block orphan.
member
Activity: 68
Merit: 10
October 17, 2013, 08:53:17 AM
#14
Anyone-Can-Spend outputs may look like an ordinary transaction, just use the address of an easy to guess brain wallet.

Or even hard to guess, and it would be spread only to some pools with a decent share of the hash rate, building a network of invisible corruption.

Could this be observed by searching blocks with same block-hight for suspicious outputs.

edit: actually the input would be suspicious, and the output conflicting, right?
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 08:21:56 AM
#13
Anyone-Can-Spend outputs seem to be the issue. Isn't that output's only intention to sacrifice funds in a provable way? what about sending those funds to Satoshi instead? Wink
Anyone-Can-Spend outputs may look like an ordinary transaction, just use the address of an easy to guess brain wallet.
In the described attack the output's intention is to bribe miner to participate in censorship.
member
Activity: 68
Merit: 10
October 17, 2013, 08:10:34 AM
#12
that's a real issue.

a rational miner is prone to corruption. It favours profit over building the longest chain.

Anyone-Can-Spend outputs seem to be the issue. Isn't that output's only intention to sacrifice funds in a provable way? what about sending those funds to Satoshi instead? Wink
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 07:58:13 AM
#11
The attack needs to be launched successfully only a couple times and other miner will stop building on the disliked miner's block since those carry high risk to be orphaned.

Maybe it is not even the miner that one targets but a certain type of transaction or address used in the block. Soon the rational miner will be trained to obey the rules of a censor with deep pocket.

Can transactions remain free if miner become "rational" ?
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 07:24:33 AM
#10
How is this different than adding a big fee to a transaction?
A big fee could be claimed by embedding its into the next block.
This bounty can only be claimed by orphaning the disliked block and it does not cost anything to the attacker if not claimed.
sr. member
Activity: 426
Merit: 250
October 17, 2013, 07:17:34 AM
#9
How is this different than adding a big fee to a transaction?

I developed the following attack while discussing https://bitcointalksearch.org/topic/feather-forks-enforcing-a-blacklist-with-sub-50-hash-power-312668
Let me summarize it for a more targeted feedback if it would work:

Assume somebody is determined to frustrate a miner.

He prepares the attack by sending a sizable amount to his own new address. He repeats for every block. The transactions might build a chain, but do not have to.

As the disliked miner creates a block containing any of his prepared transactions he launches the attack by creating a transaction double spending that transaction to a script trivially redeemable and sending it to other miner.

Assuming miner act rationally and the trivially redeemable output is of tempting size, they will start working on a block parallel to that of the disliked miner and include the double spend and a transaction redeeming it to their own address.

If repeated the disliked miner will not be able to get a block to the trunk, hence no revenue.

legendary
Activity: 1120
Merit: 1038
October 17, 2013, 07:13:21 AM
#8
I really do not understand it. Can someone convert Bitcoinian into English ?
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 05:57:24 AM
#7
That is a great way to get rid of your Bitcoins Wink

I don't think many people could afford to do that.
It is not about me. Assume a big miner or cartel of them wants to get rid of a newcomer.
b!z
legendary
Activity: 1582
Merit: 1010
October 17, 2013, 05:55:58 AM
#6
That is a great way to get rid of your Bitcoins Wink

I don't think many people could afford to do that.
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 05:49:47 AM
#5
Yes, the attack does cost money, but less than the damage it would make to the bottom line of the disliked miner.

It is not viable at the moment since miner are not "rational" but using the standard client that has no notion of trivially redeemable transactions.

I raise this not because want to be a douchebag, but to discuss if Bitcoin can be hardened to cope with the attack or if it needs alturism to avert this.
hero member
Activity: 490
Merit: 500
UNDER NEW MANAGEMENT
October 17, 2013, 05:44:04 AM
#4
let the OP carry on, let him spend his funds with each transaction deducting the fee.

slowly making the OP poorer and the miners richer..

So true.. We should thank the OP for wasting all his monies Cheesy
legendary
Activity: 4410
Merit: 4766
October 17, 2013, 05:42:58 AM
#3
let the OP carry on, let him spend his funds with each transaction deducting the fee.

slowly making the OP poorer and the miners richer..
hero member
Activity: 490
Merit: 500
UNDER NEW MANAGEMENT
October 17, 2013, 05:39:18 AM
#2
I developed the following attack while discussing https://bitcointalksearch.org/topic/feather-forks-enforcing-a-blacklist-with-sub-50-hash-power-312668
Let me summarize it for a more targeted feedback if it would work:

Assume somebody is determined to frustrate a miner.

He prepares the attack by sending a sizable amount to his own new address. He repeats for every block. The transactions might build a chain, but do not have to.

As the disliked miner creates a block containing any of his prepared transactions he launches the attack by creating a transaction double spending that transaction to a script trivially redeemable and sending it to other miner.

Assuming miner act rationally and the trivially redeemable output is of tempting size, they will start working on a block parallel to that of the disliked miner and include the double spend and a transaction redeeming it to their own address.

If repeated the disliked miner will not be able to get a block to the trunk, hence no revenue.


Sounds like a good way to be a complete douchebag...  Roll Eyes

But thankyou for the TX Fees dude Cheesy
hero member
Activity: 836
Merit: 1030
bits of proof
October 17, 2013, 05:36:29 AM
#1
I developed the following attack while discussing https://bitcointalksearch.org/topic/feather-forks-enforcing-a-blacklist-with-sub-50-hash-power-312668
Let me summarize it for a more targeted feedback if it would work:

Assume somebody is determined to frustrate a miner.

He prepares the attack by sending a sizable amount to his own new address. He repeats for every block. The transactions might build a chain, but do not have to.

As the disliked miner creates a block containing any of his prepared transactions he launches the attack by creating a transaction double spending that transaction to a script trivially redeemable and sending it to other miner.

Assuming miner act rationally and the trivially redeemable output is of tempting size, they will start working on a block parallel to that of the disliked miner and include the double spend and a transaction redeeming it to their own address.

If repeated the disliked miner will not be able to get a block to the trunk, hence no revenue.
Jump to: