Instant Bitcoin confirmation time (IDEA)

[madmadmax]

With bitcoin, a double spend isn't guaranteed to work. It all depends upon which transaction gets to the miner first.
And if you do it frequently, you will get caught because cameras are all over the place and you will be identified.

Perhaps for low value thefts you won't be but that's peanuts.

And as far as credit cards go, the problem is stolen credit cards.
You can buy lists of valid credit card numbers (something that doesn't really work with bitcoin) so you can keep defrauding the same way you would with double spending.

-=-

Some silicon valley exec just got busted for stealing legos. How was he doing it? Printing barcodes that scanned at lower prices and pasting them on the boxes so they ring up cheaper.

Thieves will always find a way.

Are you fucking 12? Seriously I sometimes get the impression that I'm chatting with children or grown men/women that never matured (e.g. DannyHamilton).

Bitcoin is a tool, it needs to be AS efficient as it possibly can, I gave a logical, great way to solve this problem if the core dev team wanted they could do it without imposing ANY restrictions or harming anyones rights, sacrificing privacy or making any other sacrifices.

Why should I buy a dull swiss knife again as a business owner?

[AliceWonder]

No, I'm 40 with an IQ of 138.

I'm sorry, but you are looking for a solution to a problem that really does not exist. That's the bottom line.

[AliceWonder]

As far as whether you as a business owner should accept bitcoin, well, that's up to you.

If you are afraid of double spends then either you have evidence it is a real problem or you are paranoid without evidence.
Which is it?

[DannyHamilton]

- snip -
I'm chatting with children or grown men/women that never matured (e.g. DannyHamilton).
- snip -

 

[AliceWonder]

Since bitcoin uses a peer to peer to network to get transactions to the miners, how hard would it be to write a point of sale client that uses a caching databases for all inputs used in transactions it picks up on the P2P network?

Then when you pay and it gets notice of payment, despite there being 0 confirmations, it can look to see if the input(s) were also used in other unconfirmed transactions.

That would not make double spending impossible but it would make it more difficult. The double spend attempt would have to be made after the purchase making the race condition more difficult to exploit.

[madmadmax]

Since bitcoin uses a peer to peer to network to get transactions to the miners, how hard would it be to write a point of sale client that uses a caching databases for all inputs used in transactions it picks up on the P2P network?

Then when you pay and it gets notice of payment, despite there being 0 confirmations, it can look to see if the input(s) were also used in other unconfirmed transactions.

That would not make double spending impossible but it would make it more difficult. The double spend attempt would have to be made after the purchase making the race condition more difficult to exploit.

Bitcoin already does that, the problem is what happens when the transaction doesn't propogate fast enough through the network, then half the network "believes" one transaction is faulty while the other believe the second transaction is faulty, ultimately discarding the latter transaction because it was signed after the first one.

[solex]

I too am coming to the conclusion that the zero-confirmation problem is best resolved with improved merchant software that detects a double-spend attempt and alerts the person working the till.

Numerous bars and shops are accepting BTC for small value transactions right now and this is working out ok. Fraud can never be stopped completely so merchants have to decide for themselves what level of risk is acceptable. Waiting an hour for a large value transaction is expected, such as when buying a car.
The green address idea will probably get used in some cases, but a small minority of merchants will need it.

Gavin posted this which is great to know:

On top of all that is a long list of new features and improvements I’d like to see get into a 0.9 release; the highest priorities on my wish list are:

“First double-spend” relay and detection. Detecting attempted double-spends as soon as possible is great for low-value, in-person transactions, and we should do more to support that use case.

https://bitcoinfoundation.org/blog/?p=204

[ElectricMucus]

Bitcoin will be replaced by a cryptocurrency supporting split-second confirmed transactions within a decade.

[madmadmax]

Bitcoin will be replaced by a cryptocurrency supporting split-second confirmed transactions within a decade.

+1

[justusranvier]

What merchants need to know in order to deal with double spends rationally is the cost to of successfully implementing a double spend attack.

There exists a P(x,y) where x is the number of confirmations and y is the value of the transactions, and P is the probability that a double spend attempt can be successfully such that the cost for the attacker is at or below y.

If P can be accurately estimated for a given transaction all a merchant needs to do is increase their prices accordingly.

If the odds of a profitable double spend for a given type of transaction is 1% then the rational merchant just raises the price by 1% to cover the losses and goes on with life. Maybe if P is high enough to start negatively impacting sales that merchant looks for technological solutions for reducing P (that don't cost more to implement than they produce in tangible improvements).

The problem is that nobody as far as I can tell is even trying to estimate P, or if they are then nobody is talking about it publicly.

[gmaxwell]

Probability is often the wrong way to think about adaptive attacks.

This isn't some wabbly toothpaste tubes going down an conveyor belt in a factory, where you can measure the rate at which they fail to get packaged and just account for it in your yield.

You might have some button on your website that costs a user nothing to hit but has a 1:10000 chance of paying them a Bitcoin.  You only get about 5000 users pressing that button on your site a year right now, and the cost of fixing the bug is 10 Bitcoin.  It sounds better to not fix it, or at least not make a priority of it— under the random model. Just increment your prices a little bit to cover the loss and you're good to go.

And indeed, the results would support that decision _until_ an attacker finds the button. And then they've pressed it 10,000,000 times in 10 minutes and you find yourself bankrupt.  These surprises are magnified by the fact that sometimes attackers take advantages of deep properties that you may not be aware of— things like button pressing being botnet-automatable. Toothpaste doesn't usually out think/research you, toothpaste isn't usually an expert who makes their living by failing to do what you expect them to do, toothpaste doesn't change its behavior just to make your day suck.

There are cases where you can armor against attacks by simply twiddling the prices, and cases where you can't. Actually delineating them can be hard because the distinctions depend not just on the details of your operation (can people automate transactions with you? can they attack you over and over again without you noticing? Are attacks which have a low cost to fail possible with you?) but on the attackers (can the partner with miners? or buy hashpower? can they get access to large amounts of funds? do they know where your bitcoin nodes are located? Can they attack multiple sites in parallel with one set of blocks? Will they still attack if it hardly makes them no money at all?). There is a lot more to things than just P(x,y).

[justusranvier]

I didn't say it was easy to estimate P, just that it is necessary.

Clearly any changes to the network which makes the cost of a double spend attack more deterministic makes it easier for merchants to price risk.