Bitcoin Forum
September 23, 2025, 05:19:18 AM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Why doesn't transaction confirmation depend on accumulated miner reward? on: August 25, 2017, 06:49:32 AM
If I'm the mining pool that originally mined block 2, then I have no incentive to mine the replacement block 1 (since I won't get the reward for it).  If I operate a mining pool that didn't solve any of the 6 blocks, then I have no incentive to participate in the attack at all (since I won't get any reward).
If i am the pool that originally mined block 2, then i will get compensated for the lost reward by the double spending transaction, no matter who mines the first attacking block that contains it. In the refined attack, the compensation for the lost rewards is included into the double spending transaction. This compensation is taken from the original amount of 1000 BTC. If someone else mines the first attacking block, i get the compensation from the transaction and the other miner gets the standard block reward and fees and on top of it some fraction of the excessive fee (also taken from the 1000 BTC). He passes on some of the excessive fees to keep the chain more profitable than the original chain. But he got more than he would have gotten on the original chain, because there is no excessive fee available on it.

Graphical version: https://drive.google.com/open?id=0B09kXol8QHGgc2RFMkxjT28xT1E
2  Bitcoin / Development & Technical Discussion / Re: Why doesn't transaction confirmation depend on accumulated miner reward? on: August 24, 2017, 06:49:39 PM
Then I misunderstood how the attack works.

In order for this to work without a colluding cartel, I assumed that, given a block with a 1000BTC transaction at height X, you would create a chain of 7 transactions that spend at least one of the same inputs, each pay a transaction fee greater than 12.5 BTC, and each have a sequential locktime beginning at X?

In that way, a miner (or pool) has an incentive to mine a competing block with the new transaction at height X that will pay a greater reward than they would have received by mining at block height X+6 (assuming they believe that this competing chain has a high probability of eventually surpassing the chain that is currently at height X+6).

You had said that "they can come up with a solution where they share some of the rewards".  That sounds a lot like "colluding cartel" to me.

Miners that don't want to be cheated are monitoring the list of blocks that are solved by their pool to make sure that they get their share of the transaction fees.  If the pool needs to "share some of the rewards" with other pools, then they'll need to let their participants know they are doing this (and the participants will want to know why), or they will lose participants that are angry that the pool isn't paying out what it should given the revenue that it has earned.

Maybe the attack needs some refinement. Lets say that the transaction that double spents immediately pays compensation for the rewards of the 6 original blocks to the same addresses. So there is a guarantee that nobody looses rewards in the case that the attacking chain wins. So these rewards can be payed out to miners even if the original 6 blocks get abondened. Furthermore the transaction adds a one time excessive fee. Now you have to decide which chain to extend. The original chain with standard block rewards and fees, or the attacking chain with standard block rewards, but excessive fees. So you extend the attacking chain. Also you pass some of the excessive fees to the next block, because you want all other miners to further extend the attacking chain. Because all lost mining rewards from the original chain were already compensated for on the atacking chain, there is no benefit in mining the original chain. In terms of rewards, both chains have the same length. Miners don't extend the longest chain, because of an arbitrary number, but because their rewards are trapped in it. It is the excessive fee (that must be partially passed to the next block) that makes the attacking chain more profitable. If everybody mines the original chain, the bribe is lost. If everybody mines the attacking chain there is some expected additional profit (and you are guaranteed not to loose your rewards). The collusion is implicit and does not need coordination (assuming all miners want to maximize their profit). No miner looses block rewards. They get the compensation for the lost blocks and profit from the excessive fee.

I still think, there is a connection between security and accumulated miner rewards. Why would you choose not to mine the attacking chain?
3  Bitcoin / Development & Technical Discussion / Re: Why doesn't transaction confirmation depend on accumulated miner reward? on: August 24, 2017, 02:43:36 PM
Quote
During the time that your malicious mining cartel is trying to find 7 blocks to collect your reward, the rest of the global hashpower is continuing to extend the original 6 block chain.
But the attack is designed to work without a colluding cartel. It is in the interest (considering mining rewards) of every single miner to extend the attacking chain. If someone extends the original chain, then he does not understand how to maximize his profit. The victim allowed this (100%) attack because of his behavior.

Quote
Furthermore, mining pools that participate in this behavior would somehow need to publicly convince all of their thousands of mining participants to voluntarily cooperate with this fraud (in which case everyone would be aware of it, and transaction recipients would know to wait for MANY more blocks before accepting a transaction as confirmed).
The attack does not need to be announced in advance. Are miners really checking what they are actually doing for their pool? The pool decides what maximizes profit. All they would see is, that they are trying to mine a block with a lower height. So recipients should adjust their behavior now.

Quote
If they tried to coordinate secretly, then the participants in the pools would notice that the winning pools in the attack were collecting much more in transaction fees than they were sharing with their users.  As such, the users would abandon the pools for cheating them out of revenue, and the mining cartel wouldn't have enough hash power to pull off the attack.
Mining pool operators could pay compensation for the lost block rewards on the original chain. So as a miner your expected payout is higher on pools that participate in the attack. And as said above, every pool and every miner has an incentive to participate.

The attack is not designed to be actually carried out. It is designed to question the behavior of current recipients.
4  Bitcoin / Development & Technical Discussion / Re: Why doesn't transaction confirmation depend on accumulated miner reward? on: August 24, 2017, 02:08:34 PM
Quote
I don't think most miners would accept double spend transactions but for the sake of simplicity, we shall assume that they will.
Shouldn't we always assume that they are only acting selfishly?

Quote
For starters, for this to work, miners will have to have a private chain within themselves. They have to mine and broadcast the blocks to each other before they can broadcast it to the network. Them broadcasting it to the network will result in nodes rejecting the new blocks since there is a longer chain with longer proof of work. Hence, you need the miners (at least 51% of them) to cooperate with you before the attack starts.
I think miners are already well connected. They can broadcast arbitrary blocks to each other for the others to decide how to react. These blocks are not invalid, they are orphans that arrive few blocks late. There is a possible future where they are part of the longest valid chain. And if there is an orphan that promises higher expected reward than the current chain, we should expect miners to mine on top of it. There is no coordination necessary. Sure, their current software might not be able to identify the expected additional reward. Or it is set up to ignore it. But it might as well accept the bribe.

Quote
Once they overtake the other chain, they broadcast their chain. By this time, majority of the community would have already realised that there is a successful 51% attack. Media outlets starts shouting and the price starts tanking. Next thing they know, their ASICs are completely worthless, together with their future income.
Its arguable that they can spend their 100BTC per block of additional fees and expect good profits but honestly, once they broadcast their chain, they have very very little time before the price crashes down.
Miners can minimize the effect on everybody else by inserting all other transactions at the same block height. No other transaction would be lost or even changed. The victim might be someone not well known (unknown?) or with bad reputation. After all, no rule was broken. The blockchain is valid. Code is law. The victim made the error of accepting a transaction as final, before it was safe to do so. Everybody must decide for himself when to accept a transaction as final. No one will come for rescue.

My point is, that the current behavior of accepting a (large) transaction as final after 6 (or any fixed number) of blocks is flawed, because it allows this type of attack. It is not a weakness in the protocol, but in the behavior of its users.
5  Bitcoin / Development & Technical Discussion / Why doesn't transaction confirmation depend on accumulated miner reward? on: August 24, 2017, 08:19:06 AM
Edit: Modified attack: https://bitcointalk.org/index.php?topic=2115635.msg21171230#msg21171230, Image: graphical version

Lets say i deposit 1000 BTC to an exchange that accepts the deposit after 6 confirmations. I immediately convert and withdraw in another currency. I am totally free to create an alternative transaction chain starting from the original block with 7 transactions that each pay a high fee (lets say 50 BTC) and that can not be mined in a single block, but only in a chain of 7 consecutive blocks (using nLockTime). I then publish this transaction chain to all miners. Even considering the loss of rewards from the original 6 blocks, the expected reward for the miners is higher, when they discard the original chain and start mining a new chain with my transactions.

Obviously my transactions will not be accepted by regular nodes, but i could communicate them to the miners directly.

If a very small miner got one of the original 6 blocks, his expected reward after switching might be less than what he already got. But i can wait for a situation where only large pools mined the original 6 blocks, that have a large enough probability to profit on my excessive fees.

Miners might fight for the blocks that contain my excessive fees. But they can come up with a solution where they share some of the rewards and it is always more profitable to extend the attacking chain.

The exchange might start to offer a fee reward on the original chain. But every reward it pays is a loss. And i am free to pay the full 1000 BTC. In the end I gained nothing, but forced a transfer from the exchange to the miners. They might want to start this kind of attack.

So, how is it save to accept a large transaction (a block that moved thousands of BTC) as final, before the same amount (some fraction?) was paid in miner rewards? Every moved coin is possibly available to bribe miners to construct an alternative chain.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!