Topic: Suggested MAJOR change to Bitcoin - page 5. (Read 9442 times)

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.

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.

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.

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

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.

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.

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 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.

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)

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

To pull off a non-Finney double spend an attacker would need to
1) Pay merchant A with transaction A.
2) Pay merchant B with transaction B.
3) Ensure merchant A receives transaction A.
4) Ensure merchant B receives transaction B.
5) Finish both transactions

all before either transaction B is seen by merchant A or transaction A by merchant B.  That is pretty tough to do.  A merchant even waiting 60 seconds make it much tougher.  If transaction B is seen by merchant A 48 seconds later well merchant A gets to keep the money (50% chance of the money) and attacker loses.

Short blocks are a concept which sounds good so alt-coins use them to be "different" but don't really solve any significant real world issue.




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

You can't fake a transaction.  Digital signatures prevent that.

You can only double spend it. The hashing power of the network prevents that.

A phone full of FPGA does nothing to alter either scenario.  Hell owning 10% of global hashing power doesn't alter either scenario.

Well, maybe 0 is a bit extreme, but without relying on any out-of-band checking mechanism you cannot assess the degree of security of the transaction and this uncertainty does not change for 10 minutes.

As soon as you have 1 confirmation (no matter at which block generation rate), you have a pretty well defined degree of security.

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

Yeah, haha, anti-social bitcoiners.

The chance that the guy you meet in starbucks to buy coins from is going to double spend on you is about the same chance that the barista flips out and murders you both. For $10k+ value tx with complete strangers you can wait an hour (or 10 min) to call it clear, or use a green address type service etc.

This is no where near worth a breaking change.

Sure, specially if you compare with Visa or Mastercard chargebacks time limits of 120 days.
Anyway, whats the problem with green address technique ?

I am not proposing to replace bitcoin, but rather to improve it but also not change the essential things.
What I am proposing would be a way for receiving side transaction fees, as a bounty to do additional calculations on the transaction which are not included in the blockchain but just to secure against fraud. It wouldn't have to be much just as much so an attacker couldn't fake a transaction with a phone full of fpgas. (in case were you buy something at the counter where it really has to go fast)

Where do you get the idea that you have essentially 0 security without a confirmation?

The need for confirms is overstated.

1) Non-finney double spend attack is very difficult to perform.  Even an instant delivery merchant can wait 60 seconds to look for second confirmation.

2) Double spend attack (not finney attack or 51% attack) is risky.  If merchant detects you then you lose your funds and merchant gains.  This is unlike virtually all other forms of conventional financial fraud where likely you are using stolen funds.   This has to reduce the propensity for even attempting double spends

3) Finney attacks require significant computational power and to justify that power would require large transaction sizes meaning that while someone could Finney attack a copy of Angry Birds for 1.5 BTC it is unlikely that will happen.

4) No form e-commerce is without fraud but the risk of a double spend is significantly less than the cost and risk of CC fraud.

Large transactions require multiple confirms but waiting an hour on large transactions isn't much of a "problem".
Small purchases are unlikely to be double spent anyways.

There are very few (if any) large instant delivery transactions that need ultra fast confirmations.

Changing block time will be difficult.  It will result in more forks and longer re-organizations.  I haven't seen anyone layout a comprehensive reason why it is worth that cost & risk.

I think this is exactly what the OP is looking for - currently the 10 minute window is just too coarse. You have essentially 0 security for 10 minutes and afterwards a security worth thousands of dollars (the cost for somebody wanting to reverse a block with one confirmation). That might not have been an issue when difficulty was very low, but with current difficulty levels this is not very practical anymore. The more hashing power you have, the higher is the security level with 1 confirmation, but that level is already much too high for many real-world purposes.

You obviously don't realize the high risk of 10 minute confirmations right now:

Hmm - you really consider an average 10 minutes for a 5 x 2 minute confirm "light-speed" - really?

My issue is the typical 50 minute confirm - or on the previous 2 difficulties, closer to an hour.

Then of course with variance you can find some 5 block confirms in the chain taking many hours ...

Variance is of course relevant to the actual base time - in standard BTC it's base time is 10minutes.

My suggestion is to set this base time to 2minutes - divide by 5.

Now 5 is not an order of magnitude thus in related mathematical calculations (base on order of magnitude changes) represents no change

Unfortunately, item -2 is how Bitcoin works - so yeah if you'd like to replace Bitcoin with some other crypto-currency that doesn't use block confirms - fine - but in this case I'm talking about Bitcoin itself, not some replacement coin

As for -1 - sorry I call all crypto-currency scam coins (yes I even came 2nd in the poll to design a logo for LTC) but the reality is that they all are either direct scams (no LTC isn't a direct scam) or they will die out given enough time.
They are useful for seeing what improvements can be made to Bitcoin, but otherwise, really not much other use at all except to take small amounts of BTC away from a lot of people (totalling a large amount of BTC) and give it to a few people.

Who needs light-speed confirmation times ? And if you REALLY need them, you already have green-addresses and the likes.
  

I'd like to dispel an extremely bizarre belief that I've seen around (no I'm not saying that SgtSpike has this belief)

That is the belief that there is something special about dealing with orphan/invalid blocks by pools.

They SHOULD simply be considered as not existing once they are determined to be orphaned/invalid
(which should take way less than a single confirm and with 2 minute blocks it will be ever faster)

i.e. just continue using your pool payment calculation based on the previous valid block until you get a non-orphan block.

You can't get the generation block coins until 120 confirms (that's coded into bitcoin) so I certainly don't see any confusion about how orphan blocks should even be dealt with by pools (bizarre e.g. : BTCGuild using special payment rules and donation incentives for dealing with orphaned/invalid blocks)