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 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.

Yes, Bitcoin 1.0 will hard fork into Bitcoin 2.0

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

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.

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)

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

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)