Thank you for your time to make a detailed response, as usual there is a lot to consider. I want to add a few points. We've actually hit the soft limit before, consistently for long periods and did not see the negative effects described there (beyond confirmation times for lower fee transactions going up, of course).
This is at odds with an earlier reply on this, which matched my recollection, especially regarding the 250KB soft-limit on March 6th, 2013: Unfortunately over-eager increases of the soft-limit have denied us the opportunity to learn from experience under congestion and the motivation to create tools and optimize software to deal with congestion (fee-replacement, micropayment hubs, etc).
And this had no hope of being properly exercised as IIRC not all mining pools were on board, Eligius had a 500KB limit at the time, and a reasonable %age of the hashing power. Look at the huge abundance of space wasting uncompressed keys (it requires ~ one line of code to compress a bitcoin pubkey) on the network to get an idea of how little pressure there exists to optimize use of the blockchain public-good right now.
Regarding efficiencies, your comment at the same time about compressed pubkeys deserves attention. Are you saying that new blocks in the blockchain could be easily made smaller with this compression? It seems a valuable benefit at this time. Fortunately, the fee market arbitrates access neutrally; but it does that at arbitrary scale. Mike completely disregard this because he believes transactions should be free (which should be ringing bells for anyone thinking X MB blocks won't be constantly X MB; especially with all the companies being created to do things like file storage in the Bitcoin blockchain).
Then perhaps the provision of free transactions should be reviewed in the light of vanishing block space. A simple change might be doubling the necessary days-destroyed per BTC. One of the mechanisms to make running against the the fee more tolerable which is simple to implement and easy for wallets to handle is replace-by-fee (in the boring, greater outputs mode; not talking about the scorched earth stuff)-- but thats something that Mike has vigorously opposed for some reason.
If Jeff is ok with RBF in the boring mode then that would be a good improvement when blockspace is under pressure. But I know he is rightly exercised over the RBF-SE which is yet another ideological debate in itself. The particular issue there is that the reject messages are fundamentally unhelpful for this (though they're a nice example of another railroaded feature, one that introduced a remotely exploitable vulnerability). The issue is that just because node X accepted your transaction doesn't tell you that node Y, N hops away did or didn't, in particular it doesn't tell you if there is even a single miner anywhere in the network that rejected it-- what would you expect to avoid this? every node flooding a message for every transaction it rejects to every other node? (e.g. a rejection causing nodes^2 traffic???). Nodes due produce rejects today; but it's not anything about anyone's opinion that prevents a guarantee there, the nature of a distributed/decenteralized system does. The whole notion of a reject being useful here is an artifact of erroneously trying to shoehorn in a model from centralized client/server systems into Bitcoin which is fundamentally unlike that.
OK. It makes sense that reject messages do not fit into decentralized systems in a meaningful way. The comments about the filling up memory stuff are grimly amusing to me in general for reasons I currently can't discuss in public (please feel free to ping in six months).
Sure thing. I would be keen to learn more about this at that time. Overall, I think the article does a good job of suggesting that that the goal of the recent blocksize proposal is a far more wide spanning change than just increment the blocksize to make a necessary room, and that its also a move to make a substantial change to the original long term security model to an underspecified one which doesn't involve fees; a trajectory for an unlimited blocksize that processes any transactions that come in, at any cost; even if that means centralizing the whole network onto a single mega-node in order to accept the scale. Or at least that appears to be the only move that has an clear answer the case of 'there will be doom if the users make too many transactions' (The answer being that the datacenter adds more storage containers full of equipment).
Well. The goal of my interest in the block-size proposal is to see a sustained decay in confirmation times avoided, which would otherwise cause negative user experiences, of a great many users, negative publicity, and tarnishing Bitcoin in the mind of the future users who may then decide not to try it out. The whole of these together would probably reduce full node numbers even faster than larger blocks. |
|
|
|
I don't know enough about the block size limits really but is increasing it just kicking the can down the road. Can we just keep doing that? A bit like how USA used to keep increasing the debt ceiling
Increasing block size limits is not solution. It is "brute force" ... we are only buying time. 1B people will require 4 GB block size limit. Maybe 'buying some time' is quite crucial for coming up with and developing the necessary solutions, and it's not 'kicking the can down the road' knowing the issue will never be properly addressed. Although I don't fully understand the lightning network and its risks/tradeoffs, the presentation slides suggest 133MB blocks would be sufficient for unlimited transactions for 7 billion users. That would be freaking awesome, and solve the scaling problem imho (but again, I don't understand it deeply enough). EDIT: Inca beat me to it  . Likewise. And the lightning network is mostly paperwork today, but could be fully operational in 3 years time. Gavin's can-kick would more than cover that period, without a monumental snafu, PR disaster, price collapse, in the meantime. |
|
|
|
This sub-forum is intended for debate about technical matters concerning Bitcoin, specifically, for the purpose of improving it. Bitcoin expert Mike Hearn has written an article "Crash Landing" where he describes what will happen if ecosystem growth continues and only normal maintenance and enhancement work is performed by developers. It paints a very serious picture, which is pretty much what I imagined when I learned about the max block size in January 2013. This article was written in the context of vigorous debate about the block size. But what I want to do here is to take a step back and find out the opinion of the technically informed community on Bitcointalk. I urge people to read it and then vote according to their considered opinion. https://medium.com/@octskyward/crash-landing-f5cc19908e32If there is a majority view that what is described is a problem, then maybe consensus can be achieved on mitigation of the risk of it coming to pass. edit: adding the average block size chart, 2 years, 7-day smoothed, https://blockchain.info/charts/avg-block-size?showDataPoints=false&show_header=true&daysAverageString=7×pan=2year&scale=0&address= |
|
|
|
When Bitcoin appeared in 2009, the capacity of each block of 10 minutes was 32mb which can be conversed to be 200tps, transactions per second. However, after that, the founder of Bitcoin Satoshi Nakamoto decreases the limitation to be 1 mb in order to prevent system to be attacked. From then on, the system of Bitcoin can deal with 7tps at most. By comparison with 1000tps of Alipay and 4000tps of VISA, it is little.
It's not even near 7tps, more like 2.7tps. A couple of months ago I sampled six days worth of blocks which were >90% full. Block_height Block_time Size_KB Num_Tx Fee_BTC 341192 31/01/2015_7:10 976.54 2518 0.3303735 341226 31/01/2015_13:01 903.09 1106 0.15922165 341305 1/02/2015_1:05 959.89 1320 0.20086461 341313 1/02/2015_2:19 912.48 693 0.2979134 341350 1/02/2015_7:49 975.67 1735 0.263689 341505 2/02/2015_5:11 976.5 735 0.16244257 341517 2/02/2015_7:02 947.72 746 0.14308729 341519 2/02/2015_7:36 957.16 482 0.13242593 341520 2/02/2015_8:02 976.45 1964 0.28018485 341525 2/02/2015_8:35 973.77 844 0.187877 341737 3/02/2015_19:00 976.49 1291 0.18828618 341765 4/02/2015_1:23 976.49 2549 0.35075577 341773 4/02/2015_2:45 941.58 1635 0.22893775 341794 4/02/2015_6:05 976.46 2380 0.31873266 341798 4/02/2015_6:50 971.04 1759 0.24739191 341810 4/02/2015_8:30 976.17 1705 0.25575189 341944 5/02/2015_4:08 976.54 2268 0.30628975 341951 5/02/2015_5:35 974.37 1635 0.23624007 341963 5/02/2015_7:53 976.46 1911 0.27444743 341965 5/02/2015_8:33 976.52 2105 0.2951799 341967 5/02/2015_9:24 973.82 2675 0.33440304 Average block size = 965KB Average number of tx = 1622 (or approximately 2.7 tps) Average block total fee = 0.25 BTC The significant finding is that 20MB is a bit of a magic number for the long-term goal of getting fees towards replacing block rewards for miners. 20MB blocks would offer 54 tps and an average total fee per block of 5 BTC (based on this evidence) which means that fees would be comparable with the reward once the average block size hits 20MB and the reward is down to 6.25 BTC (within 6 years time). |
|
|
|
wow, thanks so much for this. there are no other Bitcoin devs i trust more than Alan & Gavin. he's helped me immensely over the years as i was one of the only two to donate $500 (top level) to his initial Armory crowdfunding campaign what, 3-4 yrs ago now? for that, i got an Armory USB stick, a teeshirt, a coupla bitcoins (i think), & most importantly his old laptop with a sticker on the back with his name and phone #'s, lol. i'm quite sure he forgot to remove them and i've only ever used the # twice he's taught me alot about crypto. i've tried to tailor back my contact with him in the last year or so as i know he is way busier than ever and has grown in stature so it didn't even occur to me to ask his opinion on this matter. best thing about him is he's a great guy. i'm so glad you did and hearing his response is reassuring to me that i am pushing the right direction. thanks again. A pleasure, and snap! I donated $500 to Armory dev as well, but it was easier with BTC at $800+ :-) BTW. the quote is from sourceforge, not a personal communication... |
|
|
|
Alan Reiner (Armory lead developer) weighs in and clearly shows that he understands the Big Picture. What he writes deserves to be memorialized here as it is pertinent to the whole spirit of "Gold collapsing. Bitcoin UP" Quoted text belowThis *is* urgent and needs to be handled right now, and I believe Gavin has the best approach to this. I have heard Gavin's talks on increasing the block size, and the two most persuasive points to me were: (1) Blocks are essentially nearing "full" now. And by "full" he means that the reliability of the network (from the average user perspective) is about to be impacted in a very negative way (I believe it was due to the inconsistent time between blocks). I think Gavin said that his simulations showed 400 kB - 600 kB worth of transactions per 10 min (approx 3-4 tps) is where things start to behave poorly for certain classes of transactions. In other words, we're very close to the effective limit in terms of maintaining the current "standard of living", and with a year needed to raise the block time this actually is urgent. (2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea. It's really bad while Bitcoin is still growing, and relying on fee pressure at 1 MB severely impacts attractiveness and adoption potential of Bitcoin (due to high fees and unreliability). But more importantly, it ignores the fact that for a 7 tps is pathetic for a global transaction system. It is a couple orders of magnitude too low for any meaningful commercial activity to occur. If we continue with a cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be useful for the vast majority of the world (which probably leads to failure). We shouldn't be talking about fee pressure until we hit 700 tps, which is probably still too low. You can argue that side chains and payment channels could alleviate this. But how far off are they? We're going to hit effective 1MB limits long before we can leverage those in a meaningful way. Even if everyone used them, getting a billion people onto the system just can't happen even at 1 transaction per year per person to get into a payment channel or move money between side chains. We get asked all the time by corporate clients about scalability. A limit of 7 tps makes them uncomfortable that they are going to invest all this time into a system that has no chance of handling the economic activity that they expect it handle. We always assure them that 7 tps is not the final answer. Satoshi didn't believe 1 MB blocks were the correct answer. I personally think this is critical to Bitcoin's long term future. And I'm not sure what else Gavin could've done to push this along in a meaninful way. -Alan |
|
|
|
Matt Corallo, Blockstream co-founder, just sent an email with the subject "Block Size Increase" on btc dev mailing list , you could read it all here: http://sourceforge.net/p/bitcoin/mailman/message/34090292/quoting the relevant part: Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).
bold is mine This is an example of what I was saying yesterday about core dev being too focused on the tech to see the big picture. Matt suggests using the 1MB to apply upwards fee pressure. This is using a bit of software for something for which it was not intended. It is like using a hammer to fix a car engine. Mike Hearn has recently provided the missing piece of the puzzle of why Satoshi put the 1MB in place. It was for anti-spam when everyone who used Bitcoin needed to run a full node: a time when there were no lightweight wallets.The idea which thezerg recently came up with is far superior to just leveraging the 1MB to force up fees (which won't work as people will start to abandon Bitcoin instead). I'm for Gavin's 20MB increase. But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works. The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).
So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit). In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve). So supply (space in a block) can actually increase as demand increases.
You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit. The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high. In that case, we are no worse than today's proposal.
I like this proposal a lot. High-priority non-fee transactions that consume older coins are suppose to be just that, free and gain priority access to a block. Today's situation is even if your transaction has enough priority to qualify for free processing, they often take hours to confirm since most minors do not pick high priority transactions without a fee. This completely defeats the purpose of having the priority system at all. Reserving a front space in each block for high-priority non-fee transactions does two things: 1) It would ensure that high-priority transactions are processed in a timely fashion 2) It would encourage more competition from low-priority transactions and possibly increase the fees they need to offer to be processed quickly This would shift transaction fees more towards for profit services that are built on top of bitcoin and away from individual wallet users. I would consider this to be a good thing. Anyone on this thread have contact with any of the core developers? Have they considered it? If not how could zerg propose it (provide people here also think it makes sense...) If core dev came up with a variation of this, e.g. based upon a function of the median aggregate block fee over the previous 2016 blocks for the "buying" of blockspace >1MB then perhaps their position could be taken more seriously. |
|
|
|
I'm trying to find out if this is different to the last gavin update, where the rolling increase was proposed 20mb first and X% per increment after. Or if this new proposal is a different hacked increase to 20mb, thus requiring another hard fork in the future should this new limit need changing?
thanks
The new proposal is similar to Satoshi's original 2010 example where the max block size increases after a predetermined block height (115,000). Instead, Gavin has code allowing a one-off increase, blocks up to 20MB which are later than a predetermined timestamp (1st March 2016 00:00:00 UTC). Block timestamps can only vary +/- a couple of hours from UTC. The advantage is that everyone will know the date by which they need to have their full node upgraded. Working with block height means that the cut-over could vary, a couple of weeks earlier or later, depending on difficulty changes. Hopefully, this will get unanimous consensus in core dev (the 5 people with commit access) so that there is not a split. In theory Gavin could commit this change and someone else reverse it in an "edit war". That would be a sad situation. However, Gavin has a trump card which means he *should* be able to prevail even if he were to be in a minority of 4:1 against. Satoshi gave him the key to broadcast alerts to all the instances of BitcoinCore. So, he could fork the code and create, say "Bitcoin20", and advise all BitcoinCore users that they need to upgrade to Bitcoin20 (or BitcoinXT). I really hope it does not come to that. He has consulted many stakeholders and indications are that major miners, exchanges, wallet providers, 3rd party services, and BitcoinXT will be on-board with the change. Those that want to see how 1MB affects fees might get their wish, because March 2016 is a fair way off and there may be long periods of nearly-full 1MB blocks. The resulting problems for ordinary users will create an avalanche of demand for the 20MB change, or Bitcoin20, if that is what it takes. It is worth repeating: just because the max block size increases does not mean the blocks immediately get bigger. The 1st 20MB block may be 5 years away. edit: the last point about future limit changes. Yes, other hard-forks may be necessary, however, 20MB is large enough that it buys time for alternative scaling methods to be fully developed and implemented, such as the Lightning Networks. |
|
|
|
Some day in the future, you will need a data center to hold the whole blockchain, but that's still manageable, since by then each bitcoiner will own a data center  Yup, and this is what a 250 megabyte hard drive looked like in 1979. 30 years later you can fit 250x250 megabytes on something the size of your finger nail. When the blockchain needs a data center to hold it, a data center will fit on your desktop. we are near that limit with silicon, we can't go much farther with shrinking, 10nm is the physical limit of the material, they need something else soon enough Glass storage? http://physicsworld.com/cws/article/news/2013/jul/17/5d-superman-memory-crystal-heralds-unlimited-lifetime-data-storage |
|
|
|
Let's play a game. Lets see who can spot all the Popescu sockpuppets that will inevitability pop up in this thread. They'll turn up, oh yes, you can be sure of that.  Just six posts later one has popped up... [noise]
|
|
|
|
Hmm. It seems to be a variation of Mises' "Calculation problem" and individuals trying to know better than markets.
Without working price discovery, the function that relates supply with demand is a random function. That's why the number of full nodes appears to have no correlation with the number of Bitcoin users, number of transactions, or any other intuitive metric. Until the price discovery problem is solved, we have no reason to assume the function will become non-random. Ah! Absolutely. Particularly for non-mining nodes. |
|
|
|
luke-jr gmaxwell ptodd have done nothing to deserve the opprobium being dished up here, most of them have worked for free for years already, such ungrateful ignorance on display here is dismaying. There are many other quieter devs who disagree with gavin/hearn on this one but afraid of speaking out because of the risk of the kind of pillorying from the loud-mouths that might result. Wumpus is actually the lead dev now, gavin has been a figurehead for the last 2 versions ... and I haven't seen anyone question his role in the Bitcoin Foundation fiasco?
There is zero opprobrium on my part, just dismay and puzzlement at seeing people who have done so much for Bitcoin become willing to let it slide into a high-risk state, when that is what they have strived to avoid all along. Trying to reduce spam by block-space rationing, forcing up fees, pricing users away to 3rd party off-chain services (like Coinbase?!) is a radical economic experiment on top of what is a nascent revolution in money, taking the robustness of its ecosystem for granted. I make a point of reading gmaxwell's posts as they are always insightful, but one thing he has done remarkably well is fence-sit for over 2 years on the 1MB issue. If he dislikes Gavin's approach then where is his solution? How are crippling confirmation delays going to be avoided if core dev sits back and does nothing about the limit? Wumpus has not ventured his solution, but neither has he been on reddit actively wanting to delay action on what is the No.1 issue for Bitcoin. See if you can spot the parallel between this example and the number of nodes in the Bitcoin network: https://mises.org/library/why-nazism-was-socialism-and-why-socialism-totalitarianIn the face of the combination of price controls and shortages, the effect of a decrease in the supply of an item is not, as it would be in a free market, to raise its price and increase its profitability, thereby operating to stop the decrease in supply, or reverse it if it has gone too far. Price control prohibits the rise in price and thus the increase in profitability. At the same time, the shortages caused by price controls prevent increases in supply from reducing price and profitability. When there is a shortage, the effect of an increase in supply is merely a reduction in the severity of the shortage. Only when the shortage is totally eliminated does an increase in supply necessitate a decrease in price and bring about a decrease in profitability.
As a result, the combination of price controls and shortages makes possible random movements of supply without any effect on price and profitability. In this situation, the production of the most trivial and unimportant goods, even pet rocks, can be expanded at the expense of the production of the most urgently needed and important goods, such as life-saving medicines, with no effect on the price or profitability of either good. Price controls would prevent the production of the medicines from becoming more profitable as their supply decreased, while a shortage even of pet rocks prevented their production from becoming less profitable as their supply increased. Hmm. It seems to be a variation of Mises' "Calculation problem" and individuals trying to know better than markets. |
|
|
|
Excellent. Any serious Bitcoin business will have this view because retaining the 1MB will not only cripple the network but also cripple dependent business models. I think the problem that luke, gmaxwell, todd etc have is that they are too close to the tech. They think that the decay in confirmation times can be managed (when it will be a PR disaster), they think that the 1MB has relevance to the fees market, they ignore that node quality is improving even though node quantity declines, (but the decline should eventually be arrested by a growing ecosystem, and increasing price). They basically need to get out of the woods and see the whole landscape: like Coinbase clearly does. |
|
|
|
This is just in: Huobi Will Now Take Your Bitcoins as Stock Trading Collateral. -- Huobi's new platform lets investors buy real shares on the Shanghai Stock Exchange, while still keeping their bitcoin holdings as collateral. --(Published @ May 05, 2015 at 06:07AM by www.bitcoins.amhttp://bit.ly/1zvWCSm now this is interesting moves, this makes shanghai stock exchange become international stock exchange... Oooh yes! Just in time to be the last buyer at the peak of the Shanghai stock bubble, after it has been pumped, hyped, leveraged, fueled by decades of export cash, yuan printing, 16x-annual-income-mortgages residential property market, and eyeballs-deep-in-debt corporate commercial property bubble, and empty cities construction bubble. No more domestic buyers left in China. MUST keep super-Shanghai-super-bubble-stock-market inflated with foreign investor's BTC savings.... MUST be a silver-lining here http://www.zerohedge.com/news/2015-05-05/china-stocks-tumble-most-4-months-australia-cuts-rates-record-low |
|
|
|
no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:
I just scanned their recent reddit posts about the proposal and to be fair their position leans more to "open mind but cautious" than "outright rejection". This is good as obviously they contribute a lot to core dev, and hopefully that will continue. Luke mentions increasing the block size in an emergency: Those are all scalability issues that will not be fixed by making the blocks larger. We should fix them, not put them off. Maybe we can increase the max block size just in case of emergency, but we most definitely should not increase the actual block sizes simply to ignore real problems.
http://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqye7m6Well, frankly, passing the point of average blocks being 40% full, where confirmation times start to decay exponentially (as per the hashingit graph) is an emergency, something rightly addressed now because everyone who runs a full node needs to upgrade. |
|
|
|
Agreed.
Bitcoin is much better suited to the store of value function.
Why do you think Goldman Sachs et all are trying to pigeon-hole bitcoin as merely a "payments network"?
*also, increasing block size does nothing to address the "instant payment" problem.
The only thing Bitcoin needs to retain the SOV function is that it maintains its fixed supply. No one is talking about changing that. What you're forgetting is that thousands of years ago gold coins were in fact used on a daily basis to buy loaves of bread. Increasing usage in day to day TX's would maximize its utility as money and increase drive it's value much higher. The increase TX volume is clearly necessary to feed miners over the long run via fees. Bitcoins usage needs to be driven to the far ends of the earth into the hands of a many people as possible to guarantee is safety. Nailed it. The SOV function cannot be taken for granted. Gold has the inherent advantage of being physically rare. Bitcoin, while its issuance is capped at 21M, the software can be duplicated thousands of times. Already much duplication is happening in the alts, although they primarily use scrypt which is a very fortuitous accident of history. Lee wanted a coin which would require more memory&cpu for hashing, hence his Litecoin uses scrypt, and most new altcoins have cloned the Litecoin fork of Bitcoin. This has left the sha256 miners to focus primarily on Bitcoin while the scrypt miners are spread over many alts. Litecoin is being bled to death by all its clones. So, Bitcoin's SOV is buttressed by two things: the network effect of its ecosystem, and the hardware invested in sha256 hashing-power. Bitcoin needs to keep growing its ecosystem, and the hashing power will follow it. Bitcoin is not being bled by clones - yet - but there is a real risk if its ecosystem growth is crippled by volume constraints. *also, increasing block size does nothing to address the "instant payment" problem.
re instant payments, doesn't the lightning network provide a form of it? |
|
|
|
Would be nice if $240 holds now.
When it blasts to $300 it looks like $240 will be the bottom of any flash-crash later. |
|
|
|
Ultimately, I think Justus will be right: no block size limit. The whole above discussion regarding UTXO commitments should convince any skeptics against the future need for outsized storage space. That is a big relief. As far as bandwidth, if the TX throughput grows to a size that pushes the limits, that will be a great problem to have. I'm sure the network and technological improvements will quickly respond to that demand. Furthermore, we NEED that type of TX volume to support the miners and to further hash rate growth. The profit incentive does need to be there. As long as the price continues to increase ten fold every other year , then the block reward will be sufficient for at least the immediate future (next 5-10 years) Long term, I think justus' proposed payment structure, or something like it, will be necessary for miners and full nodes to continue to be viable. Might as well give it a try now while the network is *only* worth a few billion... (if this is gonna fail, sooner is better than later) Agreed. And perhaps JR's node services payment structure could be progressed via a Lighthouse funding process. It might get traction if it was divided into broad phases, such as: detailed technical specification, alpha/test version, beta/production-ready version The last of which would eventually need integrating with Bitcoin Core. |
|
|
|
What would a meltdown mean for Bitcoin?
IMHO a debt-driven deflationary meltdown would keep the BTC price depressed (as with gold) because billions of electronic dollars/euros etc are vanishing from the economy when debts are defaulted on. BTC would spike (like gold) afterwards when central banks react with unprecedented money printing, far beyond any QE so far, but eventually they are caught out when the velocity of money ramps up causing an overcompensation for the debt-deflationary effects, and 1970s-style high-inflation is revisited, but worse. Then BTC and gold rockets. BTC is a censorship-free refuge which will help it, plus 2/3rds are already mined, so it may front-run the above mess. |
|
|
|
Do you have tenure?
The system here is different from the American one, but yes, I have tenure and I already got all the promotions that I could have in my career as teacher/scientist. I could try running for university president, but there are too many profs here who know me already, so my chances of being elected by accident would be pretty slim. You can never answer the real question: What is your motive for your extreme interest in bitcoin? (Always with your negative slant) Because JS won't answer your question I will. His extreme interest, always with a negative slant, is a combination of: a) Extreme butt-hurt at not buying when the BTC price was $1, and can't stand seeing free-market libertarians making such easy money, so he wants it to crash to near zero, not so that he can buy cheap, but to see all BTC holders brutally punished for their hubris. b) His Keynesian inflationista perspective which rejects a Bitcoin or other decentralized cryptocurrency-based world economy which would make all governments have to run balanced budgets, reining in Big Government, the massive socialist states, nanny-states, and surveillance states. |
|
|
|
|
Show Posts
