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

[David Rabahy]

Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

[1714795079]

1714795079

[1714795079]

1714795079

[Carlton Banks]

Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

Yes they could, and yes, they would be rejected by clients compatible with Bitcoin Core's code.

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?

I think Flag day would be November 15th 2017 according to BIP 148, IIRC.

Not sure about those actual details, but I would imagine so, yes.

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)?

What you could do is enable witness pruning before you downgraded (I believe witness pruning is implemented in 13.1). That would safely sidestep such issues (and you could continue to use 13.1 or greater if you so chose). Note that you're technically not a full node after that, although witness data in all the blocks before the Segwit flag day wouldn't be pruned.

[franky1]

Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

the funny thing is that segwit meant to be soooo backward compatible that it would be accepted.
yet they need deadlines.
makes me wonder why...

i also said to gmaxwell to instill some confidence by asking their partner BTCC to go make a segwit block and include a segwit tx within that block and see if it is acceptable.. worse case is its rejected and even worse case they could use part of thier $70m to pay BTCC $12.5k to say sorry for wasting their time for making a orphan

if it doesnt orphan. then it would give confidence.... strange thing is they are not explaining why such a backward compatible block actually needs a deadline before being made.

but very funny non the last seeing all the promise become empty

[Lauda]

From year+ now this limit is NOT working as protection at all. There is just "too many" transactions to fit in 1MB.

This isn't a valid argument to increase the block size limit. If this was an valid argument, then anyone could push a scenario where it is required to keep raising the block size an *infinite* number of times by creating "too many" transactions (at each upper limit).

Block transmission is now done by header/gentx/tx list, not as full block data.

Whilst this is a very nice improvement, it has zero relevance. If you have a node with open ports, you will be straining yourself with upload bandwidth not download

Block pruning allow run full node on about 20GB HDD space.

Firstly, a client which has pruning enabled is not a full node, it is a pruned node. Secondly, it requires ~4-5 GB of space (not 20 GB). You don't even know what you're talking about and you are making demands!

1MBit connection allow to transfer over 100tx/s (1:4 in/out), block can be like 15MB on that connection.

Which leaves us with.. 0 seconds for validation? You really have no idea how Bitcoin works.

There is a technological problem to make bigger blocks.

FTFY.

When SegWit start it probably will take another year to popularize SW transactions, LN and/or sidechains.

Speculation on SegWit. The popularity of Segwit has nothing to do with the popularity of the latter two.

Think, how it is possible that "better" idea as SegWit have LESS support in miners than "worse" BU? Why over 30% is not decided?

Simple: Someone or a certain group of *someones* has been lobbying miners and feeding them FUD how LN would steal all of their fees and how Segwit == LN. Both claims are absurdly false.

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.

No, that is most certainly not the case. From what I understand Ver, he wants to *fork away* from the Core contributors are any cost.

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?

No. There will not be three currencies. If the BTU folk fork away, it is highly likely that Segwit would be activated very soon after that (be it with BIP9 signaling or UASF). In the case of two currencies, the latter, also known as BTU, would be an altcoin.

[rav3n_pl]

(...)
You don't even know what you're talking about and you are making demands!
(...)
You really have no idea how Bitcoin works.
(...)

You take your point. Even two. Very mature.

[AngryDwarf]

1MBit connection allow to transfer over 100tx/s (1:4 in/out), block can be like 15MB on that connection.

Which leaves us with.. 0 seconds for validation? You really have no idea how Bitcoin works.

Validation requires network bandwidth? Holy cuckoo.

[Lauda]

(...)
You don't even know what you're talking about and you are making demands!
(...)
You really have no idea how Bitcoin works.
(...)

You take your point. Even two. Very mature.

Cry somewhere else. Fact is, you clearly have a very impaired understanding of Bitcoin and the relevant scaling debate. I'll call you out every time you make demands with psuedo-science.

Validation requires network bandwidth? Holy cuckoo.

What are you on about? Good luck propagating 15 MB blocks through the network and validating them on time.

[hv_]

(...)
You don't even know what you're talking about and you are making demands!
(...)
You really have no idea how Bitcoin works.
(...)

You take your point. Even two. Very mature.

Cry somewhere else. Fact is, you clearly have a very impaired understanding of Bitcoin and the relevant scaling debate. I'll call you out every time you make demands with psuedo-science.

Validation requires network bandwidth? Holy cuckoo.

What are you on about? Good luck propagating 15 MB blocks through the network and validating them on time.

I really wonder how one still can think that shouting people down might lead to sth good here.

No

All means trying to 'control' bitcoin, people, forum, ... Is just NOT bitcoin. Try find some people you can sign off you ideas and feel free.

Im sure you ll get disrupted the next minute because you did no matter its good or bad.

Open your mind and let the big things happen. You are not alone.

[Searing]

Well looks like from the bitcoin core point of view 30% of this kinda hostile take over bitcoin FUD is to be expected and they are simply going to
ignore it...ie if you don't have the chops to take over from bitcoin core...we are gonna ignore your efforts or concerns....status quo

http://www.coindesk.com/bitcoin-on-developers-arent-worried-about-fork/

Oh well, I keep saying I want 'cheap coins' so I should shut up or put up

[rav3n_pl]

Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

If 148 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.

edit: fixed BIP number, its 148 not 168...  https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

[Searing]

Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP168 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 168 activate in November?

If 168 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.

So is it likely bitcoin core will pass the above (ie done deal) or will there be controversy within bitcoin core itself on pulling the trigger on such?

(likely not..just not keeping up with all this ..figured quicker to just ask for views)

edit: by pass I mean of course bitcoin core puts it out there as something to activate by the users as you state above.

[hv_]

Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

If 148 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.

edit: fixed BIP number, its 148 not 168...  https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?

[rav3n_pl]

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality

[Lauda]

BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

More like: http://luke.dashjr.org/programs/bitcoin/files/charts/software.html
90% Core
2.5% BU
7.5% others.

If 148 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

You still don't get it, do you? There is no emergent need for a capacity increase HF. As soon as the spam stopped, the mempool is nearly empty. https://tradeblock.com/bitcoin

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.

I am most certain that you don't know how Bitcoin works. You still verify the whole block, not just a partial part of it. You can effectively DoS the network with 2 MB blocks. 15 MB is absurdly large, unsafe,  unneeded and would take down a high percent of our node count.

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?

How many % are running BTU/altcoin because Ver or his employees were spreading propaganda and/or were lobbying ViaBTC/TopBTC/Jihan?

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality

It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.

[dinofelis]

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality

Indeed.  You cannot enforce a soft fork with non-mining nodes.  You can just bring them to a standstill.

At that point, the only option for the user is to downgrade to an earlier version of core, or to download a bitcoin protocol compatible piece of software somewhere else.

[Carlton Banks]

I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

No it isn't

Schnorr signatures confer scaling on-chain

Transaction encoding improvements confer scaling on-chain



Stop spreading falsehoods, these facts are readily avaliable

[rav3n_pl]

I am most certain that you don't know how Bitcoin works. You still verify the whole block, not just a partial part of it. You can effectively DoS the network with 2 MB blocks. 15 MB is absurdly large, unsafe,  unneeded and would take down a high percent of our node count.
(...)
It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.

1. Looks like you really need catch up code. Node is verifying transaction only once - when arrived.
2. Not a single line about enforcing activation of SegWit in 0.14, so how 0.13.1 is supporting BIP148 (reminder: BIP148 was published 12. march)?

I don`t know how bitcoin works, so I never write a single line of bitcoin-related software, I never contributed to Core code, I never make public lecture about Bitcoin... I`m not a moderator of national Bitcoin forum in Poland either.

[rav3n_pl]

I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

No it isn't

Schnorr signatures confer scaling on-chain

Transaction encoding improvements confer scaling on-chain



Stop spreading falsehoods, these facts are readily avaliable

Link to math please, how much data will take 10`000tps in Bitcoin blockchain using this stuff?
Or how much tps you want to scale to?

[Carlton Banks]

Link to math please, how much data will take 10`000tps in Bitcoin blockchain using this stuff?
Or how much tps you want to scale to?

Transaction encoding improvements: http://people.xiph.org/~greg/compacted_txn.txt

Schnorr: https://bitcointalk.org/index.php?topic=1377298.msg14011669#msg14011669


On-chain scaling is possible. Blocksizes are not scalable.

[ANHEQIAO]

I am not technically qualified to comment in detail.  But I am very much for compromise and 2MB with Segwit is an excellent place to start.  Let's see who is serious about moving btc ahead.