Suggested MAJOR change to Bitcoin

[kano]

Well the pool comment was there for a few reasons (one mentioned above by wareen)

Yes of late the hashing power has become WAY more centralised - and I use that word on purpose since it is the opposite of an important word in relation to the definition and goals of Bitcoin - decentralisation.



I guess there are also some more points for me to clarify:

Yes I am looking at small transactions.
Most transactions in the block-chain are small and having to wait for an hour or more for a small transaction to be accepted is definitely one of the issues that makes wider adoption of Bitcoin difficult.

This change gives vendor's the option to reduce transaction acceptance times but also allows them to keep the same acceptance times if they want.

However, it WILL reduce variance.

I would also suggest that there should be some standard acceptance of transactions based on the actual amount of the transaction
i.e. vendors should be saying that transactions in certain amount ranges have certain required confirmations - however that becomes a much more reasonable option with 2 minute blocks.
(obviously not to be enforced but certainly as a guideline)

[1715055273]

1715055273

[1715055273]

1715055273

[1715055273]

1715055273

[wareen]

While you can't be guaranteed I think many overestimate the risk especially for small transactions.

That may be so, but there is a reason why accepting 0 confirmation transactions is regarded as insecure. While there may be practical reasons why it is hard to exploit under normal circumstances, a determined attacker may still find a way to do it efficiently. Bitcoin just offers no inherent security below 1 confirmation.

Arguably the temptation for merchants to accept 0 confirmation transactions for increased customer experience is much lower when one confirmation only takes 2 minutes.
Also bear in mind, that there have been more than a few cases where no block was found for a whole hour. These outliers would be much less extreme as well.

I accept your points regarding the need for confirmations being overrated, but what about making mining for smaller pools more attractive?

That is a perk but not worth a hard break with compatibility of existing clients at least not IMHO.

I understand and I also have my doubts about "breaking the contract", but there are already some other proposals that would require a compatibility-breaking modification. I remember somebody suggesting putting them all together on a list and fixing a date far enough in the future where they all become activated. That way, improvements that would not justify breaking the compatibility by themselves could still be implemented, once the whole bunch of improvements or fixes was deemed worth it.

Keeping that in mind, we might want to argue about whether or not the change itself would be desirable - regardless of the breaking of compatibility.

[DeathAndTaxes]

Yes I am looking at small transactions.
Most transactions in the block-chain are small and having to wait for an hour or more for a small transaction to be accepted is definitely one of the issues that makes wider adoption of Bitcoin difficult.

Small transactions don't need confirmations.  Most merchants would be unwilling to wait 2-10 minutes either.

Imagine McDonalds drive through taking bitcoins (or vending machine, or some other machine like toll booth, laundry, parking garage).

A 2 minute wait (which due to variance could occasionally be 7+ minutes) is simply unviable.

A 2 minute block doesn't help that business.  Of course there is no reason a low value transaction like that needs any confirmations.

So
McDonalds under 2 minute block --- using 0-confirms
McDonalds under 10 minute block --- using 0-confirms

If this is an adoption issue is is more a PR and consumer/merchant education issue not a technical one that requires a breaking change to the protocol.

[kano]

Yes I am looking at small transactions.
Most transactions in the block-chain are small and having to wait for an hour or more for a small transaction to be accepted is definitely one of the issues that makes wider adoption of Bitcoin difficult.

Small transactions don't need confirmations.  Most merchants would be unwilling to wait 2-10 minutes either.

Imagine McDonalds drive through taking bitcoins (or vending machine, or some other machine like toll booth, laundry, parking garage).

A 2 minute wait (which due to variance could occasionally be 7+ minutes) is simply unviable.

A 2 minute block doesn't help that business.  Of course there is no reason a low value transaction like that needs any confirmations.

So
McDonalds under 2 minute block --- using 0-confirms
McDonalds under 10 minute block --- using 0-confirms

If this is an adoption issue is is more a PR and consumer/merchant education issue not a technical one that requires a breaking change to the protocol.

No I am not talking about McDonalds selling a $20 meal (yeah McDonalds isn't cheap)
I talking about every single current Bitcoin vendor I have seen.
I do not know of a single vendor that will accept anything at 0 confirms.
I'm sure there must be some, but I don't know who they are

... and I am certain you will not be able to sell the idea to any of them that they should accept transactions with zero confirms.
On the other hand, accepting them at a few lower difficulty confirms (higher difficulty than last year) would be WAY easier.

Can someone post a link to a list of some vendors that accept 0 confirmations?
I'd like to understand what demographic they are.

[wareen]

Small transactions don't need confirmations.  Most merchants would be unwilling to wait 2-10 minutes either.

True, and your McDonalds example illustrates that quite well. There probably is a line somewhere at about 10 seconds - everything faster than 10 seconds would work for "instant" payments, everything above does not make much difference if its a 2, 10 or 20 minutes.

But consider buying digital goods or Internet services. Digital merchants are also much more likely to be a victim of a Finney attack hence they should always refrain from accepting unconfirmed transactions! I think reducing the waiting time to two minutes when it comes to paywalls for articles or youtube-like videos might make a real difference in acceptance by users.

If this is an adoption issue is is more a PR and consumer/merchant education issue not a technical one that requires a breaking change to the protocol.

Well again, if we considered it an improvement it could at least go on a list of useful compatibility-breaking changes.

[DeathAndTaxes]

But consider buying digital goods or Internet services. Digital merchants are also much more likely to be a victim of a Finney attack hence they should always refrain from accepting unconfirmed transactions! I think reducing the waiting time to two minutes when it comes to paywalls for articles or youtube-like videos might make a real difference in acceptance by users.

I think you are missing the point.

To even have a 1% chance per block to execute a Finney attack currently requires 80GH/s of processing power.  

There is absolutely no reason (beyond FUD, urban legends, and misinformation) for any paywall to require confirmations.  Say you are running a porn site.  A monthly subscription of 5 BTC.  Is someone going to build a 80GH hashing farm so they have a  1% chance to steal some porn?  Really?  Now for the sake of argument lets say they do.  You WILL still find out in ~5 minutes.  Porn isn't irrevocable so you cut them off.  What did you actually lose?  5BTC?  Hardly.  More like 5 minutes of bandwidth.  Same thing w/ a copy of Angry Birds or web hosting.  Remember all these businesses currently are profitable w/ CC where the chargeback rate on digital goods is many multiples higher than the risk of a Finney attack.

Other digital services have even less risk of Finney attack.  Lets say World of Warcraft accepted Bitcoins.  Who would make an account just to use their 80 GH farm to steal one months service?  They could only play 5-10 minutes before detected.  When Blizzard catches them they delete the account.  What value would they gain unless they love playing lvl 0 characters over and over for eternity.  Likewise a Bitcoin lottery could allow 0-confirm ticket purchases but simply require 6 confirmations before making a winning payout.  So yes you could use your 80 GH farm to steal a ticket ... a ticket you can never win.

The only transaction that require confirmations are:
a) large value
 AND
b) instantaneous
AND
c) irreversible

Selling 80,000 BTC of Gold face to face needs 1+ confirmations.  An exchange needs 1+ confirmations.  A poker site might need 1+ confirmation.  Not for the deposit risk but to prevent someone making an attack by depositing money they don't have, playing and losing to create chaos and damage customer reputation.  Still even that risk could be mitigated by a hybrid deposit.  You can deposit any amount but only first 20 BTC can be wagered without confirmation (getting you started money).  You gain access to the rest of the funds after 1+ confirms and make make withdrawal after 6+ confirms.


Just because merchants so far have been very foolish in running their businesses doesn't mean the blockchain needs to be modified to accommodate misinformation.   In all those examples an attack is very unlikely and IF one happened the loss is of little or no value.  The fear of 0-confirm double spends on small transactions is just that unsubstantiated fear.

[kano]

Of course no one would pay for a 80GHash farm to steal $10 ...

People create mining farms to perform elicit things by stealing the CPU/GPU power, not by paying for it.

[DeathAndTaxes]

Of course no one would pay for a 80GHash farm to steal $10 ...

People create mining farms to perform elicit things by stealing the CPU/GPU power, not by paying for it.

Even 80GH of stolen computational power has more value than $10 in stolen goods.

[SgtSpike]

I think DeathAndTaxes has brought up some very good arguments as to why 0 confirmations is just fine to just about every transaction type.  I've always had a hunch that direction, but never bothered to do the research and figure out why.

But, the fact of the matter is, I've never heard of anyone successfully executing a double-spend attack.  Until we do hear of that happening, why are we so worried about it?

I agree that merchants should seriously look in to using 0-confirmation transactions.  It would help Bitcoin become more viable, and encourage people to use Bitcoins for purchases.

[HostFat]

CUT

I saved your message
It should be added to the wiki

[MoonShadow]

There are numerous reasons for not reducing the target interval, both present and future.  No network would be able to handle the propagation delays with a target of two minutes and a transaction volume anywhere near what Paypal processes on average.  There have been numerous threads in the past about how to process real time bitcoin transactions via channels external to the bitcoin network, as well as simply gauge the risks of accepting an unconfirmed transaction at face value for lower value transactions.

In short, no.

[OgNasty]

But, the fact of the matter is, I've never heard of anyone successfully executing a double-spend attack.  Until we do hear of that happening, why are we so worried about it?

I agree.

As far as the original topic is concerned, I think I would be more likely to solo mine if there was 5 times the odds I'd find a block, even if the payout was smaller.  That might be good for the network to have more solo miners...

[kano]

I think DeathAndTaxes has brought up some very good arguments as to why 0 confirmations is just fine to just about every transaction type.  I've always had a hunch that direction, but never bothered to do the research and figure out why.

But, the fact of the matter is, I've never heard of anyone successfully executing a double-spend attack.  Until we do hear of that happening, why are we so worried about it?

I agree that merchants should seriously look in to using 0-confirmation transactions.  It would help Bitcoin become more viable, and encourage people to use Bitcoins for purchases.

Well the double spend has happened on one of the exchanges with a scamcoin (not sure which one)
As I mentioned before the scamcoins have had their uses - one being to show actual attempts (and success) at attacking the network.

[MoonShadow]

a determined attacker may still find a way to do it efficiently.

If such a method exists, sure.  But once that method is known, there will be countermeasures.  The double-spend attack is defensible, even with zero confirms, if the vendor has good connectivity.

 Bitcoin just offers no inherent security below 1 confirmation.

That's not true, it's just that the current client doesn't presently offer sidechannel checks.  For example, a vendor's client could accept a zero confirm transaction at face value with very little risk by doing the following...

1) check that the transactions presently have the funds according to the client's own copy of the blockchain (presently done)
2) send the transaction out to all of it's peers except one, and wait until it returns to itself via the final peer.  (not presently done)  

If the saved peer returns the transaction, or no double spends are discovered from this peer in ten seconds, then assume that the transaction is valid and give the guy his Big Mac.  If there is a double spend attack underway, then either the saved peer will return the transaction that your client sent, or another one.  If it sends another one, deny the purchause.  If it sends back your transaction, it doesn't likely matter that there could be another transaction out there, because your's dominates the network.  The finney attack alters the picture somewhat, but unless you're trying to sell a new car via a drive up window, the values justify the (small) risks of accepting that transaction.  If you are selling stuff online, you can accept the transaction tenatively; and cancel the shipment of goods if the transaction fails.  If you are selling something digital in nature, such as an mp3, simply use delayed redirection for the download to allow the above ten second checks to occur.

[SgtSpike]

^^ More good thoughts from MoonShadow. 

[MoonShadow]

I think DeathAndTaxes has brought up some very good arguments as to why 0 confirmations is just fine to just about every transaction type.  I've always had a hunch that direction, but never bothered to do the research and figure out why.

But, the fact of the matter is, I've never heard of anyone successfully executing a double-spend attack.  Until we do hear of that happening, why are we so worried about it?

I agree that merchants should seriously look in to using 0-confirmation transactions.  It would help Bitcoin become more viable, and encourage people to use Bitcoins for purchases.

Well the double spend has happened on one of the exchanges with a scamcoin (not sure which one)

I think you might be thinking of the supernode being spoofed in Solidcoin, which was a different event.  Bitcoin doesn't use supernodes for this exact reason.

[DeathAndTaxes]

Well the double spend has happened on one of the exchanges with a scamcoin (not sure which one).  As I mentioned before the scamcoins have had their uses - one being to show actual attempts (and success) at attacking the network.

Not all attacks are the same and only 1 is prevented (somewhat) by a shorter block.

There are essentially 4 methods to defraud a block chain based currency:

1) "the 51% attack"  
This is the big one (and the method used to defraud the exchanges).  Start work on a block chain in private (the attack chain).  Exploit a irreversible transaction (like deposit to exchange, trade, withdraw in another currency).  Now include an alternate version in your attack chain.  When your attack chain is longer than the "legit chain" (which is inevitable if you have 51% of hashing power) broadcast your alternate chain.   The deposit to the exchange "disappears".  You keep the money and have equivalent value in an alternate currency.  Doubled your money and exchange loses the value of the deposit.  

Countermeasures:
Actively looking for a double spend: FAIL (can't be detected)
Waiting for 1 confirmation: FAIL (block will be reversed)
Waiting for 6+ confirms: FAIL (block will be reversed)
Ensuring no attacker has 51% of network:  PASS

2) The confirmed double spend.
With less than 51% hashing power you eventually will fall behind the legit chain (exact opposite of 51% attack).  However you may be able to reverse confirmations.  It requires some luck and significant fraction of hashing power (10% to 30%+).  The longer the confirmation chain the less likely you will be able to reverse the chain.  It is to prevent this attack (not 51% attack that we recommend 6+ confirms).  Satoshi paper does some analysis on how difficult it is to reverse transactions depending on how buried they are in the

Countermeasures:
Actively looking for a double spend: FAIL (can't be detected)
Waiting for 1 confirmation: FAIL (although still difficult as it requires massive hashing power)
Waiting for 6+ confirms: PASS (Increasingly improbable you can be defrauded as # of confirms increase)
Ensuring no attacker has 51% of network:  N/A

3) The Finney Attack
Attacker includes a transaction in a block he is mining (like transferring coins from himself to himself).  When he solves a block he spends those same coins in an alternate transaction and then publishes the block.  Since his transaction is already in the block it wins and the double spent merchant loses.   The opportunity for this attack is based on hashing power.  An attacker w/ 1% of global hashing power will have a 1% chance of pulling off the attack on each block.  This is the most "dangerous" of the attacks because it is theoretically plausible to pull off and will have no warning.  However it is unlikely it would be used on trivial purchases simply due to the cost.  Merchants need to evaluate if they are a potential target.  Those who aren't can accept 0-confirm transactions and those who are should wait for 1-confirm.

Countermeasures:
Actively looking for a double spend: FAIL (can't be detected)
Waiting for 1 confirmation: PASS (highly improbable attacker can get 2+ confirms)
Waiting for 6+ confirms: Not necessary but ultra cautious merchants could wait for 2+ confirms.
Ensuring no attacker has 51% of network:  N/A

3) The 0-confirm double spend
Attacker submits 2 transactions for same coins to the network.  If merchant is actively looking for double spends this is almost impossible to pull off.  Merchant could simply wait for transaction to arrive not from customer/attacker but from one of its remote peers (indicating transaction has propagated the network).  Merchant can make this more difficult by waiting for multiple confirmations and waiting say 60 seconds to see if any alternate transaction is seen.

Countermeasures:
Actively looking for a double spend: PASS (can be detected and avoided)
Waiting for 1 confirmation: Not necessary however merchants should evaluate the value of their goods & services
Waiting for 6+ confirms: Not necessary however merchants should evaluate the value of their goods & services
Ensuring no attacker has 51% of network:  N/A

So as you can see a shorter block really doesn't prevent any of the attack scenarios.  A 2 minute block isn't short enough to make real time confirmations and thus merchants will need to learn to defend against 0-confirm attacks.  A 2 minute block does prevent Finney attack but only if merchant is willing/able to wait 2+ minutes.  Very few transactions are vulnerable to this type of attack thus the value of making a breaking change seems inconclusive.

[wareen]

But consider buying digital goods or Internet services. Digital merchants are also much more likely to be a victim of a Finney attack hence they should always refrain from accepting unconfirmed transactions! I think reducing the waiting time to two minutes when it comes to paywalls for articles or youtube-like videos might make a real difference in acceptance by users.

I think you are missing the point.

You do understand that to even have a 1% chance per block to execute a Finney attack currently requires 80GH of processing power.  

There is absolutely no reason (beyond FUD, urban legends, and misinformation) for any paywall to require confirmations.

Well, that depends on what the paywall is for, but as a smallish solo miner I'd sure like to get a few songs/ebooks/games for free every month from every website that accepts 0 confirmation transactions. The combined incentive for an attacker might make this quite attractive! But then again, this would promote solo-mining which is probably a good thing for Bitcoin after all

The thing with websites and digital goods is that such an attack could be completely automated - the miner doesn't have to do anything, just make a small script that quickly buys all kinds of stuff before he issues a block that reverses the transaction. Sure, merchants could delay the acceptance to make it riskier for the attacker but I would be really careful before you suggest that there is absolutely no reason for such sites to require confirmations.

Your point is that double spending is largely a non issue - I think it is dangerous to start relying on that, simply because Bitcoin itself offers absolutely no guarantees for that. Once enough sites accept 0 confirmation transactions it will be exploited sooner or later! Such an incident might severely impact Bitcoin's reputation and I'd rather not see that happen.

Also pointing at the fact that it has not happened yet is a bit short-sighted IMHO, Bitcoin is still very little used. Just imagine you would know of a sure way to anonymously make an unlimited amount of small valued Paypal transactions...

This has nothing to do with whether we should change the block generation rate - automatically accepting 0 confirmation transactions at websites _is_ dangerous!

I acknowledge the fact that there exist ways to mitigate the risk, but please do not advertise 0 confirmation transactions as safe for automated websites before these are actually implemented, enabled by default and proven to work.

[wareen]

Very few transactions are vulnerable to this type of attack thus the value of making a breaking change seems inconclusive.

Once again: if the change was deemed beneficial, it wouldn't need to justify the breaking change all by itself but if we have this discussion now, we can potentially implement this once a breaking change is necessary for other reasons.

[DeathAndTaxes]

Merchant will need to learn to accept that.

1) You can simply pirate movies, books, games.  So the ideas that someone will use a Finney attack is somewhat dubious.  Far easier to just launch bittorrent.

2) Even IF the block time was 2 minutes is a paywall going to make user wait 2 minutes?  Really?  The tiny risk is simply not worth it.

3) There is always risk.  1+ confirms can be reversed with significant hashing power.  1000+ confirms can be reversed w/ 51% attack.  No CC transaction is risk free.  Digital goods certainly are more risk for CC than other forms.

I never said 0-confirms are risk free I said that the risk was overblown AND that changing the block time from 10 min to 2 min doesn't materially improve the situation.  Really the only attack vector it helps is against a Finney attack but even there it only helps for merchants who are willing to wait for 2 min block but not a 10 minute block.  Those waiting for 10 minute block are already "safe" and those unwilling to wait 2 min don't gain anything.

The reality is life has risk and rather than trying to develop some perfect ultra lock down system with 0.0000000000000000% risk it is better to simply design a system that mitigages risk.  If the fraud cost is 10% of that compared to CC then Bitcoin is a huge improvement.    The goal of a business should be to maximize profit (after fraud which is a cost of doing business) not trying to get fraud zero.