Topic: Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch - page 3. (Read 18304 times)

I reject your premise.  The health of the bitcoin ecosystem is hopelessly intertwined with the self-interests of miners.  This relationship goes in both directions.  Bitcoin cannot survive contrary to the self-interest of miners, and miners cannot survive without the common good of bitcoin.

If it turns out that the bitcoin system does not ultimately align these two forces, it does not deserve to be continued

The good news is that bitcoin does not appear to contain this flaw.  The people that are damaging the ecosystem are those that are advocating and defending practices that are unsafe and cannot be made safe, such as accepting transactions secured by hope rather than work.

You do bring up some interesting context.  And I will spend some time thinking about it.  But I wholly dispute this statement:


Replacing unconfirmed transactions doesn't do harm to the Bitcoin ecosystem.  It's how the system operates.  We're not "removing" security, it was never there to begin with.  The success of Bitcoin never depended on it, in any way.  We're just guaranteeing that no one is ever misled about that aspect of the system.

Also, your comment about blacklisting is really not the same at all (nor feasible).  Zero-conf replacement requires only a few miners to participate for it to make zero-conf transactions pretty much useless in zero-trust transactions.  That's not the same as blacklisting, which needs 100% miner participation to work.  Or rather, I only need a few miners to agree to mine my transaction for it to be eventually accepted.  And convincing miners to not mine the top block is going to cost you a $#!+load of money...every 10 minutes...forever.

Your point is not lost on me, I just didn't like your specific examples

I'm not intending this as a point for or against this patch, but I reading this set me wondering how many of the other assumptions we'd normally make about Bitcoin would still hold given this (fairly reasonable-sounding) idea that a majority of miners will be acting purely out of economic self-interest, regardless of damage they might do to the Bitcoin ecosystem.

One assumption that immediately falls is the idea that Bitcoins are censorship-resistant. If miners are all acting in their own rational self-interest, I can pay miners to blacklist transactions coming from your address. If you tried to spend, I'd tip any miner who creates a block that doesn't include your transactions at a higher rate than their fee. If they do manage to get into a block, I can (for a greater cost) also tip people for ignoring that block and building on another one.

If I'm trying to do this on a large scale - say I'm the DEA trying to interfere with the flow of money to drug smugglers - I can keep that taint going on all the way down the chain through future spends, so that once you take money from a drug smuggler, that money will be forever less valuable than other money. If you don't want to receive dud money that's hard to spend, you're going to have to check for the taint as well. I can run a convenient web service so that you can check for black-lists, and also white-lists of people who have confirmed their identity with me so you can be sure I won't bribe people to taint their coins. Hey presto, everybody is cooperating with me to do AML checks...

This wouldn't fly now because miners are
a) Decent people, not purely rational economic actors.
b) Fairly [shock horror] centralized, which makes them resistant to a Tragedy of the Commons. BTC Guild and Slush won't cooperate with my evil scheme for fear of damaging the future of Bitcoin, which costs them more in the long run.

False sense of security.

The point of all this is that zero-conf tx should not be used for zero-trust situations.  But merchants will, because it "seems to work" right now.  What we want is merchants to recognize this lack of security and decrease required trust, say, by having the buyer show ID before they walk out with the merchandise.  Just like they do for cashing a check (which carries much of the same risks).  As long as there is a way to use the legal system as backup, then they have appropriately compensated for the lack of security behind the zero-conf tx.  

Merchants could learn the hard way, and then they'll stop trusting zero-conf tx.  But if they do that, there's no reason any more to artificially maintain this illusion that they are somehow secure.  Might as well just write it off now and let everyone start adapting now. 

No, this is an assertion that bitcoins not be used for transactions that are immediate, even if a business is already capable of handling the levels of fraud the current system would entail.

Of course not. Until bitcoins become commonplace, the most common user of zero-confirmation transactions - brick and mortar businesses - won't really exist. If this change is inevitable like you guys claim, why not wait for it to happen naturally?

Except that there really hasn't been any security in that, just hope.  People have been living on the hope that those transactions would be confirmed some block in the future.  Most of them got away with it.  But they never had any security, not really.

I doubt it.  If there is ever a significant zero-conf market (especially a brick & mortar), they can pay mining pools to NOT allow replacement for TXNs originating from them.

This would reduce the likelihood of a double-spend dramatically.

As the credit-card business aptly shows, problems not theoretically solvable are often 99.93% (7 cents out of 100 bucks) solvable in practice http://en.wikipedia.org/wiki/Credit_card_fraud

What is the effect of this change on retail sales? Won't this make it possible to effectively re-route a transaction after an exchange of physical goods has already taken place?

Or is there an assumption or recommendation that Bitcoin not be used for transactions that are immediate, such as point-of-sale? I know it's always been recommended to wait for at least one confirmation, but up until now, there's reasonable security in accepting unconfirmed as long as you've got a full blockchain by which to compare the transaction's inputs and outputs.

Yeah, the user-interface aspects will be tricky to communicate. For instance if an undo button is implemented, it probably should actually be called something like "Attempt to cancel", and at least initially be hidden off in the RPC interface anyway.

Increasing the fee isn't such a big problem, although a dialog box that points out you have the option after some reasonable delay is a good idea. It should probably be called "Offer a higher fee" so users aren't as surprised if the lower fee version goes through anyway.

This patch makes the best case the same as the worst case: zero-confirmation transactions can be "overridden" if another transaction with a higher fee is broadcast before it makes it into a block.  We are arguing that this unquestionably how miners will operate in the future, anyway, so we change the default now to prevent any further adaptation to a  false sense of security/reality.  i.e. users currently experience transactions not being replaced so readily, so they build around an assumption that zero-conf are okay for zero-trust situations.  They're not. 

I agree this is not inline with the original intention of the software, but I don't think there's a way around it.  Miners will do this eventually, even if most of them aren't, yet.  Let's not pretend they won't.

Plus, this patch comes with the nice benefit that "stuck" tx can be easily fixed.  Though, I do agree that a non-deterministic "undo" button is a bad idea.  It would be unreliable in many ways, and would also give a false sense of reality to users.  Instead, I'd like to see a button/dialog that says "This transaction has been waiting more than one hour without being accepted.  Would you like to increase the fee to try to speed up its acceptance?" 

okay so let me understand, this problem already exist and can be triggered by bad miners,

but don't you think you are overreaching, you were ask to do a way to take transactions out of limbo.
I know very well that because i have one of those chain games, and i time i configured it under .0001 btc and
the transactions that didn't include fee never arrived, yet still pending.

Don't be naive, the coding you are doing is exactly what the bad miner needs,
if i give you 1000$ will you code me an alt-coin and an exchange for me?
Because i'm in...

A few days ago i saw a thread "how to make a genesisblock" by some kid from 4chan trying to do a noob-coin...
if you see a new alt-coin every 4 hours now you know why...

PD: i'm not questioning retep nor do i have shares on SD. Just want this discussed further before he releases any of the code.

Yup. I've spoken with evoorhees about this issue and while I don't know what their plans are exactly they had no objections. In fact, out of the roughly half dozen people running services I have either contacted, or who have contacted myself or John Dillon, nobody has actually asked us not to implement replace-by-fee. I don't want to pretend I'm speaking for them, but I suspect the few merchants that actually need zero-conf security would like to see a genuinely secure solutions be implemented like trusted computing, fidelity bonds w/ double-spend fraud proofs and off-chain mechanisms rather than the current half-measure of hoping everyone follows a de-facto standard.


Mind expanding a bit on what you mean by non-determinism?

Bitcoin is a system for deciding which of two or more transactions is the "right" one.  We use a global network and consume quadrillions of hashes every few minutes not for our own amusement, but because the problem really is that hard.

A transaction is exactly as secure as the quantity of work it would take to reverse it.  Zero work?  Zero security.  STOP ACCEPTING ZERO WORK TRANSACTIONS.  You've spent too long in dreamland, assuming that the intention to hash in the future was as good as hashes already done in the past.  They aren't, they never were, and now everyone will be forced to accept reality as it is.


Confirmations don't secure transactions.  Hashes do.  Making the blocks more frequent would mean that they have correspondingly fewer hashes of security.  Changing the lump size that hashes come in won't help anyone.

Zero-confirmation transactions were never safe.  Note that Satoshi DICE apparently waits for confirmations, on higher value bets -- an admission that SD themselves know zero-conf are not safe.

However, with regards to transaction replacement, it should be noted that it introduces race conditions that increase non-determinism.

The first step towards improved determinism is, instead, making transactions expire after a certain amount of time in memory pools, without being mined.

You just completely ignored the entire discussion in this thread.  You don't get to decide what transactions get to go in a block.  I don't, no one else does, either.  Only the miners get to decide for themselves what transactions go in the block.  And if it involves more money, they will do it eventually (though they generally are not doing it, yet).  Because they can do so while operating completely within the rules of the system.  You are welcome to add your own mining power to the system and refuse to replace transactions with your share of power.  But you don't get to tell others what they get to do with their share.

As the number of confirmations goes to infinity, transactions are irreversible.  But zero-confirmation transactions are, by definition, not confirmed, and thus there is no such thing as "reversing them."  They were never confirmed to begin with, and should never have been trusted at all until they had confirmations.   (Note:  this applies only to trustless transactions:  zero-conf can still be useful if there is a persistent relationship between the two parties, but Bitcoin was never designed to do instantaneous transactions with zero-trust)

It should never allow you to reemplace a transaction, or to change outputs,
it should allow you to give more priority to a transaction that it's stuck on the limbo of 0 fee/smaller fee transactions.

Only replace the transaction if it's the same transaction with bigger fee. to the same outputs.

Any other thing is not bitcoin, btc is not reversible.
or you just killed satoshi dice.

But talking about improving you could also change the 10 min confirmation to 2 and slash the rewards 5 times.
then they will change to a 1or 2 confirmations .

An initial implementation is available for testing.

See new thread here: https://bitcointalksearch.org/topic/initial-replace-by-fee-implementation-is-now-available-on-testnet-199947

You mention that some miners may not honor replacement undermining the usefulness.

But remember they may not honor replacement not because of any decision by them but because of limitations of technology. Old software is obvious. Slow network connections is another.

Part of what worries me about zero-conf is that if people rely on it rules may be put into place that punish miners who  fail to honor replacements or detect double-spends because they happen to be behind bandwidth constrained network connections and simply did not get the information that other, larger, more centralized miners did.

It is ironic that unavoidable technical limitations means that with unlimited blocksizes zero-confirmation transactions definitely will not be safe requiring all the decentralized trust required by the off-chain transactions that make large blocks unrequired.

A Nash equilibrium doesn't require any collusion at all.  It is something that just happens.

For example, lets say you play a game.  No communication is allowed between players and their moves are secret.

Each player picks a number from 1 to 10.  The results are announced and the players that picked the most popular number (say 7) are given $5.

The game is repeated, what number do you think will win?

Next, the referee says "For the next round, I strongly recommend 4.  You can still vote for any of the 10, but really, 4 is a great number".  Which one do you think would win?  7 might still win, but 4 has a pretty good chance.


You don't need a majority.  Say there is one pool which has 10% of the power and they say that they will queue all blocks that have the 2nd (or later) of a double spent transaction in them for 5 minuted before building on them.

Other miners now know that if they add those txs into their blocks, only 90% of the hashing power of the network will build on them for the first 5 minutes.


There are limits before the Nash equilibrium breaks down. 

Simple Nash equilibrium are the best.  That is why build on the highest POW chain is so strong.

However, as I show in my previous post, with large fees, that Nash equilibrium can break down.

Well... What if there is some sort of collusion among majority of miners (i.e. they have more than 50% of hash power combined): they will agree to decide block to mine on top of using some set of rules and some sort of a practical Byzantine fault tolerant algorithm for synchronization?

They can simply drop blocks of miners which do not agree to participate in this PBFT-synced collusion, and as far as I can tell it is stable as long as colluding miners have a majority. (I'm not quite sure about that, but I guess it will be 'stable enough' for practical purposes.)

Within this collusion pretty much arbitrary rules can be enforced.