A Scalability Roadmap - Bitcoin Foundation

Hardfork in Bitcoin Scalability Roadmap

Hardfork in Bitcoin Scalability Roadmap submitted by tonewsto to ToNewsTo [link] [comments]

@binance: Schnorr signatures are one of the most anticipated milestones on the #Bitcoin roadmap. With just a single upgrade, they can provide significant privacy & scalability benefits. They also set the scene for further developments in #BTC smart contracts https://t.co/btvAHKYwSn

@binance: Schnorr signatures are one of the most anticipated milestones on the #Bitcoin roadmap. With just a single upgrade, they can provide significant privacy & scalability benefits. They also set the scene for further developments in #BTC smart contracts https://t.co/btvAHKYwSn submitted by rulesforrebels to BinanceTrading [link] [comments]

21 months ago, Gavin Andresen published "A Scalability Roadmap", including sections called: "Increasing transaction volume", "Bigger Block Road Map", and "The Future Looks Bright". *This* was the Bitcoin we signed up for. It's time for us to take Bitcoin back from the strangle-hold of Blockstream.

A Scalability Roadmap
06 October 2014
by Gavin Andresen
https://web.archive.org/web/20150129023502/http://blog.bitcoinfoundation.org/a-scalability-roadmap
Increasing transaction volume
I expect the initial block download problem to be mostly solved in the next relase or three of Bitcoin Core. The next scaling problem that needs to be tackled is the hardcoded 1-megabyte block size limit that means the network can suppor[t] only approximately 7-transactions-per-second.
Any change to the core consensus code means risk, so why risk it? Why not just keep Bitcoin Core the way it is, and live with seven transactions per second? “If it ain’t broke, don’t fix it.”
Back in 2010, after Bitcoin was mentioned on Slashdot for the first time and bitcoin prices started rising, Satoshi rolled out several quick-fix solutions to various denial-of-service attacks. One of those fixes was to drop the maximum block size from infinite to one megabyte (the practical limit before the change was 32 megabytes– the maximum size of a message in the p2p protocol). The intent has always been to raise that limit when transaction volume justified larger blocks.
“Argument from Authority” is a logical fallacy, so “Because Satoshi Said So” isn’t a valid reason. However, staying true to the original vision of Bitcoin is very important. That vision is what inspires people to invest their time, energy, and wealth in this new, risky technology.
I think the maximum block size must be increased for the same reason the limit of 21 million coins must NEVER be increased: because people were told that the system would scale up to handle lots of transactions, just as they were told that there will only ever be 21 million bitcoins.
We aren’t at a crisis point yet; the number of transactions per day has been flat for the last year (except for a spike during the price bubble around the beginning of the year). It is possible there are an increasing number of “off-blockchain” transactions happening, but I don’t think that is what is going on, because USD to BTC exchange volume shows the same pattern of transaction volume over the last year. The general pattern for both price and transaction volume has been periods of relative stability, followed by bubbles of interest that drive both price and transaction volume rapidly up. Then a crash down to a new level, lower than the peak but higher than the previous stable level.
My best guess is that we’ll run into the 1 megabyte block size limit during the next price bubble, and that is one of the reasons I’ve been spending time working on implementing floating transaction fees for Bitcoin Core. Most users would rather pay a few cents more in transaction fees rather than waiting hours or days (or never!) for their transactions to confirm because the network is running into the hard-coded blocksize limit.
Bigger Block Road Map
Matt Corallo has already implemented the first step to supporting larger blocks – faster relaying, to minimize the risk that a bigger block takes longer to propagate across the network than a smaller block. See the blog post I wrote in August for details.
There is already consensus that something needs to change to support more than seven transactions per second. Agreeing on exactly how to accomplish that goal is where people start to disagree – there are lots of possible solutions. Here is my current favorite:
Roll out a hard fork that increases the maximum block size, and implements a rule to increase that size over time, very similar to the rule that decreases the block reward over time.
Choose the initial maximum size so that a “Bitcoin hobbyist” can easily participate as a full node on the network. By “Bitcoin hobbyist” I mean somebody with a current, reasonably fast computer and Internet connection, running an up-to-date version of Bitcoin Core and willing to dedicate half their CPU power and bandwidth to Bitcoin.
And choose the increase to match the rate of growth of bandwidth over time: 50% per year for the last twenty years. Note that this is less than the approximately 60% per year growth in CPU power; bandwidth will be the limiting factor for transaction volume for the foreseeable future.
I believe this is the “simplest thing that could possibly work.” It is simple to implement correctly and is very close to the rules operating on the network today. Imposing a maximum size that is in the reach of any ordinary person with a pretty good computer and an average broadband internet connection eliminates barriers to entry that might result in centralization of the network.
Once the network allows larger-than-1-megabyte blocks, further network optimizations will be necessary. This is where Invertible Bloom Lookup Tables or (perhaps) other data synchronization algorithms will shine.
The Future Looks Bright
So some future Bitcoin enthusiast or professional sysadmin would download and run software that did the following to get up and running quickly:
  1. Connect to peers, just as is done today.
  2. Download headers for the best chain from its peers (tens of megabytes; will take at most a few minutes)
  3. Download enough full blocks to handle and reasonable blockchain re-organization (a few hundred should be plenty, which will take perhaps an hour).
  4. Ask a peer for the UTXO set, and check it against the commitment made in the blockchain.
From this point on, it is a fully-validating node. If disk space is scarce, it can delete old blocks from disk.
How far does this lead?
There is a clear path to scaling up the network to handle several thousand transactions per second (“Visa scale”). Getting there won’t be trivial, because writing solid, secure code takes time and because getting consensus is hard. Fortunately technological progress marches on, and Nielsen’s Law of Internet Bandwidth and Moore’s Law make scaling up easier as time passes.
The map gets fuzzy if we start thinking about how to scale faster than the 50%-per-increase-in-bandwidth-per-year of Nielsen’s Law. Some complicated scheme to avoid broadcasting every transaction to every node is probably possible to implement and make secure enough.
But 50% per year growth is really good. According to my rough back-of-the-envelope calculations, my above-average home Internet connection and above-average home computer could easily support 5,000 transactions per second today.
That works out to 400 million transactions per day. Pretty good; every person in the US could make one Bitcoin transaction per day and I’d still be able to keep up.
After 12 years of bandwidth growth that becomes 56 billion transactions per day on my home network connection — enough for every single person in the world to make five or six bitcoin transactions every single day. It is hard to imagine that not being enough; according the the Boston Federal Reserve, the average US consumer makes just over two payments per day.
So even if everybody in the world switched entirely from cash to Bitcoin in twenty years, broadcasting every transaction to every fully-validating node won’t be a problem.
submitted by ydtm to btc [link] [comments]

A Scalability Roadmap | The Bitcoin Foundation

submitted by GibbsSamplePlatter to Bitcoin [link] [comments]

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit)

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit) submitted by slacker-77 to Bitcoin [link] [comments]

Where to find infos about bitcoin's roadmap / scalability ?

Hi,
I was searching about who is developing bitcoin and what is planned, but i couldn't find a clear source. Is there a website gathering these infos?
Thanks.
submitted by salutjesuisbaguette to Bitcoin [link] [comments]

Bitcoin Core's scalability roadmap in visual form

Bitcoin Core's scalability roadmap in visual form submitted by smidge to Bitcoin [link] [comments]

Bitcoin Core's scalability roadmap in visual form

Bitcoin Core's scalability roadmap in visual form submitted by smidge to btc [link] [comments]

"#Bitcoin Cash continues the Bitcoin project as Satoshi intended, as per original roadmap. Scalable. Efficient. Unrestricted."--Eli Afram

submitted by TomorrowisToday_ to btc [link] [comments]

The first Bitcoin Core scalablity roadmap (2014)

submitted by Gobitcoin to btc [link] [comments]

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit)

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit) submitted by slacker-77 to btc [link] [comments]

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit)

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit) submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Gavin Andresen | Bitcoin — A Scalability Roadmap

submitted by elux to BitcoinSerious [link] [comments]

Where to find infos about bitcoin's roadmap / scalability ? /r/Bitcoin

Where to find infos about bitcoin's roadmap / scalability ? /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Any one of our Chinese translators care to translate this page from 2014 regarding Gavin's Bitcoin Core Scalability Roadmap?

Any one of our Chinese translators care to translate this page from 2014 regarding Gavin's Bitcoin Core Scalability Roadmap? submitted by Gobitcoin to btc [link] [comments]

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit)

This is an automatic summary, original reduced by 71%.
With the decline of Bitcoin Unlimited, the support rate for the Bitcoin Core development team's Segregated Witness is rapidly increasing in terms of hashrate and node count.
To a bitcoin user's request to clarify the team's roadmap of Bitcoin Scaling in an online community, Bitcoin Core developer Luke Jr laid out various plans for the community to be aware of.
Currently, bitcoin blocks are only at 75 percent of its maximum capacity of 1 megabyte and therefore, an immediate solution to increase the bitcoin block size is not urgent as of yet.
In summation, the Bitcoin Core development team's scalability plan for bitcoin is straightforward.
As Bitcoin Core developer Greg Maxwell explained in the past, Bitcoin is different to settlement networks such as Visa.
"Some are mostly interested in Bitcoin for payments- and are not so concerned about what are, in my view, Bitcoin's primary distinguishing values- monetary sovereignty, censorship resistance, trust cost minimization, international accessibility/borderless operation, etc. Instead some are very concerned about Bitcoin's competitive properties compared to legacy payment networks," said Maxwell.
Summary Source | FAQ | Theory | Feedback | Top five keywords: Bitcoin#1 block#2 size#3 transaction#4 Lightning#5
Post found in /Bitcoin, /BitcoinAll, /btc and /CryptoCurrency.
NOTICE: This thread is for discussing the submission topic. Please do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

Press • [2017-04-04] Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit)

submitted by btcforumbot to BtcForum [link] [comments]

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit)

Bitcoin Core Developer Lays Out Scalability Roadmap Based on Segregated Witness (Segwit) submitted by CryptoCurrencyNews to CryptoCurrency [link] [comments]

Risks vs rewards in Core scalability roadmap /r/Bitcoin

Risks vs rewards in Core scalability roadmap /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Ethereum Announces “Unlimited” Scalability Roadmap - CCN: Financial Bitcoin & Cryptocurrency News

Ethereum Announces “Unlimited” Scalability Roadmap - CCN: Financial Bitcoin & Cryptocurrency News submitted by HiroJa to DogeNews [link] [comments]

The Core Development Scalability Roadmap /r/Bitcoin

The Core Development Scalability Roadmap /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

"#Bitcoin Cash continues the Bitcoin project as Satoshi intended, as per original roadmap. Scalable. Efficient. Unrestricted."--Eli Afram

submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Bitcoin SV Crypto Channel - 27/12/2018 - Tokenized ... Bitcoin Q&A: Schnorr signatures and the privacy roadmap Blockchain News - YouTube Bitcoin Tech Update with Andrew Poelstra ETHEREUM, BITCOIN SCALING BY VITALIK BUTERIN - YouTube

Bitcoin Core Developer Lays Out Scalability Roadmap Based the team’s roadmap of Bitcoin Scaling Bitcoin Core development team’s scalability plan for From a tech perspective, Bitcoin seems to be just getting started: 2018 promises to be the year that a number of highly anticipated projects are either launched or Nxt News – December 2017 (II): Great Works Are Performed Not By Strength But ... Capacity increases for the Bitcoin system We, the undersigned, support the roadmap in Capacity increases for the Bitcoin system. We have been working on scalability for several years within the Bitcoin Core project and consider this the best possible continuation of our efforts. Around summer 2015 when the scalability debate was heating up, two bitcoin conferences were organized. One in Montreal and the other in Hong Kong. After Hong Kong, an email was written to the bitcoin developer mailing list. It became the unofficial manifesto of the pro-Core side in the scalability debate. This "Core Scalability Roadmap" is well worth a read: https://lists.linuxfoundation.org ... The Bitcoin Scalability Roadmap, proposed by Gregory Maxwell in the recently held Scaling Bitcoin conference earlier this month has received a response from fellow Bitcoin Core members – Gavin ... A community dedicated to Bitcoin, the currency of the Internet. Bitcoin is a distributed, worldwide, decentralized digital money. Bitcoins are...

[index] [32020] [23688] [38222] [34991] [2714] [21839] [44877] [43804] [18919] [46831]

Bitcoin SV Crypto Channel - 27/12/2018 - Tokenized ...

These proposals have lots of positive implications, including an improvement to privacy and scalability, but what will it mean for an average Bitcoin user? What is next on the roadmap? In this ... The Schnorr signatures algorithm promises to help to address one of the most pressing problems affecting Bitcoin today: scalability. Additionally, Schnorr si... On Chain Scalability - Bitcoin Cash follows the Nakamoto roadmap of global adoption with on-chain scaling. As a first step, the blocksize limit has been made adjustable, with an increased default ... How important are privacy improvements to Bitcoin in the roadmap? How will second layers and atomic swaps help with this? When will Schnorr signatures / signature aggregation be added to Bitcoin? Reimagining the future of value. The mission of Blockchain.News is to provide reliable and credible news and updates for readers and to highlight the impacts...

#