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.
Topic: Instant Bitcoin confirmation time (IDEA) (Read 28749 times)
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).
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).
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.
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.
Bitcoin will be replaced by a cryptocurrency supporting split-second confirmed transactions within a decade.
+1
Bitcoin will be replaced by a cryptocurrency supporting split-second confirmed transactions within a decade.
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
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
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.
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.
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.
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.
- snip -
I'm chatting with children or grown men/women that never matured (e.g. DannyHamilton).
- snip -
I'm chatting with children or grown men/women that never matured (e.g. DannyHamilton).
- snip -
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?
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?
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.
I'm sorry, but you are looking for a solution to a problem that really does not exist. That's the bottom line.
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.
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?
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.
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.
You know, the more I've been thinking about this the more I'm convinced that confirmation time is an imaginary fear.
When someone sends me bitcoins, I see that they have sent it almost instantly. That doesn't validate it is not a double spend but it does validate that they have the bitcoins needed to spend, does it not?
Doesn't the P2P network block a forgery transaction that has a made-up input? Wouldn't my client know the input was invalid?
So at least I know the input is valid. What I don't know is if the sender will double spend.
That's almost exactly the same thing with credit card authorizations
They may be instant but I don't know the value is really mine for some time. The authorization can be cancelled and even after it is paid it can still be reversed. How is that any less risky than someone doing a double spend?
There's no difference between accepting 0 confirmations and accepting with just a credit card auth. None at all. In both cases the vendor is taking a risk that they won't get the money.
At least with bitcoin the window of time is much smaller for the vendor to actually know the payment is good.
When someone sends me bitcoins, I see that they have sent it almost instantly. That doesn't validate it is not a double spend but it does validate that they have the bitcoins needed to spend, does it not?
Doesn't the P2P network block a forgery transaction that has a made-up input? Wouldn't my client know the input was invalid?
So at least I know the input is valid. What I don't know is if the sender will double spend.
That's almost exactly the same thing with credit card authorizations
They may be instant but I don't know the value is really mine for some time. The authorization can be cancelled and even after it is paid it can still be reversed. How is that any less risky than someone doing a double spend?
There's no difference between accepting 0 confirmations and accepting with just a credit card auth. None at all. In both cases the vendor is taking a risk that they won't get the money.
At least with bitcoin the window of time is much smaller for the vendor to actually know the payment is good.
The difference is that the credit card company will not cancel your every transaction every day for prolonged amounts of time, generally speaking canceling a transaction is a "one time thing" only as you need a valid reason for cancellation, if you get caught canceling on valid transactions they could contact the police.
I have reviewed the green address concept and it is completely useless, ultimately a burden on the blockchain that works using a concept that is illogical and stupid.
You know, the more I've been thinking about this the more I'm convinced that confirmation time is an imaginary fear.
When someone sends me bitcoins, I see that they have sent it almost instantly. That doesn't validate it is not a double spend but it does validate that they have the bitcoins needed to spend, does it not?
Doesn't the P2P network block a forgery transaction that has a made-up input? Wouldn't my client know the input was invalid?
So at least I know the input is valid. What I don't know is if the sender will double spend.
That's almost exactly the same thing with credit card authorizations
They may be instant but I don't know the value is really mine for some time. The authorization can be cancelled and even after it is paid it can still be reversed. How is that any less risky than someone doing a double spend?
There's no difference between accepting 0 confirmations and accepting with just a credit card auth. None at all. In both cases the vendor is taking a risk that they won't get the money.
At least with bitcoin the window of time is much smaller for the vendor to actually know the payment is good.
When someone sends me bitcoins, I see that they have sent it almost instantly. That doesn't validate it is not a double spend but it does validate that they have the bitcoins needed to spend, does it not?
Doesn't the P2P network block a forgery transaction that has a made-up input? Wouldn't my client know the input was invalid?
So at least I know the input is valid. What I don't know is if the sender will double spend.
That's almost exactly the same thing with credit card authorizations
They may be instant but I don't know the value is really mine for some time. The authorization can be cancelled and even after it is paid it can still be reversed. How is that any less risky than someone doing a double spend?
There's no difference between accepting 0 confirmations and accepting with just a credit card auth. None at all. In both cases the vendor is taking a risk that they won't get the money.
At least with bitcoin the window of time is much smaller for the vendor to actually know the payment is good.
[...] from a trusted service [...]
This is where it totally fails. I wan't to be able to pay for my bread from my loot directly to the one handing the bread to me, without having to trust a centralised trusted node - aka a bank.
You, as the spender, don't need to trust the green address service at all, and are fully in control, that's the point of all the legwork with the 2-of-2 signatures. The worst that can happen is the service goes down, or tries to freeze your funds, in which case you can recover all your money after a couple days. Hell, you could event use 2 services at once in this process, with a 2-of-3 multisig, and then they'd both need to go down for you to be in any trouble (they'd have to coordinate together to prevent double spends).
The only trust that's necessary here is for the merchant to trust that if a green address service co-signs a transaction, that they'll only do that once, to avoid double spends. It's very straightforward, and almost impossible for a green address service to accidentaly mess that up.
If a merchant thinks that such a service will betray that trust (provably showing that they are untrustworthy, ruining their reputation and exposing themselves to legal action) just for this very specific transaction, then they're probably selling something really expensive (like a house), and should wait a few blocks.
Like I said before, it's completely unnecessary for now, because in practice zero-conf is safe for <10BTC transactions.
If it becomes unsafe for some reason, we can solve it with the existing tools we have (no soft/hard fork), without need for more than a minimum amount of merchant to service trust.
The business model for such a service would probably look something like:
- Making green addresses and spending from them is completely free/anonymous/all the good things.
- As a merchant, access to the spend verification service costs a small monthly fee.
BitPay could probably roll their own, and provide it as part of their service.
I don't think we can realistically do better than that, even with a hard fork. Consensus is hard.
The solution is green address.
Actually the solution is to not worry about it, it is really just another form of shoplifting. People who want to steal will find a way, and going through the register line is a bad way to do it because most places you will be caught on camera and eventually caught by law enforcement.
But double spends will be rarely attempted and I suspect the losses will likely be less than what is currently lost in debit/credit card transaction fees and chargebacks.
True. Trust and then Green addresses which is another form of trust. And green addresses are not a problem for the decentralized idea of bitcoins since they are based on trust and not mandates. Actually the solution is to not worry about it, it is really just another form of shoplifting. People who want to steal will find a way, and going through the register line is a bad way to do it because most places you will be caught on camera and eventually caught by law enforcement.
But double spends will be rarely attempted and I suspect the losses will likely be less than what is currently lost in debit/credit card transaction fees and chargebacks.
Green addresses are a bad idea, currently the Bitcoin network doesn't try to resolve double spends in any way, using my method we could at the very least reach a lower rate of scammers.
The way I forsee Green Address's working -
Company X offers green address.
I get account with Company X - meaning they know my personal information so they can sue my sorry ass if I rip them off.
Company X provides a plugin for my client. When I want to pay from a green address, I check a box. What it actually does is send bitcoins to the company I have account with who then sends to the merchant.
Merchant trusts that Company X will not double spend and Company X takes the risk that I won't double spend. A risk they take as part of membership or added fee I pay (say 1.5% on top of transaction).
Right now there is no Company X as far as I know, but when there is a need, it will happen.
The bitcoin URI that I scan with my phone could even have a payment parameter in the QR code to use a green address.
When the transaction confirmation time becomes a problem, services like that will pop up.
[...] from a trusted service [...]
This is where it totally fails. I wan't to be able to pay for my bread from my loot directly to the one handing the bread to me, without having to trust a centralised trusted node - aka a bank.
I've been trying to find ideas for weeks, now, and even though I'm progressing, none of them has convinced me.
The major issue being that miners rule.
I tried to go with a pre-confirmation chain by full nodes (clients).
But when the TX is accepted by a miner, how can it check if there is no longer pre-confirmation chain on the network for the same unspent output?
Another option I'm left with, currently, is to have secured hardware devices, such as today's credit card, that would require you to enter a password for each payment, and that would not be possible to hack too easily. If not easier to hack than a credit card, then it's all good.
Of course, such a device implies you would not know your own private keys, to avoid double spend, but just a password (a pin code equivalent) to unlock them all.
And it would imply that you trust the issuer of such devices.
Raaaaaaah!!!!! Back to square one.
Did someone actually came out with anything on that topic, apart from the zero confirmation suggestion ?
PS : This is similar to another issue raised here : https://bitcointalksearch.org/topic/split-up-transactions-by-default-268412
Based in part on https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit. Disclaimer: not tested, I may have made mistakes in designing it.
Alice: spender
Bob: merchant
George: green address service
1. Account setup:
a. Alice and George create private keys and make a 2-of-2 multisignature address.
b. Alice creates, but keeps private, a transaction (Tx1) depositing some funds into the address. She sends the hash of it to George.
c. George creates and signs a transaction (Tx2) refunding Tx1's funds back to Alice, with a locktime of a week or so. He sends that back to Alice.
d. Alice signs Tx2, keeps it, and broadcasts Tx1. The green address is now funded (after a few confirmations).
2. Spending with a merchant:
a. Alice creates and signs a transaction (Tx3) sending money to Bob. She sends the transaction to George. The change address can be a green address like in step 1, or it can be a regular address.
b. George checks that the transaction is the first one spending the output, and that Tx2 isn't valid for at least 6 blocks from now. If so he signs and broadcasts it.
c. Bob sees the transaction, he can then check that it is a green address from a trusted service (Either by querying an API, or seeing the broadcast being sent from George's green node).
d. Done
3. Taking money out
a. If George is still operational and not an asshole, Alice can just use the spending technique in step 2 to withdraw her funds.
b. If not, she has to wait until Tx2 becomes valid, then broadcast it.
4. Refreshing the account
a. Everytime Alice comes online and Tx2 is becoming valid in less than some given time frame (say 2 days), she and George repeat step 1 to create a new green address, and transfer the funds from the old one.
b. Because the funds came from a green address, they can't be double spent, and so the new address is immediately valid to use for spending.
Obviously, all of this needs to be automated by the wallet in order to be usable by people.
There's a sweet spot to be picked for the withdrawal delay and the refresh period. The shorter they are, the more fees are spent just keeping the funds rotating, and the more often Alice has to come online to refresh the funds. The longer it is, the greater the time during which George can cause the funds to become unavailable.
But that's the basic idea. Unstealable, unfreezable green addresses.
Alice: spender
Bob: merchant
George: green address service
1. Account setup:
a. Alice and George create private keys and make a 2-of-2 multisignature address.
b. Alice creates, but keeps private, a transaction (Tx1) depositing some funds into the address. She sends the hash of it to George.
c. George creates and signs a transaction (Tx2) refunding Tx1's funds back to Alice, with a locktime of a week or so. He sends that back to Alice.
d. Alice signs Tx2, keeps it, and broadcasts Tx1. The green address is now funded (after a few confirmations).
2. Spending with a merchant:
a. Alice creates and signs a transaction (Tx3) sending money to Bob. She sends the transaction to George. The change address can be a green address like in step 1, or it can be a regular address.
b. George checks that the transaction is the first one spending the output, and that Tx2 isn't valid for at least 6 blocks from now. If so he signs and broadcasts it.
c. Bob sees the transaction, he can then check that it is a green address from a trusted service (Either by querying an API, or seeing the broadcast being sent from George's green node).
d. Done
3. Taking money out
a. If George is still operational and not an asshole, Alice can just use the spending technique in step 2 to withdraw her funds.
b. If not, she has to wait until Tx2 becomes valid, then broadcast it.
4. Refreshing the account
a. Everytime Alice comes online and Tx2 is becoming valid in less than some given time frame (say 2 days), she and George repeat step 1 to create a new green address, and transfer the funds from the old one.
b. Because the funds came from a green address, they can't be double spent, and so the new address is immediately valid to use for spending.
Obviously, all of this needs to be automated by the wallet in order to be usable by people.
There's a sweet spot to be picked for the withdrawal delay and the refresh period. The shorter they are, the more fees are spent just keeping the funds rotating, and the more often Alice has to come online to refresh the funds. The longer it is, the greater the time during which George can cause the funds to become unavailable.
But that's the basic idea. Unstealable, unfreezable green addresses.
Jump to: