Hmm, both links point to the same place.
|
|
|
So, if Bitcoin indeed has "made it" then let's bump the version number to 1.0
|
|
|
Let's say a 2015 US dollar can buy a dozen eggs. At the exchange rate today that's about BTC0.0028. If Bitcoin goes to $1,000,000(2015)/BTC tomorrow like people dream about (and that dozen eggs still costs just $1(2015)) then that dozen eggs will effectively cost BTC0.000001=100 Satoshi.
If the US dollar inflation rate is severe and a 2046 US dollar is worth only 0.1% of a 2015 US dollar then the eggs will cost $1,000(2046). If the Bitcoin exchange is unexpectedly/unlikely still $360(2046)/BTC then it would take BTC2.78 to buy the eggs in 2046. If the exchange rate exactly matched the inflation then it would be $360,000(2046)/BTC and the eggs would be BTC0.0028.
If the Bitcoin exchange rate outperforms inflation and is worth $1,000,000(2015)/BTC that works out to $1,000,000,000(2046)/BTC which is well short of 1 Satoshi being worth $1,000,000.
To reach 1 Satoshi being worth $1,000,000(2046) we would have $100,000,000,000,000(2046)/BTC; if we constrain ourselves to a maximum exchange rate of $1,000,000(2015)/BTC then the US dollar inflation rate would have to be much much worse.
|
|
|
Is 2,100,000,000,000,000, i.e. 2.1 quadrillion, units enough? No? Please help me understand how many units is enough to allow transactions to flow unimpeded. Bitcoin, with a minor change, can increase the number of units by carrying more precision as opposed to creating more Bitcoins; *without* debasing.
Or are we worried about how to fund the government (I suppose it is a necessary evil)? Funding it through debasing the currency is being tried right now; I predict eventual failure. Given the ability to debase, there will be no ceiling.
Or are you whining that you want to have more Bitcoins than you can afford?
|
|
|
From the Bitcoin-core Debug Window Peers;
73.179.230.242:59060 via x.x.x.x:8333
Direction Inbound Version 70002 User Agent /Satoshi:0.11.2/ Services NETWORK Starting Height 237292 Sync Height Unknown Ban Score 0 Connection Time 10 h 4 m 39 s Last Sent 5 s Last Received 38 s Bytes Sent 1 GB Bytes Received 3 MB Ping Time 336874 ms Time Offset 1 s
That is a prime example of a peer I would like to charge for providing my full node services to it.
|
|
|
If I predict a dramatic rise often enough then eventually I might be right. If everyone ignores/forgets my other predictions that didn't happen then I look brilliant.
|
|
|
If you are implying US dollars then it depends; do you mean in terms of 2015 US dollars or 2046 US dollars?
|
|
|
If anyone was following my story; my SecondMarket Bitcoin Investment Trust is supposedly going to be available in my Schwab account on or before Dec. 14th. Slow is an understatement.
|
|
|
... and the person owning all 21,000,000? ... Lonely.
|
|
|
I wrote 15 years beacuse i expect that in next 5-10 years will be invented something 100 times more powerfull than ASIC.
If/when more powerful miners come out, even 100x the current best ASIC, then the protocol will detect the increase and increase the difficulty to keep the average 10 minutes between blocks.
|
|
|
The stress testing did lead to my old core client crashing multiple times so I replaced it with XT and then 11.1 and then setting parameters and now 11.2 -- life is good.
The 1MB block size is artificially small. Raising it immediately (or rather as soon as is reasonable) to the maximum handled by the API (32MB?) and then getting to work on exceeding that with segmenting blocks is really the only thing to do. Propagating headers fast and data afterward seems a likely to be viable approach to me. If any node can't keep up then cut them loose. Just one man's opinion.
Until Bitcoin is run on Google's datacenters? Increasing the block size will *not* cause a flood of full blocks; there aren't enough transactions in the memory pool. Heck, plenty of 1MB blocks aren't even full right now. Even if *every* block was full that's only 1MB/10min = 8Mb/10min = 839Kb/1min = 14Kb/s; compare that to 50Mb/s that plenty of folks have right now. Even if every 32MB block was full (that'd be at least 32,000 transactions per block) that's *only* 32MB/10min = 447Kb/s. I fail to see how cutting loose any (if any) modem connected full nodes is a serious issue. Or are you worried about disk space? 144 (one days worth) of 32MB blocks is *only* 4.5GB/day; a little more than 1TB/year. It will *not* take a large system and Internet link to run a full node even at 32MB blocks (even when they are all full). People are scared of what they don't understand.
|
|
|
I have never mined a single Satoshi; it was too late to do it without considerable effort; not interested; good luck to all miners. I do have a miner USB card but it runs hot and is hard to keep going. I would rather solo mine and get nothing than pool.
I was given a physical Bitcoin as a gift; cost my son around $16 (worth over $300 at the moment); best gift I ever got; got me interested.
I purchased my Bitcoins through various exchanges; I am not revealing the total amount; sorry.
I invested in the SecondMarket Bitcoin Investment Trust (BIT) and it should soon achieve liquidity as GBTC via a standard retirement account at a standard brokerage firm.
Even today someone could come to Bitcoin for the first time and just buy 21 Bitcoins; *only* about $7k.
|
|
|
The stress testing did lead to my old core client crashing multiple times so I replaced it with XT and then 11.1 and then setting parameters and now 11.2 -- life is good.
The 1MB block size is artificially small. Raising it immediately (or rather as soon as is reasonable) to the maximum handled by the API (32MB?) and then getting to work on exceeding that with segmenting blocks is really the only thing to do. Propagating headers fast and data afterward seems a likely to be viable approach to me. If any node can't keep up then cut them loose. Just one man's opinion.
|
|
|
Altering the declining reward scheme would make me want to leave Bitcoin. If I sell my Bitcoins then the price will go down *unless* there are more buyers thinking the opposite of me.
|
|
|
|