Not responding to anyone in particular, but it strikes me that one can
think about the case where a small minority (let's say H = 20%?) of nodes
select the opposite of what Core releases (LOT=false, LOT=true). I'm
ignoring the case where a critical bug is discovered in Taproot for reasons
I could e
Just to clarify, I'm not saying bitcoin core should maintain the
"oppose proposal" part of the software. presumably people opposing the
change don't want much of the recent software changes anyway.
But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
I don't expect anyone to want
Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
Som
On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote:
> I think it should be clear that a UASF-style command line option to allow
> consensus rule changes in the node in the short term, immediately before a
> fork
> carries some risk of a fork, even if I agree it may not persist over month
> On Feb 22, 2021, at 05:16, Anthony Towns wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
>> More importantly, nodes on both sides of the fork need
On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote:
> A node feeding you invalid headers (used to be) cause for a ban [...]
Headers that are invalid due to MUST_SIGNAL rules are marked as
BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're
doing headers-first relay
42 pieces waiting for me and this 1 interests me most, yet not a single comment to it. Must just be me, I guess. Anyway, please keep plugging away, Chris. And thanks.
Sent: Wednesday, February 17, 2021 at 4:27 PM
From: "Chris Belcher via bitcoin-dev"
To: bitcoin-dev@lists.linuxfoundation.org
Hello Everyone,
The below comment by Matt about different implementations and their opinion on
`lockinontimeout` is from 18 Feb 2021 communication:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html
> If the eventual outcome is that different implementations (that
