[bitcoin-dev] Taproot activation meeting on IRC - Tuesday 2nd February 19:00 UTC

2021-01-22 Thread Michael Folkson via bitcoin-dev
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 but

[bitcoin-dev] Yesterday's Taproot activation meeting on IRC

2021-02-03 Thread Michael Folkson via bitcoin-dev
Yesterday (February 2nd) we held a relatively unstructured meeting on Taproot activation on IRC which was open to all. The conversation log is here: http://gnusha.org/taproot-activation/2021-02-02.log The meeting was previously announced here:

[bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support

2021-06-17 Thread Michael Folkson via bitcoin-dev
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:

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-21 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support

2021-06-22 Thread Michael Folkson via bitcoin-dev
ls 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.linuxfoundation.org/piperm

Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support

2021-06-22 Thread Michael Folkson via bitcoin-dev
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 >> >

[bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up

2021-06-29 Thread Michael Folkson via bitcoin-dev
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:

[bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

2021-02-05 Thread Michael Folkson via bitcoin-dev
A summary of the first Taproot activation meeting (February 3rd) is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html It appears there is one (hopefully) last stumbling block before we are ready to propose Taproot activation parameters to the mailing list.

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-03-24 Thread Michael Folkson via bitcoin-dev
Thanks for this Jeremy. I agree with the vast majority of this. For those that missed yesterday's meeting the meeting log is here: http://gnusha.org/taproot-activation/2021-03-23.log Jeremy also livestreamed the meeting on his Twitch channel: https://www.twitch.tv/videos/960346848 On the choice

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-03-24 Thread Michael Folkson via bitcoin-dev
> 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

[bitcoin-dev] Announcing a new standard for soft fork activation

2021-04-01 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Update on "Speedy" Trial

2021-04-06 Thread Michael Folkson via bitcoin-dev
(The email last week was an April Fools. I did my best to make light of the situation...) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018724.html 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

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

2021-03-16 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

2021-03-22 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting

2021-03-03 Thread Michael Folkson via bitcoin-dev
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: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html It is clear

[bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

2021-03-01 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

2021-03-06 Thread Michael Folkson via bitcoin-dev
Hi Matt > 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

[bitcoin-dev] Measuring the support (or lack of support) for Speedy Trial

2021-03-07 Thread Michael Folkson via bitcoin-dev
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) https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f This is not a

Re: [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting

2021-03-04 Thread Michael Folkson via bitcoin-dev
ly way to activate Taproot. Thanks Michael 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 > wrote: > > > > At this point in time it also appears the greatest risk to Taproot > > dying a slow death

[bitcoin-dev] Taproot activation facts on lockinontimeout (LOT)

2021-02-27 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

2021-04-09 Thread Michael Folkson via bitcoin-dev
://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 apparently a technical decision mad

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

2021-04-10 Thread Michael Folkson via bitcoin-dev
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, Apr 8, 2021 at 10:57 PM David A. Harding wrote: > > > > On Thu, Apr 08, 2021 at 12:40:

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

2021-04-10 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Yesterday's Taproot activation meeting on IRC

2021-04-14 Thread Michael Folkson via bitcoin-dev
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:

[bitcoin-dev] Update on Taproot activation releases

2021-04-16 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

2021-04-08 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-18 Thread Michael Folkson via bitcoin-dev
ryone that neither choice is being forced on users, and > instead what is being forced on users, is for users to make that choice > themselves. > > Regards, > ZmnSCPxj > > > > > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-18 Thread 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. > > Matt > > On Feb 18, 2021, at 08:11, Michael Folkso

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-18 Thread Michael Folkson via bitcoin-dev
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 > > &g

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-18 Thread Michael Folkson via bitcoin-dev
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. > > Cheers > Ariel Lorenzo-Luaces > On Feb 17, 2021, at 7:05 AM, Michael Folkson v

Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?

2021-08-26 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

2021-09-07 Thread Michael Folkson via bitcoin-dev
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,

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-10 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-13 Thread Michael Folkson via bitcoin-dev
> 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 >

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-10 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

2021-09-14 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

2021-09-14 Thread Michael Folkson via bitcoin-dev
>> 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

[bitcoin-dev] Tuesday's BIP process meeting

2021-09-17 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up

2021-07-30 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC

2021-08-03 Thread Michael Folkson via bitcoin-dev
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:

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-16 Thread Michael Folkson via bitcoin-dev
> 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

[bitcoin-dev] On the regularity of soft forks

2021-10-11 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Reminder: Second BIP process meeting tomorrow at 23:00 UTC

2021-09-28 Thread Michael Folkson via bitcoin-dev
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]:

[bitcoin-dev] Wednesday’s second BIP process meeting

2021-10-03 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-01-04 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-01-03 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Taproot activates - A time/block line

2021-11-15 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC

2021-07-17 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-01-04 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

2022-02-13 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

2022-03-09 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

2022-02-14 Thread Michael Folkson via bitcoin-dev
> 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.

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-01-28 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] Improving RBF Policy

2022-02-05 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] CTV BIP review

2022-01-19 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Highlighting Taproot implementation gotchas

2022-01-20 Thread Michael Folkson via bitcoin-dev
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.

[bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-21 Thread 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 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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-22 Thread Michael Folkson via bitcoin-dev
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 &g

[bitcoin-dev] What to expect in the next few weeks

2022-04-22 Thread 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 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

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

2022-04-20 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

2022-04-20 Thread Michael Folkson via bitcoin-dev
> 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. > &

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

2022-04-20 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-24 Thread Michael Folkson via bitcoin-dev
gt; > 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 perhaps >> Jeremy thought that there would be a Spee

Re: [bitcoin-dev] What to expect in the next few weeks

2022-04-26 Thread Michael Folkson via bitcoin-dev
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. > > regards, > > Jeremy > > -- > [@JeremyRubin](https://twitter.com/JeremyRubin) > >

Re: [bitcoin-dev] What to expect in the next few weeks

2022-04-25 Thread Michael Folkson via bitcoin-dev
, 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 everyone would come to an informed view

Re: [bitcoin-dev] What to expect in the next few weeks

2022-04-23 Thread Michael Folkson via bitcoin-dev
aking 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 >> care about Bitcoin's consensus r

Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures

2022-07-20 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures

2022-07-17 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Online Socratic on MuSig2 and biweekly secp256k1 IRC meeting

2022-07-23 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-23 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] What to do when contentious soft fork activations are attempted

2022-04-30 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Transcript: Carl Dong on libbitcoinkernel

2022-04-30 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Transcript: Sydney Socratic on FROST w/ Jesse Posner

2022-04-27 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Miniscript support in hardware wallets/signing devices

2022-04-29 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs

2022-08-04 Thread Michael Folkson via bitcoin-dev
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. > > Luke > > > On Thursday 04 August 2022 14:54:54 Michael Folkson

Re: [bitcoin-dev] P2P trading replacement transactions

2022-08-06 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs

2022-08-04 Thread Michael Folkson via bitcoin-dev
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

[bitcoin-dev] Transcript: Online Socratic on MuSig2

2022-09-08 Thread Michael Folkson via bitcoin-dev
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

Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2

2022-09-12 Thread Michael Folkson via bitcoin-dev
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.

Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

2022-09-17 Thread Michael Folkson via bitcoin-dev
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,

Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

2022-09-18 Thread Michael Folkson via bitcoin-dev
tc) > 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. > > --- Original Message --- > On Saturday, September 17th, 2022