There has been an incredible community effort to make progress towards
consensus on an activation method for the proposed Taproot soft fork.
Special mentions go to David Harding, AJ Towns, Aaron van Wirdum, Jonathan
Bier, Ben Carman, Alejandro De La Torre whose resources are linked below
Yesterday (February 2nd) we held a relatively unstructured meeting on
Taproot activation on IRC which was open to all.
The conversation log is here:
The meeting was previously announced here:
The workshop was previously announced by ariard on the bitcoin-dev
mailing list here:
A reminder was posted to the bitcoin-dev mailing list here:
I don't want to divert from the topic of this thread ("Waiting
SIGHASH_ANYPREVOUT and Packing Packages"), we can set up a separate
thread if we want to discuss this further. But just a couple of
> Browsing quickly through Greg's piece, a lot of the reasoning is based on
> FOSS experience
ls to compensate for the elevated fee market.
> On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev
>> The workshop was previously announced by ariard on the bitcoin-dev
>> mailing list here:
tentially long-running periods
>> > that last weeks. It might even help in non-temporary fee market increases
>> > by giving participants extra time to use some fee-bumping technique to
>> > close or restructure their channels to compensate for the elevated fee
A summary of the first workshop is here:
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
A summary of the first Taproot activation meeting (February 3rd) is here:
It appears there is one (hopefully) last stumbling block before we are
ready to propose Taproot activation parameters to the mailing list.
Thanks for this Jeremy. I agree with the vast majority of this.
For those that missed yesterday's meeting the meeting log is here:
Jeremy also livestreamed the meeting on his Twitch channel:
On the choice
> Your response strikes me as ingenuine with regards to "other projects" as it
> is a project I understand you to be one of the parties spearheading. I think
> it's misleading to not clarify that in your response.
I support Taproot activation and any project that can help bring that
about. As I
There have been a vast number of proposals for soft fork activation in
recent months and it is important that all these important ideas don’t go
to waste. Hence I propose a new standard for soft fork activation
incorporating all the ideas into one standard. I appreciate this standard
has come too
(The email last week was an April Fools. I did my best to make light of the
I'd like to give the list an update on where we are with Speedy Trial
because it is just as absurd as it looks to an outside
> I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.
Until Core pull request(s) are merged I don't
Thanks for organizing this Jeremy, agenda looks great. I do think we are
now at the time where Taproot activation becomes a priority for all those
with a stake in Taproot activation.
Although these parameters haven't yet been finalized the proposed
(approximate) startheight is May 1st which is
Yesterday we held a UASF (LOT=true) kick off meeting on the ##uasf IRC channel.
The conversation log is here: http://gnusha.org/uasf/2021-03-02.log
It was announced (at short notice admittedly) here:
It is clear
It is approximately 8 months since Steve Lee formally kicked off the
Taproot activation discussion by setting up the ##taproot-activation
IRC channel. Obviously there was discussion that considerably predates
that but that was the first recognition that there needed to be a
focus towards a
> I'm really unsure that three months is a short enough time window that
there wouldn't be a material effort to split the network with divergent
consensus rules. Instead, a three month window is certainly long enough to
organize and make a lot of noise around such an effort, given BIP 148
I have set up a document (a gist) to measure the support (or lack of
support) for the Speedy Trial activation proposal.
Please contribute a ACK or NACK (with a qualification or additional
context if necessary)
This is not a
ly way to activate Taproot.
On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces wrote:
> On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev
> > At this point in time it also appears the greatest risk to Taproot
> > dying a slow death
I just want to lay out some facts as I see them because frankly I feel
any personal opinion is irrelevant at this point and without agreement
on facts we are going round in circles. I end with a personal opinion
which you can feel free to ignore.
1) There is a long list of current and past Core
On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote:
> On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev
> > So the latest circus act is apparently a technical decision mad
recent review notes of PR #21377 look great and are proving very
> helpful to me as I look at the PR.
> On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote:
> > On Thu, Apr 08, 2021 at 12:40:
Hi Bitcoin Mechanic
I will attend but I will be looking at Core PR #21377 over the next
couple of days and I would encourage other reviewers to review that PR
too. If that PR is merged into Core I would strongly recommend any
alternative release be fully compatible with the activation parameters
Yesterday there was a Taproot activation meeting on the
##taproot-activation Freenode channel.
The agenda was posted in advance to the mailing list by BitcoinMechanic.
The conversation log is here:
I discussed in the last Taproot activation meeting notes the plans for
an alternative release to Bitcoin Core with the Speedy Trial
activation mechanism (BIP 8, consistent use of block height) followed
by a BIP 8(1 year, LOT=true). This has now been released (version 0.1)
under the name "Bitcoin
I will continue to update the list on the latest developments as I see
them. That's all I can do.
So the latest circus act is apparently a technical decision made by a
coin toss. The rationale being that this discussion on using block
height vs a mix of block height and MTP was bikeshedding all
ryone that neither choice is being forced on users, and
> instead what is being forced on users, is for users to make that choice
> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
ots) ship different consensus rules, we should
> stop here and not activate Taproot. Seriously.
> Bitcoin is a consensus system. The absolute worst outcome at all possible
> is to have it fall out of consensus.
> On Feb 18, 2021, at 08:11, Michael Folkso
th Knots) ship
> different consensus rules, we should stop here and not
> > activate Taproot. Seriously.
> > Bitcoin is a consensus system. The absolute worst outcome at all
> possible is to have it fall out of consensus.
> > Matt
vation 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.
> Ariel Lorenzo-Luaces
> On Feb 17, 2021, at 7:05 AM, Michael Folkson v
The "No Taproot" section of the Sapio docs need updating :) What are
your plans to take advantage of Taproot with Sapio? It would have been
interesting to see what a Taproot emulator would have looked like,
although no need for it now. It seems to me Taproot would have been
harder to emulate than
With a new BIP editor (Kalle Alm) in place and Taproot activation
locked in it is probably/possibly as good time as any to revisit the
BIP process and see if we can bolster it, improve it or at least
inform why certain things operate the way they do.
Hence two IRC meetings are being organized,
> I see zero reason whatsoever to not simply reorg ~every block, or as often as
> is practical. If users opt in to wanting to test with reorgs, they should be
> able to test with reorgs, not wait a day to test with reorgs.
One of the goals of the default Signet was to make the default Signet
> Can you explain the motivation for this? From where I sit, as far as I know,
> I should basically be > a prime example of the target market for public
> signet - someone developing bitcoin applications > with regular requirements
> to test those applications with other developers without
> Huh? Why would the goal be to match mainnet? The goal, as I understand it, is
> to allow software to
use SigNet without modification *to make testing simpler* - keep the
header format the same to let
SPV clients function without (significant) modification, etc. The
point of the whole thing is
Thanks for the suggestions.
> bitcoin-dev mailing list link can be considered a BIP and saved in a BIP
> directory. Anyone can create such directories. So BIP is nothing but a
> proposal shared on bitcoin-dev mailing list.
A mailing list post is static and a BIP will go normally
>> I can only speak for myself here but I am not particularly concerned about
>> this perception of authority.
> This perception affects Bitcoin.
Personally I would rather have an optimal process that provides
clarity and helps us build better software than be sensitive to
Tuesday's BIP process meeting was announced previously here .
A conversation log of the meeting is available here .
It looks promising at this stage that we'll eventually have a bundle of changes
to warrant a new proposed BIP (BIP 3) to replace the current BIP process that
There was some additional discussion on L2 onchain support at the
recent online Sydney Socratic Seminar. It wasn't recorded but a
transcript is below.
The discussion focused partly on the rules  of BIP
Please find below the video and transcript from the online discussion
on Taproot roll out that was held on July 20th.
> Interesting discussion.Correct me if I'm wrong: but putting too many features
> together in one shot just can't make things harder to debug in production if
> something very unexpected happens.It's a basic principle of software
Soft fork features can (and should) obviously be
I was hoping to delay this post as long as possible because there are so many
interesting and important things to discuss other than soft forks and consensus
changes that seem to have taken a backseat this year due to Taproot activation.
In addition, there seems to be a world of opportunity to
As announced here  there is a second BIP process meeting tomorrow (Wednesday
September 29th 23:00 UTC). For Asia Pacific this is the morning of September
30th. It will be held on the #bitcoin-dev Libera IRC channel.
A summary from the first meeting is here .
Wednesday’s second BIP process meeting was announced previously here .
A conversation log of the meeting is available here .
A summary of the first BIP process meeting is here .
The following is a summary of what was discussed.
1) The limits or possible downsides of pursuing maximal
You are working on a use case of OP_CTV now? Cool, you only recently announced
you were working on Bitcoin Knots (and I think Wasabi before that) so I'm
losing track of all the announcements. Regardless stick with it and build out
more than a rudimentary proof of concept. That is one of the
I have already expressed my arguments on the regularity of soft forks .
Having spent months of my time on Taproot activation last year attempting to
get at least rough community consensus on the activation method it seems crazy
to me that some want to do that again so soon after Taproot
I thought I would collect together the highlights from Taproot activating for
those strange Bitcoin history buffs (including myself). If you’d rather watch
in video form 0xB10C provided an excellent livestream  showing blocks and
transactions in the run up to and directly after Taproot
There is an online Zoom call (also livestreamed on YouTube) on Tuesday
July 20th at 17:15 UTC discussing Taproot roll out post activation in
November. It will be focused at developers and so discussion will be
technical but all are welcome to attend/watch.
Murch has this wiki page monitoring
> It should be ready to go in a few months IMO
What is this assessment based on? I am assuming you haven't done a code review
of the opcode, you haven't coded up a real world use case of OP_CTV (or even a
primitive proof of concept), you haven't thought about alternative proposals
> 1.Is Lightning Network and a few other layer 2 projects vulnerable to
> multiple RBF policies being used?
Clearly the security of the Lightning Network and some other Layer 2 projects
are at least impacted or partly dependent on policy rules in a way that the
> Since this has meetings like taproot, it seems it's going to end up being
> added in bitcoin core no matter what.
Anyone can set up a IRC channel, anyone can organize a IRC meeting, anyone can
announce meetings on the mailing list. Just because an individual is
enthusiastic for a
> This is the assumption which I don't agree with and hence asked some
> questions in my email. A new RBF policy used by default in Core will not
> improve the security of projects that are vulnerable to multiple RBF policies
> or rely on these policies in a way that affects their security.
> Even if we were to adopt something like TXHASH, how long is it going to take
> to develop, test, and release? My guess is "a while" - in the meantime, users
> of Bitcoin are without a vault strategy that doesn't require either
> presigning transactions with ephemeral keys (operationally
Thanks for this Bastien (and Gloria for initially posting about this).
I sympathetically skimmed the eclair PR
(https://github.com/ACINQ/eclair/pull/2113) dealing with replaceable
transactions fee bumping.
There will continue to be a (hopefully) friendly tug of war on this probably
Can I request that you don't discuss activation methods for future soft forks
on a thread for CTV BIP review? I (and a number of others ) do not support
an upcoming activation attempt of standalone OP_CTV. If you want to discuss
activation methods for soft forks generally it
I'd just like to bring some attention to this blog post from the Suredbits team
who when implementing Taproot in bitcoin-s found a mainnet output that did not
conform to the BIP 340 specification  (invalid x coordinate) and hence were
Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy
thought that there would be a Speedy Trial signaling period for a CTV soft fork
planned to start on May 5th . That is two weeks away.
(I have to take what he says at face value. I can understand why one would be
free to resist this if you want. In some sense that's what the Speedy
> Trial procedure is for. However, I think your case would be more compelling
> if you actually had some sort of affirmative argument for why CTV induces
> systemic risk to non-users of the opcode. Expressing uncertainty over whether
If the next few weeks go how I fear they will it could get messy. If you care
about Bitcoin's consensus rules I'd request you pay attention so you can make
an informed view on what to run and what to support. For those of you who were
around in 2015-2017 you'll know what to expect. The right
> The client has a Speedy trial release similar to Taproots with parameters
> proposed to be
As I've said before I was hoping we'd avoid this exercise. Best case, it wastes
the time of people who could be working on all sorts of valuable projects for
the ecosystem. Worst case, we take a
> doesn't serve bitcoin. I think it would be better for everyone if you would
> invest your time in trying to formulate a better solution. Covenants are too
> important to just oppose them because of inaccurate framing or because of
> opposition to soft forks in general.
Ok last one. Whatever you say and whatever personal attacks you come up with
I'm not responding after this one :)
> Where can I see the use cases you have built out in recent years? Do you have
> a writeup in which you compare CTV to existing covenant enabling proposals?
> Do you have a strong
> Is there any PR to actively resist the proposal on bitcoin core?
> On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev
>> Ok so we've had to scramble a bit as I don't think anyone except perhaps
>> Jeremy thought that there would be a Spee
ersonally, were I aligned with
> your preferences, I'd be testing the forkd script and making sure it is easy
> to use as the simplest and most effective way to achieve your ends.
, Michael Folkson via bitcoin-dev
> As I said in my post:
> "If you care about Bitcoin's consensus rules I'd request you pay attention so
> you can make an informed view on what to run and what to support."
> Ideally everyone would come to an informed view
aking advantage" of some situation and attempting "to
> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev
>> If the next few weeks go how I fear they will it could get messy. If you
>> care about Bitcoin's consensus r
So this half aggregation BIP draft could potentially play the role that BIP340
did for BIP341/342 but it is too premature to start formalizing what the
equivalent of BIP341/342 for this draft BIP would look like. And given there
are use cases for this half aggregation BIP that can be worked on
Thanks for this Jonas. One question that was asked on Telegram (credit: Antoine
D) and isn't clear to me skimming the blog post and the draft BIP is whether
half aggregation needs a new output type or not like we expect cross input
signature aggregation (CISA) to . My understanding is
There is an online Socratic discussion  on MuSig2 next week (Thursday July
28th, 17:00 UTC) that Tim Ruffing has kindly agreed to attend. There is a
reading list  covering Tim's work and other people's work implementing and
researching MuSig2 and hopefully some of those people will
This looks great and I can certainly see progress being made in a number of
directions on this. I thought you did a great job with the L2 onchain support
workshops and I'm sure you'll do a great job moving this forward.
One cautionary word from someone who is probably still feeling
I’ve been in two minds on whether to completely move on to other topics or to
formulate some thoughts on the recent attempt to activate a contentious soft
fork. In the interests of those of us who have wasted days/weeks/months of our
time on this (with no personal upside) and who don’t want to
Another transcript that may be of interest to this list. Carl Dong recently did
an excellent short video explaining the libbitcoinkernel project in Bitcoin
Core. The transcript is here:
As he explains in the
I thought this transcript might be of interest to the mailing list.
Jesse Posner joined the online Sydney Socratic  last month to discuss his
work on FROST. There is a video  too. As Jesse states  "With
Assessing what should be sent to this mailing list is difficult. We don't want
to be bombarded with full on company promotional materials obviously but then
at the same time only focusing on contentious consensus changes at the expense
of everything else just gives a warped view to readers
t; network policies are. It's fine to blame nodes/miners if they single out your
> transactions, but if it's just a matter of a general policy your transactions
> are failing to meet, that's on the sender/L2 to adapt.
> On Thursday 04 August 2022 14:54:54 Michael Folkson
What do you mean by "replacement transaction"? Replacing or swapping outputs
with a counterparty's?
I guess I'm struggling to understand exactly what you are attempting to achieve
here with regards to privacy and if this additional protocol complexity is
worth it. Recall a 2 (or
A short history of RBF and BIP125
The history of BIP125 is as far as I’m aware this. RBF rules were merged into
Bitcoin Core in November 2015 . Following that merge David Harding and Peter
Todd drafted a BIP (BIP125 ) outlining the RBF rules that had been
implemented in Bitcoin Core. The
We had an online Socratic on August 11th with Tim Ruffing (co-author of MuSig2
draft BIP) and Elizabeth Crites (co-author of research papers on MuSig(2),
FROST). It was previously announced here  but ended up being rescheduled.
The transcript is here , the video is here  and a
> do you or anyone else in the Socratic know of any research to this that's
> don't involve a trade-off of theft or online connectivity?
Any generation of a signature(s), whether that be single key (e.g.
OP_CHECKSIG), multisig with multiple signatures going onchain (e.g.
I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that
CTV didn't have community consensus at the time"  and "it was the lack of
process that was the problem" the better. If people don't care about lack of
community consensus there is no process in a permissionless,
> e)Pre-baked ability to abandon the soft fork
> f)No need to regularly rebase consensus changes against bitcoin core's master
> Sent with Proton Mail secure email.
> --- Original Message ---
> On Saturday, September 17th, 2022
Mail list logo