Is there a way to make a double spend more expensive?

[monsterer]

In POW a double spender must wait until a merchant accepts his initial payment (at 1 confirmation, say), and then outpace the network to produce a longer fork and the cost is linear in the number of blocks.

Is a way to increase this cost somehow, to make it quadratic, or higher order in the number of blocks?

[1715188532]

1715188532

[1715188532]

1715188532

[1715188532]

1715188532

[teukon]

In POW a double spender must wait until a merchant accepts his initial payment (at 1 confirmation, say), and then outpace the network to produce a longer fork and the cost is linear in the number of blocks.

Is a way to increase this cost somehow, to make it quadratic, or higher order in the number of blocks?

I'm fairly certain this would necessitate difficulty perpetually increasing quadratically (and this would obviously break Bitcoin).  Do you have some idea?

[amaclin]

Is a way to increase this cost somehow?

No. In current bitcoin consensus.

[monsterer]

I'm fairly certain this would necessitate difficulty perpetually increasing quadratically (and this would obviously break Bitcoin).  Do you have some idea?

I was thinking along two different lines:

*) having some kind of implicit difficulty instead of the explicit difficulty of solving a chain of blocks we have right now. so the head block has current network difficulty, and the next previous block has double the difficulty... somehow.

*) having a different explicit linkage between blocks, such that the deeper down the chain you get, the more blocks you have re-hash. this probably requires a totally different blockchain structure tho.

[tonycamp]

this its very high tech of BTC for me i thoughted that double spend only happened when some company got the more that 50% of the mining of all decentrilization

[Delek]

This is why it's recommended to wait for 4 or 5 confirmations for high valued transactions. However, if you sell a coffee with 1 confirmation or even 0 confirmations you are probabilistically ok.

[teukon]

I'm fairly certain this would necessitate difficulty perpetually increasing quadratically (and this would obviously break Bitcoin).  Do you have some idea?

I was thinking along two different lines:

*) having some kind of implicit difficulty instead of the explicit difficulty of solving a chain of blocks we have right now. so the head block has current network difficulty, and the next previous block has double the difficulty... somehow.

*) having a different explicit linkage between blocks, such that the deeper down the chain you get, the more blocks you have re-hash. this probably requires a totally different blockchain structure tho.

I think you ultimately have the problem that no matter how you restructure things, how some parts reference others, and how you weigh everything, it takes a certain amount of work to build the structure.  The attacker would be able to build a competing structure for the same amount of work.  Additionally, the attacker will have an information advantage because the elements of their structure will be built later in time and typically in private.

[jonald_fyookball]

In POW a double spender must wait until a merchant accepts his initial payment (at 1 confirmation, say), and then outpace the network to produce a longer fork and the cost is linear in the number of blocks.

Is a way to increase this cost somehow, to make it quadratic, or higher order in the number of blocks?

The cost isn't really linear.

As Satoshi says, the chances of catching up becoming "vanishingly small", therefore the cost becomes exponentially large.

[jl777]

In POW a double spender must wait until a merchant accepts his initial payment (at 1 confirmation, say), and then outpace the network to produce a longer fork and the cost is linear in the number of blocks.

Is a way to increase this cost somehow, to make it quadratic, or higher order in the number of blocks?

The cost isn't really linear.

As Satoshi says, the chances of catching up becoming "vanishingly small", therefore the cost becomes exponentially large.

It would have to be very expensive coffee for the attacker to do such a thing as they would make a lot more money just by submitting the blocks for the block reward. So in that sense it is quite expensive. and also each block that is mined makes reorging exponentially more expensive as jonald_fyookball states.

The idea of making a double spend more expensive is interesting though. However, since there wont be consensus on all nodes as to whether there even was a double spend (we are talking about the chain reorging here), then I dont see how you can make double spending a specific input require more PoW in a way to achieve global consensus.

Unless...

If there was a separately maintained consensus of all 1 conf transactions (I think it can be proven this cant be done with 0confs), then we would have a global consensus on any attempt to double spend any outputs from this 1 conf list. So theoretically it would be possible to make the weight of any new chain that is attempting to double spend any output from the 1 conf list to be arbitrarily lower.

Just need to maintain a tree of such 1 conf txlists, and each reorg would spawn some sort of alternate 1 conf list. I think it is quite a lot of work, but probably not impossible to do. However, considering this is a hardfork and orders of magnitude more difficult than fixing malleability, it is unlikely that it will ever be done.

James

[monsterer]

The cost isn't really linear.

As Satoshi says, the chances of catching up becoming "vanishingly small", therefore the cost becomes exponentially large.

The cost of producing one block is roughly 25 BTC, the cost of producing N blocks is 25xN BTC - that looks linear in the number of blocks to me?

[teukon]

The cost isn't really linear.

As Satoshi says, the chances of catching up becoming "vanishingly small", therefore the cost becomes exponentially large.

The cost of producing one block is roughly 25 BTC, the cost of producing N blocks is 25xN BTC - that looks linear in the number of blocks to me?

Notice that the attacker will be claiming block rewards as he executes this attack.

The rest of the network does not stand still while the attack is executed.  The attacker may begin N blocks behind but it could take much more than N blocks to catch up.  The expected cost is still linear in N but it is not 25*N BTC.

A cost of 25*N BTC does come into play if we're considering an extreme case: a 100% attack.  In this scenario, the attacker rents all the hashing power in the world and sets it to work on his fork.

If the attacker has less hashing power than the rest of the network combined then he is guaranteed to stay behind in the long term and can only hope to get sufficiently lucky in the short term.  This is the situation in which, as N increases, the probability of a successful attack becomes vanishingly small.

[monsterer]

A cost of 25*N BTC does come into play if we're considering an extreme case: a 100% attack.  In this scenario, the attacker rents all the hashing power in the world and sets it to work on his fork.

Of course - I had forgotten to consider hashing power... so if the attacker has less than 50% hashing power at his disposal, the cost of producing N blocks is exponential in N?

[jonald_fyookball]

The cost to keep trying to attack is linear in time (a 25% network hash rate participant gives up 25 BTC every forty minutes), but the probability of success diminishes exponentially with the length of the reorg, so the expected ROI also diminishes exponentially with regard to the length of the reorg.

[teukon]

A cost of 25*N BTC does come into play if we're considering an extreme case: a 100% attack.  In this scenario, the attacker rents all the hashing power in the world and sets it to work on his fork.

Of course - I had forgotten to consider hashing power... so if the attacker has less than 50% hashing power at his disposal, the cost of producing N blocks is exponential in N?

If the attacker has less than 50% of the network's total hashing power then the probability that they will eventually catch up from N blocks behind falls exponentially with N.  To find a suitable cost you'd have to specify the attacker's strategy in more detail.  If, for example, the attacker never gives up, then their expected cost would be infinite for all N >= 1.