Suggested MAJOR change to Bitcoin

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

[1714152391]

1714152391

[1714152391]

1714152391

[1714152391]

1714152391

[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