[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[rav3n_pl]

There is a pool on biggest Polish bitcoin forum:
https://forum.bitcoin.pl/viewtopic.php?f=2&t=20768

Q: "What road of Bitcoin development you support?"
User can pick up to two options from:
- SegWit
- Bitcoin Unlimited
- one time to 2MB
- one time to 4MB or more
- adaptive block size
- reduce to 0.5MB
- leave 1MB





I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.

[1714768771]

1714768771

[1714768771]

1714768771

[1714768771]

1714768771

[1714768771]

1714768771

[1714768771]

1714768771

[Carlton Banks]

User can pick up to two options from:
- SegWit
- Bitcoin Unlimited
- one time to 2MB
- one time to 4MB or more
- adaptive block size
- reduce to 0.5MB
- leave 1MB





I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.

I don't think Core will do that.


rav3n, why do you refuse to understand that blocksize is a very dangerous value to change? The world is becoming a more dangerous place every day, we can't rely on the internet growing the same way it did 1990-2015. It might very plausibly become much slower and more restricted, that is a very serious risk, and not just to Bitcoin.

We can achieve on-chain scaling by making the transactions smaller, or other more intelligent ways. Blocksize changes are stupid when those things do more with less blockspace.

[Lauda]

-snip-
I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.

This doesn't make sense; Bitcoin is not a democracy and random individuals with no demonstrably relevant knowledge should not be deciding on technological solutions/limitations. How are certain groups unable of understanding something this simple?

I don't think Core will do that.

There isn't a very good proposal for an adaptive block size at the moment (IMO).

rav3n, why do you refuse to understand that blocksize is a very dangerous value to change? The world is becoming a more dangerous place every day, we can't rely on the internet growing the same way it did 1990-2015. It might very plausibly become much slower and more restricted, that is a very serious risk, and not just to Bitcoin.

Whilst I do not like doomsday scenarios, your argument is not without merit. As can be observed, NATO moving forces to Estonia & surrounding area to "combat Russian aggression", China warning US to respect airspace, etc. Things may not be as good tomorrow as they are today.

[dinofelis]

-snip-
I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.

This doesn't make sense; Bitcoin is not a democracy and random individuals with no demonstrably relevant knowledge should not be deciding on technological solutions/limitations. How are certain groups unable of understanding something this simple?

The Enlightened King.

https://en.wikipedia.org/wiki/Republic_(Plato)

[Carlton Banks]

rav3n, why do you refuse to understand that blocksize is a very dangerous value to change? The world is becoming a more dangerous place every day, we can't rely on the internet growing the same way it did 1990-2015. It might very plausibly become much slower and more restricted, that is a very serious risk, and not just to Bitcoin.

Whilst I do not like doomsday scenarios, your argument is not without merit. As can be observed, NATO moving forces to Estonia & surrounding area to "combat Russian aggression", China warning US to respect airspace, etc. Things may not be as good tomorrow as they are today.

Lauda, I'm breathing a sigh of relief over here. You've always been reasonable IMO, and I'm glad you're seeing sense in what I'm saying.


The truth is: who knows what might happen? It's not at all impossible that geopolitical tensions, and the myriad of threats they pose to the smooth running of and accessibility to the internet, could calm right down tomorrow to negligible levels. But if we really want to keep this network alive, we should be as careful as possible, and that means planning for all plausible possibilities.

Bitcoin might be a big part of what solves geopolitical tensions. It can't do that on it's own, more innovations will be needed. But a free & sound money system for all would be the bedrock or the foundation to keeping the world turning in a co-operative and healthy way, the only way to defeat the trends that take us in the opposite direction.

[rav3n_pl]

Friendly reminder: Satoshi introduced 1MB limit ONLY as PROTECTION form spam attack on network. It was like 10-100x higher than block sizes.
From year+ now this limit is NOT working as protection at all. There is just "too many" transactions to fit in 1MB.
Block transmission is now done by header/gentx/tx list, not as full block data.
Block pruning allow run full node on about 20GB HDD space.
1MBit connection allow to transfer over 100tx/s (1:4 in/out), block can be like 15MB on that connection.
There is NO technological problem to make bigger blocks.
When SegWit start it probably will take another year to popularize SW transactions, LN and/or sidechains.
Think, how it is possible that "better" idea as SegWit have LESS support in miners than "worse" BU? Why over 30% is not decided?
IF Core merge ANY code that raise block limit along witch SegWit, it will get 95% in no time. If not - I (and not only I) see no chance to activate SegWit.
We just run out of time...

[franky1]

We can achieve on-chain scaling by making the transactions smaller, or other more intelligent ways. Blocksize changes are stupid when those things do more with less blockspace.

and once segwit activates with the hope of getting all them 46m UTXO over to segwit keys to get to the possible tx count(without spam attacking to reduce) of ~4500tx/block... then what

you cant resegwit a segwit to double up again..

oh and the 1mb limit was about limiting bloat

but think rationally

segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.

(eg if the 'internet cant cope with 2mb' then the internet cant cope with 2mb)

pretending segwit helps FULL nodes by keeping a 1mb block limit. is not the truth a FULL node is handling 2.1mb
the 1mb is for old now lite clients that might aswell just be SPV clients. segwit isnt helping FULL nodes

[rav3n_pl]

segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.

Exactly.
https://testnet.smartbit.com.au/block/00000000000016a805a7c5d27c3cc0ecb6d51372e15919dfb49d24bd56ae0a8b
Is this block 40kB or 3,7MB? It take 40kB of storage/transmission or 3,7MB storage/transmission?

[Lauda]

segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.

Exactly.
https://testnet.smartbit.com.au/block/00000000000016a805a7c5d27c3cc0ecb6d51372e15919dfb49d24bd56ae0a8b
Is this block 40kB or 3,7MB? It take 40kB of storage/transmission or 3,7MB storage/transmission?

3.7 MB for full nodes. This is why Segwit may also be *too much* in the worst case scenarios. Your understanding is very flawed, therefore saying 'exactly' has zero meaning. I'll address your previous post & others soon.

[Carlton Banks]

Friendly reminder: Satoshi introduced 1MB limit ONLY as PROTECTION form spam attack on network. It was like 10-100x higher than block sizes.
From year+ now this limit is NOT working as protection at all. There is just "too many" transactions to fit in 1MB.

I have a friendly reminder for you.


Are bigger blocks the only way to increase on-chain capacity? No

Are bigger blocks the most dangerous way to increase on-chain capacity? Yes


Would improving the efficiency of how we use the blocksize that already exists be safe, add more capacity and actually improve Bitcoin's scaling? Yes


@rav3n: Why don't want you want safe capacity increases? Why don't you want true on-chain scaling?

[rav3n_pl]

Are bigger blocks the only way to increase on-chain capacity? No

But fastest to achieve and easy to code/implement.

Are bigger blocks the most dangerous way to increase on-chain capacity? Yes

No, can`t agree.

Would improving the efficiency of how we use the blocksize that already exists be safe, add more capacity and actually improve Bitcoin's scaling? Yes

These is no way to make it NOW. It should be done YEAR ago.

@rav3n: Why don't want you want safe capacity increases? Why don't you want true on-chain scaling?

It is impossible to make it. It is easy to calculate. On-chain scaling is a myth.

As for NOW upgrade to 2MB block will unload mempool in about week, bot we don`t know how long it last. This why I see adaptive block size as best option. Do once and forget. Like diff is working now.

[David Rabahy]

Which is the more desirable outcome; one currency or two?  If two then finish the war and split off already -- I know, I know, who gets to claim the legacy.  If one then a compromise (no matter how dangerous, etc.) will have to be entered; hurry.  Given human nature (righteousness) I have lost confidence in this approach.

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

There really is only one legacy, right?  We can't have two currencies both considered to be the proper descendent of the original Bitcoin, right?

[dinofelis]

Which is the more desirable outcome; one currency or two?  If two then finish the war and split off already -- I know, I know, who gets to claim the legacy.  If one then a compromise (no matter how dangerous, etc.) will have to be entered; hurry.  Given human nature (righteousness) I have lost confidence in this approach.

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

There really is only one legacy, right?  We can't have two currencies both considered to be the proper descendent of the original Bitcoin, right?

The point is that no split off is interested in not being bitcoin, because the brand name is what counts.  So we'll stick with JUST 1).

[Carlton Banks]

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

Likely moot, David.


The possibility of BU forking is increasingly unlikely. There is no community support really, despite loud voices screaming there is.

And one of the loudest voices on Bitcointalk (no, not me) has already begun to promote the next contentious hard fork attempt. It's very likely over, for now.

The point is that no split off is interested in not being bitcoin, because the brand name is what counts.  So we'll stick with JUST 1).

No, dino. It wouldn't matter if some successful hard fork coup wanted to use the Bitcoin name to "win", they can't win if their software design or code isn't up to standard. The name doesn't matter, the code does

[franky1]

one day
carlton: forks are bad

next day
carlton: just fork already

next day
carlton: forks are bad

just admit it.. dynamic implementations want consensus. its core that is going to pull the contentious split granade pin, no one else

dynamic implementations have made no threats of banning, changing algo or any deadlines. its just a free open choice and only activates if there is consensus.

if people really want to know what will happen if dynamic accepting pools were to rock the boat without consensus

2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

about 3 seconds of drama.. and its over and in the trash no harm no foul.

it wont matter if the block was 250byte over limit 1mb over limit or 3terrabyte over limit.. 3 seconds later.. its in the trash.

dynamics has no contentious crap. it only works by consensus.
only core using a lower than 95% bip9(yep they can do that), UASF or algo change will cause contentious split

P.S dont blame the pools for being the only vote power of segwit..... core choice that way by going soft.

[K128kevin2]

I don't think that core proponents are specifically against bigger blocks. Personally I am in favor of increasing the block size, but not in an incredibly stupid and irresponsible way like Bitcoin Unlimited, so I voted "Yes" in the poll.

[iamnotback]

As many have argued previously, it's merely kicking the can down the road.

There might not be any road if you don't kick forward faster:

Seen that way, I agree.  It is a toy system to play with.

One person's permutation toy, is another man's erector set.

Look at the massive level of innovation being unleashed on Ethereum (and Raiden is bringing payment channels to Ethereum very soon, well before Bitcoin will have LN):

https://bitcointalk.org/index.php?topic=1839699.0

Bitcoin is mucking around while Rome burns. Meanwhile Ethereum might just land on a killer app and leave Bitcoin in the dust. We'll see...

[David Rabahy]

Ok, suppose there's no bone thrown from Core to the other camp(s).  When the heck does SegWit activate?  And more importantly, how does it activate?  Hmm, the SegWit blocks will be accepted by "original" Bitcoin nodes because they look good.  So, a bunch of blocks end up on the chain with "extra" meaning.  Weird.

So, my full node (no matter what version I'm running) will see these SW blocks; will they be ok?  Hmm, do SW blocks come in two flavors?  One with the witness data and one without?  Which will my full node get?  If a block with witness data is delivered couldn't it be bigger than 1MB?

Btw, the non-Core camps could embrace SegWit (or is FlexTran their choice instead?) to compromise, right?

I'm truly sorry to be so thick about this but I truly want to try to understand.

[Carlton Banks]

Ok, suppose there's no bone thrown from Core to the other camp(s).  When the heck does SegWit activate?  And more importantly, how does it activate? 

Likely "Flag day" activation, it was accepted as a draft BIP recently (BIP 149 IIRC)

Hmm, the SegWit blocks will be accepted by "original" Bitcoin nodes because they look good.  So, a bunch of blocks end up on the chain with "extra" meaning.  Weird.

So, my full node (no matter what version I'm running) will see these SW blocks; will they be ok?  Hmm, do SW blocks come in two flavors?  One with the witness data and one without?  Which will my full node get?  If a block with witness data is delivered couldn't it be bigger than 1MB?

If you're using 0.13.1 equivalent client or higher, do nothing and you'll receive tx/witness original style blocks, and the new form of witness blocks.

If you're using 0.13.0 equivalent client or lower, you'll only receive the tx/witness original style blocks. Witness blocks are an add-on parallel block, older nodes will not receive the witness blocks, Segwit nodes won't relay witness blocks to "0.13.0 or less" nodes.

[David Rabahy]

Hmm, if I switch later (sometime after Flag Day = June 14, 2017) to a 0.13.1 or higher version then will my node catchup on all of the witness data blocks?

If I were to run a 0.13.1 or higher version and then downgrade (not sure why, just thinking out loud) then would my full node be ok or would it get confused by the witness data blocks?  Hmm, is downgrading a risky behavior?  Ah, or would downgrading safely involve starting from scratch (in terms of the whole blockchain)?