Topic: Suggested MAJOR change to Bitcoin (Read 9442 times)

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.

Well said. I'm sold.

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.

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.

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.

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.

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.

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.



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.

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.

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

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.

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.

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.

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.

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

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

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.

Found another one: https://bitcointalksearch.org/topic/m.382612
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).

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.

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.