Suggested MAJOR change to Bitcoin

[kano]

OK, anyone who has dealt with any of the recent scamcoins (especially LTC) will have noticed one big scamcoin advantage that shows why Bitcoin will never be adopted in a big way:
transaction confirm times.

Simply put, a 5 transaction confirm is regularly over an hour (especially during the recent excessively slow difficulty readjustments - slow due to the code design ignoring the reality of the recent down turn)

Yet there is a reasonably straight forward solution that has a collection of advantages and only one disadvantage:

My solution: decrease the block time to 2 minutes and decrease the block payout to 10 bitcoins.

The one disadvantage: more blocks in the block chain - however this doesn't actually mean that the blockchain will become 5 times larger, it just means there will be 5 times the number of basic block headers (80 bytes) and more data due to there being more (smaller) merkle trees.
In terms of transactions, it will, of course, make no difference - the transactions themselves will just be distributed across the blocks.

It has been made clear by most people around here (including Gavin) that namecoin mining adding an extra 46 bytes per block for no advantage to Bitcoin at all, is considered 'nothing' - so those people would have a tough time arguing that this change that is of great advantage to Bitcoin with a small size increase in the block-chain is bad due to the size increase.

Now for the advantages:
1) The overall total coin production will remain the same (yes of course the code would halve it to 5 then 2.5 then 1.25 etc as before)

2) The overall average rate of coin production will be the same

3) If you want to argue why 10 minutes per block times 5 confirms is better then you just wait 2 minutes per block times 25 confirms and get that same warm fuzzy feeling

4) If you prefer to only have an average 10 minutes to wait per transaction, you can rest assured that it is possible with 5 confirms of lower difficulty blocks (which, by the way, everyone was happy with that lower difficulty confirmation last year - why not this year?)

5) There will be lower variance in block confirms which will also mean there will be lower variance in payout in smaller mining pools and thus fewer small mining pools will fail unlike what has been happening over the last few months.

6) There is the current issue I have already mentioned in another thread that will be mostly resolved by this also ... i.e. I'm suggesting that retargets would still occur every 2016 blocks or in the new case, once every 2.8 days since it's the number of blocks that determines the validity of the retarget, not the amount of time (I don't agree that 2016 was necessary, but anyone who thinks it is, well 2.8 days = 2016 blocks with this change)

Now where did I get the idea form?
Simple: watching and waiting for LTC transactions vs never bothering to watch/wait for BTC transactions (coz they are so damn slow)

Again, I can really only see two arguments about this (that I have already mentioned some details above)

1) Increase in data in the block-chain (not a 5 times increase - WAY way less)

2) Decrease in confirm security if people want to use 5 confirms (back to the security of BTC last year)

Of course this change will mean a fork with a specified future block at which point it will take place.

Discussion/Comments anyone?

And please give reasons for or against.

[1714124989]

1714124989

[1714124989]

1714124989

[1714124989]

1714124989

[dogisland]

For those that didn't know what LTC is (as I didn't) http://litecoin.org/

And for why we use 10 minutes currently https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F

Personally I think it's a good idea.

[blueadept]

I thought the biggest reason blocks are supposed to be generated no less than 5 minutes apart was in preparation for much higher network volume, which would increase block propagation time?  The rest of the points you make are valid AFAIK.  If you're really looking for security in no-confirmation transactions, an open-source version of something like transactionradar.com (with some additions) might work instead of changing Bitcoin altogether.

Imagine a node that's "well-connected" - connects to many other nodes in the Bitcoin network, as well as to as many miners as it can.  When it gets a transaction, it does an extra set of checks by requesting the transaction from each mining node it knows about.  As soon as a large percentage of the mining nodes (by number or, preferably, by hashing power) have accepted the transaction, it could be considered as on the way to confirmation.  This would only work for small transactions that you don't mind having a very small chance of being double-spent.  For higher value transactions, you wait until the transaction is in a block and has a number of confirms growing (logarithmically?) with the value of the transaction before you consider it good.

[wareen]

I'm absolutely in favor of this - 10 minutes is really too far on the conservative side.

Of course, this would be a huge change and might sound scary but I don't see any compelling reasons why we shouldn't do this, since it has been more or less proven to work with the alternate coins.

Especially the reduction of mining centralization would be a big advantage IMHO - it is arguably not healthy for Bitcoin to have 2/3 of the mining capacity being controlled by just two pools. Having more frequent blocks, mining solo is much more attractive.

It would also reduce the window of opportunity for Finney attacks.

Of course we would see reorgs more often and miners with slower Internet connections would have a slight disadvantage. Another disadvantage is that the core rules of Bitcoin would be changed, thereby somehow breaking the contract we all agreed to when we joined Bitcoin. But overall I think the advantages outweigh and it would greatly improve Bitcoin's user experience.

[dogisland]

As soon as a large percentage of the mining nodes (by number or, preferably, by hashing power) have accepted the transaction, it could be considered as on the way to confirmation.

That would be great as part of some sort of Bitcoin instant payment service. i.e. Bitcoin payflow notifoes you when it's pretty sure a transaction will go into a block.

[SgtSpike]

You WILL see more invalid/orphaned blocks by doing this.  More pools will find more blocks at the same time, and one or the other of them will have to be invalidated.

Also, seeing 5 confirms on a 2-minute method would equate to the same security as 1 confirm on the 10-minute method, so unless you're looking for completing a transaction with less that one confirmation worth of security (that is, one confirmation within the current 10-minute method), what's the point?  Why not just use 1 confirmation as confirmation enough?

[ElectricMucus]

-1 for calling Litecoin a scamcoin.
-2 for the idea in general, this would further disrupt the thrust in BTC and fast confirmations aren't an issue right now, I can imagine to enable some sort of "preconfirmations" once additional hashing power is available payed for with transaction fees, this would be a way better and securer system and it could take place in about a second.

[kano]

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)

[gusti]

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

[kano]

-1 for calling Litecoin a scamcoin.
-2 for the idea in general, this would further disrupt the thrust in BTC and fast confirmations aren't an issue right now, I can imagine to enable some sort of "preconfirmations" once additional hashing power is available payed for with transaction fees, this would be a way better and securer system and it could take place in about a second.

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.

[kano]

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

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

[wareen]

so unless you're looking for completing a transaction with less that one confirmation worth of security (that is, one confirmation within the current 10-minute method), what's the point?

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.

fast confirmations aren't an issue right now

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

[DeathAndTaxes]

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.

[DeathAndTaxes]

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.

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

[ElectricMucus]

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)

[gusti]

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

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

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

[FreeMoney]

so unless you're looking for completing a transaction with less that one confirmation worth of security (that is, one confirmation within the current 10-minute method), what's the point?

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.

fast confirmations aren't an issue right now

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

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.

[wareen]

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

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?

[DeathAndTaxes]

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)

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.

[DeathAndTaxes]

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.

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.

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.

[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)

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

[MoonShadow]

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.

This would only work once, because it would be evident that such an event has occurred after the fact.  It would be fraud, and easily provable, and thus carries the same legal risks; and would immediately crash your "credit" with those affected vendors.  If this happens enough, those vendors will not accept bitcoin so easily without identifying information; but anonimity was never a certainty.  I have no anonimity with any of the vendors that I have traded with, it's just that no one else outside of the transaction has that data like is necessary with Paypal or Visa transactions.  Said another way, the transaction isn't tied to my identity in records except those that the vendor may keep.  Don't count on being anonymous to your vendors.

[finway]

You are a "Hero" man,
I'll just give you that:
Confirmations are not relative to security,
it's only relative to respending.


For a respending , 10minutes waiting is affordable.

[MoonShadow]

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.

We've had this discussion, and several like it, many times on this forum over the past two years.  I can assure you, the answer is no the target interval will not be changed.  For all the reasons already presented to you and others as well.

[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)

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.

Actually I think it was doublec's exchange, so nothing to do with the %!$#%@$% SolidCoin 2.0

... wanders off to search for the post on the subject ... hmm it was i0coin and doublec's exchange ... still searching ...

Here: https://bitcointalk.org/index.php?topic=36425.msg554140#msg554140

[gmaxwell]

OK, anyone who has dealt with any of the recent scamcoins (especially LTC) will have noticed one big scamcoin advantage that shows why Bitcoin will never be adopted in a big way:
transaction confirm times.
Simply put, a 5 transaction confirm is regularly over an hour (especially during the recent excessively slow difficulty readjustments - slow due to the code design ignoring the reality of the recent down turn)
Yet there is a reasonably straight forward solution that has a collection of advantages and only one disadvantage:
My solution: decrease the block time to 2 minutes and decrease the block payout to 10 bitcoins.

This is a perennially bad proposal.   The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time.   If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.

Reducing the inter-block time further reduces security by creating additional hash power dilution:  When many blocks are found faster than the global communication time of the network (which, if you observe LP skews between pools, can already be up to a minute) then the network there will be may more short term forks and attackers can gain additional advantage by allowing their target to land in one fork, while applying their own power to another fork. The dilution also generally gives single large (good or bad) miners an additional advantage because of their improved power concentration.

A faster block time still is far too slow for "instant transactions" of the POS kind. So we have no less need for solutions for that, and when we have mature solutions for that then your whole concern is mostly moot.

Faster time between blocks would also be burdensome on low trust light clients— which don't need to know much but they do need to know the block headers.  Requiring 4x the storage on mobile phones is not nice.

The increase block rate also increases exposure to DOS attacks marginally.

Finally, and perhaps most importantly:  Any fundamental change in the distributed protocol will not be accepted by rational bitcoin users (unless its some bugfix essential for bitcoin's survival).   If we were willing to change this— whats next? The subsidy? The geometric decline?  Start skimming 5% off to send to a Glorious Leader?    Changes to the immutable bitcoin distributed algorithm would _seriously_ undermine trust and rightfully so.  We may be stupid, we're not that stupid.

[kano]

Firstly, finally a response against the idea that isn't one of:
 1) Change is bad - don't change anything
and/or
 2) Everyone on the planet who deals with Bitcoin transactions does it wrong and no one is going to fix that

Meanwhile:

...
Finally, and perhaps most importantly:  Any fundamental change in the distributed protocol will not be accepted by rational bitcoin users (unless its some bugfix essential for bitcoin's survival).   If we were willing to change this— whats next? The subsidy? The geometric decline?  Start skimming 5% off to send to a Glorious Leader?    Changes to the immutable bitcoin distributed algorithm would _seriously_ undermine trust and rightfully so.  We may be stupid, we're not that stupid.

I don't really think a stupid response it relevant ...

... and ... my suggested change has no effect at all on the production rate of bitcoins or who should get them other than the people and pools that mine them.

Meanwhile I doubt the validity of some of what you have said based on LTC and how it already functions well in the real world.

Also:

If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security.

I have already answered that by saying that if people want the same txn security they already have, then they simply wait for 5x the confirms - problem solved!

But again, change isn't bad by definition.

You are simply saying that the current value is correct and less security is incorrect.
Not what the difference actually is or why we must use the current value.

Reducing the inter-block time further reduces security by creating additional hash power dilution:  When many blocks are found faster than the global communication time of the network (which, if you observe LP skews between pools, can already be up to a minute) then the network there will be may more short term forks and attackers can gain additional advantage by allowing their target to land in one fork, while applying their own power to another fork. The dilution also generally gives single large (good or bad) miners an additional advantage because of their improved power concentration.

I usually mine multiple pools and have never seen two pools LP a minute apart (even when I was mining 5 pools at the same time back when there were major network problems and the big pools kept getting ddos'd)
2 minutes was chosen since it is above such problems and has shown in the real world to work well.

That additional advantage for large miners has not shown to exist in any scamcoin except at their start when the difficulty was well below what it should be.
(though I managed to make over 30BTC in the first 2 days of LTC with my low power CPU mining ...)

Faster time between blocks would also be burdensome on low trust light clients— which don't need to know much but they do need to know the block headers.  Requiring 4x the storage on mobile phones is not nice.

Um ... do any of these exist?

The increase block rate also increases exposure to DOS attacks marginally.

I'd say the opposite.
Can you give an example of why?
My example would be that the network has to deal with a small amount of extra data and thus a ddos attack is relatively somewhat less effective since the difference between normal and ddos is slightly less.

[2112]

(which, if you observe LP skews between pools, can already be up to a minute)

It makes me wonder: have any of the pool operators tried to implement long poll with Twitter?

I kinda understand their pain: how to implement a reliable multicast when seemingly the only tool available is a massive abuse of unicast?

[MoonShadow]

Faster time between blocks would also be burdensome on low trust light clients— which don't need to know much but they do need to know the block headers.  Requiring 4x the storage on mobile phones is not nice.

Um ... do any of these exist?

Yes.

[iddo]

If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security.

I have already answered that by saying that if people want the same txn security they already have, then they simply wait for 5x the confirms - problem solved!

That's inaccurate, there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication. See more details in "faster transaction time" section of https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin

kano: it's quite obvious that what's gonna happen in reality is that with 2mins blocks almost everyone will still wait for 6 confirms instead of 5x6 confirms, i.e. you propose something like giving away free machine guns to the entire population and saying don't worry about shooting incidents because people can choose not to use them.

[kano]

Then you better not read the previous page where a few are saying that people should accept all but expensive txn's at 0 confirms ...

[iddo]

Then you better not read the previous page where a few are saying that people should accept all but expensive txn's at 0 confirms ...

0 confirms for inexpensive txns, while scanning the network to detect double-spending attempts, is discussed here: https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation

The point about machine guns is how many confirms should the GUI client wait for, before indicating to the user that the txn is secure. Suppose everyone agreed with your 2mins blocks idea, are you suggesting that the official client wait for 6 confirms or 30 confirms? If you're suggesting 6 confirms that's where the machine guns analogy could be valid.

[maaku]

This is a perennially bad proposal.   The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time.   If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.

What definition of security are you using? For any of the double-spends mentioned in this thread it is the number of confirmations that matters, irregardless of global hash rate (yes, the wiki is wrong on this point). If you think otherwise, I'd love to see the math to back it up.

[wareen]

We've had this discussion, and several like it, many times on this forum over the past two years.  I can assure you, the answer is no the target interval will not be changed.

I know and I understand that, however what might have changed since the last time I saw this discussion, is that we now have a few somewhat working proof of concepts with the alt-coins and the mining infrastructure has become more concentrated.

Faster time between blocks would also be burdensome on low trust light clients

That's a very good point I hadn't considered yet!

Finally, and perhaps most importantly:  Any fundamental change in the distributed protocol will not be accepted by rational bitcoin users (unless its some bugfix essential for bitcoin's survival).

I'm not so sure about that. Consider for example the extension of the divisibility - a compatibility breaking change that is regarded as absolutely unproblematic because nobody is expected to object.
If we have a consensus that a change is beneficial for Bitcoin then such a change might very well be accepted by a rational Bitcoin user.

As for the more frequent reorgs: everything relying on Bitcoin should be able to deal with reorgs - even at the current blockrate.

Now I can see all your objections, but I'm not yet convinced that this change would make Bitcoin overall significantly worse (apart from maybe the issue with the light clients - which is a very valid point!).

Lets face it: 10 minutes is a pretty arbitrary constant which is arguably on the conservative side when it comes to compensating for network delay. I'm pretty sure many would defend 6 minutes just the same right now if Satoshi had chosen 6 minutes instead (disregarding the fact that making it lower then would be less attractive).

there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.

That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations.

I understand the reluctance to change the Bitcoin contract but I feel it should be possible to discuss such changes objectively based solely on their relative merits. The network effect is all great and gives us an advantage over the competitors right now, but it is not very far-sighted to argue from the standpoint that every fundamental change to Bitcoin is necessarily bad.

I'm happy to see a discussion for possible ways to make it less risky to accept payments within under 10 minutes. Changing the blockrate is one of them and I'm not saying it's the best. I would for example really like to see a listening period be agreed upon and implemented in the client.

[iddo]

This is a perennially bad proposal.   The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time.   If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.

What definition of security are you using? For any of the double-spends mentioned in this thread it is the number of confirmations that matters, irregardless of global hash rate (yes, the wiki is wrong on this point). If you think otherwise, I'd love to see the math to back it up.

The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?

[iddo]

Faster time between blocks would also be burdensome on low trust light clients

That's a very good point I hadn't considered yet!

Yeah, that's a good point that I didn't really appreciate until now, so I added it to the Litecoin wiki comparison.
Still waiting for gmaxwell to explain his other point about DOS attacks with faster average blocks

[maaku]

there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.

That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations.

The power dilution is approximately the network latency of the dishonest network minus the network latency of the global (honest) network, divided by the expected block interval. As a consequence, it has little difference if we're talking about dishonest pools. Given that the current network latency is about 2 seconds, it has very little effect at all. We can get well under a minute before it even starts being measurable.

The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?

No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.

[iddo]

I'm happy to see a discussion for possible ways to make it less risky to accept payments within under 10 minutes. Changing the blockrate is one of them and I'm not saying it's the best.

In the long term, option 3 of having centralized hubs as a layer on top of bitcoin is probably the best idea, also because of scalability issues discussed here: https://en.bitcoin.it/wiki/Talk:Scalability

[iddo]

there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.

That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations.

The power dilution is approximately the network latency of the dishonest network minus the network latency of the global (honest) network, divided by the expected block interval. As a consequence, it has little difference if we're talking about dishonest pools. Given that the current network latency is about 2 seconds, it has very little effect at all. We can get well under a minute before it even starts being measurable.

The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?

No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.

The honest hash power dilution isn't just a result of network latency, but also because there's higher probability for the event of miners finding a block at about same time, at the lower difficulty that's implied by faster block average. You appear to claim that honest hash power dilution in negligible because in effect there are no more than couple hundreds of actual miners because everyone mines in pools, but would you make the same claims if everyone were solo-mining? Note that the current situation of having only few centralized pools might improve in the future, either by using p2pool or by using protection from malicious pool operators where miners prepare the block locally and use the pool's reward address (and then the event of finding different blocks at about same time will have similar probability compared to solo-mining). So overall it's false to say that only the number of confirms matters, because if honest miners have 70% power then it's being diluted by the faster block average time, and we're just arguing about the measure of this dilution? Feel free to provide more detailed analysis...

Edit: what I wrote here is wrong, I was operating under the misconception that chain forks cause hash power dilution, which is false. Credit goes to MeniRosenfeld for correcting me, see the next post.

[iddo]

Actually, after asking Meni Rosenfeld about it, he started to convince me that the honest hash power dilution with faster blocks is less severe than what I estimated.

For simplicity, let's assume network propagation time of 1 second, i.e. it takes 1 second for each node to broadcast the longest chain that it knows of to all other nodes.
With 2mins blocks, on average once every 120 seconds some node sends the block it found, so during the 1 second of propagating the new block, the other miners are wasting their hash power while working on a shorter chain, so 1 out of 120 seconds is being wasted on average. If there's a fork where e.g. two groups of miners work on different chains of same length then that's ok, i.e. they don't dilute any of their hash power because of this fork. So in total 1/120 of the honest hash power is being wasted, which is only 0.83%, and with Litecoin 2.5mins blocks it's only 0.66%, and with 1min blocks it's only 1.66%
Simple huh?

[DeathAndTaxes]

That assumes a network propagation time to all other nodes in <1 second.  Currently that is fine but someday (and we should be building bitcoin for the someday) with hundreds of thousands of nodes propagation time will be multiple seconds to reach 90% of nodes and there will always be inefficient edge cases so propagation time for last 10% of network might be double that.

Of course is all (or 90%) of the mining is done by a consortium of 10 major mining corporations which share ultra low latency links with each other that becomes a non-issue.  However we shouldn't be trying to create problems where centralized control by massive mining pools is the "solution".

[MoonShadow]

No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.

The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be.  But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block.  The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is.  No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block.  The choice of a 10 minute target interval is certainly arbitrary, but a 2 minute target is no less arbitrary; and the rational for choosing 10 minutes is sound.  Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network.  The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.

[2112]

That assumes a network propagation time to all other nodes in <1 second.  Currently that is fine but

It isn't fine even now. The latency over Tor's 6-hop hidden service connections is significantly higher. I was under impression that Bitcoin from the start was designed to be tolerant of higher-latency networks like Tor.

[DeathAndTaxes]

That assumes a network propagation time to all other nodes in <1 second.  Currently that is fine but

It isn't fine even now. The latency over Tor's 6-hop hidden service connections is significantly higher. I was under impression that Bitcoin from the start was designed to be tolerant of higher-latency networks like Tor.

Tolerant yet but faster hops is always better.  That is why 10 minutes is a compromise.  30 minutes blocks would be even better for high latency links and a larger network.  The shorter the block the higher the penalty for high propagation times.

2 min vs 10 min doesn't solve the issue that  0  to 10 seconds is the "critical window".  A 2 min confirm vs 10 min confirm doesn't help most merchants but does make latency of the network a much larger issue.

[kokjo]

to ensure your safety, you would have to wait a hour anyway.
it does not matter if you wait 6*10min or 30*2min.

its the same security, the blockchain is only proof of time.

[maaku]

No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.

The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be.  But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block.  The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is.  No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block...

I understand that, but that is not a meaningful distinction in the context of this thread or in the practicalities of attacking bitcoin. If I have 30% of the global hash power and overnight bitcoin changes from 10min blocks to 2min blocks, my likelihood of executing a double-spend after X confirmations is negligibly different before and after.

Yes it is would be 5 times harder if the honest network magically increased to 5x it's original size, but that's not what will actually happen if the block interval is changed.

...Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network.  The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.

If bitcoin ever reaches Visa-level of adoption, we will likely see many federated, industrial mining operations connected by direct fiber-optic connections. Latency will be no higher than it currently is with bitcoin or Visa (a few seconds, typically).

to ensure your safety, you would have to wait a hour anyway.
it does not matter if you wait 6*10min or 30*2min.

its the same security, the blockchain is only proof of time.

No, that's simply not true by any meaningful measure (see my previous post), although it's a commonly repeated myth on these forums.

That statement is equating security/safety with number of hash operations needed to undo a transaction. But that would only be true if work stopped on the honest chain. In actuality, the only thing that matters (and the math shows this) is percentage ownership of the global hash rate, and the likelihood of pulling off that attack decreases geometrically with the number of confirmations, regardless of block interval length.

[MoonShadow]

No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.

The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be.  But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block.  The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is.  No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block...

I understand that, but that is not a meaningful distinction in the context of this thread or in the practicalities of attacking bitcoin. If I have 30% of the global hash power and overnight bitcoin changes from 10min blocks to 2min blocks, my likelihood of executing a double-spend after X confirmations is negligibly different before and after.

Yes it is would be 5 times harder if the honest network magically increased to 5x it's original size, but that's not what will actually happen if the block interval is changed.

That's not at all what I said.  And no, simply switching the target interval from 10 to 2 does not mean that the confirmations are as secure after any particular number of blocks.  At two minutes, 30 confirmations are roughly as secure as 6 are now.  The confirmations themselves are not magic, they only represent an amount of time passed since your transaction was recorded.  It's the time(multiplied by the difficulty) that creates the security.

...Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network.  The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.

If bitcoin ever reaches Visa-level of adoption, we will likely see many federated, industrial mining operations connected by direct fiber-optic connections. Latency will be no higher than it currently is with bitcoin or Visa (a few seconds, typically).

Maybe, maybe not.  The interval is still arbitrary and the logic for 10 minutes remains as sound as it would be for 2 minutes.  IT would certainly be much longer for edge of network solo miners.  Keep in mind, at a Visa level of transaction processing, each block would be around 10 gigs.  At 2 minutes, each block would still be around 2 gigs, but the multi-connection thing multiplies the burden  upon the nodes.

to ensure your safety, you would have to wait a hour anyway.
it does not matter if you wait 6*10min or 30*2min.

its the same security, the blockchain is only proof of time.

No, that's simply not true by any meaningful measure (see my previous post), although it's a commonly repeated myth on these forums.

That statement is equating security/safety with number of hash operations needed to undo a transaction. But that would only be true if work stopped on the honest chain. In actuality, the only thing that matters (and the math shows this) is percentage ownership of the global hash rate, and the likelihood of pulling off that attack decreases geometrically with the number of confirmations, regardless of block interval length.

It's not a myth.

[ctoon6]

i have some statements i believe to be true.

overall security never changes no matter what the target block time is. only time and blocks being generated will make coins more secure.

shorter times would allow us to get past the initial "uncertainty". because once you get a transaction inside a valid block, you are for the most part more secure than if you just accepted an unconfirmed transaction. this is the only benefit to decreasing block time, otherwise it only has negatives like more space required to store the chain (overhead) and more times when 2 or more blocks compete to become part of the chain.

if it were up to me i would decrease it to 2-5 minutes.

[d.james]

It's a great idea, 2min blocks = 10min to get 5 confirmations.
Result: 10 minute wait is so much better than 1 hour!!

But I have a better idea, 1min blocks = 5 min to get 5 confirmations.
5min is BETTER than 10min!!

I'm sure someone can top my idea shortly. 

[SgtSpike]

It's a great idea, 2min blocks = 10min to get 5 confirmations.
Result: 10 minute wait is so much better than 1 hour!!

But I have a better idea, 1min blocks = 5 min to get 5 confirmations.
5min is BETTER than 10min!!

I'm sure someone can top my idea shortly. 

Read the thread.

[kano]

That assumes a network propagation time to all other nodes in <1 second.  Currently that is fine but someday (and we should be building bitcoin for the someday) with hundreds of thousands of nodes propagation time will be multiple seconds to reach 90% of nodes and there will always be inefficient edge cases so propagation time for last 10% of network might be double that.

Of course is all (or 90%) of the mining is done by a consortium of 10 major mining corporations which share ultra low latency links with each other that becomes a non-issue.  However we shouldn't be trying to create problems where centralized control by massive mining pools is the "solution".

That is one of the points I have already made of decreasing the block generation time which will decrease the block creation variance.
More smaller pools will be able to survive and not fail due to the current high variance in block creation.

However, related to another post, any discussion about increasing the number of LP's on the network is pointless.
This has already happened with merged mining and the factor is much higher than 5 times already - and who tried to stop it?
(well actually I did try )

[maaku]

I understand that, but that is not a meaningful distinction in the context of this thread or in the practicalities of attacking bitcoin. If I have 30% of the global hash power and overnight bitcoin changes from 10min blocks to 2min blocks, my likelihood of executing a double-spend after X confirmations is negligibly different before and after.

Yes it is would be 5 times harder if the honest network magically increased to 5x it's original size, but that's not what will actually happen if the block interval is changed.

That's not at all what I said.  And no, simply switching the target interval from 10 to 2 does not mean that the confirmations are as secure after any particular number of blocks.  At two minutes, 30 confirmations are roughly as secure as 6 are now.  The confirmations themselves are not magic, they only represent an amount of time passed since your transaction was recorded.  It's the time(multiplied by the difficulty) that creates the security.

Show me, mathematically, why that is the case.

I have done the math (summarized earlier), and done simulations to verify this fact: as long as BLOCK_INTERVAL is significantly larger than NETWORK_LATENCY, one's chance of forcing a re-org to undo a transaction depends only on the number of confirmations and the percent of global hash power controlled.

So please, either bust out the math to show me where I'm wrong, or tell me how you're defining 'security'. Because from where I sit, breaking the security model means undoing a transaction, and the chance of doing that depends only on your relative hash rate and the number of confirmations.

But heck, don't take my word for it. Page 6 from Satoshi's whitepaper:

p = probability an honest node finds the next block
q = probability the attacker finds the next block
q_z = probability the attacker will ever catch up from z blocks behind

q_z = (1 if p <= q) or ( (q/p)^z if p > q )

EDIT: For what it's worth, I agree with what has been posted earlier that decreasing the block interval yields little benefit unless you can get it down to single-digit seconds. 10 minutes remains a very good compromise. But nevertheless, decisions should be made on the facts.

[DeathAndTaxes]

That assumes a network propagation time to all other nodes in <1 second.  Currently that is fine but someday (and we should be building bitcoin for the someday) with hundreds of thousands of nodes propagation time will be multiple seconds to reach 90% of nodes and there will always be inefficient edge cases so propagation time for last 10% of network might be double that.

Of course is all (or 90%) of the mining is done by a consortium of 10 major mining corporations which share ultra low latency links with each other that becomes a non-issue.  However we shouldn't be trying to create problems where centralized control by massive mining pools is the "solution".

That is one of the points I have already made of decreasing the block generation time which will decrease the block creation variance.
More smaller pools will be able to survive and not fail due to the current high variance in block creation.

Except the smaller the block time the more important latency becomes especially as the network grows.  That is more likely to result in large pools remaining dominant.  Every time a small pool works on a orphaned block that is effectively wasted hashing power.  Larger pools with low latency links to each other would be more efficient and thus gain more marketshare.

However, related to another post, any discussion about increasing the number of LP's on the network is pointless.
This has already happened with merged mining and the factor is much higher than 5 times already - and who tried to stop it?
(well actually I did try )

Well only because you were uninformed.  LP don't have the potential to cause an orphaned block, only a block change does.  A block change leads to an LP but it is the block change not the LP that has the potential to fragment the network.  100x the LP (for example a pool issuing a LP on every new transaction) wouldn't have any affect on the rest of the network.  Changing the block time from 10 min to 2 minutes however would increase the likelihood of splitting the network AND make re-orgs take longer affecting the efficiency, stability, an security of the network.  Those problems would only get worse as the network gets larger and propagation delays grows.

[gmaxwell]

I have done the math (summarized earlier), and done simulations to verify this fact: as long as BLOCK_INTERVAL is significantly larger than NETWORK_LATENCY, one's chance of forcing a re-org to undo a transaction depends only on the number of confirmations and the percent of global hash power controlled.

This is a misleading description.  You're happily waving away the _cost_ of a particular attack.

Take bitcoin as it is.... if you'd like to buy computing time to mine a six block fork you should pay 300 BTC (plus some premium to get it all at once, I suppose). Under the 2.5/minute 12.5 BTC model, the cost would be 75.5 BTC.

(Before you protest that burst computing capacity in excess of bitcoin violates the security model— realize that is effectively an argument that honest bitcoin mining must consume a majority of all fungible computing power in the universe,  as compared to the far more limited requirement that the majority sustained hash power applied to bitcoin be honest.    It's also important to keep in mind that not all the attacks we guard against are races against the public network. It's pretty easy to isolate single nodes via sibyl attacks then slowly feed them blocks which have no chance of surviving on the main network)

The assumptions also require that blocks are not frequently found under the network latency. The 1s number being thrown around is nuts and obviously and observably not true today. Keep in mind that forwarding nodes also check the validity of the blocks before propagating them some of our larger recent blocks are hitting a second of validation (computation/disk IO) alone. This is why it takes several hours to syncup a new client now.

Then there is the point which I made in my first post which seems to have been ignored— part of why we _wait_ is not just to gain confirmations, but to reduce the risk that there was a network partition with considerable hash power on both sides.  E.g. If EU and the US lose internet connectivity people can spend on both sides. In order to be secure you must wait long enough that such a split is unlikely and/or long enough that if a split were to happen people would have an opportunity to detect it intervene (e.g. miners could stop processing new txn, sites could switch to higher confirmation limits— but only if they've detected the partition, which takes time if you are to avoid false positives).  Both criteria require absolute time, the distribution of blocks is irrelevant.

Perhaps I missed it, but I haven't really seen anyone address the point I made that this kind of change (10->2.5minutes) is a change in value but not in character. It doesn't suddenly make the system suitable for direct POS usage. There is a fairly narrow range of use cases where that would constitute an improvement and I suspect almost all of those uses could be adequately addressed by the solutions employed for POS processing.  (I assume everyone agrees that switching to _two second_ blocks needed for comfortable direct POS processing (keeping in mind the variance) most certainly would break it, even if you care to debate my arguments against decreases in general)   (Oh, I see maaku's edit now— oh well, this is worth repeating)

[maaku]

This is a misleading description.  You're happily waving away the _cost_ of a particular attack.

I am doing no such thing. Rather I am recognizing that the practical reality of the situation such that much of the costs of mounting an attack would be up-front/sunk costs (buying hardware, building a botnet, etc.), so much so that in any realistic scenario the difference in cost between simply preparing an attack and actually mounting it would be relatively quite small.

In the absence of a cloud-based burst-compute utility suitable for hash-computations at a scale to rival bitcoin and at a reasonable price (which doesn't, and likely will never exist), utility computation is a terrible model for the economics of attacking bitcoin.

Take bitcoin as it is.... if you'd like to buy computing time to mine a six block fork you should pay 300 BTC (plus some premium to get it all at once, I suppose). Under the 2.5/minute 12.5 BTC model, the cost would be 75.5 BTC.

(Before you protest that burst computing capacity in excess of bitcoin violates the security model— realize that is effectively an argument that honest bitcoin mining must consume a majority of all fungible computing power in the universe,  as compared to the far more limited requirement that the majority sustained hash power applied to bitcoin be honest.    It's also important to keep in mind that not all the attacks we guard against are races against the public network. It's pretty easy to isolate single nodes via sibyl attacks then slowly feed them blocks which have no chance of surviving on the main network)

The assumptions also require that blocks are not frequently found under the network latency. The 1s number being thrown around is nuts and obviously and observably not true today. Keep in mind that forwarding nodes also check the validity of the blocks before propagating them some of our larger recent blocks are hitting a second of validation in computation alone. This is why it takes several hours to syncup a new client now.

1) such burst computing capacity does not exist
2) you're assuming the price-per-hash of utility compute will be comparable to the expenditures of your average bitcoin miner. in reality, it will be orders of magnitude more with something like AWS.
3) bitcoin needn't "consume a majority of all fungible computing power"--just a majority of the discretionary computing power/excess compute capacity. As stated that's a false argument, because...
4) you're ignoring the opportunity cost of that burst computing capacity. for small amounts of compute power this is zero. but once you exceed excess capacity you will be competing with existing users, driving up the price far in excess of actual costs.
5) if you can isolate a node, a 10 minute block interval won't provide much more protection than a X-second interval--.
6) network latency is 2.1 seconds today, with really very little optimizations. i expect average network latency for well connected nodes to go down, not up in the long term, but that is really a topic for a different thread.

Then there is the point which I made in my first post which seems to have been ignored— part of why we _wait_ is not just to gain confirmations, but to reduce the risk that there was a network partition with considerable hash power on both sides.  E.g. If EU and the US lose internet connectivity people can spend on both sides. In order to be secure you must wait long enough that such a split is unlikely and/or long enough that if a split were to happen people would have an opportunity to detect it intervene (e.g. miners could stop processing new txn, sites could switch to higher confirmation limits— but only if they've detected the partition, which takes time if you are to avoid false positives).  Both criteria require absolute time, the distribution of blocks is irrelevant.

Perhaps I missed it, but I haven't really seen anyone address the point I made that this kind of change (10->2.5minutes) is a change in value but not in character. It doesn't suddenly make the system suitable for direct POS usage. There is a fairly narrow range of use cases where that would constitute an improvement and I suspect almost all of those uses could be adequately addressed by the solutions employed for POS processing.  (I assume everyone agrees that switching to _two second_ blocks needed for comfortable direct POS processing (keeping in mind the variance) most certainly would break it, even if you care to debate my arguments against decreases in general)

And those are valid points which I agree with. Bitcoin should remain at 10 min block intervals, IMHO--but for these reasons, not because it offers any additional protection against hidden-adversary double-spend attacks (it doesn't).

[kano]

I do believe the discussion has gone a bit off target (IMO)

Simply because of a few things that I would love anyone to disprove (hopefully at least 2) is wrong):

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance

2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)

3) Most if not all online transaction processing requires at least 5 confirmations

Then again the added extra

4) Small pools are failing due to the high variance in block finding

Now yes it is useful to give arguments for or against changing the current functionality of Bitcoin, however, it does seem rather pointless to not provide a better solution that can be accepted ... since the problem exists and is not going away.

I would actually extend that to say: POS is not feasible with bitcoin without some other form of transaction validation added to it.
And really, that has nothing to do with what I'm suggesting here.

Reality: online bitcoin transaction are too slow.

My suggestion of a drop in difficulty (with a directly related drop in the value of a block) seems to be quite a feasable solution without dumping bitcoin as it stands ... and I will also add that adding some extra on top of bitcoin to deal with < 10sec confirmations seems more like hacking bitcoin into something else - rather than just creating a new 'something else'.

[DeathAndTaxes]

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance

A drop to 2 minute block, 1 minute block or even 30 second block won't solve that.  No business is going to wait 2 minutes any more than they would 10 minutes.  Even at 30 second block that is simply too long and occasionally a 30 second block will result in multi-minute wait.  So shortening the block time solves nothing.

2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)

No one accepts bitcoins period (or close to no one).  Guess we should end bitcoin then right?  Maybe few merchants accept 0-confirms because people like you continually scream that they can't.

3) Most if not all online transaction processing requires at least 5 confirmations

No they don't.  Examples have been provided.

Why does a monthly porn site need confirmations?
Why does an online video game need confirmations?
Why does an webhosting need confirmations?
Why does an online poker room need confirmations?
Why does a bitcoin lottery need confirmations?
Why does a mail order company need confirmations to begin processing the order?
Why does a password recovery service (hashing farm) need confirmations?
Why does a research site (yahoo answers) need confirmations?

Think about those examples and tell me what does the company lose on the few instances that they don't catch a double spend for say 5 minutes?  What does the attacker gain (remember there is still a 50% chance merchant is paid)

Some transactions require confirmations.  Transactions that are INSTANTANEOUS, HIGH VALUE AND IRREVOCABLE need confirmations.  An example would be an exchange, a registrar,

4) Small pools are failing due to the high variance in block finding

Don't try to save small pools, make it so large pools aren't a threat.  Technology like p2pool or even a traditional pool where block header creation is done at the miner level would eliminate the risk that large pools represent.  Even if you feel small pools are essential a small block time makes latency hugely important and a group of large pools could ensure they have less invalid blocks than small pools. Invalid blocks currently are rather rare but will occur much more frequently in a larger network and shorter block.  If anything short blocks may kill small pools once and for all.

I would actually extend that to say: POS is not feasible with bitcoin without some other form of transaction validation added to it.
And really, that has nothing to do with what I'm suggesting here.

Of course it is. Have you thought how you can complete a double spend.

You have two businesses A & B.  You create pair of double spend transactions A & B.
How will you ensure A sees transaction A and B sees transaction B but A doesn't see B and B doesn't see A.

Start thinking about it that way and you will realize countermeasures are rather easy. 
Can you name a single example of a 0-confirm double spend?

Reality: online bitcoin transaction are too slow.

Reality: confirmations are not necessary for most transactions.   A drop in block time won't make confirmations noticeably faster and 1-confirm only provides additional protection against a single and very specific type of attack (Finney attack).

My suggestion of a drop in difficulty (with a directly related drop in the value of a block) seems to be quite a feasable solution without dumping bitcoin as it stands

Except you fail to see it solves absolutely no problem while crippling the ability for Bitcoin to handle higher transaction volume.  The reality is that 10 minute blocks may be too small if Bitcoin network every became very large (hundreds of thousands or millions of nodes).

[MoonShadow]

The topic of workable instant POS solutions for bitcoin have been worked to death on this forum.  I've participated in many of those threads.  Is the search function, I'm not the one obligated to make the case that anything needs to change, nor that I'm wrong about the security model.  The math presented in this thread is incomplete, IMHO.  All a block is in this regard is a unit of measurable proof-of-work performed.  Just because such proof-of-work can be conveiently modeled around the unit, doesn't mean that the unit doesn't still represent the work that is done to create a block; and the work done is a continuous stream of proof-of-work.

As far as a POS system, there are a number of workable models that have been proposed by myself and others.  The most likely future solution, IMHO, is a side-channel network that allows bitcoin 'banks' such as more sophisticated online wallet services to securely communicate with each other in real time, verifying to each other that the client does have such a balance with much the same result as how an electronic check is processed today.  No, this would not be terriblely anonymous; but still more so than using a credit card for purchases today.  The vast majority of people don't need anoninimty in every little daily transaction anyway.

[maaku]

The math presented in this thread is incomplete, IMHO.  All a block is in this regard is a unit of measurable proof-of-work performed.  Just because such proof-of-work can be conveiently modeled around the unit, doesn't mean that the unit doesn't still represent the work that is done to create a block; and the work done is a continuous stream of proof-of-work.

Meaningless and inconsequential--blocks don't have inherent difficulties. If the pool operator gives me a block it could take me a billion hashes to find a solution--or I could get it on the first try. How long it takes is just dumb luck in choosing the right (or wrong) starting nonce.

[kano]

Sorry - you misunderstood some of what I was saying ...

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance

A drop to 2 minute block, 1 minute block or even 30 second block won't solve that.  No business is going to wait 2 minutes any more than they would 10 minutes.  Even at 30 second block that is simply too long and occasionally a 30 second block will result in multi-minute wait.  So shortening the block time solves nothing.

What I meant was exactly what I wrote - you require people to believe in 0 confirmation for POS to work with current bitcoin.
BUT people don't believe in it - they believe that they require 5 confirmations.
(I am also not arguing the validity of 0 confirmations - for or against)

2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)

No one accepts bitcoins period (or close to no one).  Guess we should end bitcoin then right?  Maybe few merchants accept 0-confirms because people like you continually scream that they can't.

Yes there are many sites that accept bitcoins - seriously I'm not sure why you made that statement at all.
I have never said to anyone that they can or cannot accept 0 confirmations.
I have simply made the very clear observation that few if none actually do accept 0 confirmations.

3) Most if not all online transaction processing requires at least 5 confirmations

No they don't.  Examples have been provided.

Why does a monthly porn site need confirmations?
Why does an online video game need confirmations?
Why does an webhosting need confirmations?
Why does an online poker room need confirmations?
Why does a bitcoin lottery need confirmations?
Why does a mail order company need confirmations to begin processing the order?
Why does a password recovery service (hashing farm) need confirmations?
Why does a research site (yahoo answers) need confirmations?

Think about those examples and tell me what does the company lose on the few instances that they don't catch a double spend for say 5 minutes?  What does the attacker gain (remember there is still a 50% chance merchant is paid)

Some transactions require confirmations.  Transactions that are INSTANTANEOUS, HIGH VALUE AND IRREVOCABLE need confirmations.  An example would be an exchange, a registrar,

Again - I am not saying that they MUST accept 5 confirmations, I am simply observing that they ALL (or most) do want 5 confirmations.

4) Small pools are failing due to the high variance in block finding

Don't try to save small pools, make it so large pools aren't a threat.  Technology like p2pool or even a traditional pool where block header creation is done at the miner level would eliminate the risk that large pools represent.  Even if you feel small pools are essential a small block time makes latency hugely important and a group of large pools could ensure they have less invalid blocks than small pools. Invalid blocks currently are rather rare but will occur much more frequently in a larger network and shorter block.  If anything short blocks may kill small pools once and for all.

OK I don't understand that statement at all.
Saving small pools will reduce the threat of large pools. Simple.
Reducing variance WILL help reduce the number of small pools that fail due to the current large variance (especially with regard to PPS)
Latency is already at X and we get Y collisions.
5Y collisions is not even an order of magnitude higher .........

I would actually extend that to say: POS is not feasible with bitcoin without some other form of transaction validation added to it.
And really, that has nothing to do with what I'm suggesting here.

Of course it is. Have you thought how you can complete a double spend.

You have two businesses A & B.  You create pair of double spend transactions A & B.
How will you ensure A sees transaction A and B sees transaction B but A doesn't see B and B doesn't see A.

Start thinking about it that way and you will realize countermeasures are rather easy.  
Can you name a single example of a 0-confirm double spend?

You seem to have this issue with 0 confirmations.
All I can say is that you then need to convince all the people out there that trade with bitcoins that they should accept 0 confirmations.
I'm not trying to validate or repudiate 0 confirmations.
I'm simply looking at a way to deal with how Bitcoin works (and fails) NOW.

Reality: online bitcoin transaction are too slow.

Reality: confirmations are not necessary for most transactions.   A drop in block time won't make confirmations noticeably faster and 1-confirm only provides additional protection against a single and very specific type of attack (Finney attack).

Here I think you are definitely wrong.
Again the reason why I made this thread is due to dealing with both BTC and LTC.
When I make LTC transactions I do watch and wait form them to complete at the target and then deal with the result ASAP.
With BTC transactions I just set and forget them and get back to them some time later in the future because they are too slow.
You may see no difference between an average 10 minutes and an average 50 minutes, but I can GUARANTEE that more than 90% of people would see the difference.
More so, consider adding variance onto 10 minutes vs adding variance onto 50 minutes.
The numbers make one hell of a big difference actually.
Not only that, people who accept BTC can reduce their acceptance to 2, 4, 6 etc minutes if they feel happy with fewer confirmations than 5 for smaller transactions.
At the moment they can't get below 10 minutes (though that is sometimes as high as 1 hour) without accepting 0 confirmations.
Yeah that may or may not be OK - but I am again talking about how BTC is use today, not someone's ideal of how it SHOULD be used.

My suggestion of a drop in difficulty (with a directly related drop in the value of a block) seems to be quite a feasable solution without dumping bitcoin as it stands

Except you fail to see it solves absolutely no problem while crippling the ability for Bitcoin to handle higher transaction volume.  The reality is that 10 minute blocks may be too small if Bitcoin network every became very large (hundreds of thousands or millions of nodes).

It cripples nothing.
The actual transactions (on average) simply become spread across 5 x 10 BTC blocks instead of being only in 1 x 50 BTC block.
... and your last comment really says that the current BTC is no good with some number of orders of magnitude larger network.
I don't see that as a good reason for you wanting to turn people away from the current BTC.

[HostFat]

Many are wasting time here, to me kano is just spreading FUD only to push his idea

[kano]

Many are wasting time here, to me kano is just spreading FUD only to push his idea

What FUD?

[HostFat]

Example:

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance
2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)
3) Most if not all online transaction processing requires at least 5 confirmations

And you will continue to write those things to push your idea even if you are wrong.

[iddo]

I corrected the pros/cons comparison of faster blocks at:
https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin
Credit goes to MeniRosenfeld and gmaxwell

kano: apologies for hijacking your thread with all the probability analysis, and regarding the main issues that concern you I (again) recommend that you give more thought to option 3 of having centralized hubs as a layer on top of bitcoin for inexpensive+instant transactions, also because of scalability issues discussed at https://en.bitcoin.it/wiki/Talk:Scalability

[kano]

Example:

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance
2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)
3) Most if not all online transaction processing requires at least 5 confirmations

And you will continue to write those things to push your idea even if you are wrong.

Who did you steal that staff flag on your account from ...

That quote is bullshit. You just removed the point of the quote for your own whatever stupid reasons you have.
Or did you not even bother to read ANY of the context?

The quote is:

Simply because of a few things that I would love anyone to disprove (hopefully at least 2) is wrong):

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance

2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)

3) Most if not all online transaction processing requires at least 5 confirmations

I even posted again explaining what they meant.

Leave the thread and go get confused elsewhere.

[kano]

I corrected the pros/cons comparison of faster blocks at:
https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin
Credit goes to MeniRosenfeld and gmaxwell

kano: apologies for hijacking your thread with all the probability analysis, and regarding the main issues that concern you I (again) recommend that you give more thought to option 3 of having centralized hubs as a layer on top of bitcoin for inexpensive+instant transactions, also because of scalability issues discussed at https://en.bitcoin.it/wiki/Talk:Scalability

Heh no worry with the hijack - it is on topic but I was more just trying to get some comments relating to how Bitcoin is actually used also.
All the maths in the world will not make most people agree to waiting on average 50 minutes for a transaction to go through - which seems to be what happens at the moment - but no one seems to actually have an actual opinion on that either (other than calling it FUD)
I even asked before if anyone knows of any sites that accept 0 confirmations but no answer from anyone.
I certainly do not know any.

[HostFat]

I even asked before if anyone knows of any sites that accept 0 confirmations but no answer from anyone.
I certainly do not know any.

2/3 second to found one
https://bitcointalk.org/index.php?topic=42477.0

[MoonShadow]

The math presented in this thread is incomplete, IMHO.  All a block is in this regard is a unit of measurable proof-of-work performed.  Just because such proof-of-work can be conveiently modeled around the unit, doesn't mean that the unit doesn't still represent the work that is done to create a block; and the work done is a continuous stream of proof-of-work.

Meaningless and inconsequential--blocks don't have inherent difficulties. If the pool operator gives me a block it could take me a billion hashes to find a solution--or I could get it on the first try. How long it takes is just dumb luck in choosing the right (or wrong) starting nonce.

They still represent an average difficulty to find one, which is why they are used as a standard unit in the probability calculations to start with.  Just because someone could get lucky and find a block on the first try doesn't mean that the odds of an attacker have improved, nor does it mean that the block represents just what work one node preforms to create the block.  It represents the, often unknown, average amount of work that the whole honest network must perform to produce a block.  The point that the percentages of hashing power still apply regardless of the block interval is true, for if an attacker can produce 51% of the hashing power of the network it doesn't matter what the target interval actually is.

[Tuxavant]

Can't most of this confirmation delay problem be solved by simply designing a POS system that can handle pre-paid tabs? I'm pretty sure where I'm going within the next 10 minutes, where I'll be spending money, and generally how much (most of the time).

Merchants could allow you to setup an account in advance and provide you a bitcoin address to send any amount. When you're heading to the grocery store, fire off $100 to your account. By the time you get there, the merchant can see plenty of confirmations to let you shop. When you leave, the store sends the change back to your pre-determined bitcoin address and gives you a printed receipt.

[DeathAndTaxes]

Can't most of this confirmation delay problem be solved by simply designing a POS system that can handle pre-paid tabs? I'm pretty sure where I'm going within the next 10 minutes, where I'll be spending money, and generally how much (most of the time).

Merchants could allow you to setup an account in advance and provide you a bitcoin address to send any amount. When you're heading to the grocery store, fire off $100 to your account. By the time you get there, the merchant can see plenty of confirmations to let you shop. When you leave, the store sends the change back to your pre-determined bitcoin address and gives you a printed receipt.

It could however the probability that someone would build a hashing farm to execute a Finney attack against a grocery store is highly improbable as the reward would be low, the risk of being identified would be high, and timing would be extremely difficult.

Non-Finney double spends can be detected trivially.  Meatspace is the least likely area to be targetted for attacks because it is not as easily controlled, the person has to risk not just their coins but their identity, and the timing is very tough.

[wareen]

I even asked before if anyone knows of any sites that accept 0 confirmations but no answer from anyone.
I certainly do not know any.

2/3 second to found one
https://bitcointalk.org/index.php?topic=42477.0

Found another one: https://bitcointalk.org/index.php?topic=30475.msg382612#msg382612
Too bad they went out of business with somebody stealing ~80k BTC in total because they (presumably) accepted unconfirmed transactions...

Anyway - just saying that it can be dangerous to make people believe that they don't need to worry about accepting unconfirmed transactions. There might be webshops that outgrow their initial business and while it may have been totally acceptable to not worry about transaction confirmations as long as they only traded cards for Magic: The Gathering, the case might be different now...

Sure everybody from software engineering is aware of the dangers coming from a system or a module being used outside the scope of its original use case - but that's certainly not Bitcoin's fault.

Of course, we're all responsible programmers here and experts on Bitcoin so we don't need to discuss this any further. I think we more or less agree upon the risk of unconfirmed transactions - however small it may be. As long as the merchant is aware of that risk and takes appropriate measures - everything's alright!

The Bitcoin vs. Litecoin comparison page does a good job of summarizing all the pros and cons of faster confirmation times - thanks iddo!

I thought about this whole topic some more and I am now convinced that the real issue is to make instant (<10 seconds) transaction acceptance as secure as possible. First step would probably be to implement the often touted listening period, second step would be to find a good and secure mechanism to check that at least the larger mining pools know about the transaction.

As a third step I'd suggest implementing a confidence measure for transactions, because security is not a boolean thing. This could either be implemented as a webservice like the Transaction Radar or better still, directly in the client, taking into account all the information the client has (ie. number of connections, priority of the transaction, number of peers knowing about the transaction, relative hashing power of the mining nodes that know the transaction, time since last block, etc.). Coming up with a good formula for such a measure might be a bit tricky, but we could start with some conservative guesstimations.
Once we had such a measure, merchants could use it in combination with the value of the transaction and possibly other external information and decide when it is safe enough for them to accept the payment.

Sorry to go a bit off-topic with this, but I think what most people really want from faster confirmation time is more security in under 10 minutes. The problem with pool centralization can probably be tackled with other measures (eg. p2pool).

[kano]

...
I thought about this whole topic some more and I am now convinced that the real issue is to make instant (<10 seconds) transaction acceptance as secure as possible. First step would probably be to implement the often touted listening period, second step would be to find a good and secure mechanism to check that at least the larger mining pools know about the transaction.

As a third step I'd suggest implementing a confidence measure for transactions, because security is not a boolean thing. This could either be implemented as a webservice like the Transaction Radar or better still, directly in the client, taking into account all the information the client has (ie. number of connections, priority of the transaction, number of peers knowing about the transaction, relative hashing power of the mining nodes that know the transaction, time since last block, etc.). Coming up with a good formula for such a measure might be a bit tricky, but we could start with some conservative guesstimations.
Once we had such a measure, merchants could use it in combination with the value of the transaction and possibly other external information and decide when it is safe enough for them to accept the payment.

Sorry to go a bit off-topic with this, but I think what most people really want from faster confirmation time is more security in under 10 minutes. The problem with pool centralization can probably be tackled with other measures (eg. p2pool).

Yes I agree with you totally on the issue of "instant (<10 seconds) transaction"
However considering how simple my change I've suggested is and the rather high negative response to it is, I can't see any "instant (<10 seconds) transaction" suggestion getting acceptance for a VERY long time.

Again, my reasoning behind this change is that it is a simple change to the protocol, it gives people that warm fuzzy feeling they want with confirms and they can even get exactly the same security (whatever that clearly unknown value to almost everyone is) that they currently get but also allows people to reduce the ridiculous wait times down to not so ridiculous wait times if they want and still have confirms.

... and it reduces the variance.

[DeathAndTaxes]

Again, my reasoning behind this change is that it is a simple change to the protocol, it gives people that warm fuzzy feeling they want with confirms and they can even get exactly the same security (whatever that clearly unknown value to almost everyone is) that they currently get but also allows people to reduce the ridiculous wait times down to not so ridiculous wait times if they want and still have confirms.... and it reduces the variance.

None of those are true except the reduction in variance.  A breaking change on a peer2peer network is never "simple".

[kano]

Again, my reasoning behind this change is that it is a simple change to the protocol, it gives people that warm fuzzy feeling they want with confirms and they can even get exactly the same security (whatever that clearly unknown value to almost everyone is) that they currently get but also allows people to reduce the ridiculous wait times down to not so ridiculous wait times if they want and still have confirms.... and it reduces the variance.

None of those are true except the reduction in variance.  A breaking change on a peer2peer network is never "simple".

Point out what in there is false ...
(obviously your definition of simple may differ from mine )

[DeathAndTaxes]

There are essentially 4 threats that a block chain faces.

0-confirm doublespends
finney attack
reversing blocks
51% attack.

A shorter block round does nothing against 51% attack or 0-confirms.  2 minute block does not to promote real time access.  I know you think 0-confirms transactions are impossible but if you do you should abandon Bitcoin now because retail usage will REQUIRE realtime transaction processing and 2 minute blocks isn't realtime.

2 minute block does nothing against a finney attack.  To get equal protection from reversing a block requires the same amount of time so it does nothing there either.

The only place it helps is the hypothetical (and likely non-existent merchant) who is only willing to wait 2 to 9 minutes but not 10+ minutes and thus uses 0-confirm transactions on 10 minute block but would wait for 1-confirm on a 2 minute block.  That merchant doesn't exist.  Either a merchant wants max security or realtime access their is no merchant who is sitting there saying "I can't only 3.17 minutes so I guess I need to accept 0-confirm transactions.

[paraipan]

Can't most of this confirmation delay problem be solved by simply designing a POS system that can handle pre-paid tabs? I'm pretty sure where I'm going within the next 10 minutes, where I'll be spending money, and generally how much (most of the time).

Merchants could allow you to setup an account in advance and provide you a bitcoin address to send any amount. When you're heading to the grocery store, fire off $100 to your account. By the time you get there, the merchant can see plenty of confirmations to let you shop. When you leave, the store sends the change back to your pre-determined bitcoin address and gives you a printed receipt.

good idea, i was thinking about this few days ago too, every "big store" could use a card system that you can charge with coins before leaving home for example. To receive the card you could tell them the unique address they gave you to send the coins, do your shopping and pay with that. Have an option to keep the change on the card or send back to one of your addresses after paying.
This option opens allot of possibilities for the merchant and resolves the slow confirmation problem with big purchases.

If bitcoin ever starts being used for making small purchases like pack cigarettes, bread, toilet paper and such you have to realize that accepting 0-confirms will not be an issue because once broadcast a transaction will get in a block for sure, it's in the code.

[kano]

There are essentially 4 threats that a block chain faces.

0-confirm doublespends
finney attack
reversing blocks
51% attack.

A shorter block round does nothing against 51% attack or 0-confirms.  2 minute block does not to promote real time access.  I know you think 0-confirms transactions are impossible but if you do you should abandon Bitcoin now because retail usage will REQUIRE realtime transaction processing and 2 minute blocks isn't realtime.

2 minute block does nothing against a finney attack.  To get equal protection from reversing a block requires the same amount of time so it does nothing there either.

The only place it helps is the hypothetical (and likely non-existent merchant) who is only willing to wait 2 to 9 minutes but not 10+ minutes and thus uses 0-confirm transactions on 10 minute block but would wait for 1-confirm on a 2 minute block.  That merchant doesn't exist.  Either a merchant wants max security or realtime access their is no merchant who is sitting there saying "I can't only 3.17 minutes so I guess I need to accept 0-confirm transactions.

Thanks for that summary.
Nice to get that definitive 100% complete list of all the attacks that will ever be possible on the current BTC block-chain.

However, you clearly haven't actually looked at the numbers relating to those attacks and given some consideration as to what those numbers actually mean and what reducing the block time to 2 minutes actually means.

It's pretty much the standard response of a lot (not all) people around here that since Satoshi said the value for Bitcoin in some calculation is X then it must stay at X forever.
I'm not arguing that X is right or wrong I am offering a suggestion that all the mythical online BTC services that usually trade with 5 confirmations that averages on 50 minutes but can take anywhere from a few minutes to a few hours can be given the option to reduce the variance in that (by simply using 5x2minutes x5 confirms) or even reduce the average time by using less than 5x the number of old confirms.

You see 10 minutes x 5 x variance is actually a very long time.
Even 2 minutes x 25 x variance is actually a real world solution.
Yes you can quote maths all day long, but the variance when the base figure is 5x the size certainly makes me say f*** it I'll go do something else. Were it not for the fact that I actually mine BTC, I'd have given up not long after I started with BTC back in July.

You yourself keep arguing that 0 confirmations is fine - so I can't even see your argument against 5 x 2 minute confirmations except that your promoting 0 confirmations here where you should be trying to convince the BTC community if you think it is safe.
Though I will add that there have certainly been some interesting comments in here regarding the safety of accepting 0 confirmations - though myself I have no idea of the details.

[gmaxwell]

It's pretty much the standard response of a lot (not all) people around here that since Satoshi said the value for Bitcoin in some calculation is X then it must stay at X forever.

You received may other detailed and thought out arguments here and your dismissal of them out of hand is incredibly disrespectful to the people who took the time to response to this obvious non-starter proposal.   That said, you're right.  That is the response and for a damn good reason.

The only reason bitcoin isn't inferior to the numerous other 'currencies' out there is because the rules of the core system— good or bad— are mostly nonvolatile.

Sometimes this results in weaknesses, maybe even ones which could be corrected but not for the inability for grand wizards to continue to tweak the rules,  but at least you can plan for and engineer around those weaknesses without the risk that BitFed Chair Kano is going to dish out another Great Plan.

This means that changes need to be well justified and be mostly free of negative side effects— even to people who prioritize costs/benefits quite differently from you.  Certainly there are things that can pass the test— but twiddling with block times or difficulty calculations ... probably not.

Some of these things, like the inter-block time, are just trade-offs— there are a broad range of values which are all members of the pareto frontier (though I think 2 minute blocks are probably fast enough to actually be outside the range of good trade-offs for the reason given here)  and any different value will be worse for enough of the users (without being _better_ for many more of them) that you'll not over come the well justified bias against change. (Well justified because changes undermine confidence in the stability of the system and simply because changes have serious costs)

You also encounter this kind of stop-screwing-with-shit response because there is simply a constant stream of people who think it would be great to leave their mark on bitcoin by twiddling this @#$@ inconsequential parameter or that @#$@# inconsequential parameter.  While doing to they distract people from real development work and cast a cloud of doubt over the stability of the system for people who don't know enough to know that these proposals will go nowhere. Sometimes people do this in order to promote "alternatives" whos increased adoption will be greatly profitable for them.  Whatever the motivations— honest, selfish, or otherwise— it all gets old really fast.

[kano]

My comment is simple and based on the following:
The current block time is 10 minutes.
What does this actually represent?
Why does the default client enforce 5 confirmations for txn's and 120 confirmations for block generation?
How exactly is 1/5 of that bad for txn's?
(Why is block generation 120 confirmations?)

I am not saying that 1/5 of that is NOT bad - though the nay sayers can always just use 5x 1/5 ...
I'm just really not interested in the comments that say that it is 10 minutes and 10 minutes is safe, but 2 minutes isn't safe.
Yes 1/5 may not be as secure for most or all circumstances, but "because Satoshi said so" really isn't a good excuse.
Even worse to say that security at level X is fine but at X/5 isn't fine.
That may or may not be the case, but quantify it, not just simply say X is good, X/5 is bad.
Also, I would actually not be at all surprised to find that even X is bad under the current environment ... ...

... as for leaving a mark ... who gives a shit.
For all I care you can say it was your idea.
The "problem" that "I" perceive is what I'm looking at and saying that 'maths says it must be that way' obviously doesn't solve any problem.
(as before with my thread about the difficulty calculation - which "Satoshi's" code has a BUG in it that produces a slightly higher difficulty than expected from the calculation due to a common end case bug ...)

[DeathAndTaxes]

My comment is simple and based on the following:
The current block time is 10 minutes.
What does this actually represent?
Why does the default client enforce 5 confirmations for txn's and 120 confirmations for block generation?
How exactly is 1/5 of that bad for txn's?
(Why is block generation 120 confirmations?)

I am not saying that 1/5 of that is NOT bad - though the nay sayers can always just use 5x 1/5 ...
I'm just really not interested in the comments that say that it is 10 minutes and 10 minutes is safe, but 2 minutes isn't safe.
Yes 1/5 may not be as secure for most or all circumstances, but "because Satoshi said so" really isn't a good excuse.
Even worse to say that security at level X is fine but at X/5 isn't fine.
That may or may not be the case, but quantify it, not just simply say X is good, X/5 is bad.
Also, I would actually not be at all surprised to find that even X is bad under the current environment ... ...

... as for leaving a mark ... who gives a shit.
For all I care you can say it was your idea.
The "problem" that "I" perceive is what I'm looking at and saying that 'maths says it must be that way' obviously doesn't solve any problem.
(as before with my thread about the difficulty calculation - which "Satoshi's" code has a BUG in it that produces a slightly higher difficulty than expected from the calculation due to a common end case bug ...)

Satoshi never said 5 is safe.  His paper outlines a large number of attack strengths and the decreasing probability of reversal.  For very high attack strength 5 is pittifully weak.  To have real strength would require hundreds of confirmations.   Maybe you should actually read the paper.  If you want to save time the confirmations and strength analysis is at the end.

[gmaxwell]

Why does the default client enforce 5 confirmations for txn's and 120 confirmations for block generation?

Block generations which are lost in a chain split (e.g. due to a network partitioning event) can _never_ be recovered, even assuming a complete lack of bad intent. Moreover, it's "coins from thin air" — the burden on the economy from not being able to spend a coin the instant that it's generated is pretty insignificant... thus favoring bigger numbers.

The actual limit is 100, but the client uses a somewhat higher number because if you're ahead of your peers on the chain and you use it right at 100 your txn will drop.   In the common situation where you have many inputs to choose from the benefit of being able to choose the 'barely viable' one is small.

Would 200 or 90 have worked just as well? They'd give a little more or less security against a particular failure mode, in exchange for slower or faster access to newly created coins, but bother of those would probably be okay. But as a chain validation rules they have to be identical across the network, so there must actually be a number. No number is perfect, and people will have different preferences.

The "problem" that "I" perceive is what I'm looking at and saying that 'maths says it must be that way' obviously doesn't solve any problem.
(as before with my thread about the difficulty calculation - which "Satoshi's" code has a BUG in it that produces a slightly higher difficulty than expected from the calculation due to a common end case bug ...)

No, you've misunderstood the time-warp bug. The difficulty is not too high or too low as a result. The size of the window is correct.  The issue is that the sequence of windows spans from block to block without overlap, which means that one _gap_ (not one block) is excluded.

[kano]

Why does the default client enforce 5 confirmations for txn's and 120 confirmations for block generation?

Block generations which are lost in a chain split (e.g. due to a network partitioning event) can _never_ be recovered, even assuming a complete lack of bad intent. Moreover, it's "coins from thin air" — the burden on the economy from not being able to spend a coin the instant that it's generated is pretty insignificant... thus favoring bigger numbers.

The actual limit is 100, but the client uses a somewhat higher number because if you're ahead of your peers on the chain and you use it right at 100 your txn will drop.   In the common situation where you have many inputs to choose from the benefit of being able to choose the 'barely viable' one is small.

Would 200 or 90 have worked just as well? They'd give a little more or less security against a particular failure mode, in exchange for slower or faster access to newly created coins, but bother of those would probably be okay. But as a chain validation rules they have to be identical across the network, so there must actually be a number. No number is perfect, and people will have different preferences.

The "problem" that "I" perceive is what I'm looking at and saying that 'maths says it must be that way' obviously doesn't solve any problem.
(as before with my thread about the difficulty calculation - which "Satoshi's" code has a BUG in it that produces a slightly higher difficulty than expected from the calculation due to a common end case bug ...)

No, you've misunderstood the time-warp bug. The difficulty is not too high or too low as a result. The size of the window is correct.  The issue is that the sequence of windows spans from block to block without overlap, which means that one _gap_ (not one block) is excluded.

Yes I know it is one gap - that's what I said in the other thread.
However you call it - it ignores the time of the first new difficulty block.
The gap from the last difficulty block to the first new difficulty block (i.e. the time of the first new difficulty block) is excluded (thus 2015 gaps) but divided by 2016 thus reducing the average block time thus slightly increasing the difficulty - that IS correct.
If you really can't see it - let me know and I'll quote the actual code with comments.

[FreeMoney]

Block generations which are lost in a chain split (e.g. due to a network partitioning event) can _never_ be recovered, even assuming a complete lack of bad intent. 

What does this mean?

If the split is resolved in less than 120 then the generator loses them. If longer than 120 then he might have spent them and the recipient loses them, but so what? The sender still owes however many coins, he's the one out coins if there is no ill intent exactly as if the split is healed earlier.

Maybe I don't get it.

[gmaxwell]

If the split is resolved in less than 120 then the generator loses them. If longer than 120 then he might have spent them and the recipient loses them, but so what? The sender still owes however many coins, he's the one out coins if there is no ill intent exactly as if the split is healed earlier.
Maybe I don't get it.

In the less than 120 case he's not "out them"— they simply never transferred into his control and he never could not have made someone else think they were on their way.

Contrast to a transaction with older coins— in a split the transaction could fall out of the chain, but the nodes would immediately put the transaction back in. Absent a specific effort to respend the same inputs in the split (which would require having awareness and access to the split) this will always be successful.  Basically for the coinbase every split deep enough to cover it is as bad as the worst case in the regular transaction case.

[SgtSpike]

Can't most of this confirmation delay problem be solved by simply designing a POS system that can handle pre-paid tabs? I'm pretty sure where I'm going within the next 10 minutes, where I'll be spending money, and generally how much (most of the time).

Merchants could allow you to setup an account in advance and provide you a bitcoin address to send any amount. When you're heading to the grocery store, fire off $100 to your account. By the time you get there, the merchant can see plenty of confirmations to let you shop. When you leave, the store sends the change back to your pre-determined bitcoin address and gives you a printed receipt.

Bad idea.

1.  People are impulsive.  I'd say that probably 50% of the time I go to the store, it's on my way from point A to point B, not a planned trip originating from my house.
2.  It'd be inconvenient compared to current credit/debit methods.  People will always use the most convenient method, so Bitcoin must be competitive with credit/debit services, not more inconvenient than them.
3.  There's no reason 0-confirmation couldn't work for a grocery/department store.  I imagine it would be treated the same as outright theft if someone double-spent, so any security cameras would show evidence of who the person was, and they could be arrested and charged if caught.

[MoonShadow]

3.  There's no reason 0-confirmation couldn't work for a grocery/department store.  I imagine it would be treated the same as outright theft if someone double-spent, so any security cameras would show evidence of who the person was, and they could be arrested and charged if caught.

This ^^

A zero confirm transaction in real life is just like cash in this way.  The vendor can instantly confirm that the coins that you are sending them both exist and that, at that moment, they are legitimately yours. (And without needing to verify your identity for the majority of transaction events)  This is far better than even what the retail vendor can do to verify that a $20 bill is not counterfit, which is largely limited to the use of a pH marker and going on faith that their cashier isn't a complete idiot.  The fact that it's possible to defraud someone who accepts zero-confirm transactions doesn't equate to that being an unacceptable business risk, particularly when compared to the risks of not only counterfit cash, but credit card fraud and check fraud that vendors are notrequired by legal tender laws to accept as a condition of doing business.  Confirmations would only be required for high value items on the order of a motor vehicle, or online digtial products that 1) are instantaneous and irreversable and 2) do not require that the user provide their identity in some fashion.  For example, Valve could accept bitcoin through Steam with zero confirms because they 1) can reverse the purchase of a license or virtual item if the customer's coins never arrive, whether that is intentional or not and 2) Valve knows who their customers are, even if they don't know what their real names or home addresses might be, because they know their IP addressses.  Any online vendor that sells physical products, say via dropshipping, can simply confirm the deal at the end of the session and only approve the shipments to the dropshipping company once a few confirms have occurred, or cancel said shipments with an email notice if the confirmations never materialize within a rational time frame.  This practice, once common, will be as acceptable to the online shopping public as the practice of providing an unknown server your name, addresss, CC number and date of birth; in addition to being significantly safer and more convient for the customer.  It would also have the side benefit of protecting the vendor from the possibility of long confirmation delays because the customer was unwilling to add a transaction fee, for if there is no transaction fee and the transaction languishes in the queue, the deal will simply expire and if the customer was legitimately trying to buy something, he won't be so inclined to try to save .01 BTC.

[Tuxavant]

A zero confirm transaction in real life is just like cash in this way.

Well said. I'm sold.

[kano]

OK, I give up.

The typical answer seems to be that everyone is going to go out and convince all the online BTC traders to accept 0 confirms for small transactions since very few if any already do that - and the risks involved in accepting 0 confirms are so small that none should care for anything but large transactions.
(hmm and yet after 2 years most online BTC traders still don't accept 0 confirms and I can't see anyone here doing anything about that either)

Thus the variance and time problems (of which there are many) with confirms can be ignored.

OK the idea is no good.
Close thread.