4 ms·

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

by bdcs 12y ago

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

nullc 12y ago
> 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.)
- amscanne 12y ago
  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. Edit: formatting made it unclear.
- mike_hearn 12y ago
  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.
  - bdcs 12y ago
    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.

by bdcs 12y ago

nullc 12y ago

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

amscanne 12y ago
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. Edit: formatting made it unclear.
mike_hearn 12y ago
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.
- bdcs 12y ago
  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.