Which of these 3 possibilities is the most likely to happen (if any) to improve the Bitcoin network?
The debate seems to be only focused on block size. I think options 1 and 2 are the way to go.
Topic: Three Challenges for Scaling Bitcoin (Read 2398 times)
We've been working on concepts similar to 1) and 3) for quite some time (2 years) and have a functioning system almost ready to go. The eMunie platform is totally block less hence I say similar.
I'm actually writing some documentation as I reply here on these solutions we have implemented in eMunie. We're planning a public beta test in the next 4-6 weeks that demonstrate not only those concepts, but also many other features of the platform.
I'll post back here when I've finished these articles and posted them to my blog.
I'm actually writing some documentation as I reply here on these solutions we have implemented in eMunie. We're planning a public beta test in the next 4-6 weeks that demonstrate not only those concepts, but also many other features of the platform.
I'll post back here when I've finished these articles and posted them to my blog.
This is way to radical to implement practically. All of these "solutions" propose fundamental changes to the Bitcoin currency. These ideas are interesting, and it may be an idea to try developing your own altcoin based on these suggestions and see if you make any money out of it.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
holy crap, is this for real?
is this sharding scheme actually possible?
is this sharding scheme actually possible?
The ideas expressed in the blog (although very interesting) seem too radical for the situation at hand.
While author advocates having hard-forks with regular intervals in order to keep improving Bitcoin (which I support as well), he intends to abolish the limit completely not realizing that it's the only measure that forces people to come together and decide on the future of Bitcoin. Without the limit there will be little to no incentive to do that and the inertia of the process will make sure that any attempts to change it get shut down.
The limit in question serves as a coherency mechanism for Bitcoin and is similar to a barrier in pthread terminology. No thread is allowed to run further until all threads reach the barrier, share their experiences with each other and decide on the next run. The limit determines the bandwidth target for the network and therefore is the only guardian of the consensus.
While author advocates having hard-forks with regular intervals in order to keep improving Bitcoin (which I support as well), he intends to abolish the limit completely not realizing that it's the only measure that forces people to come together and decide on the future of Bitcoin. Without the limit there will be little to no incentive to do that and the inertia of the process will make sure that any attempts to change it get shut down.
The limit in question serves as a coherency mechanism for Bitcoin and is similar to a barrier in pthread terminology. No thread is allowed to run further until all threads reach the barrier, share their experiences with each other and decide on the next run. The limit determines the bandwidth target for the network and therefore is the only guardian of the consensus.
The right answer is to re-engineer the system to not have the [block size] problem in the first place.
http://blog.sldx.com/three-challenges-for-scaling-bitcoin/
http://blog.sldx.com/three-challenges-for-scaling-bitcoin/
Jump to: