Will Bitcoin 'Hard Fork' in any useful features.. ?

[spartacusrex]

This is IMHO Bitcoin's greatest strength and greatest weakness..

I, and many others I'm sure, feel that a stable protocol, immutable and set in stone, would be a very positive thing. v1.0 if you will. But being flexible also has it's upside.

Imagine if the structure of Gold, at an atomic level, kept changing ? This would not be cool.

But Bitcoin is not Gold, it is something quite different. (with obvious similarities though)

So when a new Coin comes along that does X, and everyone says - Ohhh, that's really cool, Bitcoin 'can' be changed, and soft/hard-fork in the features.

Some things will not be possible (I contend, but you may disagree) but most things.. absolutely. There is certainly no lack of technical expertise working on BTC.

So is this the future of Bitcoin, to absorb the abilities of the newcomers ? (Like that guy in Heroes.. who cuts heads open..)

 

[helloeverybody]

It would be nice to fork in some fancy features but at this point i just want to get this block debate out of the way and onto bigger blocks or whatever it is thats decided. From their on in maybe we could start worrying about better features.

[spartacusrex]

yep - this block size debate/war/issue sure is getting ugly..

And if it has taken a war of this magnitude to change one number, I can see why people are cautious about thinking that anything even remotely more complicated will ever be introduced..

But - I think we are learning a lot, about the nature of the btc beast, and this may pave the way for smoother less fractious transitions in the future.

One would hope, at least.

[helloeverybody]

yep - this block size debate/war/issue sure is getting ugly..

And if it has taken a war of this magnitude to change one number, I can see why people are cautious about thinking that anything even remotely more complicated will ever be introduced..

But - I think we are learning a lot, about the nature of the btc beast, and this may pave the way for smoother less fractious transitions in the future.

One would hope, at least.

I suppose in theory bitcoin could steal a lot of what other altcoins offer so that it remains ther master coin but with all the dramas involved around "simply increasing" the block size you can imagine how much more there would be for adding fancy features. It would be good though.

[Denker]

yep - this block size debate/war/issue sure is getting ugly..

And if it has taken a war of this magnitude to change one number, I can see why people are cautious about thinking that anything even remotely more complicated will ever be introduced..

But - I think we are learning a lot, about the nature of the btc beast, and this may pave the way for smoother less fractious transitions in the future.

One would hope, at least.

I suppose in theory bitcoin could steal a lot of what other altcoins offer so that it remains ther master coin but with all the dramas involved around "simply increasing" the block size you can imagine how much more there would be for adding fancy features. It would be good though.

And this is the problem what many people don't seem to understand.
It's not about just increasing the block size. It is about scaling!
And scaling is much more than just an increase of the block size.Things should be done properly and not in a rush.
And beside all that it also became a political thing. Tough times.

[simon66]

Yes, I think that once great blockchain technologies are developed and proven that they will be added onto Bitcoin. I think in the future there will be many more technologies added to bitcoin.

I think that one of the biggest reasons that there is so much blocksize debate is that many of the proposals have other things added in with it that many do not agree with.

In time though I think bitcoin will get passed this and continue back on the right path of advancing the technology.

[BitUsher]

https://en.bitcoin.it/wiki/Hardfork_Wishlist
https://en.bitcoin.it/wiki/Softfork_wishlist

[mirana12345]

There's no doubt imho, that bitcoin will take some new features in the future , and make a hard fork, and i don't really see any reason
why it should not do that. Any change for the better, and optimizations, are most certainly welcome.

The problem is that you need majority of the network to make it so, and judging by the recent debates, that is not as easy as you would think.
The only parts where i would draw the line is cap. limit and fee and block reward structure as those are the core elements that should not be changed, ever.

[pawel7777]

yep - this block size debate/war/issue sure is getting ugly..

And if it has taken a war of this magnitude to change one number, I can see why people are cautious about thinking that anything even remotely more complicated will ever be introduced..

But - I think we are learning a lot, about the nature of the btc beast, and this may pave the way for smoother less fractious transitions in the future.

One would hope, at least.

I suppose in theory bitcoin could steal a lot of what other altcoins offer so that it remains ther master coin but with all the dramas involved around "simply increasing" the block size you can imagine how much more there would be for adding fancy features. It would be good though.

And this is the problem what many people don't seem to understand.
It's not about just increasing the block size. It is about scaling!
And scaling is much more than just an increase of the block size.Things should be done properly and not in a rush.
And beside all that it also became a political thing. Tough times.

That's not an argument, core devs also see the need of scaling, proposing segwit in near future and LN later on. This debate is bit more complex than simple "to scale or not to scale?"

[franky1]

if core (blockstR3am) just added in the 2mb buffer with their april update there would be no debate and everyone would be happy, and there would be extra features too

[alani123]

Unlikely, bitcoin classic is looking to actually take away useful features. Like sidechains, segwit and RBF. All those projects with great potential, bitcoin classic is one fork with vested interest into making them fail.

[pawel7777]

Unlikely, bitcoin classic is looking to actually take away useful features. Like sidechains, segwit and RBF. All those projects with great potential, bitcoin classic is one fork with vested interest into making them fail.

How exactly are they taking the segwit and sidechains away?

[BitUsher]

if core (blockstR3am) just added in the 2mb buffer with their april update there would be no debate and everyone would be happy, and there would be extra features too

I was under the impression they are already adding a 1.75-2MB "buffer" in April. Are you now advocating for the need of 4MB instead? Should we fork Classic and increase maxBlockSize to 4MB now?

[RustyNoman]

It would be nice to fork in some fancy features but at this point i just want to get this block debate out of the way and onto bigger blocks or whatever it is thats decided. From their on in maybe we could start worrying about better features.

We can do a very simple hard fork. No other new features apart from the 2MB block size. We can plan the hardfork date three month in advance to give people enough warning.

[alani123]

Unlikely, bitcoin classic is looking to actually take away useful features. Like sidechains, segwit and RBF. All those projects with great potential, bitcoin classic is one fork with vested interest into making them fail.

How exactly are they taking the segwit and sidechains away?

Would invest in building a multi billion dollar venture on a distributed ledger that would go through schisms every time there was a debate and some propaganda?

[franky1]

if core (blockstR3am) just added in the 2mb buffer with their april update there would be no debate and everyone would be happy, and there would be extra features too

I was under the impression they are already adding a 1.75-2MB "buffer" in April. Are you now advocating for the need of 4MB instead? Should we fork Classic and increase maxBlockSize to 4MB now?

no.. thats a misdirect.. they are switchin data around into 2 blocks. the main block and the witness block.. but.. here is the kicker.. all the other features of blockstream will add more data to the main block that the moving of signatures meant to have saved.

for instance a signature is less data saved than the 250bytes of data that a payment code would have in the main blockchain.
so the average transactions size of a 2009-2015 tx would be less data. than a 2016 segwit confidential transaction.

take for instance a very laymans tx (dont knit pick. its for simple demo purposes and not real data lengths or real data)

{TXID:0123456790ABCDEF
IN[TXID:ABCDEF0123456790,sig:a0b1c2d345e67f89]
OUT[address:1Ar4nd0m4ddr3ss,value:100000000]
}
lets say this very layman tx is 116 characters

with segwit it would be
mainblock
{TXID:0123456790ABCDEF
IN[TXID:ABCDEF0123456790]
OUT[address:1Ar4nd0m4ddr3ss,value:100000000]
}
now 95 characters(blockstreamers utopian promise of less data.. but).. PLUS
witness
{TXID:0123456790ABCDEF
0:a0b1c2d345e67f89
}
44 characters. (totalling 139)as the witness merkle needs the TXID and an index to be able to refer back to the mainblock tx and the mainblock tx needs to refer to the witness merkle

then ontop.. lets start thinking about the new features, eg confidential transactions would turn a segwit FULL ARCHIVAL DATA transaction into
{TXID:0123456790ABCDEF
IN[TXID:ABCDEF0123456790]
OUT[address:1Ar4nd0m4ddr3ss,value:PC1234567890987654321abcdeffedcba]
}
{TXID:0123456790ABCDEF
0:a0b1c2d345e67f89
}

which in total would be a laymans 119 in the mainblock vs the old 116 in the main block (segwit+confidential fulldata combined=163)

so thats why core needs to set the mainblock limit to 2000000 ASWELL as all their little features.. so that its true capacity increase aswell as features increase.

[pawel7777]

Unlikely, bitcoin classic is looking to actually take away useful features. Like sidechains, segwit and RBF. All those projects with great potential, bitcoin classic is one fork with vested interest into making them fail.

How exactly are they taking the segwit and sidechains away?

Would invest in building a multi billion dollar venture on a distributed ledger that would go through schisms every time there was a debate and some propaganda?

Is that suppose to be an answer to my question, or are you replying to something else?

[BitUsher]

no.. thats a misdirect.. they are switchin data around into 2 blocks. the main block and the witness block.. but.. here is the kicker.. all the other features of blockstream will add more data to the main block that the moving of signatures meant to have saved.

for instance a signature is less data saved than the 250bytes of data that a payment code would have in the main blockchain.
so the average transactions size of a 2009-2015 tx would be less data. than a 2016 segwit confidential transaction.

so thats why core needs to set the mainblock limit to 2000000 ASWELL as all their little features.. so that its true capacity increase aswell as features increase

Are you sure you have done the math correctly ? Core's new "features" requires an additional 2,000,000 bytes of data , or will you be happy if they simply match an effective 2MB of capacity? What about the fact that Segwit allows for signature pruning?

[alani123]

Unlikely, bitcoin classic is looking to actually take away useful features. Like sidechains, segwit and RBF. All those projects with great potential, bitcoin classic is one fork with vested interest into making them fail.

How exactly are they taking the segwit and sidechains away?

Would invest in building a multi billion dollar venture on a distributed ledger that would go through schisms every time there was a debate and some propaganda?

Is that suppose to be an answer to my question, or are you replying to something else?

Rhetorical question but here's a more on-point answer. Gavin included pretty heavy anti-sidecdhain propaganda in promotion of XT. Bashing blockstream was one of the main points in the promotional campaign and still is popular among supporters of bitcoin classic. Handing him control over bitcoin updates would likely make large investors and ventures uninterested in building on bitcoin all together. As of segwit, here's a detailed answer.

[richardsNY]

We already have all the features in Bitcoin that we need. I really can't think of something useful that I want to see gets included in Bitcoin. Maybe faster confirmation times, but this will most likely never be implemented into Bitcoin.

[Ayle56]

I can't remember whee I read it, but somebody said altcoins provide testing platforms for new experimental features, and if those features are proven to work in an altcoin they could then be considered for inclusion into Bitcoin. However, I can't think of any altcoin features that have been included in Bitcoin yet. 

[franky1]

no.. thats a misdirect.. they are switchin data around into 2 blocks. the main block and the witness block.. but.. here is the kicker.. all the other features of blockstream will add more data to the main block that the moving of signatures meant to have saved.

for instance a signature is less data saved than the 250bytes of data that a payment code would have in the main blockchain.
so the average transactions size of a 2009-2015 tx would be less data. than a 2016 segwit confidential transaction.

so thats why core needs to set the mainblock limit to 2000000 ASWELL as all their little features.. so that its true capacity increase aswell as features increase

Are you sure you have done the math correctly ? Core's new "features" requires an additional 2,000,000 bytes of data , or will you be happy if they simply match an effective 2MB of capacity? What about the fact that Segwit allows for signature pruning?

seriously you are soo far off the path that i think your just trolling..

what i mean to say is,  if before segwit the average block was 2000 tx.. for a very short time.. 1mbsegwit will maybe get 3000 tx(and about 1.5mb full archival databloat).. but then when features like confidential transactions become a thing. the mainblock will have extra data in it that only 1500 transaction would fit. not the old 2000 anymore. and not the proposed 3000 blockstream dream up.

so if the average today is 2000. and the community want more capacity AND features.. a 2mb segwit would allow 3000 transactions with all the features (and about 3mb full archival databloat), instead of just 2000 without segwit or block increase

(numbers are laymen examples picked out of my head just to convey a scenario, so dont knitpick that they are not exact numbers)

[franky1]

We already have all the features in Bitcoin that we need. I really can't think of something useful that I want to see gets included in Bitcoin. Maybe faster confirmation times, but this will most likely never be implemented into Bitcoin.

only possible way to mess with confirm times is maybe to set todays 25btc 10 minute(average) reward.. as a 2.5btc 1minute(average) reward and make the difficulty easier to make blocks on an average of 1 minute. by setting the difficulty adjuster to 20160 blocks per adjustment.

but messing with all of that can cause alot of bugs, issues and headaches.

i think the easier solution would be if 'malle' got fixed.miners stopped preferring certain transactions and just done "first in first out" instead. and RBF wasnt a thing. people could trust zero confirms a bit more (even with a few percent chance of orphans)

[OROBTC]

...

I would like to see:

1)  a transparent path forward so that rancorous debates re Block Size are foreseen (and hence avoided) in the future.

2)  a higher minimum fee for transactions (say, always BTC0.0002) to discourage "dust" and valueless clogging of the system.

3)  anyone proposing changes to better spell out reasons and consequences of stated changes.


Many of you already know I am not a programmer, so I likely miss technical issues, but the above I would like to see BEFORE any "useful features" that would likely introduce BUGS or other problems.

[BitUsher]

seriously you are soo far off the path that i think your just trolling..

what i mean to say is,  if before segwit the average block was 2000 tx.. for a very short time.. 1mbsegwit will maybe get 3000 tx(and about 1.5mb full archival databloat).. but then when features like confidential transactions become a thing. the mainblock will have extra data in it that only 1500 transaction would fit. not the old 2000 anymore. and not the proposed 3000 blockstream dream up.

so if the average today is 2000. and the community want more capacity AND features.. a 2mb segwit would allow 3000 transactions with all the features (and about 3mb full archival databloat), instead of just 2000 without segwit or block increase

(numbers are laymen examples picked out of my head just to convey a scenario, so dont knitpick that they are not exact numbers)

Your numbers are indeed incorrect, but rather than nitpick I will address your argument directly by suggesting you are including features which don't yet exist , and features which won't likely exist before other capacity improvements are made. CT is no where near being ready and the LN is further along in development. Additionally, CT won't exist until a HF is completed which will indeed raise maxBlockSize or add flexcap for capacity. If you have been following Core's development you would be aware that they want to increase blocksize directly and need to with a HF. They just want it done safely, with consensus, and with more changes than simply kicking the can over and over every time we need more capacity.

https://www.reddit.com/r/Bitcoin/comments/3zv7rt/confidential_transactions_might_kill_bitcoin/cypa1rs

Thus your statements again are misguided and misleading. I really don't care what implementation you support but please stop speculating with details that you are unaware of.

[datz]

Yes, Bitcoin 1.0 will hard fork into Bitcoin 2.0

[spartacusrex]

I want ALL the wonderful features they are working on.. LN, Side chains, CT, .. AND the scale / block size increase..

There's plenty more ways yet to prune the chain..

I hope we get there.

[Tavos]

It would be good if there were new features added, but I would be fine with just the block size increasing.

[franky1]

Thus your statements again are misguided and misleading. I really don't care what implementation you support but please stop speculating with details that you are unaware of.

im not in support of any of the band-camps. i just want REAL capacity increase. not the wishy washy bait and switch crap that core proposes.
and its not just CT that will cause data bloat.

there are other things that add extra bytes of data to the main chain transactions very soon after segwit gets implemented.

and if you see the roadmap they want all their features in BEFORE even thinking about upping the blocklimit cap.
if they are now changing the road map this week to up the limit, that that is them finally giving in to the community. which is a positive step, lets just hope the magic number of a new block limit they finally agree on is actually going to allow more REAL capacity, to cope with all their features

[BitUsher]

im not in support of any of the band-camps. i just want REAL capacity increase. not the wishy washy bait and switch crap that core proposes.
and its not just CT that will cause data bloat.

there are other things that add extra bytes of data to the main chain transactions very soon after segwit gets implemented.

and if you see the roadmap they want all their features in BEFORE even thinking about upping the blocklimit cap.
if they are now changing the road map this week to up the limit, that that is them finally giving in to the community. which is a positive step, lets just hope the magic number of a new block limit they finally agree on is actually going to allow more REAL capacity, to cope with all their features

Many of those "upgrades" and changes improve scalability and the numbers do matter so if you have some evidence that those features being implemented before LN or the next HF will use most of the capacity lets discuss those specifics. It may appear anal retentive , but this is a scenario where the specifics really do matter and we cannot simply gloss over the details.

 I understand your frustration and motivations for wanting a simple and quick capacity increase, but just keep in mind that most of the core developers are very large bitcoin holders and are ideologically motivated to make sure this project succeeds. In fact one of the principle scaling solutions - LN demands much larger block sizes.

[gmaxwell]

but then when features like confidential transactions become a thing. the mainblock will have extra data in it that only 1500 transaction would fit. not the old 2000 anymore. and

No, 99% additional data from CT is witness data (the range proofs). So what you're arguing would be true for "classic"'s 2MB direction, but not for Bitcoin Core's roadmap.

I suppose it's not an issue for classic: none of the people involved for it have ever proposed or implemented extensions like that to Bitcoin, none of them are likely to do so.

[franky1]

but then when features like confidential transactions become a thing. the mainblock will have extra data in it that only 1500 transaction would fit. not the old 2000 anymore. and

No, 99% additional data from CT is witness data (the range proofs). So what you're arguing would be true for "classic"'s 2MB direction, but not for Bitcoin Core's roadmap.

I suppose it's not an issue for classic: none of the people involved for it have ever proposed or implemented extensions like that to Bitcoin, none of them are likely to do so.

stop drumming on about the classic fanboys.. there are actually people that are not fanboys of any corporate brand, and just want real capacity increases.

rather then being helpful and telling the community which new features will add more data. you prefer to defend and argue the opposite and downplay the issues. and try to get the rest of the community to do the hard work

so how about be honest and tell the community what new features blockstream intend to release BEFORE they will do a REAL block limit rise. and how it would change the capacity.

yes segwit increases capacity INITIALLY, but be helpful and tell the community what will then add more data to the main block that can impact capacity that segwit meant to have increased.

like for instance how many new constants/variable/opcodes will be added to make sidechains work. how many extra bytes of data..

for instance OP_return was reduced in february 2014 to be 40bytes payload. (from memory so dont get pedantic if the date isnt accurate)
but for things like payment codes.. this is again raised to 80bytes.. so there is a 40 byte excess.

so please look at all the new features intended to be added and add up all the extra bytes that would suddenly be needed to perform these new features, compared to normal 2015 transactions(pre segwit)

EG show a demonstration of a basic one input to one output transaction(2015 pre segwit design).. and then show a transaction demo that represents how much extra data is needed in moving funds to a sidechain. and count the byte difference of the transactions.
do the same for payment codes.. (obviously highlighting the old OP_return 40 byte payload vs 80byte payload)

[johnyj]

Unlikely, bitcoin classic is looking to actually take away useful features. Like sidechains, segwit and RBF. All those projects with great potential, bitcoin classic is one fork with vested interest into making them fail.

Yes, there is such intention, the logic behind Classic is that it should stick to the original vision of Satoshi, to make it a p2p cash system instead of settlement system

So the scaling road map will be totally different if you consider the difference in direction behind two factions. Many features that is useful for one direction will be harmful for the other direction

Currently people still focus on major consensus rule and play it nicely, only the proposals benefiting both factions get applied. But since they are running towards different directions, sooner or later the diviation of opinion will become so large that no any major consensus can be reached over any change.

In that case OP's proposal to make the rules set permanently will be a better way, since that will save all the energy spent on these fruitless debate and everyone can focus on building extra features based on a fixed bitcoin architecture. That's also the thinking behind bitcoin unlimited, make one time change and don't touch it any more, so that all the future debate is unecessary, just like no one arguing over why gold can not be engineered to be much lighter

[johnyj]

This is IMHO Bitcoin's greatest strength and greatest weakness..

I, and many others I'm sure, feel that a stable protocol, immutable and set in stone, would be a very positive thing. v1.0 if you will. But being flexible also has it's upside.

Imagine if the structure of Gold, at an atomic level, kept changing ? This would not be cool.

People can not change the architecture of gold because so far they have not find a way to defeat the power of nature. But the barrier to change bitcoin architecture is hash power and user acceptance (most users just blindly upgrade so their opinion can be manipulated through propaganda), it is not that hard, but it is becoming harder and harder overtime because you can't easily change the inertia of 7 year's history

As a comparison, IPV6 is trying to replace IPV4, with better space and functions etc, but it took 18 years and still has not reached mainstream. As long as the old architecture works, any large change will be postponed

[spartacusrex]

I just hope we don't lose some of the truly great minds in this process.

Anyone who thinks removing gmaxwell from the 'able-to-commit' list was a good idea, is insane.

Thinking about it, I suppose this is what the Bitcoin Foundation, or whatever it was called, should have been dealing with. The protocol. And just that.  Deciding in a far more academic way what should be forked in, and what not to. Or whether to just leave it be altogether. Might have been a far easier pill to swallow.

Then everyone could be working on implementations of said protocol.

Bottom line, if Classic takes over, and we don't get CT, LN, Sidechains, SegWit etc etc .. that would be a very great shame.

[johnyj]

I just hope we don't lose some of the truly great minds in this process.

Anyone who thinks removing gmaxwell from the 'able-to-commit' list was a good idea, is insane.

Thinking about it, I suppose this is what the Bitcoin Foundation, or whatever it was called, should have been dealing with. The protocol. And just that.  Deciding in a far more academic way what should be forked in, and what not to. Or whether to just leave it be altogether. Might have been a far easier pill to swallow.

Then everyone could be working on implementations of said protocol.

Bottom line, if Classic takes over, and we don't get CT, LN, Sidechains, SegWit etc etc .. that would be a very great shame.

It will be ideal that you can have multiple universes in our real world. Thus forks can extend into different universes where everyone can select the universe that suits their idealism

In that case, we will have one world where Blockstream realize their high-tech dream of CT,LN,SC,SW, and in another world we will have Gavin using his 1GB blocks to send coffee transaction (not so unrealistic in decades given a bluray disk today is already more than 50G)