Suggested MAJOR change to Bitcoin

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