These days we regard transactions with one confirmation to be 'Confirmed'. Only transactions with 0 confirmations are 'Unconfirmed'. Waiting for 6 confirmations is a recommendation but should not keep the transaction shown as unconfirmed.
Misc code sanity:
NACK, considering transactions confirmed any earlier than 6 blocks is unwise. If anything, this should be increased due to the disturbing amount of centralised hashrate in cex.io.
@luke-jr I'm sure you misunderstand: this doesn't affect any balance computations or such, and still shows the clock icons for transactions for 1..5 confirmations.
It only replaces the awkward Unconfirmed (1 of 6 confirmations) status messages by Confirmed (1 of 6 recommended confirmations). Only transactions with 0 confirmations are Unconfirmed.
What happened to "Validating" (1-2 blocks) and "Processing" (3-5 blocks)? :o
For end-users using the terminology "confirming" (1-6 blocks) and "confirmed" (6+) seems like a good idea to me - especially how it makes clear that unconfirmed is a totally status than the process of confirming. So I would make it:
Unconfirmed
Confirming (1 of 6 recommended confirmations)
Confirmed
Help text would be like so:
"An unconfirmed transaction hasn't been accepted by any miner - it's just floating around the Bitcoin network and there's no guarantee it will ever confirm. The confirmation process starts when the transaction is first included in a block by a miner, the first confirmation. However, it's still possible, although unlikely, that the block might itself get rejected, so for the first few confirmations we say the transaction is 'confirming'. Once about six confirmations have passed the chance of all six blocks getting eventually rejected is extremely low, so we call the transaction 'confirmed'."
Is there a reason that we shouldn't have a setting for the definition of "confirmed" to be used in this display and coin selection?
We have single pools with 30% hash-power someone compromising that single host would have a success rate for reversing a six block deep chain would be 13.2% (http://people.xiph.org/~greg/attack_success.html) and the particular pool right now with 30% has previously been "compromised" and used abusively (https://bitcointalk.org/index.php?topic=327767.0). For large high value transactions which are otherwise completely unsecured I would not consider 6 blocks adequate. ... though I might be alone in this, making it configurable might be helpful if some incident creates a long forks and we can tell people to just up that setting to increase their security as a workaround.
FWIW— my practical experience in helping out individual traders with large transactions in the last week is that lots of people, though not everyone, consider 0 confirms safe enough to take irreversible actions (::face-palm::) and were surprised when I educated them otherwise. "I thought double-spending was really unlikely" was something I heard multiple times, and some people thought the network nodes would reject blocks that contained transactions which conflicted with ones in their mempools.
@gmaxwell Strong ACK on that.
Peter Vessenes asked me a few months ago if I'd be interested in, or knew someone who might be interested in, writing some whitepaper's and calculators for merchants and the like to get better insight into what kinds of risk they were taking by accepting after what # of confirmations. Anything that gets us away from the "magic six" number is a good thing.
I tried to reason about this risk analysis a while back and ran into the problem that the expected return of such an attack is related to the number of things you can concurrently attack in a block. The result is that you can't simply say "This 10 BTC transaction isn't at risk because it's much smaller than the expected cost of the attack." because that could just be one transaction parallel attack against dozens of services amounting to thousands of Bitcoin.
On a related subject, our metric for confirmed really shouldn't be "number of confirmations" but the marginal height advantage over the next best chain which does not include the transaction, with some modification if blocks are really slow (e.g. isolation attack). But thats hideously complicated to implement. After headers-first it may be possible to implement advantage-over-next-best-chain without the doesn't-include constraint without much work. I dunno, the whole subject of risk analysis is a horrible rat-hole and I'm afraid solid advice will have poor patient-concordance.
Attacks are rare and the cost of being immune to attacks hits you with every transaction. Maybe some of the answer here is simply insurance rather than transacting safely.
Yes I know, fortunately you can do that reasoning by adding up all the transactions in that block(s). Unfortunately that gives maximum expected returns in the tens of millions...
Anyway, make it configurable to get people thinking. A nice dropdown box with "low security" "medium security", "high security" and "paranoid" corresponding to 1, 3, 6 and 100 confirmations or so wouldn't be a bad idea to promote user understanding. (more interesting for other wallets though...)
One may want to accept different numbers of confirmations in different contexts. Wait 100 confirmations for a house. 1 or even 0 for a coffee. OTOH it's already possible to wait any number of confirmations that you want before acting on a transaction. The 6 recommended transactions are just a quick visual indication.
I'm generally against adding options, if we added an option for everything bitcoiners hairsplitting over then we'd have an options pane like the space shuttle cockpit. But in this case if it affects coin selection as well as display I'm not against it.
Hi all. You've got me a little worried with all of this - I'm building a merchant terminal which is going to be used mainly for small transactions (few dollars max, like coffees etc.) Are you saying I can't let my customers walk out of the door for 10-60 minutes after purchasing? Or is it still safe to accept 0-conf transactions for small amounts? If so, what checking do I need to implement to rule out obvious double-spends and other cheats? Any links to detailed discussions would be very welcome.
@NanoAkron coffee is not generally representative of all uses of Bitcoin. Do your merchants also wait months for credit card transactions to settle? Do they pay telechex fees to accept checks? Do they even obtain signatures on their credit card transactions?
You cannot rule out double-spends if you are accepting transactions without confirmation. Beyond making sure that you've heard the transaction from a full node you either operate or trust implicitly there isn't really a ton of checking that can be done.
For small amounts the risk is probably acceptable— and if its concerning getting ID makes sure you can blacklist the customer. But that isn't the same as saying that there is no risk by any means.
Changed it to Unconfirmed/Confirming/Confirmed as @petertodd's suggestion.
Making the 6 confirmations configurable is outside the scope of this pull request but can be done later.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/4ad17cfa6bf99890f30f3458b53f8fce57a10df8 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
These days we regard transactions with one confirmation to be
'Confirmed'.
Waiting for 6 confirmations is a recommendation but should not
keep the transaction shown as unconfirmed.
Misc code sanity:
- Merge maturity/status enums, they had become completely disjunct
- 'confirmed' flag is now called 'countsForBalance' for clarity