Bitcoin Forum
December 08, 2016, 02:46:57 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 [6]  All
  Print  
Author Topic: Suggested MAJOR change to Bitcoin  (Read 8050 times)
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 13, 2011, 03:50:26 AM
 #101

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.


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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481208417
Hero Member
*
Offline Offline

Posts: 1481208417

View Profile Personal Message (Offline)

Ignore
1481208417
Reply with quote  #2

1481208417
Report to moderator
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
November 13, 2011, 08:24:29 AM
 #102


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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
November 13, 2011, 08:45:21 AM
 #103

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
Legendary
*
Offline Offline

Activity: 1344



View Profile
November 14, 2011, 04:44:34 PM
 #104

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
Legendary
*
Offline Offline

Activity: 1666



View Profile
November 14, 2011, 10:43:20 PM
 #105


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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
Tuxavant
Hero Member
*****
Offline Offline

Activity: 756


Bitcoin Mayor of Las Vegas


View Profile WWW
November 14, 2011, 11:04:57 PM
 #106

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

Well said. I'm sold.

Generation Bitcoin | G+ | FB | Bitcoins In Vegas | CoinBus.com | TOR Exit Operator 1MVTPATVCKBMfALRHJsXpHfKJu7GyL7nAc
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 14, 2011, 11:17:52 PM
 #107

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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 2 3 4 5 [6]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!