Bitcoin Unlimited Proposed Development Roadmap

[theZerg]

Here are some ideas I have for the next steps with our client. What are your ideas?

EDIT: The associated names give credit to the originator of the idea, not necessarily the person who will implement or merge the technology into Bitcoin Unlimited.

Protocol optimization (increase network efficiency to allow greater scalability):
BUIP022: XInv (Peter Tschipper)
pass transaction hash 64-bit prefixes rather than the full 256 bit hash
Combine multiple hashes into a single message
Shorten the meta-data
result is 75%+ smaller than today's INV

Node economic incentives (create incentives for non-mining nodes):
Node protocol payment channels
SPV nodes open a payment channel with full nodes to access data

Mining optimization (attract miners to Bitcoin Unlimited and increase network efficiency):
BUIP023: Optimization of block creation and mining pool networking interface
reduces the time miners are idle or not productive.
this time costs miners about $1.5 per unproductive millisecond per day
Subchains (weak blocks) (Peter Rizun)
allows additional security for zero-conf payments
allows pre-creation of next block candidate making GBT speed unimportant

Hard Fork (prepare features in case hard forks become possible):
BUIP024: Extension blocks with address sharding (Andrew Stone)
Deliver unlimited scalability by allowing most participants and all hardware to only handle a subset of the blockchain.
Fraud Proofs (Justus Ranvier)
instead of requiring a complete UTXO search, efficiently show that a transaction is invalid
Hardware wallet optimization
inputs specify the balance -- txn is illegal, even if signed, if a balance is incorrect
Flexible Transactions (from Bitcoin Classic) or similar
solves malleability (and everything that SW solves)
clean and simple -- removes lots of "technical debt"
allows future transaction types and capabilities
makes txns slightly smaller
Trailing, sorted UTXO commitments
investigate feasibility

 

[sickpig]

@theZerg if memory servers it seems to that there was also a BUIP from @Peter Tschipper to apply compression to datastream between peers? was it BUIP017?

edit: forgot to say that the proposed roadmap sounds great!

 

[HelloGuy]

Compact Message Format proposed by Tom is very important. The P2P layer of Bitcoin should be re-designed again. And it is not consensus related, we can work on a different port. It could be a minor step to exit Core.

In about 12 months, we will need features below:

UTXO database: UTXO will going to be increase a lot. We should manage the UTXO in a seperate database, which can use both RAM and SDD for storage.

Multiple hard disk storage: in both vps and home computer, it will be more convenient if we can store the blockchain data in several different folders, which are most likely on different hard disks, even ftp servers.

Some cloud nodes will want to serve the new nodes bootstrap, but the high speed SDD is expensive. They may want to store the pruned data in SDD to serve the transaction relay and block validation and SPV nodes service, and to store the whole blockchain in a separate cheap HDD, or even a FTP server.

 

[Christoph Bergmann]

That an impressive roadmap.

Do you know how much time the steps will need?

Are the optimizations and the node incentives possible without a hardfork?

 

[_mr_e]

Very impressive. It's great to see a team that is actually building what the people want rather then whatever they want to force on everyone.

 

[Norway]

BUIP024: Extension blocks with address sharding (Andrew Stone)
Deliver unlimited scalability by allowing most participants and all hardware to only handle a subset of the blockchain.

This!

 

[Tom Zander]

Hi all.

I think a roadmap is typically something that you plan for your team to work on so I think its very funny to see my work and my name show up while I'm as far as I know not part of the BU team.

Don't get me wrong, I'm flattered. But I don't think its right.

I suggest using wording like Classic used; "Segregated Witness from Core, when it is available.". So I suggest "Flexible Transactions from Classic". And leave out all the other details and link to my blog if you really want them.

Cheers!

 

[_mr_e]

You should really consider joining forces with BU. I hate to say it but it feels as though classic's name has been successfully dragged through the mud while BU is being widely regarded as the potential future contender. You're work is amazing, I hate to see it destroyed by character(project) assassination.

 

[theZerg]

Hi all.

I think a roadmap is typically something that you plan for your team to work on so I think its very funny to see my work and my name show up while I'm as far as I know not part of the BU team.

Don't get me wrong, I'm flattered. But I don't think its right.

I suggest using wording like Classic used; "Segregated Witness from Core, when it is available.". So I suggest "Flexible Transactions from Classic". And leave out all the other details and link to my blog if you really want them.

Cheers!

Sorry, I was crediting the author of the idea, not implying anything about who will do the work for Bitcoin Unlimited. Justus Ranvier is also not a BU developer and Peter Rizun does not write code...

 

[Erik Hedman]

Well, as you are asking for ideas, I'll humbly bring up this old one by me about letting a node operator have an influence over soft- and hard forks:
https://bitco.in/forum/threads/using-the-acceptable-depth-mechanism-to-vote-for-different-versions-bits.1168/

 

[HelloGuy]

Well, as you are asking for ideas, I'll humbly bring up this old one by me about letting a node operator have an influence over soft- and hard forks:
https://bitco.in/forum/threads/using-the-acceptable-depth-mechanism-to-vote-for-different-versions-bits.1168/

Node voting is a bad idea, just as one IP one vote, which was refuted by Satoshi.

 

[Erik Hedman]

Could you elaborate on why you believe it's a bad idea? Unlimited already have the same mechanism when it comes to block size.

And maybe the discussion of this proposal should be in the original thread and not this thread.

 

[HelloGuy]

About the block size, Unlimited is still one CPU one vote. And the governance model of Bitcoin should not changed too much. The problem with Core is that some developers are trying to take control. However, if we let the ordinary transactions to have power, it is also change of the governance model. People are very easy to be led by some people like Greg, who is good at soliciting and intimidation. We should keep the same governance model of Bitcoin as it is.
[doublepost=1472399914][/doublepost]And I also oppose the idea of sharding. Sharding is beautiful technically, but we should not do it right now.

Right now the block size of Bitcoin is only 1MB, and every year the blockchain data is around 50GB. If the block size goes up to 64MB, the blockchain data per year will be 3TB. Then let us take a look at the price of the hard drive:

https://www.amazon.com/s/ref=nb_sb_noss_2/165-5811331-4154723?url=search-alias=aps&field-keywords=4TB+hard+drive

Surprisingly cheap!!!

And of course, there is pruning technologies that is already working in Core! Right now you can store the pruned data of blockchain history with only 2GB size! (https://bitcoinmagazine.com/articles/bitcoin-core-released-what-s-new-1456241356)

We should make less change as long as there is no problems. Sharding could be done when the block size is already more than 1GB or something like that. And even at that time, I doubt the necessary to do the sharding, as for so valuable payment network, even with 1GB blocksize the technology is able to handle the problems very well with the 1GB block size.

Now the Unlimited and other non-Core side development teams are all short of developers. With the very few developers, we should focus on doing the right thing in the best quality, but not spending precious time on the beautiful but temporally useless idea now.

 

[Erik Hedman]

@HelloGuy I do agree that resources are limited, and I have no problem to see my proposal never float to the top of the priority heap.

Concerning your other comments, I will answer them in the thread that I started in May about my idea, I don't think this is the right place to discuss the merits of that idea.

 

[HelloGuy]

https://bitcointalk.org/index.php?topic=1534271.0

About node economic incentives