Hi Pieter,
Addressing your comments:
>> Thank you very much for all the clarifications; it’s good to have them
>> sorted out and clearly structured. From what you wrote it follows that we
>> still need to reserve a dedicated purpose (with new BIP) for BIP340
>> signatures to avoid key reuse,
Hi Adam,
Commenting on your question:
> With segWit vs pre-SegWit didn't wallets just select and standardize
> on a different HD derivation path?
>
> Is there something else needed than a Schnorr derivation path?
The general accepted practice (defined in BIP43) is to define a dedicated
> 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
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
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
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
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
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
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
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
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
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
"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
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
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
16 matches
Mail list logo
