Pages:
Author

Topic: Will Bitcoin 'Hard Fork' in any useful features.. ? (Read 1224 times)

legendary
Activity: 1988
Merit: 1012
Beyond Imagination
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)

hero member
Activity: 718
Merit: 545
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.

legendary
Activity: 1988
Merit: 1012
Beyond Imagination
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
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
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
legendary
Activity: 4214
Merit: 4458
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)

staff
Activity: 4172
Merit: 8419
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.
legendary
Activity: 994
Merit: 1034
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.
legendary
Activity: 4214
Merit: 4458
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
full member
Activity: 140
Merit: 100
fastdice.com The Worlds Fastest Bitcoin Dice
It would be good if there were new features added, but I would be fine with just the block size increasing.
hero member
Activity: 718
Merit: 545
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.

sr. member
Activity: 295
Merit: 250
"to survive, we must live and fly"
Yes, Bitcoin 1.0 will hard fork into Bitcoin 2.0
legendary
Activity: 994
Merit: 1034
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.
legendary
Activity: 2912
Merit: 1852
...

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.
legendary
Activity: 4214
Merit: 4458
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)
legendary
Activity: 4214
Merit: 4458
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)
full member
Activity: 185
Merit: 100
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. 
legendary
Activity: 1232
Merit: 1091
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.
legendary
Activity: 2422
Merit: 1451
Leading Crypto Sports Betting & Casino Platform
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.
legendary
Activity: 994
Merit: 1034
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?
legendary
Activity: 2436
Merit: 1561
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?
Pages:
Jump to: