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

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)

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.

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

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

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)

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.

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.

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

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

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.

Yes, Bitcoin 1.0 will hard fork into Bitcoin 2.0

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.

...

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.

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)

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)

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. 

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.

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.

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?

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