I agree.
Thank you Erik for proposing it. It's a pretty good idea.
P.S. I wouldn't want a chain split of a low percentage of users though. The
minority will be at the mercy of massive PoW swings and the chain will lose
friends so it's not good for anyone. I recommend changing the final percenta
> Today users should start cooperating again to continue using the
> optimal strategy.
the "gradual" method of reducing the % of miners required for lock-in
as time goes on seems to encode this optimal strategy.
On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
wrote:
>
> On Tue, Feb
On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
wrote:
>
> If social consensus is what drives technical consensus and not the other way
> around it seems as if there cannot exist a valid (rational?) reason to oppose
> Taproot itself, and then by extension with the arguments la
On Mon, Feb 22, 2021 at 06:10:34PM -0800, Jeremy via bitcoin-dev wrote:
> 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
I don't think that's a good way to try to look at things -- number of
nodes h
Relative to your arguments, Keagan and Jeremy, and speaking in favor of
LOT=false, from my limited perspective:
> As Jeremy points out, the LOT=true possibility always exists here, and we
have multiple high profile people saying they will be running that
regardless of how things turn out. It seems
I wanted to follow up on what Jeremy and others are saying regards finding
consensus on LOT. I've seen a few other opinions saying that finding
consensus on the LOT value is far more important than what the LOT value
actually is. This makes sense because if 100% of economic activity is
running the
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
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
Hmm, indeed, I may have missed that you can skip the headers issues by not
persisting them, though there are other follow-on effects that are concerning
and I think still make my point valid.
A node feeding you invalid headers (used to be) cause for a ban - is that
information still persisted?
On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
> It was pointed out to me that this discussion is largely moot as the
> software complexity for Bitcoin Core to ship an option like this is likely
> not practical/what people would wish to see.
> Bitcoin Core does not ha
I think the most important thing is that the configuration setting is
advertised if somebody were to query the node for its capabilities.
Is this the case?
That way the default value isn't really the important thing.
There are longstanding and well-known nodes, for example. Community
support an
I don’t think “some vocal users are going to threaten to fork themselves off”
is good justification for technical decisions. It’s important to communicate
and for everyone to agree/understand that a failed BIP 8/9 activation, in the
scenario people are worried about, is not the end of the story
What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some
of the concerns of having to coordinate a UASF with an approaching deadline.
Cheers
Ariel Lorenzo-Luaces
On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev
wrote:
>Good morning list,
>
>> It was point
Good morning list,
> It was pointed out to me that this discussion is largely moot as the software
> complexity for Bitcoin Core to ship an
> option like this is likely not practical/what people would wish to see.
>
> Bitcoin Core does not have infrastructure to handle switching consensus rules
On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> (off-list)
>
> Your email client didn't thread correctly, so I'm not sure if you saw my
> responses to Adam's email, but note that there
That was not off-list; by the way, as a reminder
(off-list)
Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there
is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is
a nontrivial undertaking in Bitcoin Core fro
Good day all, this is my first post to this mailing list. Per Adam's
comment below:
> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assum
It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an
option like this is likely not practical/what people would wish to see.
Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after
(Also in response to ZMN...)
Bitcoin Core has a long-standing policy of not shipping options which shoot
yourself in the foot. I’d be very disappointed if that changed now. People are
of course more than welcome to run such software themselves, but I anticipate
the loud minority on Twitter and
Personally I don't really have much of a view and think either
LOT=true or false is better in the context, they both seem safe given
the current context, where basically everyone is saying "are we there
yet", including pools (88.7% going out of their way to say YES
https://taprootactivation.com).
Hi Michael
I think you're right, sorry for getting a little apocalyptic at the
end there lol.
> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev
>
> Thanks for your response Ariel. It would be useful if you responded to
> specific points I have made in the mailing list post or at
Good morning list,
> This is absolutely the case, however note that the activation method itself
> is consensus code which executes as a part
> of a fork, and one which deserves as much scrutiny as anything else. While
> taproot is a model of how a soft-fork should
> be designed, this doesn't im
> getting unlucky and hitting a 4-block reorg that happens to include a
double-spend and some PR around an exchange losing millions would be worse
than having Taproot is good.
We are at the point where an upgrade that confers significant long term
benefits for the whole ecosystem is not as importa
Hi all,
I think it's important for us to consider what is actually being considered
for activation here.
The designation of "soft fork" is accurate but I don't think it adequately
conveys how non-intrusive a change like this is. All that taproot does
(unless I'm completely missing something) is i
Thanks for your response Matt. It is a fair challenge. There is always
going to be an element of risk with soft forks, all we can do is attempt to
minimize that risk. I would argue that risk has been minimized for Taproot.
You know (better than I do in fact) that Bitcoin (and layers built on top
o
This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
be designed, this doesn't imply anything about the consens
To ensure we're on the same page, here - I'm not advocating we give up on Taproot. Indeed, without having dug deep into
the issue, my overall impression is that Knots has a tiny transaction-processing userbase and it likely isn't worth
giving deep thought to whether it forks itself off from the n
You say "short term PR", I say "risking millions of user dollars".
On 2/18/21 09:51, Michael Folkson wrote:
> getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an exchange
losing millions would be worse than having Taproot is good.
We are at
We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
much as absolutely possible. Again, while I think Taproot is
If the eventual outcome is that different implementations (that have material
*transaction processing* userbases, and I’m not sure to what extent that’s true
with Knots) ship different consensus rules, we should stop here and not
activate Taproot. Seriously.
Bitcoin is a consensus system. The a
Bitcoin is a consensus system. Please let’s not jump to (or even consider)
options that discourage consensus. We all laughed at (and later academics
researched showed severe deficiencies in) Bitcoin XT’s “emergent consensus”
nonsense, why should we start doing things along that line in Bitcoin?
Right, that is one option. Personally I would prefer a Bitcoin Core release
sets LOT=false (based on what I have heard from Bitcoin Core contributors)
and a community effort releases a version with LOT=true. I don't think
users should be forced to choose something they may have no context on
before
Good morning all,
> "An activation mechanism is a consensus change like any other change, can be
> contentious like any other change, and we must resolve it like any other
> change. Otherwise we risk arriving at the darkest timeline."
>
> Who's we here?
>
> Release both and let the network decid
"An activation mechanism is a consensus change like any other change, can
be contentious like any other change, and we must resolve it like any other
change. Otherwise we risk arriving at the darkest timeline."
Who's we here?
Release both and let the network decide.
On Thu, Feb 18, 2021 at 3:0
Thanks for your response Ariel. It would be useful if you responded to
specific points I have made in the mailing list post or at least quote
these ephemeral "people" you speak of. I don't know if you're responding to
conversation on the IRC channel or on social media etc.
> The argument comes fro
Something what strikes me about the conversation is the emotion surrounding the
letters UASF.
It appears as if people discuss UASF as if it's a massive tidal wave of support
that is inevitable, like we saw during segwit activation. But the actual
definition is "any activation that is not a MASF
Yesterday (February 16th) we held a second meeting on Taproot
activation on IRC which again was open to all. Despite what appeared
to be majority support for LOT=false over LOT=true in the first
meeting I (and others) thought the arguments had not been explored in
depth and that we should have a fo
42 matches
Mail list logo
