Just to inform this list, this pull request has since been assigned a BIP
number (BIP 388) [0].
Thanks
Michael
[0]: https://github.com/bitcoin/bips/pull/1389
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://
Hi Peter
Interesting post. By implicitly committing in advance to the fee paid by the
spending transaction CTV is certainly nailing its colors to the CPFP mast
rather than operating in a RBF world. And in a future high fee environment
(ignoring whatever is driving those high fees, monetary or n
t Bitcoin: https://www.youtube.com/@portofbitcoin
On Thursday, 18 January 2024 at 18:00, Peter Todd wrote:
> On Wed, Jan 17, 2024 at 05:29:48PM +, Michael Folkson via bitcoin-dev
> wrote:
>
> > Hey Luke
> >
> > I'd be happy to pick up working on BIP 3 again (
Hi Christopher
In the absence of a response from someone who is working on MuSig2/FROST etc I
did ask Tim Ruffing about the problems with using x-only pubkeys for MuSig2 etc
in an (online) London Bitcoin Devs meetup [0] in 2022.
His response was:
"If you want to do more complex things, for exa
Hey Luke
I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this
issue and others that are repeatedly cropping up (e.g. confusion on the
recommended flow for working on proposed consensus changes, when to open a pull
request to bitcoin-inquisition, when to open a pull request
In the interests of time I'll just pick two to respond to but I don't agree
with any of your points.
> Covenants allow trustless utxos sharing and also are needed for vaulting. The
> numerous use cases are documented, built out and on signet to my knowledge.
> Check out[utxos.org](http://utxos.
Hi Erik
> So what exactly are the risks of CTV over multi-sig?
It is a strange comparison. Multisig is active onchain and is being used today
for all sorts of things including Lightning and setups that address risk of
single key loss or malicious signing. When discussing risks of CTV there are
Hey AJ
Thanks for this, pretty much agree with all of it. It seems like a week doesn't
go by now without a new individual popping out the woodwork proposing an
upcoming activation of CTV with no new PoCs and no new insights. I'm not sure
what it is about CTV (versus say other proposals) that it
Hi alicexbt
> It has been assigned CVE-2023-33297
Did you personally request the CVE ID? Say via here [0]? Did you confirm with
someone listed on the vulnerability reporting process [1] for Bitcoin Core that
it made sense to do that at this time? I'm not sure whether completely
bypassing that
Hi alicexbt
"Open source" has the word "open" in it. Pushing everything into closed,
private channels of communication and select groups of individuals is what I've
been trying to push back upon. As I said in my initial response "it doesn't
scale for all bug reports and investigations to go thr
Hi alicexbt
The vulnerability reporting process requires communication and resolution via a
small group of individuals [0] rather than through open collaboration between
any contributors on the repo. There are clearly examples where the process is
critically needed, the most obvious past exampl
0659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
--- Original Message ---
On Wednesday, May 10th, 2023 at 22:24, Andrew Chow via bitcoin-dev
wrote:
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>> The decision process for
e project contributors)
>>> can express their view in this PR?
>>> https://github.com/bitcoin/bitcoin/pull/27604
>>>
>>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev
>>> wrote:
>>>
>>>> On Sun, May 7, 2023 at 12:36 PM
ibutors) can
> express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604
>
> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev
> wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev
>> wrote:
>>
> im unclear as to the purposepaying an onchain transaction fee greater than
> the amount receiving could possibly serve.
If you expect fees to continue to rise and be sustained at abnormally high
levels for a long period of time you might seek to close your Lightning
channel(s) and move whatev
> probably easier just to reject any transaction where the fee is higher than
> the sum of the outputs
And prevent perfectly reasonable transfers of value and attempted Lightning
channel closes during fee spikes? If I want to close my Lightning channel
during a protracted fee spike where I hav
Hi Ali
I'd point you to Andrew Poelstra's post from January 2023 [0] and a Bitcoin
StackExchange answer I recently posted [1].
> Considering that miners are largely the entities at fault for allowing the
> system to be abused like this, the harmony of Bitcoin transactions is being
> disrupted
el Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
--- Original Message -------
On Sunday, May 7th, 2023 at 18:35, David A. Harding wrote:
> On 2023-05-06 21:03, Michael Folkson via
There has been a proposed new maintainer on Bitcoin Core (ryanofsky). In the
Core dev IRC meeting [0] yesterday it received multiple ACKs.
The decision process for adding a new maintainer was according to the IRC
meeting that the maintainers decided privately there was a need for a
maintainer “
Hi Salvatore
Can you clarify for me which bucket this proposal sits? We have APO, CTV,
OP_VAULT etc that are proposals to add additional functionality to SegWit
version 1, Tapleaf version 0 scripts. We have Simplicity that would need a new
Tapleaf version (e.g. Tapleaf version 1). And then ther
son
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--- Original Message ---
On Wednesday, April 19th, 2023 at 22:33, Andrew Chow via bitcoin-dev
wrote:
> Responses in-line.
> Note that the opinions expressed in this email are my own and are not
> representative o
r 18, 2023 at 12:40:44PM +, Michael Folkson via bitcoin-dev
> wrote:
>
> > I do think the perception that it is “the one and only” staging
> > ground for consensus changes is dangerous
>
>
> If you think that about any open source project, the answer is simple:
&
project have the same inclinations as a subset of the Core maintainers.
>
>
> This perception (if exists) can be killed by creating a custom signet,
> maintaining it differently, get more reviews, testing and share details with
> community regularly.
>
> /dev/fd0
> floppy disk guy
at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--- Original Message ---
On Wednesday, April 19th, 2023 at 10:05, Kostas Karasavvas
wrote:
> Hi Michael,
>
> On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson
t tech for many use cases
>
> although im partial to 118 as well because lightning is a killer app and it
> makes batch channels more efficient
>
> On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev
> wrote:
>
>> Communication has been a challenge on Bitco
Any thoughts on this from the Core Lightning contributors? The way I see it
with upcoming proposed changes to default policy (primarily though not
exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
(primarily though not exclusively for Lightning) that a tighter coupling
Communication has been a challenge on Bitcoin Core for what I can tell the
entire history of the project. Maintainers merge a pull request and provide no
commentary on why they’ve merged it. Maintainers leave a pull request with many
ACKs and few (if any) NACKs for months and provide no commenta
Hi Andrew
> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
>> The countermeasure is that you should always know the entire Taptree when
>> interacting with someone
Hi alicexbt
Thanks for the suggestion. I'll take a look at the branch.
I'm personally pretty bullish on Lightning and Core Lightning is criminally
underused. Plus it is more exciting (and hopefully will attract more
contributors) to try something ambitious than just trim Core. I'll see if it is
I saw it was announced, yes. The author is brilliant, he has now managed two
alternative implementations of Core in two different languages :)
The problem though and why I and many others think the Knots style fork of Core
is the better option is because you avoid reimplementing consensus code i
I tweeted this [0] back in November 2022.
"With the btcd bugs and the analysis paralysis on a RBF policy option in Core
increasingly thinking @BitcoinKnots and consensus compatible forks of Core are
the future. Gonna chalk that one up to another thing @LukeDashjr was right
about all along."
A
Hi alicexbt
There does seem to be some confusion on this which I'm going to look into. I
don't think ranting and raving or throwing toys out the pram on the mailing
list is the productive way to go though. I'll chat to some people offline and
see what the confusion is and hopefully this can be
I think it best I leave this discussion to others then as something I've
written has obviously offended you. I'll also leave it to others to assess
whether I was disrespectful or attacking your character or quality of
experience in that email. Someone working on the P2P or mempool part of the
B
Hey John
There was a discussion [0] started by Lisa on the mailing list last year on
whether there is any point to a full node maintaining a mempool last year which
you may find interesting. I also recommend Gloria's presentation [1] from
Adopting Bitcoin last year on transaction relay policy.
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality.
Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is
possible with him. But as others have said turnin
Hi alicexbt
Thanks for setting this up. Generally it seems to me like an excellent idea to
set up custom signets (and/or get proposals enabled on the default signet) for
testing and experimenting with new proposals.
I have two questions.
1) In this particular case the -mempoolfullrbf configura
Thanks for this AJ, especially the history on prior soft forks, the vast
majority of which I was unclear on.
> The point of doing it via signet and outside of core is there doesn't
need to be any community consensus on soft forks. Unlike mainnet, signet
sBTC isn't money, and it isn't permissionle
I've given this some extra thought and discussed with others who may later
chime in on this thread. I'm now convinced this should be done on a custom
public signet rather than on the default signet. SegWit was added to a new
testnet (Segnet) for testing rather than the pre-existing testnet and I
t; approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)
> e)Pre-baked ability to abandon the soft fork
> f)No need to regularly rebase consensus changes against bitcoin core's master
> branch
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> --- O
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" [0] 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, ope
Hi Ali
> 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.
OP_CHECKMULTISI
Hi
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 [0] but ended up being rescheduled.
The transcript is here [1], the video is here [2] and a readi
Hi alicexbt
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 n)
> 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.
>
> Luke
>
>
> On Thursday 04 August 2022
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 [0]. Following that merge David Harding and Peter
Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had been
implemented in Bitcoin Core. The
Hi Antoine
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 t
Hi
There is an online Socratic discussion [0] on MuSig2 next week (Thursday July
28th, 17:00 UTC) that Tim Ruffing has kindly agreed to attend. There is a
reading list [1] covering Tim's work and other people's work implementing and
researching MuSig2 and hopefully some of those people will att
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 t
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 [0]. My understanding is Schnorr
Hi
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:
https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/
As he explains in the vi
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 r
Hi
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 o
Hi
I thought this transcript might be of interest to the mailing list.
https://btctranscripts.com/sydney-bitcoin-meetup/2022-03-29-socratic-seminar/
Jesse Posner joined the online Sydney Socratic [1] last month to discuss his
work on FROST. There is a video [2] too. As Jesse states [3] "With th
hat as well, if they
> do not entail substantial technical risk. Personally, 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.
>
> regards,
>
> Jeremy
il 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev
wrote:
> 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 every
to discuss it in hypothetical terms anymore, do we?
>
> 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
> wrote:
>
>> Ok so we've had to scramble a bit as I don't think anyone except pe
> certain people are "taking advantage" of some situation and attempting "to
> confuse".
>
> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev
> wrote:
>
>> If the next few weeks go how I fear they will it could get messy. If you
>&g
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 out
emic risk. Not all soft-forks are equal, and therefore the meta-consensus
> requirements for getting them activated should vary based on how broadly
> consequential the change is.
>
> Feel free to resist this if you want. In some sense that's what the Speedy
> Trial procedure is for.
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 [1]. That is two weeks away.
(I have to take what he says at face value. I can understand why one would be
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
find a common way forward to activate covenants. This
> 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
> 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 Rus
Hi Jorge
> 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 so
> 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.
Rig
Hi Prayank
> 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
base blockchain/netwo
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
for the res
> 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 diffic
Hi
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 [0] (invalid x coordinate) and hence were
burned.
https://suredbits.com/taproot-funds-burned-on
Eric, Luke
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 [0]) do not support
an upcoming activation attempt of standalone OP_CTV. If you want to discuss
activation methods for soft forks generally it would
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 thin
> 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
for any parti
I have already expressed my arguments on the regularity of soft forks [0].
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 activ
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 [0] showing blocks and
transactions in the run up to and directly after Taproot activa
> 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
> engineering.
Soft fork features can (and should) obviously be t
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 l
Wednesday’s second BIP process meeting was announced previously here [0].
A conversation log of the meeting is available here [1].
A summary of the first BIP process meeting is here [2].
The following is a summary of what was discussed.
1) The limits or possible downsides of pursuing maximal de
As announced here [0] 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 [1].
[0]:
https://lists.linuxfound
Tuesday's BIP process meeting was announced previously here [0].
A conversation log of the meeting is available here [1].
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
is described in
>> 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
inaccurate perceptions
Hey Prayank
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 go
> 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
> jum
> 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 to
> 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
res
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, one
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 C
Please find below the video and transcript from the online discussion
on Taproot roll out that was held on July 20th.
Video: https://www.youtube.com/watch?v=GAkLuZNsZzw
Transcript:
https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/
Reading list:
https://g
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.
Transcript:
https://btctranscripts.com/sydney-bitcoin-meetup/2021-07-06-socratic-seminar/
The discussion focused partly on the rules [1] of BIP 1
Hi
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 p
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
https://github.com/ariard/L2-zoology/blob/master/workshops/package-rel
t; temporary periods of fee congestion, even potentially 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 chan
> restructure their channels to compensate for the elevated fee market.
>
> On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev
> wrote:
>>
>> The workshop was previously announced by ariard on the bitcoin-dev
>> mailing list here:
>> https://lists.lin
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
things.
> Browsing quickly through Greg's piece, a lot of the reasoning is based on
> FOSS experience
The workshop was previously announced by ariard on the bitcoin-dev
mailing list here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html
A reminder was posted to the bitcoin-dev mailing list here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.
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 Co
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.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018769.html
The conversation log is here:
http://gnusha.org/ta
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
i
block height) we may have avoided getting into this
> deadlock in the first place.
>
> Your recent review notes of PR #21377 look great and are proving very
> helpful to me as I look at the PR.
> https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40
>
> Thanks
> Michael
>
> On Thu,
ul to me as I look at the PR.
https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40
Thanks
Michael
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
> wrote:
> > So the latest circus act is
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 al
1 - 100 of 121 matches
Mail list logo
