So we get to 140 tps...
What happens if we reach that in say 5 years... Another hard fork?
I just don't think changing it like this is a smart way of dealing with the issue, why not a dynamic size that scales with the network as some other coins do...?
Now I think the hardfork isn't necessary (I've read a lot of article,topics). The 1 MB blocksize is necessary to keep the coin decentralized (more & more people save the blockchain on their PC) and bitcoin will stay a valid an great alternative to the current economy system in the next few years. For example if someone want to send money to his relatives in another country/nation, in this case bitcoin can help (because the fees are lower than moneygram,western union, bank transfer, etc...) and the 7 tps aren't a real problem. " Hi Mike,
I'm glad to answer any questions you have. If I get time, I ought to write a FAQ to supplement the paper.
There is only one global chain.
The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling. If you're interested, I can go over the ways it would cope with extreme size.
By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions.
I don't anticipate that fees will be needed anytime soon, but if it becomes too burdensome to run a node, it is possible to run a node that only processes transactions that include a transaction fee. The owner of the node would decide the minimum fee they'll accept. Right now, such a node would get nothing, because nobody includes a fee, but if enough nodes did that, then users would get faster acceptance if they include a fee, or slower if they don't. The fee the market would settle on should be minimal. If a node requires a higher fee, that node would be passing up all transactions with lower fees. It could do more volume and probably make more money by processing as many paying transactions as it can. The transition is not controlled by some human in charge of the system though, just individuals reacting on their own to market forces." Bitcoin was designed to scale up from day one. Deal with it. |
|
|
|
I thought the point was to increase the block size limit to avoid having to use off chain transactions. The block size limit should raised because off-chain transaction systems should not be artificially subsided. If the limit is not raised, the more transactions will be pushed off chain which otherwise belong on the chain, which won't exactly kill the entire space right away, but as a plan B it's far inferior to allowing the distribution of on-chain vs off-chain transactions to find a natural balance. I don't even think transactions will be pushed off-chain anymore than what is happening organically today. Yes, it is good that off-chain solutions develop, but they should attract user business on their own merits, not be a refuge for users who are forced there. Forcing users to do something stretches the network effect to its limits. Users will instead transact with a different cryptocurrency, and Bitcoin will hemorrhage market share. |
|
|
|
while we are talking alts - does a faster blocktime result in a higher tps?
would it be 28 tps for litecoin for example?
Correct, assuming that Lee did not change the MAX_BLOCK_SIZE constant for LTC. Note that the 7 tps was an early estimate, whereas 2.7 tps is being seen on existing ~1MB Bitcoin blocks, which means ~11 tps for Litecoin, assuming also that they will have larger tx from P2SH and some 2.0 data storage. The fact that LTC has a 4x higher tps than BTC should be ringing alarm bells for the "keep-1MB" people (those who actually like Bitcoin, not the pro-alt-coin kill-bitcoin shills). |
|
|
|
For a price chart which spans more than 10 years, the inflation-adjusted version is also useful. (This one a little stale though).
Okay so we are fairly near but now somewhat below recent decades' highs. What do you think that indicates? It looks to me that it will bounce from the $1100s, probably for a few years, even permanently. Too many shooting wars and currency wars going on for gold to stay down IMHO. |
|
|
|
For a price chart which spans more than 10 years, the inflation-adjusted version is also useful. (This one a little stale though).  |
|
|
|
So is it getting increasingly obvious that bitcoin is more of a "gold standard" and less of a currency to be used for a scalable amount of transactions?
To be clear. Bitcoin, being a payments system and inbuilt currency, when used for a scalable amount of transactions, makes it more and more of a "gold standard". |
|
|
|
Doesn't matter anyway. I'm going to release 250KB coin and blow everyone out the water. If 1MB is better than 20MB, then logic says 250KB must be better than 1MB, right?
Brace yourself, 0.5tps here we come...
Ah, so it's like homeopathy. I should've known better. If fewer transactions is better than more transactions, the why allow transactions at all? Just mine coins and let them sit in the same address forever, like Yap stones. Bitcoin can just be a perfect store of value due to its inherent... um.... bitcoininess. No need to actually transact with it at all. Indeed. Because Bitcoin is clearly electronic gold then I am amazed that the price was nearly zero for 2 years after launch. Didn't people realise what a scarce resource it was then? There was already evidence that they could be sent irreversibly from person A to person B. Satoshi and Hal demonstrated it. That should be proof enough even today. |
|
|
|
That's an interesting line of reasoning.
It suggests that Bitcoin can only succeed if no such attackers exist. Bitcoin can only succeed by growing larger than all attackers. Maybe you and Peter Todd need to get in a room: "Nifty paper proving what we knew already: w/o a blocksize limit there's no PoW security -> death of Bitcoin." http://t.co/VPsgVkdzj9( https://twitter.com/petertoddbtc/status/564934207487897601?s=03) Since his tweet misrepresents what the paper says, it seems to me that he's irrationally entrenched in his opinion. Yep. It is another downside of problems like this remaining unresolved for so long. As the debate continues people do become entrenched when they have have invested so much time and mental energy in their position. They have to admit to themselves that they wasted a lot of effort, if they reverse their view. This is further "cemented" once they go public and stake their reputation on an entrenched position. Peter did this with his video, and Mircea has done it on his blog in front of all his followers. I have still not seen any reasonable argument why Bitcoin can't be allowed to scale at the rate of the slowest improving computing technology that it uses: (bandwidth, at present). |
|
|
|
I agree with the goal of never again having to do a hard fork to change the limit, but am not sure if linear increases are appropriate for a system that could grow geometrically.
Could you support starting with a 2MB cap that then doubles every year?
I'd might be OK with a 5MB cap that doubles when the block reward halves, depending on how it effects TOR/DSL users.
Between 2MB and 5MB is a reasonable starting point, although the 2MB is too tight for very long. It doesn't even have to double every year, just every two years to match bandwidth improvement: http://www.nngroup.com/articles/law-of-bandwidth/Summary: Users' bandwidth grows by 50% per year (10% less than Moore's Law for computer speed). The new law fits data from 1983 to 2014.
Nielsen's Law of Internet bandwidth states that:
a high-end user's connection speed grows by 50% per year
The dots in the diagram show the various speeds with which I have connected to the Net, from an early acoustic 300 bps modem in 1984 to an ISDN line when I first wrote this article (and updated to show the 120 Mbps upgrade I got in 2014). It is amazing how closely the empirical data fits the exponential growth curve for the 50% annualized growth stated by Nielsen's Law. (The y-axis has a logarithmic scale: thus, a straight line in the diagram represents exponential growth by a constant percentage every year).
 |
|
|
|
If 2 MB is all that can be agreed on now, then it's better to schedule that hard fork ASAP rather than agree on something marginally higher in 6-12 months. I personally think that 10 MB would probably be fine, though I know that there are many people who would disagree with me.
True, and yes 10MB might be the optimum for a long time. It is notable that a lot of the "pro" group have an open mind as to how the limit should be raised. e.g. I am also open to different proposals on exactly what to replace the current 1 MB restriction with, in order to make the right trade off between distribution of full nodes, and transaction throughput.
I also think that some "anti" people underestimate the public relations disaster that would result from the self-inflicted wound of actually maxing out the 1MB limit. The world's press would jump on it as evidence that a decentralized community cannot be trusted to manage a global currency. It would be "proof" that only blockchains with some centralized control (e.g. by major banks) are the way forward. Obviously, rubbish in the long run, but it would put doubt in the minds of many potential supporters of Bitcoin. |
|
|
|
I haven't read this thread much at all, so maybe this has already been said, but I've been noticing a lot of people saying things like, "If the block size isn't raised, then that would be bad because ..." But just wanting larger blocks isn't a good argument for increasing the max block size. By far the most important issue is what the network can support. We're just going to have to learn to deal with the fact that the network's capacity is limited and fees will probably always be larger than people want. (However, I do believe that the network could very likely support 10 MB blocks right now, though probably not 50 MB blocks, for example.)
Indeed. Which is why Matt's relay system and IBLT are needed, and will massively improve the situation for block propagation. People arguing for 1MB forever ignore this, yet when 20MB blocks finally appear they will take less than 1MB to broadcast through the network. It will only be bootstrapping new nodes and re-sync which will need the full blocks transmitted. Bandwidth is the limiting factor, disk space less so. You proposed increasing the limit to 2MB in 2 years. This is what should have been done in Feb 2013 when this debate last came up in earnest. Unfortunately, this is now too little too late. IBLT was not considered at that time, but it is something we are aware of now. |
|
|
|
So raising the limit slowly will stop the blockchain spammers? That makes no sense. If they can spam at 2MB then they can spam at 1MB and at 20MB. We can find measures to live with the spam, but limiting the block size at 1MB isn't a valid solution for this.
Correct. Let's say the block limit becomes 20MB and some spammer was capable of filling up three of them in a row, delaying confirmations for 1/2 an hour. In which case, the same spammer could right now, fill up 60 blocks at 1MB, and delay confirmations for 10 hours! Worse, once the 1MB blocks are normally 75% full, any spammer with that capability could probably cripple tx confirmations for a whole week! |
|
|
|
Itīs official. http://www.chinatimes.com/realtimenews/20150208002335-260410Google translate:: "Hong Kong, " Wen Wei Po" reported bitcoin (bitcoin) again to Hong Kong investors ' loss of hand bad feet " : Hong Kong, a Bitcoin payment platform has suddenly closed down , estimated at nearly 3000 Bitcoin investors may lose everything at any time . It is understood that when a group of Hong Kong investors in Bitcoin trading platform related office visits , found that have been left vacant , suspected of fraud and pyramid selling , the estimated total amount of all " victims ' losses at any time up to three billion Hong Kong dollars . Today they will collectively Police...." Thanks to Jorge for breaking the news. Wait until this hits the news worldwide on monday, which will probably trigger the crash to sub 100. We would go there anyways, but a good news story will probably add more momentum and preserves us from more failed pumps and boring sideways action before the crash. So why aren't the Chinese exchanges dumping like crazy? 3 billion yuan = 2.17 million btc at the current price. 3000 investors means the average investor had 725 btc each  |
|
|
|
Cyprus did not cause the April 2013 rally. I don't know why everyone thinks that... Also, Greece isn't going to impact bitcoins price.
correct. I keep pointing it out myself, but people don't listen to reason a lot these days. Why do people call it an April rally? It started in January and ended in April. People also blame MtGox for the crash from $266. Whereas gox went down afterwards, when it was about $125, and after their outage the price continued from that level. |
|
|
|
Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea. Both Satoshi and I objected that it wouldn't scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed. The 1MB limit was there by the time Bitcoin launched.
It would be great if Satoshi would chime in. Maybe if the coin does indeed begin to snap in two? There is no need for Satoshi to chime in (although if he did reappear I have a list of questions). The first version of the client had no block size limit. The second version of the client had no block size limit. The next 146 commits to the repo had no block size limit. The source code is the proof. The block size limit wasn't added as an anti-spam mechanism until more than 21 months after the genesis block. I think Satoshi was worried about rapid improvements in hashing power giving one rogue miner the ability to bloat the blockchain with a series of large (32MB?) blocks. The first mention of using FPGAs that I can find on Bitcointalk is July 2010, three months before the 1MB change. At the time Bitcoin was gaining traction with a community behind it, and a serious spam attack would have damaged its progress. Thanks for the hashing analysis from a much more experienced perspective! I am still interested in how this little processor can do... even if I was off by a factor of about 10, it might still be competitive with much more expensive and energy intensive desktop processors. I can get about 2100 khash/sec using all 4 cores of my 64 bit machine when the system is otherwise idle, and that certainly makes the fans blow a lot of hot air. I though it might be possible for VIA to overcome because custom circuits (FPGA or ASIC) for some cryptographic functions have in the past proved orders of magnitude faster than general desktop processors or even GPUs.
(my bold emphasis) |
|
|
|
Finex is starting to look tsunami like again It's Huobi the anchor chain again. Must be the big Chinese mining pools still dumping coins. Don't they know the rest of the world is revving for the next bull run? |
|
|
|
It is not the job of "base money" to be stable against other currencies. Base monet doesn't give a f*ck what it's value is or even whether it has any - its job is to function as a monetary medium of high integrity which means resistance to counterfeit, fungibility and tranrsmittability.
In a physical market, many things fulfill that role. In an electronic platform only cryptocurrencies can fulfill that role - in other words they can be transmitted on an electronic platform without the need for a counterparty (bank).
There is a fundamental drawback of open source cryptocurrencies: anyone can copy the code and make a new one. So, Bitcoin is finite, but cryptocurrency is infinite. So why do bitcoins trade in the $200s but all the copies, the alts, trade for much less, usually in the cents? The reason is Bitcoin's first mover status which has allowed it to get a head-start, the network effect which has kept a head of steam behind it for 6 years. People use Bitcoin because other people use it, and the mining power builds up as the ecosystem grows. It is a positive feedback loop. People do not need lots of cryptocurrencies. They only need one. Just as multiple different fiat currencies are a pain for an international traveller. So, what can go wrong? If Bitcoin were to hit some limit, I dunno what, just maybe there is a limit in the code which people might start writing threads about on bct, but anyway, if Bitcoin hit some limit and couldn't scale anymore, then the network effect is arrested. Bitcoin, just being software that can be copied does not have the privilege of gold which is a rare physical element. Some other version of Bitcoin, an existing alt perhaps, which can scale will build up its own network effect from all the users who can't use Bitcoin. If Bitcoin found some crazy limit where only 1% of 1% of the world's population could use it, then it would become obsolete. It would be a footnote in the history books written about the alt which eventually succeeded as the new electronic gold standard. |
|
|
|
Edit: Will you be supporting any efforts to kill off the 1mb chain after the fork? Sorry last edit
I am sure he won't. He has load of important stuff to move onto. The problem with the 1MB chain is that difficulty will be so high for the few miners left on it that it will take a year for diff to fall until 10 minute blocks are happening again. Every 2016 blocks the diff can only fall 75%, so it won't be usable for several adjustments, and these will take massive amounts of time. |
|
|
|
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).
Probably the best time to let soft-limits persist was in 2011/12 when the ecosystem was smaller, the funds at stake were a lot smaller, users considered the software more experimental than beta, and the world's press wasn't really watching. 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.
My experience of (centralized) financial systems over many years is that ignoring hardware and software constraints as they are approached invariably causes outages. Also, that trying to train a user-base or worse, a market, to behave differently to accommodate IT constraints is a Sisyphean task. There are probably hundreds of IT experts who are concerned about the block size limit, because they can see the risks in it, which they recognize from prior (usually bitter) experience. And, this is where the role of Core Dev is crucial. If there are major efficiencies to be had, "low-hanging fruit", then it would be wonderful to see them go live and reflected in smaller blocks etc. But right now, we can only project forwards, from what is happening with the average block size. |
|
|
|
The assertion that a fee market only works if miners act as a cartel is false. The situation in which miners do not act as a cartel simply presents the consumer with a range of prices which they can choose among, paying a premium if they are willing to pay for high-priority or prompt service or taking a discount for making low-priority or slow transactions.
Imagine a market in which there is no cartel. To make it simple, suppose that there are ten miners each with ten percent of the hashing power, and that the block size limit is not routinely reached. Because they are economically rational and facing different prices for bandwidth and electricity in their respective neighborhoods, they all set different minimum-fee policies.
The consumer is faced with ten different price points for a "minimum acceptable" fee, which determines how many of these miners would accept his or her transaction.
So... paying a minimum fee would get your tx accepted by one miner. On average you're going to have to wait ten blocks before that miner gets a block, so your expected tx time is about 100 minutes. Paying a median fee would get your tx accepted by any of five miners. On average you're going to have to wait two blocks before one of those five gets a block, so 20 minutes. Paying the highest fee would get your tx into any block regardless of who mines it, so you'll be in the very next block in around 10 minutes.
The point is that consumers are not faced with a binary "pay enough" or "don't pay anything" choice; they are faced instead with the opportunity to select a level of responsiveness desired and pay for the priority they want or need on a by-transaction basis.
This is a great explanation! It fits the "unconstrained" block size scenario, which is how Bitcoin has worked for most of its existence, except for a day or so about March 6th, 2013, when the 250KB soft-limit was effective. It does mean that when users create a transaction they have a single-shot at getting the fee right. In the simplified example, if a user pitches their fee so that 2 miners will accept it (out of 10), and then change their mind, deciding that waiting an expected 50 minutes is too long, then they are SOL, the unconfirmed tx can't be changed. Fortunately this is rare. The "constrained" block size scenario makes necessary the ability for ordinary users to increase the fee. Users will want to update the fee on their unconfirmed tx to manage the instability in confirmation times, otherwise their tx can remain stuck in cyberspace, and they are helpless. Certainly, protocol block limits should not be hit unless all wallets first support the updating of fees on unconfirmed tx. |
|
|
|
|
Show Posts
