Responding between lines...

On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty <earonesty@gmail.com> wrote:
I personally appreciate the minimal changes, and often encourage development to be done this way - when it needs to be released quickly.  But does this need to be released quickly?


Segwit2mb is a last resort option. It does not need to be released quickly. Not at all. It just needs to be there in case no other option is chosen. I put tentative dates. We can move them.
 
- maybe the proposal should be renamed segwit 8mb and be discussed solely in terms of block weights.

The name does not matter much. The name means joining segwit with a 2Mb hard-fork. It's a grammatical name.

I also disagree with the idea that segwit2mb is a 8mb increase. As stated by in the Bitcon.org website [1] and backed up by scientific research, “a block filled with standard single-signature P2PKH transactions would be about 1.6MB and a block filled with 2-of-2 multisignature transactions would be about 2.0MB.”. As standard blocks are a combination between P2PKH, and 2-of-3 multisignatures, the actual average segwit block size will be close to 2.0MB.

Because Segwit2Mb doubles the maximum size of a block, the average block size for a block filed with average transactions is 4.0Mb.

[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-size

I can explain in a following e-mail why creating 8Mb blocks on purpose is generally is an irrational choice. And in the case where it could provide an economic benefit, adding parallel block validation to Core nullifies any adversary advantage.



> a high consensus hard fork is probably preferable to a low consensus soft fork, however there is nothing to indicate that segwit as it stands isnt already very high consensus except for a handful of pool operators protecting fee income.  
 
You and me may never know the reasons why these operators (or many many of other users) prefer to increase the block-size. I suppose it has to do high the high current transaction fees as compared to less than a year ago.
Anyway consensus can only be achieved if one understands the others may have reasons that do not match ours. 

Last, if this proposal is rejected by any side, then we'll definitively learn that side is not looking for any consensual resolution of the conflict.
 
- miners who currently object to segwit while pretending to like larger blocks will find some excuse to object to this too.


If they do, we'll get a lot of public, verifiable information from that fact. The cost to include this patch is low compared with the benefit it can bring and the information we can gather in case one of the sides rejects it.

However, I've received positive feedback from them until now.
 
- Given the challenges miners seem to have in flipping bits, I expect any fork that requires 95pct hash power to be vaporware.

Then we'll learn a lot about hard-forks, the limits of miner "voting" and the quorums we can expect.

Regards, 
Sergio.
 

On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The hard-fork is conditional to 95% of the hashing power has approved the segwit2mb soft-fork and the segwit soft-fork has been activated (which should occur 2016 blocks after its lock-in time)

Miners signalling they have upgraded by flipping a bit in the nVersion field has little relevance in a hard fork. If 100% of the hash power indicates they are running this proposal, but the nodes don't upgrade, what will happen?

For the record, I actually talk a lot about hard forks with various developers and am very interested in the research that Johnson in particular is pioneering. However, I have failed to understand your point about 95% miner signalling in relation to a hard fork, so I am eagerly awaiting your explanation.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev