Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-03 📝 Original message:On 3/3/21 09:59, Anthony ...
📅 Original date posted:2021-03-03
📝 Original message:On 3/3/21 09:59, Anthony Towns wrote:
> I think it would be worthwhile to also update getblocktemplate so that
> miners signal uptake for something like three or four retarget periods
> prior to activation, without that signalling having any consensus-level
> effect. That should allow miners and businesses to adjust their
> expectations for how much hashpower might not be enforcing taproot rules
> when generating blocks -- potentially allowing miners to switch pools
> to one running an up to date node, pools to reduce the amount of time
> they spend mining on top of unvalidated headers, businesses to increase
> confirmation requirements or prepare for the possibility of an increase
> in invalid-block entries in their logs, etc.
I strongly agree. Ideally such signaling could be placed in the witness nonce, however this may require pool updates to
ensure pool server software is not assuming the 32-byte-0-nonce in wide use today. It is a worthwhile change in any
case, as it avoids the need to change pool software for future forks which place commitments in the nonce.
>> 2) The high node-level-adoption bar is one of the most critical goals, and
>> the one most currently in jeopardy in a BIP 8 approach.
>
> A couple of days ago I would have disagreed with this; but with Luke
> now strongly pushing against implementing lot=false, I can at least see
> your point...
Right. It may be the case that the minority group threatening to fork off onto a lot=true chain is not large enough to
give a second thought to. However, I'm not certain that its worth the risk, and, as Chris noted in his post this
morning, that approach is likely to include more drama.
Matt
📝 Original message:On 3/3/21 09:59, Anthony Towns wrote:
> I think it would be worthwhile to also update getblocktemplate so that
> miners signal uptake for something like three or four retarget periods
> prior to activation, without that signalling having any consensus-level
> effect. That should allow miners and businesses to adjust their
> expectations for how much hashpower might not be enforcing taproot rules
> when generating blocks -- potentially allowing miners to switch pools
> to one running an up to date node, pools to reduce the amount of time
> they spend mining on top of unvalidated headers, businesses to increase
> confirmation requirements or prepare for the possibility of an increase
> in invalid-block entries in their logs, etc.
I strongly agree. Ideally such signaling could be placed in the witness nonce, however this may require pool updates to
ensure pool server software is not assuming the 32-byte-0-nonce in wide use today. It is a worthwhile change in any
case, as it avoids the need to change pool software for future forks which place commitments in the nonce.
>> 2) The high node-level-adoption bar is one of the most critical goals, and
>> the one most currently in jeopardy in a BIP 8 approach.
>
> A couple of days ago I would have disagreed with this; but with Luke
> now strongly pushing against implementing lot=false, I can at least see
> your point...
Right. It may be the case that the minority group threatening to fork off onto a lot=true chain is not large enough to
give a second thought to. However, I'm not certain that its worth the risk, and, as Chris noted in his post this
morning, that approach is likely to include more drama.
Matt