"Dirty Deals in Smoke-Filled Rooms" J. Ranvier discusses a Mike Hearn proposal

[justusranvier]

Secondly - if I read it correctly, this doesn't affect the fungible nature of Bitcoin, does it? It does not allow for arbitrary blocking of transactions or theft of coins, nor does it "taint" an ouput. Is this understanding correct? Does it not just allow for reallocation of the coinbase?

The proposal is theft of coins.

The Bitcoin protocol right now has no built in mechanism via which a third party can reassign a balance.

If such a mechanism is ever added to Bitcoin, then Bitcoin is worthless. It doesn't matter how little they promise to use it (at first).

When it comes to the question of, "under what circumstances can miners vote to confiscate funds on the blockchain," the difference between "never" and "rarelty" is infinitely greater than the difference between "rarely" and "frequently". Biitcoin only has value if the answer to the question is "never".

[1715131311]

1715131311

[1715131311]

1715131311

[1715131311]

1715131311

[1715131311]

1715131311

[Peter R]

It is NOT an outrageous idea that 'criminal' are held to account.  It is NOT and outrageous idea that solutions contain design elements which facilitate this.  It is, in fact NOT an outrageous idea that the Bitcoin protocol evolves such elements in order to 'fight crime'.  They would be hugely effective at solving this very real problem.

I don't think many people would argue that we shouldn't fight crime.  By all means, if a miner operates an out-of-band double-spend service and knowingly aides people in defrauding others, then they've committed a crime.  Most jurisdiction around the world have laws to deal with fraud.  

Do I think the protocol should be changed?  Absolutely not!  My resolve here is hardened by my belief that any heterogeneity added to the protocol would actually make it less secure for everyone.  Not only would it not help with fraud, IMO it would actually make fraud easier.    

Bitcoin is powerful because it is useful.  It is therefore useful both for good and for bad, by definition.  Any attempt to make it less useful for bad will also make it less useful for good.  

[murraypaul]

Secondly - if I read it correctly, this doesn't affect the fungible nature of Bitcoin, does it? It does not allow for arbitrary blocking of transactions or theft of coins, nor does it "taint" an ouput. Is this understanding correct? Does it not just allow for reallocation of the coinbase?

The proposal is theft of coins.

The Bitcoin protocol right now has no built in mechanism via which a third party can reassign a balance.

Speaking specifically of the coinbase only, that isn't really true, is it?
Miners can already attempt to deliberately orphan a block, which would have the same effect of removing the coinbase allocation.

[Peter R]

Secondly - if I read it correctly, this doesn't affect the fungible nature of Bitcoin, does it? It does not allow for arbitrary blocking of transactions or theft of coins, nor does it "taint" an ouput. Is this understanding correct? Does it not just allow for reallocation of the coinbase?

The proposal is theft of coins.

The Bitcoin protocol right now has no built in mechanism via which a third party can reassign a balance.

Speaking specifically of the coinbase only, that isn't really true, is it?
Miners can already attempt to deliberately orphan a block, which would have the same effect of removing the coinbase allocation.

If a block gets orphaned, then its associated coinbase is simply unusable.  Nothing was re-assigned.  

If you create a mechanism where outputs assigned to a particular bitcoin address can be moved without an ECDSA signature produced by the corresponding private key, then this is coin confiscation.  The legitimacy of the blockchain ledger would be severely shaken (and IMO eventually destroyed).   

[5flags]

Bitcoin is powerful because it is useful.  It is therefore useful both for good and for bad, by definition.  Any attempt to make it less useful for bad will also make it less useful for good.  

This is why I've always been against tainting or blacklisting coins. Transactions must be cast in stone (assuming no orphaning etc), this is fundamental. If there is a theft, then there is a theft. But the coinbase is subtly different...isn't it?

I guess what I'm trying to understand is this: Finney attacks as a service are an entirely predictable reality. What response should there be? Is Mike's proposal any more likely to be abused than a mining pool providing double spends as a service?

[murraypaul]

Secondly - if I read it correctly, this doesn't affect the fungible nature of Bitcoin, does it? It does not allow for arbitrary blocking of transactions or theft of coins, nor does it "taint" an ouput. Is this understanding correct? Does it not just allow for reallocation of the coinbase?

The proposal is theft of coins.

The Bitcoin protocol right now has no built in mechanism via which a third party can reassign a balance.

Speaking specifically of the coinbase only, that isn't really true, is it?
Miners can already attempt to deliberately orphan a block, which would have the same effect of removing the coinbase allocation.

If a block gets orphaned, then its associated coinbase is simply unusable.  Nothing was re-assigned.  

The old block's coinbase is unusable. The new replacement block get a coinbase.
The exact coinbase hasn't been reallocated, but 25 BTC have been taken from one miner, and 25BTC have been given to another.
The financial result is the same as if the original BTC were reallocated, even if the technical details are different.

[LiteCoinGuy]

tl;dr version

• Mike Hearn proposes to let miners vote on "reallocation" of blocks with double spends attempts
• Multiple others point out that this would let the miners vote to "reallocate" any block they wanted to. Examples of many different ways of abusing that mechanism cited
• Mike says "hey you guys don't understand!" in as many different ways he can, and also "bitcoin is a failure if my idea doesn't work!" with enthusiastic/well meaning cadence
• TierNolan and gmaxwell discuss using side-chains of various designs to mitigate the problem in the only usage case that is affected (in person payments)

In summary, Mike proposes a pernicious and controversial mechanism, and no-one agrees that that's the way to solve the problem of offering double spending as a service. Mike tries hard to suggest it's not controversial or pernicious, and no-one agrees with that either.

Case closed. (file under "Mike Hearn - controversial proposals")

best summary  (agree)

[justusranvier]

The financial result is the same as if the original BTC were reallocated, even if the technical details are different.

Those mere technical details are in fact the relevant difference.

Doing a sufficient amount of work to orphan part of the chain has a high cost associated with it. Holders of Bitcoin can calculate the risk losing their funds due to a reorg because that cost can be calculated.

When you allow miners to confiscate generation outputs with a mere vote instead of via the proof of work process it becomes easier to do, therefore it will be used more often.

It also most certainly will not stop with confiscating the rewards of "bad" miners. Of course that's just the small end of the wedge. Once voting by miners, as opposed to producing the valid ECDSA signatures, is established as a legitimate way of editing the ledger, then the path will be cleared to enable all sorts of other editing.

This is exactly how to destroy Bitcoin - by taking away its most important advantage it holds over legacy currencies.

[Peter R]

Bitcoin is powerful because it is useful.  It is therefore useful both for good and for bad, by definition.  Any attempt to make it less useful for bad will also make it less useful for good.  

I guess what I'm trying to understand is this: Finney attacks as a service are an entirely predictable reality. What response should there be? Is Mike's proposal any more likely to be abused than a mining pool providing double spends as a service?

Firstly, I think we need to accept that P_0-confirm will never be 0.  It is simply not possible for the entire world to come to consensus one every transaction in less than a second. 

That being said, how can we minimize the success rate of double-spend attempts?  The answer is to make it easier to come to consensus!  This means that miners and nodes should accept into mempool and relay all valid transactions.  This means that miners should build on top of the longest chain in all circumstances.  This means that protocol rules should be simple and codified. 

Fraud is a crime committed by humans.  It should be fought at the social level.  If a user double-spends against a merchant, how is this different than someone passing off a fake $20?  If a mining service assists a user to double-spend, then how is this different that a counterfeiting cartel selling fake bills at a discount?  We already have mechanisms to fight fraud.   

Is Mike's proposal any more likely to be abused than a mining pool providing double spends as a service?

Q: Why does it take so long for a wire transfer or a cheque to clear in the legacy financial system?  A: Because there is so much complexity in the protocol and consensus mechanism.  Adding more complexity to the bitcoin protocol (i.e., implementing Mike's proposal) will make bitcoin slower and less secure. 

[windpath]

tl;dr version

• Mike Hearn proposes to let miners vote on "reallocation" of blocks with double spends attempts
• Multiple others point out that this would let the miners vote to "reallocate" any block they wanted to. Examples of many different ways of abusing that mechanism cited
• Mike says "hey you guys don't understand!" in as many different ways he can, and also "bitcoin is a failure if my idea doesn't work!" with enthusiastic/well meaning cadence
• TierNolan and gmaxwell discuss using side-chains of various designs to mitigate the problem in the only usage case that is affected (in person payments)

In summary, Mike proposes a pernicious and controversial mechanism, and no-one agrees that that's the way to solve the problem of offering double spending as a service. Mike tries hard to suggest it's not controversial or pernicious, and no-one agrees with that either.

Case closed. (file under "Mike Hearn - controversial proposals")

Great analysis. There really is no "problem" with double spend attempts other then that they are rejected by the network as intended.

[5flags]

Firstly, I think we need to accept that P_0-confirm will never be 0.  It is simply not possible for the entire world to come to consensus one every transaction in less than a second. 

Agreed.

Fraud is a crime committed by humans.  It should be fought at the social level.  If a user double-spends against a merchant, how is this different than someone passing off a fake $20?  If a mining service assists a user to double-spend, then how is this different that a counterfeiting cartel selling fake bills at a discount?  We already have mechanisms to fight fraud.

Yes, fraud is a social problem. But what is Bitcoin, if not a technological solution to a social problem (i.e. the need to transact securely and freely)?

[Peter R]

The financial result is the same as if the original BTC were reallocated, even if the technical details are different.

Those mere technical details are in fact the relevant difference.

Doing a sufficient amount of work to orphan part of the chain has a high cost associated with it. Holders of Bitcoin can calculate the risk losing their funds due to a reorg because that cost can be calculated.

When you allow miners to confiscate generation outputs with a mere vote instead of via the proof of work process it becomes easier to do, therefore it will be used more often.

It also most certainly will not stop with confiscating the rewards of "bad" miners. Of course that's just the small end of the wedge. Once voting by miners, as opposed to producing the valid ECDSA signatures, is established as a legitimate way of editing the ledger, then the path will be cleared to enable all sorts of other editing.

This is exactly how to destroy Bitcoin - by taking away its most important advantage it holds over legacy currencies.

What I highlighted in bold is key.  To spend an output, one must produce a valid ECDSA signature.  If it ever becomes possible to spend ("reassign") outputs without a valid ECDSA signature but with a vote instead, then the legitimacy of the blockchain ledger is lost.  Any balance would be subject to confiscation by popular opinion (tyranny of the majority). 

[murraypaul]

Bitcoin is powerful because it is useful.  It is therefore useful both for good and for bad, by definition.  Any attempt to make it less useful for bad will also make it less useful for good.  

I guess what I'm trying to understand is this: Finney attacks as a service are an entirely predictable reality. What response should there be? Is Mike's proposal any more likely to be abused than a mining pool providing double spends as a service?

Firstly, I think we need to accept that P_0-confirm will never be 0.  It is simply not possible for the entire world to come to consensus one every transaction in less than a second. 

That being said, how can we minimize the success rate of double-spend attempts?  The answer is to make it easier to come to consensus!  This means that miners and nodes should accept into mempool and relay all valid transactions.  This means that miners should build on top of the longest chain in all circumstances.  This means that protocol rules should be simple and codified. 

The likely way forward to provide merchants more security for 0-conf transactions would seem to be a service offered by a collection of large mining pools, where the merchant could submit a transaction, and receive the following guarantees:
- We have not seen a conflicting transaction
- We will accept your transaction
- We will not replace it with any conflicting transaction
- We will relay your transaction to all of our peers
- We will include your transaction in our next block
(Controversially, if the merchant pays extra)- If a block is created with a conflicting transaction, we will not build off it, but will work to orphan it and include your transaction in our replacement block

If enough hashing power agrees to offer guarantees like that, it would be in the interests of all other miners not to mine a conflicting transaction either, to avoid being orphaned.

[Peter R]

Bitcoin is powerful because it is useful.  It is therefore useful both for good and for bad, by definition.  Any attempt to make it less useful for bad will also make it less useful for good.  

I guess what I'm trying to understand is this: Finney attacks as a service are an entirely predictable reality. What response should there be? Is Mike's proposal any more likely to be abused than a mining pool providing double spends as a service?

Firstly, I think we need to accept that P_0-confirm will never be 0.  It is simply not possible for the entire world to come to consensus one every transaction in less than a second.  

That being said, how can we minimize the success rate of double-spend attempts?  The answer is to make it easier to come to consensus!  This means that miners and nodes should accept into mempool and relay all valid transactions.  This means that miners should build on top of the longest chain in all circumstances.  This means that protocol rules should be simple and codified.  

The likely way forward to provide merchants more security for 0-conf transactions would seem to be a service offered by a collection of large mining pools, where the merchant could submit a transaction, and receive the following guarantees:
- We have not seen a conflicting transaction
- We will accept your transaction
- We will not replace it with any conflicting transaction
- We will relay your transaction to all of our peers
- We will include your transaction in our next block
(Controversially, if the merchant pays extra)- If a block is created with a conflicting transaction, we will not build off it, but will work to orphan it and include your transaction in our replacement block

If enough hashing power agrees to offer guarantees like that, it would be in the interests of all other miners not to mine a conflicting transaction either, to avoid being orphaned.

This is (sort of¹) how bitcoin already works except the merchant receives this "service" by default.  And this is why even 0-confirm double-spend attempts careful crafted to game mempool acceptance heterogeneity still only succeed with a small probability.  

I think most people who want to "fix" bitcoin don't realize how secure it already is!


¹Bitcoin is more secure and not as convoluted.

[Peter R]

I wanted to add a note to new readers:

At any time, I can modify the bitcoin source code to allow me to spend your coins.  But since no one else will agree to use this source code, my transactions will only be accepted by my node.  If I mine a block where I spend your coins, then the network will reject my block (and I'll also lose the 25 BTC coinbase award).  I could keep mining on my "Peter R" fork, and in fact could award myself 1,000 BTC block rewards, but if no one wants to play by my rules, then doing so would be pretty pointless.  

The point is that no one can force a change to bitcoin.  Only simple changes with extremely broad support would ever be adopted because the process is entirely voluntary.  We'll never agree on something like re-assignment of balances by popular opinion and even if enough people supported it (and they won't), the network would fork and we'd have two coins: (1) confiscation coin, and (2) bitcoin.  If you had 10 BTC at the time of the fork, you'd control 10 BTC on the bitcoin chain and 10 BTC on the confiscation-coin fork.


Just look at how long it took us all to agree that the new unit should be 10^-6 BTC and that it should be called "bits"!

[murraypaul]

The likely way forward to provide merchants more security for 0-conf transactions would seem to be a service offered by a collection of large mining pools, where the merchant could submit a transaction, and receive the following guarantees:
- We have not seen a conflicting transaction
- We will accept your transaction
- We will not replace it with any conflicting transaction
- We will relay your transaction to all of our peers
- We will include your transaction in our next block
(Controversially, if the merchant pays extra)- If a block is created with a conflicting transaction, we will not build off it, but will work to orphan it and include your transaction in our replacement block

If enough hashing power agrees to offer guarantees like that, it would be in the interests of all other miners not to mine a conflicting transaction either, to avoid being orphaned.

This is (sort of¹) how bitcoin already works except the merchant receives this "service" by default.  And this is why even 0-confirm double-spend attempts careful crafted to game mempool acceptance heterogeneity still only succeed with a small probability.  

I think most people who want to "fix" bitcoin don't realize how secure it already is!
¹Bitcoin is more secure and not as convoluted.

There is no guarantee that a transaction will be included in the next block.
And 3-4 are assumed to be default behaviour, but not required?
Plus, the merchant currently only receives the 'service' from the node they submit to. Receiving it simultaneously from pools covering say 60% of hashing power is a much more powerful guarantee.

[snarlpill]

I wasn't able to read through the whole thread at the moment, but is there really a problem with double-spends and the BTC network? I've never had any occur, or seen any myself.

[Peter R]

There is no guarantee that a transaction will be included in the next block.

There cannot be a guarantee that a transaction will be included in the next block unless you control 100% of the hash power. 

And 3-4 are assumed to be default behaviour, but not required?

I don't follow. 

Plus, the merchant currently only receives the 'service' from the node they submit to. Receiving it simultaneously from pools covering say 60% of hashing power is a much more powerful guarantee.

Merchants can already estimate the % of the network that has accepted a transaction into mempool by employing a well-connected listening node.  The "service" of finding out if a peer has TX1 (or a conflicting variant TX2) in mempool is just one of the perks of being a node lol.


If most of the network has accepted TX1 into mempool, then most likely it will be TX1 that gets mined.  If 10% of the hashpower has TX2 in mempool then the probability that TX2 gets confirmed (instead of TX1) is approximately 10%. 

[Peter R]

I wasn't able to read through the whole thread at the moment, but is there really a problem with double-spends and the BTC network? I've never had any occur, or seen any myself.

Here's an example of one of the possible issues:

Right now, Miner E controls 10% of global hash power and will not accept TXs that spend outputs to certain on-chain gambling sites, while most other nodes and miners accept and relay all valid TXs.  

As Peter Todd demonstrated, if a fraudster wants to attempt to double-spend a 0-confirm TX, then he can create a TX that pays 0.1 BTC to a merchant and 0.001 BTC to an on-chain gambling site.  This TX will be accepted by 90% of the network hashpower (rather than almost 100% if he hadn't included the 0.001 BTC to the gambling site).  

Next, the fraudster receive the merchandise from the store, goes to his car (before the TX is confirmed) and broadcasts a new TX that double-spends those coins to an address that he controls.  Most nodes and miners reject it, but Miner E accepts this into mempool (b/c they don't perceive it to be a double spend).  Since Miner E controls 10% of the global hash rate, he succeed in defrauding the merchant approximately P = 10% of the time.  

If we assume that F = 5% of the population attempts to double-spend at every opportunity and has the capacity to game the mempool heterogeneity, then the total losses due to zero-confim fraud are:

   losses = F x P = 0.1 x 0.05 = 0.5%

If this (or whatever loss % applies to your business [F and P are not constant]) is too great a risk, then require 1 or more confirmations.  

The Mike H proposal is to try to reduce P by adding additional complexity to the protocol that will result in heterogeneity to the block-acceptance criteria.  IMO this will actually make the network less secure and increase fraud risk.  


I agree that many people are hand-waving about the dangers of 0-confirm double spends but I've never seen any real statistics on F and P in various cases; perhaps BitPay has them...

[murraypaul]

There is no guarantee that a transaction will be included in the next block.

There cannot be a guarantee that a transaction will be included in the next block unless you control 100% of the hash power.  

There is no guarantee that [once] a transaction [has been received by a pool it] will be included in the next block [mined by the pool].

And 3-4 are assumed to be default behaviour, but not required?

I don't follow.  

There is nothing stopping a node deciding to drop a transaction from its mempool and prefer a different one, or deciding not to relay it.

Plus, the merchant currently only receives the 'service' from the node they submit to. Receiving it simultaneously from pools covering say 60% of hashing power is a much more powerful guarantee.

Merchants can already estimate the % of the network that has accepted a transaction into mempool by employing a well-connected listening node.  The "service" of finding out if a peer has TX1 (or a conflicting variant TX2) in mempool is just one of the perks of being a node lol.

If most of the network has accepted TX1 into mempool, then most likely it will be TX1 that gets mined.  If 10% of the hashpower has TX2 in mempool then the probability that TX2 gets confirmed (instead of TX1) is approximately 10%.  

How many merchants are going to be interested in running a full bitcoin node, just to be able to safely process transactions?
I'm sure most would rather pay a small fee to someone else to provide that guarantee for them.
The way to gain mainstream acceptance is to hide the technical details, and provide simple services, not to require everyone else to learn all about it.
Merchants don't have to deal with each and every little bank out there, they deal with Visa and Mastercard instead.