Hyperdeflation, own half the world by headstart - don't you care at all?

[DeathAndTaxes]

Not a single one of those is still valid.  The 51% attack issue was a real problem a year ago, but it no longer is.  Any government that tried to build a gpu cluster capable of overtaking the network now would distort that market and pay huge premiums to do so, even if other goverments didn't secretly oppose them.

No govt (or other entity with $1M+ budget) would build a hashing farm out of GPUs they would contract for some sASIC or ASICs.  Still any govt which killed Bitcoin would only prove the system works and is important enough to try and destroy.

Bitcoin even "killed" would be the cryptocurrency equivalent of napster and would spawn the the crypto equivalent of bittorrent.  Every attack would only make the next generation more robust, more popular and more mainstream.  Most people didn't even know about mp3 or file sharing before the record industry attacked Napster.

You can't kill ideas.  No doubt people will keep trying but open source means knowledge is retained and perfected.  The next version isn't starting from scratch.  Cryptocurrency WILL be mainstream.  It might not be Bitcoin but it will happen.

Trying to stop it is as futile as trying to prevent public access to encryption (which yes the US govt did try back in the 1970s - 1990s).

[1713989464]

1713989464

[MoonShadow]

Not a single one of those is still valid.  The 51% attack issue was a real problem a year ago, but it no longer is.  Any government that tried to build a gpu cluster capable of overtaking the network now would distort that market and pay huge premiums to do so, even if other goverments didn't secretly oppose them.

No govt (or other entity with $1M+ budget) would build a hashing farm out of GPUs they would contract for some sASIC or ASICs.  

Hmmm, probably so, but the end result would be similar.  Such moves against bitcoin wouldn't go unnoticed forever, and there are certainly factions both between and within governments that would likely move to undermine any such attacks.

[Haplo]

Hmmm, probably so, but the end result would be similar.  Such moves against bitcoin wouldn't go unnoticed forever, and there are certainly factions both between and within governments that would likely move to undermine any such attacks.

The US government happily spends $1 Trillion every year in bridge to nowhere projects. That's 1000 billion dollars. 100million would easily erase BTC forever, and there's absolutely zero that could be done about it. Mind you I'm ignoring any current computing clusters they might have available to compete.

Sure, it might be obvious that something is going wrong, but let's not forget who invented Tor, so if you think it will be easy or even possible to stop, think again. If the government wants to DoS BTC, then BTC will be DoSed. The developers would have to spend all their time trying to come up with some sort of counter-strategy, and development on the actual features of BTC would stop (best case scenario). However, given a few months eventually people would give up interest, and that's the end of that. Since the government can play by the rules and still do damage, there's basically nothing you can do against it.

Furthermore, timejacking attacks and similar don't even require 51%. There's some evidence that certain pool operators may be doing this already, although for the most part pool operators have refrained from causing trouble. (well, except for luke jr, and all of that noise)

Finally, at a current rate of only 80tx per block, it's totally unknown how the network will behave if/when things get really busy. It's also unknown how things will play out as the mining subsidy drops off, although already there's problems with empty blocks and botnets and such. An unreliable network is worthless to someone who wants to do business. Imagine if VISA transactions could be randomly dropped and had to be resent, or if it took an hour or 6 hours just to be sure that didn't happen. There would be no VISA. Not only that, but privacy on BTC sucks, which is one of its supposed main advantages vs centralized money. While there are a few ways privacy could be improved (that I know of thus far), an improvement in blockchain reliability would require some major changes to the protocol, and it's not necessarily obvious what would work or what wouldn't. That sort of effort isn't likely to happen unless its with another currency, or in BTC until it's much too late to fix.

I never said that cryptocurrencies were a bad idea, or that they can't work at all, just that BTC is an experiment and likely to come crashing down at one point or another.

[MoonShadow]

Hmmm, probably so, but the end result would be similar.  Such moves against bitcoin wouldn't go unnoticed forever, and there are certainly factions both between and within governments that would likely move to undermine any such attacks.

The US government happily spends $1 Trillion every year in bridge to nowhere projects. That's 1000 billion dollars. 100million would easily erase BTC forever, and there's absolutely zero that could be done about it. Mind you I'm ignoring any current computing clusters they might have available to compete.

Sure, it might be obvious that something is going wrong, but let's not forget who invented Tor, so if you think it will be easy or even possible to stop, think again. If the government wants to DoS BTC, then BTC will be DoSed. The developers would have to spend all their time trying to come up with some sort of counter-strategy, and development on the actual features of BTC would stop (best case scenario). However, given a few months eventually people would give up interest, and that's the end of that. Since the government can play by the rules and still do damage, there's basically nothing you can do against it.

Furthermore, timejacking attacks and similar don't even require 51%. There's some evidence that certain pool operators may be doing this already, although for the most part pool operators have refrained from causing trouble. (well, except for luke jr, and all of that noise)

Finally, at a current rate of only 80tx per block, it's totally unknown how the network will behave if/when things get really busy. It's also unknown how things will play out as the mining subsidy drops off, although already there's problems with empty blocks and botnets and such. An unreliable network is worthless to someone who wants to do business. Imagine if VISA transactions could be randomly dropped and had to be resent, or if it took an hour or 6 hours just to be sure that didn't happen. There would be no VISA. Not only that, but privacy on BTC sucks, which is one of its supposed main advantages vs centralized money. While there are a few ways privacy could be improved (that I know of thus far), an improvement in blockchain reliability would require some major changes to the protocol, and it's not necessarily obvious what would work or what wouldn't. That sort of effort isn't likely to happen unless its with another currency, or in BTC until it's much too late to fix.

I never said that cryptocurrencies were a bad idea, or that they can't work at all, just that BTC is an experiment and likely to come crashing down at one point or another.

You display your ignorance of the system with these above statements.  No, the US government couldn't do more than irritate the network with an Anonymous style DoS.  It would take some talented work for them to find just my node, much less all of them.  And you can't DoS what you can't find.  It's literally true that the only way to stop Bitcoin now is to shut off the entire Internet and keep it that way.

[Haplo]

I'm not talking about a network DoS. I'm talking about DoSing the blockchain and its functioning.

http://bitcoin.stackexchange.com/questions/1099/string-along-is-this-possible-and-is-it-an-attack
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

Some combination of the above while only generating empty blocks, and virtually no tx will get to the blockchain anymore. If enough tx back up, it can become impossible for all the backed up tx to fit in a single block, and once that happens tx will be dropped more often than they succeed.

[MoonShadow]

I'm not talking about a network DoS. I'm talking about DoSing the blockchain and its functioning.

http://bitcoin.stackexchange.com/questions/1099/string-along-is-this-possible-and-is-it-an-attack
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

Some combination of the above while only generating empty blocks, and virtually no tx will get to the blockchain anymore. If enough tx back up, it can become impossible for all the backed up tx to fit in a single block, and once that happens tx will be dropped more often than they succeed.

Except those theories are B.S.  The only way to do what they imply is to have enough of the hashing power to deny all other miners the chance to broadcast a valid block, which either requires significantly more than 50% of the total hashing power of the network (which is actually over 100% if you are attacking the network, the 50% number assumes the worst case, that half of the previously honest network suddenly turns malicious) in which case you can do much more harm to the legitimacy of Bitcoin than a simple DoS attack on the blockchain; or one must be able to deny Internet access to a significant majority of your mining competitors for as long as you can (thus creating a sudden drop in the effective hashing of the network, leaving you with a cluster that is effectively half of the network anyway, but even this still requires that you be the biggest single cluster on the network).  The only known effective way to deny all miners access to the Internet, is to turn the entire thing off.  I seriously doubt that is even possible these days, for Bitcoin isn't particularly dependent upon DNS, which is the 'normal' way that is imagined about an 'internet kill switch'. 

In the long run, the most damage that either of these methods could do is to delay transaction clearing, not prevent them from occurring.  This could be a problem if the network could be backed up for days, but that is extremely unlikely.  Even Deepbit (should it turn to the dark side) couldn't do either of these things for more than an hour, assuming that the contributing miners didn't bail.

And as you pointed out, the current transaction rate wouldn't result in much backup at all.  Bitcoin would have to be several orders of magnitude more popular for that to be any risk at all, in which case bitcoin would also have several orders of magnitude more market cap value, and thus several orders of magnitude more hashing power (at least if the past three years is any guide in this matter).

[whitslack]

Eventually (100+ years, probably) this would lead to a loss of fungibility of BTC, and the smallest unit of coin would end up buying more than the smallest items you would want to buy.

I'm surprised no one else seized the opportunity to correct this false logic. Bitcoins are infinitely divisible. That they are presently divisible only to 8 places after the decimal point is just an implementation detail of the current protocol. It would be trivial to adjust the software so that, after a certain block number is reached, the decimal point becomes shifted for all blocks after that (until the next time a shift is needed). Some day, the Satoshi will not be the smallest possible unit of Bitcoin. We will have milli-Satoshis and perhaps even micro-Satoshis eventually. The beauty of a digital commodity is that it is infinitely divisible with perfect accuracy.

[MoonShadow]

Eventually (100+ years, probably) this would lead to a loss of fungibility of BTC, and the smallest unit of coin would end up buying more than the smallest items you would want to buy.

I'm surprised no one else seized the opportunity to correct this false logic. Bitcoins are infinitely divisible. That they are presently divisible only to 8 places after the decimal point is just an implementation detail of the current protocol. It would be trivial to adjust the software so that, after a certain block number is reached, the decimal point becomes shifted for all blocks after that (until the next time a shift is needed). Some day, the Satoshi will not be the smallest possible unit of Bitcoin. We will have milli-Satoshis and perhaps even micro-Satoshis eventually. The beauty of a digital commodity is that it is infinitely divisible with perfect accuracy.

Personally, I didn't feel like it.  But good call considering you haven't been here very long, most people don't understand this is possible.

[R-]

$150M monetary base is larger than some nations.   To put it into a useful context Paypal for example only processed $5B in transactions last year.  With a velocity of 10 (money changing hands 10x annually) $150M monetary base could support $1.5B in transactions.

Most of us expect that the annual velocity of bitcoin to be much higher than fiat currencies, due to the relatively quick settlement rate of the bitcoin network.  Although most people get paid for their work weekly, with about a week delay on average, before they can again spend those funds themselves; it's actually possible for employees in a bitcoin economy to be paid daily and spend those same coins an hour later.  The higher velocity capable with bitcoin also means  that the bitcoin price is likely to be suppressed compared to a currency with a much lower velocity due to technical constraints.

For those who don't understand what I'm talking about; although cash is an instant form of settlement of trades, most transactions in modern economies are credit transactions.  Although such transactions are 'completed' instantly (based upon the credit of the buyer) they take up to 45 days or longer to be 'settled', during which time any real funds involved in the transactions are not available for further transactions.  Think about sending a paper check in the mail to pay a bill; the funds to pay the bill are supposed to be in your account before you write the check (otherwise it's "kiting" which is fraud) and mail the check.  The check must travel via mail to the company, then back to the bank, before the transaction is completed.  This is true even if the company credits your payment upon arrival or not.  But the company cannot use those funds when they credit you with the payment, they must wait until the check clears your bank and is on account at their bank.  As you can imagine, just a paper check can take weeks.  Businesses with merchant accounts at the credit card companies can get access to those funds faster (as in a couple of hours) because the credit card company can credit the merchant's account for an (assumed) valid CC transaction; however, such credit based transactions are not final for much longer due to rules and laws governing consumer credit protection.  So a merchant could re-spend his new funds pretty quickly, but if it turns out that he was burned he loses those funds after the fact, (chargebacks) and then finds himself in the debt of the CC company.  It doesn't take long before merchants start to maintain a standing reserve balance, just like one would do for a checking account.  The aggregate result of all these reserve accounts is a drop in velocity/increase in cash demand/increase in relative fiat currency value.  (Yes, the suppression of velocity can result in the increase in value of the currency, so long as the issuing institution is expected to still be able to follow through).

Since bitcoin is truly settled (as fast as) in one hour, those funds really can be re-spent without fear of chargebacks.  Thus reserve accounts are less necessary under bitcoin than under a credit based fiat economy, which was the only way to do online transactions up until this point. 

This is a superb point.

[airnesst]

and what will happen when all 21 millions bitcoins will be on the market ? wont be easier to attack the network at that time ?

[R-]

and what will happen when all 21 millions bitcoins will be on the market ? wont be easier to attack the network at that time ?

If everyone stops mining it will.

[Haplo]

Eventually (100+ years, probably) this would lead to a loss of fungibility of BTC, and the smallest unit of coin would end up buying more than the smallest items you would want to buy.

I'm surprised no one else seized the opportunity to correct this false logic. Bitcoins are infinitely divisible. That they are presently divisible only to 8 places after the decimal point is just an implementation detail of the current protocol. It would be trivial to adjust the software so that, after a certain block number is reached, the decimal point becomes shifted for all blocks after that (until the next time a shift is needed). Some day, the Satoshi will not be the smallest possible unit of Bitcoin. We will have milli-Satoshis and perhaps even micro-Satoshis eventually. The beauty of a digital commodity is that it is infinitely divisible with perfect accuracy.

Personally, I didn't feel like it.  But good call considering you haven't been here very long, most people don't understand this is possible.

Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.

In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things. Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.

Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division. Admittedly, that's not much of a problem since BTC and the blockchain don't scale properly to that sort of throughput anyway.

[MoonShadow]

Eventually (100+ years, probably) this would lead to a loss of fungibility of BTC, and the smallest unit of coin would end up buying more than the smallest items you would want to buy.

I'm surprised no one else seized the opportunity to correct this false logic. Bitcoins are infinitely divisible. That they are presently divisible only to 8 places after the decimal point is just an implementation detail of the current protocol. It would be trivial to adjust the software so that, after a certain block number is reached, the decimal point becomes shifted for all blocks after that (until the next time a shift is needed). Some day, the Satoshi will not be the smallest possible unit of Bitcoin. We will have milli-Satoshis and perhaps even micro-Satoshis eventually. The beauty of a digital commodity is that it is infinitely divisible with perfect accuracy.

Personally, I didn't feel like it.  But good call considering you haven't been here very long, most people don't understand this is possible.

Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.

Developers can't "stop the world" in any context, and tweaks can be made to the running network anyway, at least as long as users are willing to upgrade.  The network is particularly fault tolerant.

In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things.

You don't know how the system works, but in the same sentence claim that Satoshi did a lot of stupid things?  Are you trolling?

Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.

Point one isn't true, but only because a decimal shift isn't how it would be done.  The values are stored in a 64 bit integer variable, but only about 54 bits are in use, so the leading bits can be taken as a 'marker' to tag values using an extended standard.

Point two is certainly true.

Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division.

Where did you come up with that BS number?

[R-]

Eventually (100+ years, probably) this would lead to a loss of fungibility of BTC, and the smallest unit of coin would end up buying more than the smallest items you would want to buy.

I'm surprised no one else seized the opportunity to correct this false logic. Bitcoins are infinitely divisible. That they are presently divisible only to 8 places after the decimal point is just an implementation detail of the current protocol. It would be trivial to adjust the software so that, after a certain block number is reached, the decimal point becomes shifted for all blocks after that (until the next time a shift is needed). Some day, the Satoshi will not be the smallest possible unit of Bitcoin. We will have milli-Satoshis and perhaps even micro-Satoshis eventually. The beauty of a digital commodity is that it is infinitely divisible with perfect accuracy.

Personally, I didn't feel like it.  But good call considering you haven't been here very long, most people don't understand this is possible.

Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.

Developers can't "stop the world" in any context, and tweaks can be made to the running network anyway, at least as long as users are willing to upgrade.  The network is particularly fault tolerant.

In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things.

You don't know how the system works, but in the same sentence claim that Satoshi did a lot of stupid things?  Are you trolling?

Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.

Point one isn't true, but only because a decimal shift isn't how it would be done.  The values are stored in a 64 bit integer variable, but only about 54 bits are in use, so the leading bits can be taken as a 'marker' to tag values using an extended standard.

Point two is certainly true.

Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division.

Where did you come up with that BS number?

I am digging this banter. Keep it coming!

[Haplo]

Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.

Developers can't "stop the world" in any context, and tweaks can be made to the running network anyway, at least as long as users are willing to upgrade.  The network is particularly fault tolerant.

Like they did with the overflow bug? It may be true they can't now, but it could be necessary, and/or it will take a very long time to get everyone to upgrade. Assuming it doesn't get broken because people "upgrade" themselves to game the system.

In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things.

You don't know how the system works, but in the same sentence claim that Satoshi did a lot of stupid things?  Are you trolling?

When I say "stupid and unnecessary things", I mean the 2GB blockchain that's been generated in only three years and with provably less than 5-10 tx per minute! At VISA levels that's totally unsustainable. 90% of all "usages" of scripts and contracts are totally economically useless and will probably never be used by anyone for anything, whereas per file size scripts take up the vast majority of unspent txOuts that need to be tracked. The only thing BTC really is is a giant, overglorified balance ledger sheet, that needs only to track unspent account balances per account in order to be accurate. Instead it tracks unspent txOuts individually, which then all must be put into txIns individually in order to be spent, yet again multiplying the size requirement of the blockchain.

If the blockchain had been engineered to efficiently fill its primary purpose- simple yet secure monetary exchange, rather than a bunch of useless contracts by default, then the blockchain could be < 50MB rather than > 2GB. I consider it a product of Satoshi's economic ignorance, although beyond that I can't read his mind so I don't know what else he was thinking when he designed it to be such a complicated mess. The abstraction between public key and address hash is also extra without actually providing much benefit (unless you want to keep your SHA256 pubkey from being stolen by quantum computers.. which would make bitcoin useless in about 50 different other ways anyway).

Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.

Point one isn't true, but only because a decimal shift isn't how it would be done.  The values are stored in a 64 bit integer variable, but only about 54 bits are in use, so the leading bits can be taken as a 'marker' to tag values using an extended standard.

Point two is certainly true.

Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division.

Where did you come up with that BS number?

21,000,000,000,000.00
The number of BTC that will ever be produced (est) with 1 satoshi = 1 cent per decimal places, and what you get is 21Tn, or about twice the M2 money supply of the United States, only divisible down to 1 cent.

A uint64 could potentially hold about 50 times as much (although that's questionable given that it was set up backwards it probably can't fully use the uint64). Comparatively, absorbing the world economy and still maintaining divisibility so that tx fees are still reasonable compared to exchange value would require maybe 20 times a uint64 at minimum, given the disparity between current economic status and potential economic output.

More importantly, the means for changing the decimal place rests solely in the hands of the programmers, as there is no user-defined setting for it. That means as prices shift and the currency appreciates, users and merchants will not have any means of shifting what is considered a "base unit", and no way of standardizing what they mean even if they implement that functionality privately. Having to complain to the devs about something basic like that in regards to the protocol really defeats the purpose of decentralization of the currency, or at the very least makes it cumbersome to use.

[MoonShadow]

Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.

Developers can't "stop the world" in any context, and tweaks can be made to the running network anyway, at least as long as users are willing to upgrade.  The network is particularly fault tolerant.

Like they did with the overflow bug?

The devs didn't stop anything over the overflow bug.  All that they did was contact a majority share of miners, let them know that there was a problem, and asked them to cooperate.  They did.  If they had not, the devs couldn't had done much of anything to stop the overflow bug.  In hindsight, it wouldn't have amounted to much anyway.  Once those same miners had upgraded to the patched client, those same clients just started to reject blocks with an overflow transaction and backed up the blockchain as far as was required automaticly.  There were still old clients trying to submit tainted blocks for weeks because there were miners who had not been paying attention and had not upgraded.  I was here when that all went down, and wasn't mining; and I can honestly say the network didn't really skip a beat from the perspective of a casual user.

 It may be true they can't now, but it could be necessary, and/or it will take a very long time to get everyone to upgrade. Assuming it doesn't get broken because people "upgrade" themselves to game the system.

In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things.

You don't know how the system works, but in the same sentence claim that Satoshi did a lot of stupid things?  Are you trolling?

When I say "stupid and unnecessary things", I mean the 2GB blockchain that's been generated in only three years and with provably less than 5-10 tx per minute! At VISA levels that's totally unsustainable. 90% of all "usages" of scripts and contracts are totally economically useless and will probably never be used by anyone for anything, whereas per file size scripts take up the vast majority of unspent txOuts that need to be tracked. The only thing BTC really is is a giant, overglorified balance ledger sheet, that needs only to track unspent account balances per account in order to be accurate. Instead it tracks unspent txOuts individually, which then all must be put into txIns individually in order to be spent, yet again multiplying the size requirement of the blockchain.

If the blockchain had been engineered to efficiently fill its primary purpose- simple yet secure monetary exchange, rather than a bunch of useless contracts by default, then the blockchain could be < 50MB rather than > 2GB. I consider it a product of Satoshi's economic ignorance, although beyond that I can't read his mind so I don't know what else he was thinking when he designed it to be such a complicated mess. The abstraction between public key and address hash is also extra without actually providing much benefit (unless you want to keep your SHA256 pubkey from being stolen by quantum computers.. which would make bitcoin useless in about 50 different other ways anyway).

<sigh>  Again, you display your ignorance in such matters.  There are sound reasons for everything that ou sight, and foreseeable solutions to the potential problems that you noted.  These topics have been debated to no end long before you ever arrived.  The search function is your friend.

Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.

Point one isn't true, but only because a decimal shift isn't how it would be done.  The values are stored in a 64 bit integer variable, but only about 54 bits are in use, so the leading bits can be taken as a 'marker' to tag values using an extended standard.

Point two is certainly true.

Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division.

Where did you come up with that BS number?

21,000,000,000,000.00
The number of BTC that will ever be produced (est) with 1 satoshi = 1 cent per decimal places, and what you get is 21Tn, or about twice the M2 money supply of the United States, only divisible down to 1 cent.


[/quote]

Okay, I see what you did there.

A uint64 could potentially hold about 50 times as much (although that's questionable given that it was set up backwards it probably can't fully use the uint64). Comparatively, absorbing the world economy and still maintaining divisibility so that tx fees are still reasonable compared to exchange value would require maybe 20 times a uint64 at minimum, given the disparity between current economic status and potential economic output.

Again, there are sound reasons for the choices.  Do some research, please.

More importantly, the means for changing the decimal place rests solely in the hands of the programmers, as there is no user-defined setting for it. That means as prices shift and the currency appreciates, users and merchants will not have any means of shifting what is considered a "base unit", and no way of standardizing what they mean even if they implement that functionality privately. Having to complain to the devs about something basic like that in regards to the protocol really defeats the purpose of decentralization of the currency, or at the very least makes it cumbersome to use.

Not yet, but someone is going to add such funtions before they are really neeed.

[Haplo]

The devs didn't stop anything over the overflow bug.  All that they did was contact a majority share of miners, let them know that there was a problem, and asked them to cooperate.  They did.  If they had not, the devs couldn't had done much of anything to stop the overflow bug.  In hindsight, it wouldn't have amounted to much anyway.  Once those same miners had upgraded to the patched client, those same clients just started to reject blocks with an overflow transaction and backed up the blockchain as far as was required automaticly.  There were still old clients trying to submit tainted blocks for weeks because there were miners who had not been paying attention and had not upgraded.  I was here when that all went down, and wasn't mining; and I can honestly say the network didn't really skip a beat from the perspective of a casual user.

Well, I can see quite plainly that BTC is still around. However, that was what? 2-3 years from its beginnings? Every year more BTC users and miners are added to the overall pool. How long until the people not paying attention outnumber the people who do? What happens if some change requires a major update to clients as well as miners?

Moreover, if I'm not mistaken when the overflow bug was discovered, the devs issued an "emergency alert" similar to the "check for new updates" function present in basically all other modern software. This feature, while only a half-implementation of automatically detecting new updates, has since been disabled. I don't know that there's even a "correct" answer to that problem, with the complexities of alt clients added into the mix.

When I say "stupid and unnecessary things", I mean the 2GB blockchain that's been generated in only three years and with provably less than 5-10 tx per minute! At VISA levels that's totally unsustainable. 90% of all "usages" of scripts and contracts are totally economically useless and will probably never be used by anyone for anything, whereas per file size scripts take up the vast majority of unspent txOuts that need to be tracked. The only thing BTC really is is a giant, overglorified balance ledger sheet, that needs only to track unspent account balances per account in order to be accurate. Instead it tracks unspent txOuts individually, which then all must be put into txIns individually in order to be spent, yet again multiplying the size requirement of the blockchain.

If the blockchain had been engineered to efficiently fill its primary purpose- simple yet secure monetary exchange, rather than a bunch of useless contracts by default, then the blockchain could be < 50MB rather than > 2GB. I consider it a product of Satoshi's economic ignorance, although beyond that I can't read his mind so I don't know what else he was thinking when he designed it to be such a complicated mess. The abstraction between public key and address hash is also extra without actually providing much benefit (unless you want to keep your SHA256 pubkey from being stolen by quantum computers.. which would make bitcoin useless in about 50 different other ways anyway).

<sigh>  Again, you display your ignorance in such matters.  There are sound reasons for everything that ou sight, and foreseeable solutions to the potential problems that you noted.  These topics have been debated to no end long before you ever arrived.  The search function is your friend.

I have read most of the arguments, as well as a lot about the protocol itself on the wiki. That is how I know that many of the design choices were either economically or programatically unsound.

There definitely needs to be a connection between accounting and the security of that accounting, but there is no need for them to be inseparable, and ultimately the accounting is more important than documenting the security forever, not to mention potentially orders of magnitude more efficient spacewise.

There does not need to be any direct connection between standard tx and contracts with complicated scripts. Standard tx have no need for scripts, and of the few (like 2 at most) scripts that have an actual use, they could be simplified a great deal. Currently you can't even use the scripts that are useful, ie the minimal trust escrow feature.

Finally, the "solution" of pruning the merkle trees of previous tx doesn't help miners any, and furthermore excludes clients (ie anyone who doesn't own a giant server cluster) from verifying tx for themselves. Not only does that kill decentralization, but it also stops merchants from verifying tx, which means either they can't use BTC or else the customer has to stand around for an hour or so waiting for the first confirmation. I don't call that a solution at all.

A uint64 could potentially hold about 50 times as much (although that's questionable given that it was set up backwards it probably can't fully use the uint64). Comparatively, absorbing the world economy and still maintaining divisibility so that tx fees are still reasonable compared to exchange value would require maybe 20 times a uint64 at minimum, given the disparity between current economic status and potential economic output.

Again, there are sound reasons for the choices.  Do some research, please.

Sound economically? Sound in terms of programatic and storage efficiency? Sound in terms of flexibility?

That's too vague to agree or disagree with. I still have yet to read the whitepaper, but I'll get around to it soon enough. ATM I couldn't tell you specifically what in terms of satoshi's theory I may agree or disagree with, only what I've seen in the actual implementation thereof.

More importantly, the means for changing the decimal place rests solely in the hands of the programmers, as there is no user-defined setting for it. That means as prices shift and the currency appreciates, users and merchants will not have any means of shifting what is considered a "base unit", and no way of standardizing what they mean even if they implement that functionality privately. Having to complain to the devs about something basic like that in regards to the protocol really defeats the purpose of decentralization of the currency, or at the very least makes it cumbersome to use.

Not yet, but someone is going to add such funtions before they are really neeed.

Perhaps. That depends on what hooks are left in the original client for this and whether or not they are flexible enough to allow what needs to be done. It also depends on how standardized said hooks are, and whether there will be disagreements on how to extend the implementation. In terms of shifting decimals fluidly and the storage of the values and the standardization thereof there's a whole lot of room for compatibility to break. The longer implementing it in a standard way is put off, the worse the potential disconnect becomes.

I'll have to read the whitepaper to see if it says anything specific on the matter.

[Rothgar]

I bought a t-shirt.  I was worried that it was a bad purchase because the price of bitcoin might go up.  A very easy solution, buy more bitcoin.  Problem solved.

[DeathAndTaxes]

Haplo it is amazing that you can write so much and yet be consistently wrong.  I mean probability would indicate that a monkey randomly pressing keys would occasionally be right.

Haplo Myth:
the block chain could be 50MB.

Reality:
There are 1.8 million tx in the block chain thus 50MB/ 1.3 = ~27 bytes.  Entire tx stored in 27 bytes which can't be brute forced?  (cough cough) bullshit.

Haplo Myth:
pruned blockchain will prevent verification of tx by node without full blockchain

Reality:
Merkle tree was chosen because pruned blockchain will still allow tx verification

Haplo Myth:
There is no reason for the public address vs public key

Reality:
Addresses can be constructed from a public key but also can be constructed from other base types.  The use of an address allow similar processing regardless of the underlying structure.  It also provides cheksum, version, and protocol identification.  This greatly reduces the probability coins are sent to "nowhere".

Haplo Myth:
complex contracts take up more sense.

Reality:
p2sh allows massively complex scripts and contracts to take up no more space in blockchain that a "simple" tx.

Haplo how about you actually read the whitepaper, wikis, and code before incorrectly pointing out flaws.  
 
Haplo has no clue.

[Haplo]

Haplo it is amazing that you can write so much and yet be consistently wrong.  I mean probability would indicate that a monkey randomly pressing keys would occasionally be right.

Haplo Myth:
the block chain could be 50MB.

Reality:
There are 1.8 million tx in the block chain thus 50MB/ 1.3 = ~27 bytes.  Entire tx stored in 27 bytes which can't be brute forced?  (cough cough) bullshit.

Haplo Myth:
pruned blockchain will prevent verification of tx by node without full blockchain

Reality:
Merkle tree was chosen because pruned blockchain will still allow tx verification

Haplo Myth:
There is no reason for the public address vs public key

Reality:
Addresses can be constructed from a public key but also can be constructed from other base types.  The use of an address allow similar processing regardless of the underlying structure.  It also provides cheksum, version, and protocol identification.  This greatly reduces the probability coins are sent to "nowhere".

Haplo Myth:
complex contracts take up more sense.

Reality:
p2sh allows massively complex scripts and contracts to take up no more space in blockchain that a "simple" tx.

Haplo how about you actually read the whitepaper, wikis, and code before incorrectly pointing out flaws.  
 
Haplo has no clue.

Please read this post and then you can go back to your ad homs.

By reducing the blockchain to the current unspent txOuts, he was able to reduce the total size from ~1GB at the time to 75MB, the majority of which was taken up by the scripts. Without needing scripts for standard tx, that could probably be cut in half, and if unspent txOuts were reduced to account balances it could probably be cut down to 1/4 that. The biggest change that would entail is that txIn would take the full value of the account rather than the full value of each referenced txOut, which would no longer be required for txIns. You would still have to store a few weeks of blockchain on top of that, but that's still < 100MB easily.

As for the method by which addresses are created, I never said there weren't reasons for it, just that it could be done better. Hash of pubkey+checksum+version = 2 levels of abstraction. Pubkey + checksum + version = 1 level of abstraction. On the other hand, for what I have in mind it may not even require reducing the abstraction, just creating a second address type. The main reason for reducing the abstraction is so that both need not be included when signing a tx, which might reduce the raw blockchain size by a small amount, although any amount becomes significant at 100tx+ per second.

Miners running off of centralized pools are already "dumb", and that with the current blockchain bloat this tendency toward centralization is guaranteed to continue (I don't see droves of DeepBit members jumping on the P2Pool train) which would basically defeat the whole purpose of BTC as a decentralized anarcho-currency. AFAIK pruned merkle trees can only be used to verify your own balance, and not anyone else's. That is, you can't mine using only that, and you if you can't mine then you also can't verify a tx someone has sent to you.