Previously, processors and merchants accepting bitcoin payments would wait until a large fraction of bitcoin nodes listed a 0-conf txn as "valid-but-unconfirmed," the so-called memory pool or mempool (because it is a collection of transactions in RAM). This works well, because we empirically know how nodes operate: they accept these valid-but-unconfirmed txns into the blockchain and reject (both discard and fail to relay) any competing txns ("doublespends"). Doublespend attacks worked by filling the global mempool with the doublespends before the original txn fills the mempool. Naïve software wouldn't check the global mempool. So really, there were two types of 0-confs: txns which were agreed upon by >90% of the global mempool and those which it was unknown (but sometimes assumed).
Now, BitUndo changes how people perceive mining nodes! No longer is the mempool immutable, but rather mutable for a price. This price, as it stands, is 10% per successful undo and 0% per failure. So if BitUndo (and federated pools) controls 1% of the network, then 99% of 0-confs will confirm, 1% will be undone, and 0.1% of the total transferred will be paid in fees to BitUndo. It throws more of a wrench into the system as the BitUndo federation varies from 0% to 100%. Empirically, it will be trivial to see what percentage of the network is engaged in BitUndos. If that percentage becomes materially large, then it will have a material effect on how the system treats 0-confs, for better or worse.
Interesting, this service is definitely available privately (or should be assumed to be). As U.S. Supreme Court Justice Louis Brandeis once said: Sunlight Is the Best Disinfectant
> processors and merchants accepting bitcoin payments
Citation needed. The existing behavior is very easy to rip off: You write two transactions, the one paying yourself, one paying the merchant. Simultaneously you hand a big miner the first while handing every other node you can reach the second. It's very likely that the first doesn't propagate at all, but you'll have a decent successrate at reversing.
Blockchain.info even had a handy tool before to author double spends but they've removed it.
In any case; there is some real subtly here. Both the case where miners are alturistic and don't help doublespends even if bribed and where miners always just take the highest bidder are consistent models which can enable safe zero conf transactions. But the transaction styles you use to get safe zeroconf are very different, and inconsistent behavior in the network is basically pessimal. There has been some debate in the past if the greedy behavior shouldn't already be the default: most people believe that it will eventually be in that state, and so there is a tradeoff between setting the right expectations for the long term but requiring more advanced handling of zero-conf vs having the best security for the simplest possible ways of using Bitcoin. I don't think there is a clear answer to the tradeoff, but because the inconsistency is bad I think if non-trivial hashpower picks this up the network will need to change the default behavior.
(Since I expect someone will ask: To get safe-zero-conf in the greedy miner world, you have the party pay you (optionally with an additional security fee if they are really untrusted), and if you see them a doublespend you spend the entire payment to fees (so you'll win the auction very likely). If they've provided any security at all their expectation is negative, if you make them provide enough security (E.g. security = tx value plus ε) then you can give them negative expectation without losing money yourself.)
Come on Gregory. You don't need to provide citations for reality. Just go and spend some Bitcoins into the economy, then tell me how many sellers required 6 confirmations. I don't remember the last time anyone required me to wait except for exchanges.
Thank you Gregory Maxwell and Mike Hearn for your comments! Your bitcoin thoughts (in general) are truly insightful! And, Mike, your forum "outreach" to help people understand bitcoin better is also to be commended. As a general PSA, I recommend to everybody interested in bitcoin to read the comments of mike_hearn in this thread; he (and the other core devs) spend a lot of time explaining non-intuitive aspects of bitcoin. PS. Mike, do you have a centralized source for your comments? Between G+, medium, bitcointalk, ad-hoc videos, etc. it's hard to keep track.
Gregory, my only data point for a 'merchant' accepting txns which have zero conf WITH widespread network propagation (say, >70%) is blockchain.info's now-defunct laundry service. 0conf w/o net. prop. was never accepted, 0conf w/ net. prop. was accepted for 'small' amounts, 1 conf for med amounts, 2 conf for large amounts, and 3 conf for extra large amounts. Anyway, you knew all this better than I did, but you asked so here you go. Thank you for explaining the greedy-miner strategy for safe confirmations. The problem I see with that, is the merchant needs a fast connection to "destroy" the transaction in time.
It took me a bit, but I think I now understand what you are saying. I'm a novice, so please correct me if I'm wrong.
The "greedy" behavior would be when minors explicitly prefer a sequence of transactions such as:
Customer => Merchant: X+ε (1)
Merchant => fees: X+ε (1)
over
Customer => Customer: X+ε (2)
Going so far as to swap out (2) with (1), even if they already have (2). If there is no double spend, presumably the trustworthy merchant would send back ε after sufficient confirmation []. Or, in a world with fees, the ε would be fees in the original transaction (still serving the purpose of costing the malicious customer Bitcoin, even with successful double spend).
That seems like a decent solution.
[*] Or I suppose it could be in the same block. No difference.
Interesting product. It doesn't really look like this is meant to make any money for the developer yet (maybe the plan is to add fees to their mining pool at some point in the future?). I suspect the point is to drive policy so that companies and individuals don't trust transactions with zero confirmations, or at least start checking for double-spend attempts. The standard right now for many companies is to accept zero-confirmation transactions (e.g. bitpay does this). Because this is such a widespread practice, it's effectively a security vulnerability of the bitcoin network as a whole. If this site can change this standard, then maybe they'll make the bitcoin ecosystem more secure.
This is an interesting phenomenon of the bitcoin ecosystem. If someone owns a lot of bitcoins, they're incentivized to make something like this even if it doesn't directly make them any money.
> It doesn't really look like this is meant to make any money for the developer yet
Incorrect.
> the new fee you will need to pay is 10% of the undo amount, plus the original mining fee. Note: If you are sending a secret transaction, you must then double this fee
Ah, I didn't catch that part. 10% of the transaction seems like quite a steep fee. I don't really like how they hide the fee breakdown buried in the developer documentation.
Breaking instant payments doesn't make Bitcoin more secure, it just makes it less useful. The model generalises to probabilistic rewriting of the block chain, there's nothing special about confirmed vs unconfirmed.
Bitcoin assumes the majority of hash power obeys the rules. At the moment, nobody knows how to build a system in which the majority of all players are dishonest and colluding against you, and Bitcoin is definitely not such a system. People who think it can be trivially evolved into such a system need a reality check: the more miners become dishonest and don't play by the rules, the less useful Bitcoin becomes. It doesn't take 51% to make it practically useless either.
Bitcoin apps/sites are using blockchain.info API as a hot wallet. I bet some exchanges are secretly doing this too. Surprised there doesn't already exist a hot wallet as a service yet. A competent one would make assloads of profit from gambling and betting sites that don't want to run their own.
Won't that be a big problem for everyday transactions though, to have to wait 10 mins for a confirmation instead of immediately like swiping a credit card when say you go out to eat or go grocery shopping?
Won't that then hurt the usefulness of bitcoin and adoption rate?
Perhaps there's a place and need for certain supporting infrastructure around Bitcoin—similar to what we have with bank cards. In the latter case payment doesn't necessarily happen immediately as you swipe the card (the transaction can be pending authorization for a few days afterwards).
Some service could provide instant payments with Bitcoin and handle chargebacks, disputes, credits, etc. I guess if Bitcoin is successful, the big players would go after that.
Doesn't this mean paying with bitcoin in the real world is now broken? Merchants will either have to make people wait for up to 10 minutes for the transaction to confirm or risk that person reversing the transaction after walking out the door.
Now broken? It was always broken in this manner. Merchants have always had to account for the risk of unconfirmed transactions in one way or another (and if they were ignoring that they were negligent).
With online shopping it's relatively easier in that you can wait until the payment posts to the network before you complete the transaction, but this definitely would interfere with brick-and-mortar types of activities, ATMs, etc.
Merchants already have to understand and factor in risk with credit card reversals – merchants will need to learn what their risk is with bitcoin and factor that risk into their price just as they already do (or should do) with the risk from non-cash txns.
Wild. So, if this takes off (ie, enjoys miner adoption) and if the incentive structure works as advertised (ie, miners stand to make more by accepting the invalidating transactions), then this pretty much destroys the credibility of 0-confirms except with trusted parties, yes?
You can't pretend like zero-confirmation transactions have never been useful. They have been used in practice for small amounts, many times, with no issues, and this system obviously changes things.
They are useful in customer-merchant contexts because the merchant can cancel the order after anyway in case of a double spend, and in in-person contexts because you're in person so the risk of trying to cheat is too high. That's the main reason why zero-confs are fine; you only really need the preliminary notification to be instant, not total security.
Wouldn't that present a horrible UX in some cases when paying with bitcoin? You'd have to wait ~10 minutes to access your purchase while the transaction is confirmed
No, there is credibility demonstrated by actual practice. Merchants accept zero-confirmation transaction, specifically in-person. Yes, there's a risk that the transaction never gets in the block or is double-spent, but that risk for certain kind of transactions is low enough to be tolerated.
Right now nodes do not accept double spending transactions, no matter how much they pay in mining fees. This makes simple security promise for 0-conf transactions: the most relayed version is the one that most probably will be included in the block. So merchants can accept such transactions because they know that reversing it would cost much more than 100% of the transaction value.
If enough nodes on the network replace transactions when the mining fee is, say, 10% higher than the previous version (or 10% of the total amount, or whatever), then for the user it is much cheaper to “take money back”. You will send $5 for your coffee and get back $4 with no sweat. Merchant will lose all $5. You can say goodbye to 0-confirmation transactions.
So what do we have:
1) Users get some sort of “undo” function which is nobody was asking for. In my view, if there’s a problem with accidental button clicking in the UI, it’s simpler to fix right there, not by changing the entire network.
2) No one can rely on 0-confirmation transactions anymore. Even today they are not safe, but for small purchases the risks are pretty low, so they work for many people to everyone’s satisfaction. But with network-wide “replace with higher-fee transaction” the risk will go up significantly to make this feature unusable.
However, in the long run, 0-conf transactions won’t be the future of instant micropayments (we’ll have some sort of distributed clearing network instead), so we might not care that much. But the value of “undo” is still very questionable to throw away usefulness of 0-conf transactions today.
Final note: Bitundo can’t be useful when it’s small. It’s either working more than 90% of the time for legitimate “undos” (which makes 0-conf txs useless) or it’s used marginally only by those who wish to rob merchants who accept 0-conf transactions. In which case they still may render 0-conf transactions useless.
Well, this throws a real wrench into services like BitPay that rely on verifying _only_ that a transaction has been broadcast, instead of making you wait until 1 or more confirmations (which can take 10 minutes, or 30, who knows). This always seemed like a hack to me anyway. Bitcoin is just not really set up well for quick transactions, which is just about the only kind of transaction you actually want on the internet.
I think it's a good thing for this sort of service to come out now while Bitcoin is fairly young. Accepting zero-confirmation transactions has always been bad practice, making double spending more likely in this case means that people will be far less likely to accept them.
So, in practice, what is the probability that a transaction would really be cancelled if the issuer of the payment uses this service approximately two minutes after initiating the transaction? (I assume that two minutes are a realistic estimate of the time it takes to realise that one has made a mistake, remember this service, search for it online, and fill out the necessary info.)
Easy back of the envelop calculation: If a block is generated every two minutes in average, you have a 80% probability that the new block is not generated in that two minutes. So if everyone is in this service then the probability of success is 80%.
The same idea can be used with a rogue client. Just generate a conflicting transaction.
I’m not sure, but if there are conflicting transactions, then most of the miners just pick the first transaction they received. But let’s be optimistic and suppose that they pick at random, so you have a 80%/2=40% that the new conflicting transaction is picked and the original dropped.
IIRC some miners are filtering the transactions to process the transactions with bigger fees, even in the case of not conflicting transactions. So perhaps a bigger fee can be used as an incentive to choose the “right” transaction.
There's too many variables to give a simple answer. It depends on the current state of the network (the miners mempools), the priority of your transaction, the fee/bytes of your transaction, and what % of the hashing power bitundo has. Some transactions take a few blocks to get confirmed, these are the ones that have a much, much higher likelyhood of being undone.
>Q: How likely is it to undo my transaction
A: The likelihood is approximately the same as the percentage of mines using bitundo. Right now, this is pretty low.
If I understand correctly, the time left doesn't really matter. It should be totally dependent on their share of hashing. If undoing requires them to pick the winning nonce, it should be much like a lottery (your chance at any given time depends more on your share of purchased tickets more than anything else).
And if that's the case, this seems like a pretty pointless service. Until they get a large share, it won't work the vast majority of the time. And even when they do get a large share, undoing still won't work most times.
I think people should stick to n-of-m checking versus this scheme.
When people try to undermine a system, two negative things may happen: 1) The system that is being undermined will be pushed too far and it won't be see as reliable and/or 2) The system that is perpetrating the undermining will get patched out of existence.
Both scenarios end poorly for the bitcoin ecosystem.
If you want to send a bitcoin but aren't sure you'll be receiving what was intended to be your half of the transaction, stick to n-of-m signature transactions.
EDIT: With that being said, I believe it's time for the BTC community to figure out how to patch this problem before it ruins zero-confirm for bitcoin.
Bitcoin is a system that is woefully misunderstood by many people. It is not a honey badger. It is at heart a system that takes a positive view on humanity. It's a system built on the assumption that the majority of players are honest and stick to the rules. In a world in which most people think long term and don't spend all their time trying to stab each other in the back, this works.
But is humanity really that way? Or does society require a small number of rulers keeping the ruled in line? Every day that Bitcoin works well, the answer shifts towards "no, decentralisation of power can work". And if BitUndo gathers significant hash power, the answer shifts more towards "yes, decentralised solutions can't work if they rely on an honest majority".
If you read the literature, distributed systems very commonly require some kind of honest majority, if only because the definition of "honest" needs to be set by something. There isn't really a way to make Bitcoin work in a world where most other players are colluding against you.
>But is humanity really that way? Or does society require a small number of rulers keeping the ruled in line?
IMO it depends on the specific ecosystem, and there is no definitive answer for this question. Some systems bring out the worst in people, some don't. However, as bitcoin is a financial system, greed is a major force that it must contend with. As the value of BTC grows, the incentive for bad behavior will grow with the rewards. For that reason, I personally cannot imagine that bitcoin can continue indefinitely without some sort of regulation. I'd love to be wrong about that, however.
It remains to be seen if BitUndo can realize their goal under the current framework. It's quite possible that the costs coupled with the initially low success rate and the desire for miners to protect the value of their holdings might prevent it from ever gaining traction. However, their efforts highlight an attack vector and there may be ways to disincentivize their scheme early on.
No fraud or scam. Bitcoin users have acted very aggressively to the idea -- and felt best to censor it.
What they seem to not realize, is that double spend attacks were very viable previously (putting conflicting transactions in different part of the network), submitting double-spends directly to pools, finley attack etc.
The thing bitundo brings to the table is legitimacy. People can undo a transaction without foreknowledge they will need to. This is nothing but a good thing for the bitcoin network, and it reminds people that 0-confirmation transaction never were, and never will be safe.
Double spends are not currently "very viable", as indicated by the fact that they were not happening and accepting instant payment is the standard. This is objective reality, not something you can argue away. A different world being theoretically possible does not translate into it magically happening with no effort. You are making an effort to change our happy situation for your own profit, in other words, to make Bitcoin less useful over the long run to benefit yourself in the short run. I can't tell if you're motivated by greed or a particularly poorly thought out world view.
Also, why are you claiming this is somehow specific to unconfirmed transactions? Corrupt miners can also rewrite the block chain. If you get paid enough and have enough hash power, why not see if you can overtake the chain head? So don't claim it's somehow specific to unconfirmed transactions. It isn't.
Bitcoin fundamentally assumes that the majority of mining power is "honest", defined to mean following the rules laid down by Satoshi in the core software. You can see this by simply reading the white paper:
"The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes."
(last sentence, first page)
You are attempting to bribe miners to become "dishonest" and "attack the network" in Satoshi's language. If enough people did what you suggest, the system's fundamental assumption would be invalidated and the entire network would break. If merely a small number of people do it, it just makes the system unreliable, untrustworthy and pushes people towards centralised fixes like payment processors that levy higher fees, trusted third parties that prevent double spending, secure hardware, etc. All things that increase Bitcoin's costs and reduce its competitiveness vs regular banking. Doing this doesn't help anyone or prove any point, it just adds sand into an otherwise useful system by increasing transaction costs.
tl;dr you are like a kid kicking down someone's sandcastle on a beach, then saying "they should have been guarding it better, anyone could have done what i did!".
To be fair, if comparing Bitcoin to a sandcastle is a fair comparison, then it's better for this to be made obvious to everybody before it reaches critical mass.
Perhaps more importantly, this feature doesn't actually rely on miners being dishonest. There is no rewriting of the blockchain going on. All that is required is that miners are greedy. That is, when two conflicting transactions are in the mempool, it requires that miners prefer the transaction that comes with a higher fee.
I think people involved with it over the long term have always said that it's a risky experiment that might fail. Bitcoin resembles a sandcastle far more than a honey badger, that's for sure.
"Honesty" is defined to mean "following the rules". The first seen rule is a part of that set. BitUndo isn't attempting to fork the chain today, but they certainly could - it's a simple extension of their model. Double spending for a fee doesn't really care whether a tx is unconfirmed or not, it simply alters the price charged.
Security isn't a binary yes/no thing and double-spending-for-a-fee does not require unconfirmed transactions. Confirmed txns can be replaced too, it just costs more.
> Bitcoin users have acted very aggressively to the idea -- and felt best to censor it.
It's not even ironic anymore when they respond in this fashion. They'd probably even remind you that only the government can technically "censor" something, and that if people want accurate news on Bitcoin they are free to pick a competitor to /r/bitcoin that will provide it.
I'm not 100% sure I understand why miner would prefer BU pools as opposed to other pools. Is it because the miners receive 100% of the mining fees? (as opposed to having to pay admin fee to the pool manager) BU's income is the fee payed by successful customers.
That means that there should be an equilibrium point between "miners for hire" (that try and target specific transactions) and regular miners.
So basically it's a 0-10 minute buffer on transactions that if you pay them enough to cancel your mistaken one... they'll do their best to get the secondary transaction mined first?
Now, BitUndo changes how people perceive mining nodes! No longer is the mempool immutable, but rather mutable for a price. This price, as it stands, is 10% per successful undo and 0% per failure. So if BitUndo (and federated pools) controls 1% of the network, then 99% of 0-confs will confirm, 1% will be undone, and 0.1% of the total transferred will be paid in fees to BitUndo. It throws more of a wrench into the system as the BitUndo federation varies from 0% to 100%. Empirically, it will be trivial to see what percentage of the network is engaged in BitUndos. If that percentage becomes materially large, then it will have a material effect on how the system treats 0-confs, for better or worse.
Interesting, this service is definitely available privately (or should be assumed to be). As U.S. Supreme Court Justice Louis Brandeis once said: Sunlight Is the Best Disinfectant