PSA: Miners SHOULD NOT signal segwit if the community is not in widespread agre

[Luke-Jr]

Softforks require community support, and miners should evaluate this before signalling activation of them. If the community is significantly divided over whether a softfork should be deployed, miners should not signal support for the softfork until this contention is resolved.

Bitcoin Core and [segwit-capable] derivatives by default will indicate to segwit-enabled miners that they should signal for segwit support, but GBT's versionbits support (see BIP 9) is intentionally designed such that the miner may safely choose to ignore this recommendation and omit the signal - Core does not force anyone to signal segwit. Miners and pools should choose whether to signal for segwit (and other softforks or policy decisions) on their own, and not rely on defaults.

People using stratum mining pools should note that they may not be able to override the pools' decisions. If your pool does not disclose to you whether they signal for a given softfork, or they signal (or don't-signal) for one inappropriately, you should switch to a pool that matches your position.

Note that I am intentionally not saying whether or not segwit actually is controversial here. Personally, I support segwit and think the only rational objection is that the block size limit increase may be unsafe if we cannot trust miners to continue making 1 MB or smaller blocks for the near future. But the community should make their own decision (perhaps post your position here for miners to see), and miners should decide whether or not to signal based on the community's consent.

[franky1]

luke how about your promise for an implementation for 2mb base 4mb weight??[as an independent coder as i fear your employer and paid colleagues will refuse it in core]

your vote is unclear especially in concern of the word "blocksize increase" (you dont explain legacy blocksize vs base/weight)
Yes
Yes, but I would prefer it without a block size increase (prefer: 0.6mb txdata 0.4mb witness(1mb total weight) instead of 1mb base 4mb weight)
Yes, but I would prefer it without a "witness discount"
Yes, but I would prefer it as part of a hardfork(purely to have user nodes updated first)
Yes, but I would prefer it as part of a hardfork with base block increase(prefer: 2mb txdata 4mb weight instead of 1mb base 4mb weight)
No, I want to block it until after a hardfork(purely to have user nodes updated first)
No, I want to block it until after a hardfork with base block increase(prefer: 2mb txdata 4mb weight instead of 1mb base 4mb weight)
No, I want an alt-segwit without a block size increase(prefer: 0.6mb txdata 0.4mb witness(1mb total weight) instead of 1mb base 4mb weight)
No, I would prefer an alt-segwit without a "witness discount"
No, I would prefer segwit to be done as part of a hardfork
No, I will elaborate why in a comment


what should happen:
is node implementations are released first and the community upgrade. that way miners can see that a high percentage of nodes are running and able to FULLY validate and be ready to accept what miners will produce/allow later.
then when happy of a secure large % FULL validation by the network, the pools then and only then vote, due to being happy with the usernode adoption. and if pools reach the high percentage, then it activates. knowing the network is high majority fully validating

what should not happen:
pools flag, pools activate... and then users nodes upgrade later. (facepalm to that concept) with just 2week check and 2 week grace (double facepalm)
its especially bad when core are holding back an implementation so that users cant even use segwit wallet/transactions. and wont be available until after activation(i understand why its done, but still shoddy).. it seems like a rash rush to activate it before securing the network (thousands of nodes) to be able to utilise it.

again what should happen. and also what will make everyone happy
phase zero:
all the diverse implementations all supporting the feature, including a core version that offers dynamic blocksize (allowing 2mb base 4mb weight so everyone is happy including segwit fans) where OPTIONS within the node offer dynamic changeable settings (there is no reason for devs to spoon feed settings when users can/should change settings to then let consensus decide that everyone wants it, not the devs)

phase one: users(full nodes)
a year is given for getting to 95%, when/if it is at 95% at any time within the year..(a)
a month is then given to ensure it stays at 95%, incase of temporary fluke/sybil attack etc(b)
and then a months grace(c)

obviously if it does reach 95%(a) that is about 270 of 5400 not upgraded. probably less than 270 at(b) and even less at (c)
obviously if it never reaches 95%(a), it doesnt move to (b) or (c) or phase 2

phase two:pools(full nodes)
mining pools flag their desire(happy that phase one wasnt a fluke/sybil, etc).
again no timescale to reach 95% for pools. but at 95%(d)
a month is given to ensure it stays at 95%(e)
and a months grace(f)
obviously if it never reaches 95%(d), it never activates, no drama, no fuss

please note:
the time between (b) and (f), ends up being many many months. meaning alot of time is given for the ~270 lingering user nodes to well surpass the 95%
thus only making the orphan risk well under 5%.

[Luke-Jr]

luke how about your promise for an implementation for 2mb base 4mb weight??

It is still a work in progress. See my hardfork2016 branch on github.

[as an independent coder as i fear your employer and paid colleagues will refuse it in core]

I do not have an employer by choice. It certainly should be refused in Core unless the community comes to agreement to deploy it first - same as with any hardfork proposal.

your vote is unclear especially in concern of the word "blocksize increase" (you dont explain legacy blocksize vs base/weight)

There is no such thing as "legacy blocksize". Witness data has always been included in the block size, and there is no reason for that to change with segwit.

what should happen:
is node implementations are released first and the community upgrade. that way miners can see that a high percentage of nodes are running and able to FULLY validate and be ready to accept what miners will produce/allow later.
then when happy of a secure large % FULL validation by the network, the pools then and only then vote, due to being happy with the usernode adoption. and if pools reach the high percentage, then it activates. knowing the network is high majority fully validating

The problem is that nodes are anonymous and cannot be detected. We could add some system where they publish their agreement, but it would only work for new nodes, not the old ones which are just as important. (Note that listening nodes are not all nodes.)

phase one: users(full nodes)
a year is given for getting to 95%, when/if it is at 95% at any time within the year..(a)
a month is then given to ensure it stays at 95%, incase of temporary fluke/sybil attack etc(b)
and then a months grace(c)

95% is not consensus sufficient for a hardfork. The remaining 5% would continue Bitcoin and the 95% would simply leave into an altcoin.

please note:
the time between (b) and (f), ends up being many many months. meaning alot of time is given for the ~270 lingering user nodes to well surpass the 95%
thus only making the orphan risk well under 5%.

That's assuming those lingering nodes are actually lingering, and not actively objecting. If they are objecting, then they cannot be forced to switch.

[franky1]

I do not have an employer by choice. It certainly should be refused in Core unless the community comes to agreement to deploy it first - same as with any hardfork proposal.

how can the community choose it, if the dev team refuse it. its like apple saying the community wont buy an apple8 phone so lets not make one, then by not making one, a month later apple says "see noone has bought an apple8"
(because it doesnt exist for the community to even get)
its called a self fulfilling prophecy.
how about try a different prophecy "if you build it, they will come" field of dreams
ofcourse if it doesnt reach 95% then nothing happens, no harm done.

your vote is unclear especially in concern of the word "blocksize increase" (you dont explain legacy blocksize vs base/weight)

There is no such thing as "legacy blocksize". Witness data has always been included in the block size, and there is no reason for that to change with segwit.

legacy in conversational terms means OLD.. legacy blocksize is a conversational term for old blocksize. not a branded buzzword that core likes to use

but thats where core love buzzwords. now the combined data they are calling "MAX_BLOCK_WEIGHT" not "blocksize", oops now its "MAX_BLOCK_SERIALIZED_SIZE" which is the same size as their other term "MAX_BLOCK_WEIGHT", yet they also have "MAX_BLOCK_BASE_SIZE" which is what the OLD term for the "blocksize" rule is about and core want to keep "MAX_BLOCK_BASE_SIZE" at 1mb
(for conversational purposes: 'base' and 'weight' are obvious abbreviations of cores new buzzwords)..

Code:

static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
/** The maximum allowed size for a block excluding witness data, in bytes (network rule) */
static const unsigned int MAX_BLOCK_BASE_SIZE = 1000000;

previously

Code:

-    if (cmpctblock.shorttxids.size() + cmpctblock.prefilledtxn.size() > MAX_BLOCK_SIZE / MIN_TRANSACTION_SIZE)
+    if (cmpctblock.shorttxids.size() + cmpctblock.prefilledtxn.size() > MAX_BLOCK_BASE_SIZE / MIN_TRANSACTION_BASE_SIZE)

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

Block size

Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:

Block weight is defined as Base size * 3 + Total size. (rationale[3])

as you can see they changed buzzwords "blocksize" for "basesize" then made a new metric outside of the blocksize for weight and serialised size
which can only be utilised if people no longer do legacy (old/traditional) transactions and instead do segwit transactions.
those sticking to legacy(old/traditional) implementations and legacy(old/traditional) transaction types see the MAX_BLOCK_BASE_SIZE as the "blocksize" and ignore "weight"s and "serialization" buzzwords. meaning the "blocksize" and "base"(MAX_BLOCK_BASE_SIZE) are the same.

which is where i saud you should clarified the difference of base and weight in your vote. but anyway thats just all buzzword core like to play around with, because in the "blocksize debate" we know cores 1mb base 4mb weight does not equal 4x capacity. so them pretending 4mb weight is a big improvement, is not. its just switching buzzwords to pretend its a massive improvement. yet reality is estimated at 1.8x not 4x even if the "weight" is 4x

what should happen:
node implementations are released first and the community upgrade. that way miners can see that a high percentage of nodes are running and able to FULLY validate and be ready to accept what miners will produce/allow later.
then when happy of a secure large % FULL validation by the network, the pools then and only then vote, due to being happy with the usernode adoption. and if pools reach the high percentage, then it activates. knowing the network is high majority fully validating

The problem is that nodes are anonymous and cannot be detected. We could add some system where they publish their agreement, but it would only work for new nodes, not the old ones which are just as important. (Note that listening nodes are not all nodes.)

and not all pools are detectable either, only those solving a block are detectable. so over a month period. its not showing all pools votes. only those doing enough work to get a block solved.

much like https://bitnodes.21.co/, doesnt show all nodes, but the ones with enough incoming and outgoing to be seen by the network.
same goes for pools. there may be 25 pools and 100 people (foolishly)solo mining. but they are not seen. only the 18ish that show they are a healthy part of the network are seen

phase one: users(full nodes)
a year is given for getting to 95%, when/if it is at 95% at any time within the year..(a)
a month is then given to ensure it stays at 95%, incase of temporary fluke/sybil attack etc(b)
and then a months grace(c)

95% is not consensus sufficient for a hardfork. The remaining 5% would continue Bitcoin and the 95% would simply leave into an altcoin.

seriously wrong assumption
for instance BU has the rules right now for a differing blocksize.. yet is not forking off to an altcoin.!!
its still part of the network!! same for all other diverse nodes too
at this point even a 2mb base 4mb weight is the "maximum" meaning 1mb base is still acceptable to the new rules.
0kb ->4mb weight still allows for 1mb to be acceptable
there is no altcoin doomsday here!!

ethereum did not split simple due to rule change. they split due to --oppose-dao-flag option that activated the ban list(aded intentional split code) to not be part of the consensus(majority) ethereum network
no one is proposing to intentionally split the network with banIP/useragent code. they are proposing using consensus
to upgrade the network as a single chain..
no altcoin!
ill explain more in a minute

please note:
the time between (b) and (f), ends up being many many months. meaning alot of time is given for the ~270 lingering user nodes to well surpass the 95%
thus only making the orphan risk well under 5%.

That's assuming those lingering nodes are actually lingering, and not actively objecting. If they are objecting, then they cannot be forced to switch.

at 95% of nodes the chain FOLLOWS the majority.. not the minority. all that happens is the orphan risk changes from about 1%-2% (standard at the moment) to being 5% risk due to the minority.

the 5% minority ends up receiving blocks it rejects and either powers off because it cant stay in sync with the majority or they upgrade to join the majority.
the only way it "altcoins" is intentionally banIP/ban useragent of the majority opposition and then forms their own small network and sync to their own lower blockheight that is not interrupted by the 95%.

if the minority do oppose the change and add some code to slit off and form their own micro network. then they become the altcoin! because they are not with the majority.

i think you have been having too many propaganda tuition seminars by your employer and colleagues and not done much independent thinking of rational and realistic outcomes