Topic: "Dirty Deals in Smoke-Filled Rooms" J. Ranvier discusses a Mike Hearn proposal (Read 3697 times)

Very well put my man.

I couldn't imagine F being that high anyway. 

This problem would mainly apply to face-to-face transactions of little value and merchants could be alerted as soon as a double spend is detected.  The thief would hardly have left the building by that time and could be arrested in many cases.  Let the justice system handle it for now and if it becomes a chronic problem then revisit the issue.

As we have seen with the March 2013 fork, protocol changes can have unintended consequences.  I vote to tread as lightly as possible in that respect.

My reaction as well.  I thought it sounded like something from The Onion.

Seriously, anyone who is hiring developers who are to timid to defend their work or put up with some occasionally harsh criticism might want to keep their HR dept active.  Nothing is more valuable than having a bright and sometimes antagonistic set of eyes making observations in my experience.

And for several years I seem to notice a pattern of Gavin saying some pretty offensive things in a passive/aggressive manner then acting all butt-hurt when others escalate things.


I've been a fan-boi of Todd's and Maxwell's for a while now.  Garzik used to be up there but has fallen off.  I don't follow things closely enough to know much about Larimer.

I'm really heartened to see the grey-beards working on sidechains.  I like the treechains idea even better in principle but I'd take either.  And maybe even both.  I'll bet that those who are involved with both efforts have the native ability to recognize the strengths, weaknesses, and overlaps of the respective works, and I hope they choose to cooperate be it in Bitcoin or on a more general-use publishing system.

The article led me to research Peter Todd and Mike Hearn.  I came away a new fan of Peter Todd. 

LOL @ developers scared to post on the dev list because of him.

I wonder what the nature of the smoke in the backroom was ?

Dan Larimer and Peter Todd FTW.

+1

A sufficiently high fee should (nearly) guarantee inclusion in the next block found by honest miners.  Market-driven floating fees and child-pays-parent prioritizing should also make the TX priority criteria more transparent and flexible in the future.  Your idea would actually give less predictable results while paying the miners twice (the standard fee and some "monthly service fee" you seem to be proposing).    


Nothing besides the source code.  Compliant nodes neither accept double-spent TX variants into mempool nor relay them to their peers.  If a non-compliant peer floods the network with numerous TX variants spending the same outputs, they will be dropped as part of DoS mitigation.  

If you imagine a network where the majority of nodes and miners just start doing "whatever" then we have bigger problems lol.  


Merchants can employ a listening node by using a third-party payment processor such as BitPay.  Your idea would actually give less predictable results.  

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].

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.


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.

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...

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


I don't follow. 


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%. 

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.

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.

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"!

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.

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.

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). 

Agreed.


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)?

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

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.   


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. 

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.

best summary  (agree)