Topic: Best practice for fast transaction acceptance - how high is the risk? (Read 26567 times)

I don't get what gold has to do with fast transactions.
There's no such thing as intrinsic value, but there's no need to discuss it here.
It's being discussed here and here.

Read through all of this and here is the solution to fast transactions without the fear of loss due to double spends.  Simply accept any transaction with the value below REWARD * Gold value/2.  (NOTE: I hate valuing items with no intrinsic value with another item with no intrinsic value - Gold is the real constant here not dollars.)

So long as minners are getting paid fairly for the job they do it's not a problem.

I don't know if it would be feasible, but here's a proposal for real time confirmation:

https://bitcointalksearch.org/topic/a-block-chain-for-real-time-confirmations-4382

If it won't work, can you explain why?

Thanks [mike].  The new service will have an API for executing purchases, so an attacker could easily choose the time of his attack and execute the purchase very rapidly.  It looks like I'll be waiting for confirmation blocks


In my particular case, a customer only needs an email address, so I'm not sure I can do much to prevent transaction splitting without also ruining the experience for legitimate customers.  I'll definitely give it some more thought though.

You're still open to the 'finney attack' described earlier, if whatever you're selling is worth having somebody mine on an ATI 5970 for a while it's possible you could be defrauded. For that attack to work the attacker has to be able to choose the time of his transaction, and you have to accept it very quickly.

As the mining difficulty goes up, this attack becomes harder and harder to pull off. And it's going up very fast right now:



So I guess you could try and weigh up the cost of defrauding you vs the cost of being able to successfully mine blocks.

I'd suggest re-examining the idea that you can't detect if it's the same user making two smaller transactions to get below the limit. It's rare that a business really can't have any trust in its customers at all.

The question of accepting transactions without confirmation is important for a service I'm working on.  I can't require confirmations for only purchases above $50 because a buyer could structure his purchase as two $25 purchases and I'd have no way to detect it.  So given the current Bitcoin network, would something like the following work?

• Generate a new Bitcoin address for the purchase
• Wait for a payment transaction (T) to that address to arrive
• Wait 1 minute for the transaction to propagate through much of the network
• Choose N random nodes in the network
• Ask each one if it knows about T
• Using statistical sampling calculations, determine a confidence level (P) that T is known to all nodes
• if the probable loss from a double-spend is less than the probable profit, the purchase is allowed without confirmations; otherwise, confirmations are required

I admit to knowing little about the technical details of possible double-spend strategies, so can someone point out how this technique could be circumvented?

For supermarkets it would seem that there is enough time between deciding to go there and checkout to make sending coins ahead the best solution. A supermarket is no more likely to fail to send your excess bitcoins back than it is to fail to give you the change from your $100 bill after all. However places like gas stations would be much more likely to need a faster solution.

Edit:I should acknowledge https://bitcointalksearch.org/topic/suggestion-introduce-penalty-for-attempted-double-spend-3168 where jav advocates something amounting to shunning.

An effective way to discourage double spending attempts would be to propagate both attempted transactions and then "shun" the inputs.

"Shunning" is where the network mutually agrees that it will never accept as valid any transactions or blocks which contain a shunned address or shunned TxOut. If shunning is not unanimous then any transactions by non-participants, which transfer money from a shunned address or use a shunned TxOut as an input to a transaction, are themselves shunned.

In the shunning community, the value of these shunned transactions or addresses can be redistributed among themselves as they wish or (preferably) considered forever gone in an even more irrevocable fashion than if the private key had merely been lost.

If a merchant has accepted a transaction and has handed over the goods before a transaction has been incorporated into a block then it's cold comfort that the double spender's money is shunned after the double spend is detected. The merchant is still owed payment for the goods. The solution is as follows:

Firstly, the merchant should require that the transaction paying him for the goods should be from a TxOut or an address that holds many more bitcoins than the value of the transaction. That is, the "change" portion of the transaction that returns the "unspent" portion of the TxOuts referenced back to the payer should be much larger than the value transferred to the payee. If the payer attempts a double spend then the payer runs the risk that all the bitcoins will be shunned even though the value of the attempted fraud is much lower. This scheme has the advantage that it requires little change to the existing infrastructure.

Optionally, in the event of a double spend, the network could elect to honour the payment part of the transaction and shun the "change". This means that the merchant is not out of pocket while the fraudster is punished. In order to signal which is payment and which is "change", the payer structures the transaction such that the "change" is paid to an address that was also used to sign the crediting transaction. Care needs to be taken with such schemes to make sure that double spending remains uneconomical when the double spender acts in undetectable collusion with one or more of the double-spent merchants.

A supplemental scheme would give the sender feedback about the propagation of the transaction across the network but it involves much more infrastructure change and network traffic. We observe that a minority of miners generate the majority of blocks. If the merchant can see that the transaction has been accepted by these miners then he is confident it will not be double spent. The proof of a miner's power is the number of blocks it generates in a given time. If the generated blocks always credited the same address for a particular miner then we would know who the biggest miners were (at the cost of a big loss of pseudonymity for the miner). The merchant would require that the payer construct a transaction which also requires some proportion of the largest miners to sign that they have received the transaction and will include it in their next block, in return for some fee. When the merchant sees the miner's receipts arrive across the network then he is comfortable handing over the goods.

Note that the last supplemental scheme is tentatively included merely to spark off ideas as it is ugly. I would also warn against shunning as, although simple and powerful it easily results in fragmentation and I feel that the schisms it facilitates could weaken or even destroy Bitcoin.

ByteCoin  

So far all of this discussion has pointed out one fact to me.  On small transaction sizes these attacks are not worth it.  On larger transactions you can usually wait. 

With cash you can get counterfeits  (I have lost a few $20 bills due to that)
With checks they can bounce (and this is MUCH easier to do then with bitcoin)
With credit cards they can be charged back (while rare, this has happened to most merchants)

I think most people can take the risk of a double spend attack on $50 or less.  You would as a merchant also know (by face at least) the person who did this to you and you would not deal with them again. 

First, "potentially forking" changes like that would be structured as:

if (block number < SOME_BLOCK_NUMBER_IN_THE_FUTURE)
  ...old rules
else
  ...new rules

Assuming a super-majority of people agree with the change and upgrade before we get to SOME_BLOCK_NUMBER_IN_THE_FUTURE, the switch will happen smoothly.

Is there a chance of changing?  Sure, but I think anybody who wants to make such a fundamental change would need to do a LOT of testing-- maybe spin up or recruit a few hundred machines all over the world on a test network, have them mine and simulate transactions to each other (ideally with similar volume to the real network) while going through the transition and making sure there weren't any unintended consequences.  And convince a super-majority of people that the benefit of their potentially forking change outweighs the risk of disrupting the network if there's some consequence they didn't think of or that their test network didn't simulate properly.

Practically, would dropping the block time from 10 minutes to 1 minute be worth the risk?  I doubt it.  1-10 minutes (1 would be the average, get unlucky and it could take 10) is still too long to wait for small-value in-person transactions.

RE: democratic organ:  bitcoin is a kind of a democracy.  Whatever code the majority of miners/nodes is running makes the rules.

Many important discussions in this thread. :-) Some more thoughts:


What you are proposing is definitely a nice way of using Bitcoin's feature of additional constraints for transactions, I like it. But your suggestion really just boils down to depositing money somewhere. Either at the grocery store itself or a third party, mybitcoin-like service. And the whole (trust) problem with depositing money has been pointed out before.

I find it worth repeating though ( :-P ): I'm still not convinced that a mybitcoin-like payment processor is something to look forward to. I agree that having it backed by Bitcoins and being easy to audit is a step in the right direction, but that only solves some of the problems with today's central payment processors. You just have to look at the current situation: Even if PayPal was backed by Bitcoins (in theory not too far-fetched), it could still shut down accounts at random and be a headache to deal with. And to those who argue that there could be several mybitcoin-like services which interact with each other: There is also no reason why Google-Checkout couldn't also accept Amazon Payments and then just transfer any outstanding differences directly between Google and Amazon. Doesn't happen though. As soon as a payment processor is big enough, it rather tries to compete than to cooperate.


I have been thinking the same thing, that 10 minutes maybe really is just too much on the conservative side. I mean in terms of money flow the current situation could be kept (seems to work fine right now, so no reason to change it). But instead of 50 BTC per block, there could be 5 BTC per block and then a block every minute. It would allow for a more fine-grained decision on how many confirmations one need. If you want the old level of security you would then just have to wait for 60 blocks.

I guess the block rate has been discussed before frequently and there are many good arguments for the different sides. What this really makes me wonder: Is there even a chance of this ever changing? How would it change? Someone with access to the official repository committing it and releasing it? and would that result in an immediate fork from people who think it's a stupid idea? I wonder if Bitcoin needs some sort of democratic organ to make a decision like that.

That's my conclusion.  One of the websites I'm planning on releasing RSN will feature 0-confirmations.  Average transaction will be ~2 BTC.

I also think people will notice if double-spends start appearing with any frequency.

X and Y are both addresses I control. The point of what I was describing is not to double spend, it's to screw about with the network by exploiting this new idea of rejecting suspicious blocks. As Hal said any change to the voting rules needs really careful thought to avoid opening up exotic attacks, including new types of DoS.

But yeah, just ignoring this problem sounds good to me :-)

One more thought:  the "finney attack" can only be profitable if the reward from cheating is greater than (reward of mining times the probability your block will be rejected because you delay announcing it while you "run down to the store").

Reward for block is currently $50, that will (hopefully!) continue to rise for the next decade or two.

Say it takes you 5 minutes to complete a transaction at the corner store (half the average block gen time)... today you'd have to make a $25-or-greater purchase just to break even.

Seems likely this attack will be completely impractical for transactions under $200 when the block reward is worth more than $400.  0-confirmations (just wait N seconds to look for a quick double-spend) for any transaction under $200 seems "good enough" to me.