Suggested MAJOR change to Bitcoin

[kano]

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

What FUD?

[1714873042]

1714873042

[1714873042]

1714873042

[1714873042]

1714873042

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