Add release notes for mining changes

sdaftuar commented at 8:08 pm on July 19, 2016: member

MarcoFalke added the label Docs and Output on Jul 19, 2016

in doc/release-notes.md: in 5972ac317b outdated

157+
158+With this change, the `-blockminsize` command line option has been removed.
159+
160+The command line option `-blockmaxsize` remains an option to specify the
161+maximum number of serialized bytes in a generated block; however, use of that
162+option is discouraged in favor of a a new command line option,

luke-jr commented at 8:28 pm on July 19, 2016:

No, it should not be discouraged (yet). Miners are encouraged to set blockmaxsize to 600000-750000 (the latter being the default).

luke-jr commented at 8:30 pm on July 19, 2016: member

This is missing any mention that miners should not produce blocks larger than 1 MB until the network is known to be capable of handling it. This is critical for miners to understand before BIP 141 activates.

sipa commented at 4:20 pm on July 20, 2016: member

@luke-jr Do you know of a way to formulate that in a measurable way? How are miners expected to judge “the network known to be capable of handling it”? Also, BIP 141 won’t activate in the release these notes are for.

luke-jr commented at 5:30 pm on July 20, 2016: member

When most miners are comfortable shutting off centralised relay networks and removing explicit outside addnode/connect to their nodes, that seems a reasonable indication that the network is ready.

sipa commented at 5:31 pm on July 20, 2016: member

I doubt they would ever be confortable doing that, even with only empty blocks.

luke-jr commented at 5:41 pm on July 20, 2016: member

Miners worked fine without centralised networks before. It’s not like it’s unreasonable.

sipa commented at 11:07 am on July 21, 2016: member

@luke-jr What I think the right criterion is, is whether the additional propagation delay from a larger block size would not affect (or only in a negligable amount) the economics of running things like relay network, SPV mining, … etc. And it may well be the case that compact blocks, better mempool logic, validation caching, … bring us closer to that, as they make relay times less dependent on the block size, and more on validation time (for which block weight is probably a better measure, if UTXO growth is taken into account).

I don’t think release notes are the place for this kind of discussion, though. Are you ok with just removing the language about discouraging/encouraging how people use these options, and simply state their existence?

Then we can see what effect the changes in the 0.13 release have on the network, and reassess whether any recommendations are needed in the first release that actually does a block size increase (through segwit)?

Add release notes for mining changes 52a4158f1f

sdaftuar force-pushed on Jul 21, 2016

sdaftuar commented at 2:12 pm on July 21, 2016: member

Updated to address comments.

I added a brief section on segwit to correct any confusion that somehow 0.13.0 supports segwit on mainnet. We should consider expanding that section to include more helpful notes on how to use 0.13.0 on testnet.

luke-jr commented at 2:52 pm on July 21, 2016: member

I’m fine with deferring any recommendations until segwit has been released for mainnet.

in doc/release-notes.md: in 52a4158f1f

191+is unaffected by this distinction (as BIP 141 activation is not supported on
192+mainnet in this release, see above), but in future releases and after BIP 141
193+activation, these calculations would be expected to differ.
194+
195+For optimal runtime performance, miners using this release should specify
196+`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.

luke-jr commented at 2:54 pm on July 21, 2016:

NACK.

sipa commented at 2:57 pm on July 21, 2016:

Can you suggest an alternative here? I think we should somehow convey that there is a performance penalty to using -blockmaxsize.

in doc/release-notes.md: in 52a4158f1f

195+For optimal runtime performance, miners using this release should specify
196+`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.
197+Additionally (or only) specifying `-blockmaxsize`, or relying on default
198+settings for both, may result in performance degradation, as the logic to
199+support `-blockmaxsize` performs additional computation to ensure that
200+constraint is met.  (Note that for mainnet, in this release, the equivalent

luke-jr commented at 2:56 pm on July 21, 2016:

Why is there performance degradation? That was not the case a few months ago, and we probably shouldn’t release if it’s noteworthy here.

sipa commented at 3:01 pm on July 21, 2016:

Because we sort based on fee per weight; checking whether the size constraint is met is an additional check that is not otherwise needed. @sdaftuar do you have any numbers?

Furthermore, widespread use of having two constraints (both size and weight) would necessitate a non-linear optimization algorithm for transaction selection, which is much harder. That on its turn would make fee estimation much more complicated as well, because wallets would need to know whether weight or size will be the constraining factor.

luke-jr commented at 3:06 pm on July 21, 2016:

So if ordering by fee-per-bytes is a performance issue, just order by fee-per-weight and close the block out when the size limit is hit. The overhead for that check should be negligible.

As this stands, it is de facto pushing miners toward a configuration that ought to be discouraged when segwit activates.

sdaftuar commented at 3:13 pm on July 21, 2016:

I don’t have any numbers, and as far as I know no one has attempted to measure this.

I don’t think it’s good for the network for some miners to discover a performance gain that is not disclosed, so I think it’s completely unacceptable to hide this fact.

Furthermore, we ought to change the defaults so that the optimal performance would happen by default. That’s outside the scope of this PR, but if there’s agreement that this should be done, I’d be happy to implement and open a separate pull. (The only reason I haven’t argued more strenuously for this is that I was satisfied with disclosure in the release notes.)

sipa commented at 3:13 pm on July 21, 2016:

So if ordering by fee-per-bytes is a performance issue, just order by fee-per-weight and close the block out when the size limit is hit.

That’s exactly what the current code does. But it still needs to actually compute the serialized size all the time to know when the limit is hit.

As this stands, it is de facto pushing miners toward a configuration that ought to be discouraged when segwit activates.

I disagree, sorry. Long-term, constraining block weight should be the only limit if we want predictable fees and incentive compatibility with UTXO set size growth. Actual serialized size of blocks on the network shouldn’t matter if it’s made independent from propagation times by better-than-naive block relay protocols.

luke-jr commented at 3:49 pm on July 21, 2016:

I’m talking about right now, not long-term. It is not acceptable for miners to be pushed off blockmaxsize <= 1M for the time being. If that means adding a cache of the real size of the transactions, that sounds like a proper avenue to go down.

laanwj commented at 3:53 pm on July 21, 2016: member

Thanks for writing this up @sdaftuar . Looks like a clear story, I’m just going to merge this, if anyone has suggested changes they can be made later.

laanwj merged this on Jul 21, 2016

laanwj closed this on Jul 21, 2016

laanwj referenced this in commit 76bc30beab on Jul 21, 2016

sipa commented at 3:56 pm on July 21, 2016: member

@luke-jr The default is still max 750 kB (incurring the likely small performance loss), and this release does not have any means of increasing above 1 MB. The release notes simply explain the code changes.

luke-jr commented at 4:02 pm on July 21, 2016: member

But the release notes as currently written give incentive to take blockmaxsize and convert to blockmaxweight which can potentially produce blocks up to 3 MB once segwit is deployed.

MarcoFalke locked this on Sep 8, 2021

Add release notes for mining changes #8374