Nostr notes by

📅 Original date posted:2023-05-08 🗒️ Summary of this ...

2023-06-19T19:42:05+02:00

In reply to nevent1q…va4l
_________________________

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Michael Folkson suggests adding more moderators to the lightning-dev mailing list due to the increasing number of emails and intertwined discussions.
📝 Original message:
Perhaps we need another moderator or two for the lightning-dev mailing list? There are already a lot of emails on the bitcoin-dev mailing list and so despite my views on the trend of Bitcoin and Lightning discussion becoming increasingly intertwined it probably makes sense to keep both bitcoin-dev and lightning-dev lists and just bump the number of moderators on lightning-dev.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Monday, May 8th, 2023 at 22:07, Vincenzo Palazzo <vincenzopalazzodev at gmail.com> wrote:

> > Is there a better place to have public communication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week.
> >
> > Would hate to see this list die but wondering if there's a better place for discussions?
>
>
> I think currently the list is the most accessible way that we have.
>
> I am not aware of any other tools that are as accessible as the list archive
> to search for some history, and also to allow people in 10 years from now to
> implement some of the ideas proposed these days.
>
> But I would agree to change communication tools if we do not lose these
> two properties.
>
> Cheers.
>
> Vincent.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2023-04-18 🗒️ Summary of this ...

2023-06-09T15:13:03+02:00

In reply to nevent1q…pn6a
_________________________

📅 Original date posted:2023-04-18
🗒️ Summary of this message: The dysfunction in the Bitcoin Core project has led to the idea of a Knots style Bitcoin implementation integrated with Core Lightning, as a tighter coupling between the full node and the Lightning node could eventually make sense.
📝 Original message:
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 between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense. Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.

The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:

> 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 new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>
> Thanks
> Michael
>
> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230418/a61cc0c7/attachment-0001.html>;

📅 Original date posted:2023-05-10 📝 Original message: ...

2023-06-09T15:08:48+02:00

In reply to nevent1q…prty
_________________________

📅 Original date posted:2023-05-10
📝 Original message:
>From my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing.

Now where it sits on the software stack assuming a user opts into such a reputation "service" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the "core" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service.

So yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a "core" of a Lightning node issue.

Thanks
Michael

[0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html

--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Wednesday, May 10th, 2023 at 12:57, Christian Decker <decker.christian at gmail.com> wrote:

> Hi Antoine,
>
> this is an intrinsic issue with reputation systems, and the main
> reason I'm sceptical w.r.t. their usefulness in lightning.
> Fundamentally any reputation system bases their expectations for the
> future on experiences they made in the past, and they are thus always
> susceptible to sudden behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
> This gets compounded as soon as we start gossiping about reputations,
> since now our decisions are no longer based just on information we can
> witness ourselves, or at least verify its correctness, and as such an
> attacker can most likely "earn" a positive reputation in some other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
> I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
> Cheers,
> Christian
>
> On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.riard at gmail.com wrote:
>
> > Hi *,
> >
> > > Our suggestion is to start simple with a binary endorsement field. As
> > > we learn more, we will be better equipped to understand whether a
> > > more expressive value is required.
> >
> > I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation.
> >
> > I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement.
> >
> > Opened an issue on the repository to converge on a threat model:
> > https://github.com/ClaraShk/LNJamming/pull/13
> >
> > I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces.
> >
> > Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming.
> >
> > Best,
> > Antoine
> >
> > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
> >
> > Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen kirkcohenc at gmail.com a écrit :
> >
> > > Hi list,
> > >
> > > Some updates on channel jamming!
> > >
> > > # Next Call
> > > - Monday 01 May @ 15:00 UTC
> > > - https://meet.jit.si/UnjammingLN
> > > - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
> > >
> > > # Data Gathering
> > > During these weekly calls, we've come to agreement that we would like
> > > to gather data about the use of HTLC endorsement and local reputation
> > > tracking for jamming mitigation. A reminder of the full scheme is
> > > included at the end of this email, and covered more verbosely in [1].
> > >
> > > We have a few goals in mind:
> > > - Observe the effect of endorsement in the steady state with
> > > logging-only implementation.
> > > - Gather real-world data for use in future simulation work.
> > > - Experiment with different algorithms for tracking local reputation.
> > >
> > > The minimal changes required to add HTLC endorsement are outlined in [2].
> > > Our suggestion is to start simple with a binary endorsement field. As
> > > we learn more, we will be better equipped to understand whether a
> > > more expressive value is required.
> > >
> > > With this infrastructure in place, we can start to experiment with
> > > various local reputation schemes and data gathering, possibly even
> > > externally to LN implementations in projects like circuitbreaker [3].
> > > We'd be interested to hear whether there's any appetite to deploy using
> > > an experimental TLV value?
> > >
> > > # Reputation Scheme
> > > - Each node locally tracks the reputation of its direct neighbors.
> > > - Each node allocates, per its risk tolerance:
> > > - A number of slots reserved for endorsed HTLCs from high reputation
> > > peers.
> > > - A portion of liquidity reserved for endorsed HTLCs from high
> > > reputation peers.
> > > - Forwarding of HTLCs:
> > > - If a HTLC is endorsed by a high reputation peer, it is forwarded
> > > as usual with endorsed = 1.
> > > - Otherwise, it is forwarded with endorsed = 0 if there are slots and
> > > liquidity available for unknown HTLCs.
> > >
> > > Endorsement and reputation are proposed as the first step in a two part
> > > scheme for mitigating channel jamming:
> > > - Reputation for slow jams which are easily detected as misbehavior.
> > > - Unconditional fees for quick jams that are difficult to detect, as
> > > they can always fall under a target threshold.
> > >
> > > Looking forward to discussing further in the upcoming call!
> > >
> > > Best,
> > > Carla and Clara
> > >
> > > [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
> > > [2] https://github.com/lightning/bolts/pull/1071
> > > [3] https://github.com/lightningequipment/circuitbreaker
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2022-11-26 📝 Original message: Hi ...

2023-06-09T15:07:27+02:00

In reply to nevent1q…3e2x
_________________________

📅 Original date posted:2022-11-26
📝 Original message:
Hi Antoine

I've got a lot to catch up on re channel jamming but just to say I'm deeply skeptical about attempting to embed a reputation layer or reputation credentials into the Lightning protocol. Admittedly I'm somewhat of a curious amateur in the field of reputation systems but a number of people (me included) have had to look into reputation systems in the past for projects/startups they were working on and centralized reputation systems are absolute minefields to manage effectively though some corporations do manage it. Decentralized reputation systems baked into a protocol is just a step too far. All you need is one edge case where the attacker can ensure an innocent party is blamed and the reputation system falls apart. The protocol developer is in the position of assessing who is telling the truth out of two opposing viewpoints on Reddit etc.

I do think reputation systems will play a key part in a future Lightning Network (to some extent they already are with sites like 1ML and Amboss) but they won't be managed by protocol devs, they will be managed by multiple flavors of companies and projects (hopefully open source but most likely closed source too, for profit, non-profit etc) who are free to use whatever metrics and weigh those metrics however they like. The protocol just can't afford to expand into areas where there is case by case judgment and statistical analysis required. It will become bloated, ineffective and put protocol developers in the position of deciding who ultimately receives routing fees rather than just enabling payments can get from A to B. Identity is easier, you either control a private key or you don't. Reputation is much more difficult, there will be some attacks where a probabilistic assessment will need to be made on who the perpetrator of the attack was. You don't add that to the (already long) list of protocol developers' responsibilities.

So feel free to continue to explore reputation and reputation systems but a strong warning that this is likely not solved at the protocol level. Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others. I've included some links to some additional reading on reputation systems in case you are interested.

Thanks
Michael

[0]: https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
[1]: https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
[2]: https://www.bitrated.com/faq

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Monday, November 21st, 2022 at 06:01, Antoine Riard <antoine.riard at gmail.com> wrote:

> Hi LN Devs,
>
> tl;dr A formalization of a reputation-based scheme to solve channel jamming is proposed. The system relies on "credentials" issued by routing hops and requested to be attached to each HTLC forward request. The "credentials" can be used by a reputation algorithm to reward/punish payment senders and allocate channel liquidity resources efficiently. The "credentials" initial distribution can be bootstrapped leveraging one-time upfront fees paid toward the routing hops. Afterwards, the "credentials" subsequent distribution can rely on previous HTLC traffic.
>
> A protocol description can be found here, with few extensions already to the BOLTs:
>
> https://github.com/lightning/bolts/pull/1043
>
> There is also a work-in-progress proof-of-concept in LDK (on top of our coming soon^TM HTLC intercepting API):
>
> https://github.com/lightningdevkit/rust-lightning/pull/1848
>
> This work builds on previous reputation-scheme research [0] [1]. It also integrates the more recent proposals of upfront fees as a straightforward mechanism to bootstrap the reputation system. Bootstrapping the system with more economically cost-effective privacy-preserving UTXO ownership proofs not only add another layer of engineering complexity, there is still a proof size vs proof generation/validation trade-off to arbiter between ZKP cryptosystems.
>
> Rather to seek for a game-theory equilibrium defined as a breakeven point as in the latest unconditional fee research [2], this proposal aims to use reputation credentials to allow HTLC traffic-shaping. This not only should protect against jamming situations (either malicious
> or spontaneous) but also allow active HTLC traffic-shaping, where a routing hop can allow extended channel liquidity lockups based on accumulated reputation (e.g for hold-invoices). This is also a reduced overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC forward behavior can be qualified as "whitewashing" from the routing hop viewpoint.
>
> It should be noted, this current reputation-credential architectural framework assumes credentials distribution at the endpoint of the network. However, the framework should be flexible enough for the credentials to be harvested by the LSPs, and then distributed in a secondary fashion to their spokes, when they need it, or even attached transparently thanks to trampoline. So one design intuition, there is no strong attachment of the reputation to the endpoint HTLC sender, even if the protocol is described in a "flat" view for now.
>
> Let's evaluate quickly this mitigation proposal against a few criterias emerged from recent research.
>
> The mitigation is effective, in the sense a routing hop can apply a proportional relationship between the acquisition of the reputation and the amount of liquidity resources credited in function of said reputation. In a period of steady state, the reputation acquisition cost can be downgraded to 0. In periods of channel congestion, the reputation credentials to liquidity units translation can be severed, in the limit of routing hop acceptable competitiveness.
>
> The mitigation is incentive-compatible, if the credentials are not honored by their issuers, the HTLC senders can evict them from the routing network view for a while. The successful usage of credentials can lead to more credentials allocated for longer and more capacity-intensive channel lockups. In case of HTLC failure, the failure source could be forgiven by routing hops to maintain the worthiness of the sender credentials.
>
> The mitigation can be made transparent from the user, as the credentials harvesting can be done automatically from a pre-allocated budget, similar to the fee-bumping reserves requirement introduced by anchor output. At the end of today, if we take modern browsers as an example, the average user doesn't check manually the TLS certificates (for what they're worth...).
>
> The mitigation can conserve high-level privacy, as the usage of blinded signature (or another equivalent cryptosystem breaking signature/message linking) should allow the credentials issued during a preliminary phase to be undistinguishable during the redeem/usage phase. New CPU/memory DoS vectors due to the credentials processing should be watched out.
>
> About the ease of implementation, there are few protocol messages to modify, a HTLC intercepting API is assumed as supported by the implementation, onion messages support is also implied, landing EC blinded signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms adaptations might be more serious but still reasonable. The "credentials-to-liquidity" allocation algorithms are likely the new real beast, though I don't think any reputation scheme can spare them.
>
> There could be a concern about the centralization inertia introduced by a reputation system. Intuitively, the argument can be made that any historical tracking (such as routing buckets) favor established LN incumbents at the gain of efficiency. A counter-argument can be made, a new routing hop can lower the acquisition cost of its issued credentials to attract more HTLC traffic (accepting higher jamming risk).
>
> On the ecosystem impacts, it should be studied that this proposal would impact things like inbound channel routing fees [3], ratecard [4] or flow-control valve [5] and the whole liquidity toolchain. Hopefully, we don't significantly restrain the design space for future LN protocol upgrades.
>
> On the proposal modularity and flexibility, each routing node has oversight on its routing policy, acquisition methods, credentials to liquidity rate. New acquisition methods can be experimented or deployed when ready, e.g stakes certificates with only e2e upgrade. The credentials themselves could have "innate" expiration time if we use things like short-lived ZKP [6]. The credentials framework can be extended beyond solving jamming, as a generalized risk-management framework for Bitcoin decentralized financial network, e.g transaction signature exchange ordering in multi-party transactions [7] or finding reliable Coinjoin counterparties.
>
> Feedback welcome.
>
> Cheers,
> Antoine
>
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
> [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
> [5] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
> [6] https://eprint.iacr.org/2022/190.pdf
> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221126/0a8f484f/attachment-0001.html>;

📅 Original date posted:2018-08-01 📝 Original message: ...

2023-06-09T14:51:17+02:00

In reply to nevent1q…fznu
_________________________

📅 Original date posted:2018-08-01
📝 Original message:
Thanks for this ZmnSCPxj, very interesting.

A couple of follow ups please:

1) Poon-Dryja (LN penalty), Decker-Wattenhofer and Decker-Osuntokun-Russell
(eltoo) just refer to the process for claiming funds when an old state is
broadcast? Poon-Dryja doesn't require a soft fork but
Decker-Osuntokun-Russell does?
2) How does Decker-Wattenhofer claim funds when an old state is broadcast?

On Wed, Aug 1, 2018 at 11:36 AM, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning list,
>
> Recently, somebody on the IRC channel, asked regarding smart contracts
> being transported via LN.
>
> Indeed, this is theoretically possible, provided the "smart contract" is
> implementable as a Bitcoin SCRIPT.
>
> Afterwards, I opined that, for transportation of *arbitrary* contracts,
> Poon-Dryja is superior to either Decker-Wattenhofer or
> Decker-Osuntokun-Russell.
>
> So, first, my other opinions:
>
> 1. The only smart contract you really want to transport is HTLC (or
> equivalent in scriptless script). There really is no point in transporting
> any other contract on LN. HTLCs can even be used to implement
> (nontransferable) swap options, and can be composed (at the cost of
> increasing CLTV limits on backoff) to create multi-step swaps.
>
> 2. Decker-Osuntokun-Russell "eltoo" is far superior to Poon-Dryja
> "LN-penalty" in everything else, except transportation of *arbitrary*
> contracts.
>
> Now, ultimately any Bitcoin SCRIPT may be expressed as a Boolean
> computation whether or not the contract has been fulfilled by the
> transaction that attempts to claim it.
>
> So I introduce, an arbitrary contract C, ostensibly to be transported over
> LN.
>
> And I introduce our transactions, as so: [scriptSig, redeemScript] ->
> redeeming transaction
>
> To transport C over a channel between nodes A and B, under Poon-Dryja, we
> first have a channel anchoring transaction onchain:
>
> [/*arbitrary*/, A && B] ->
>
> Now suppose the entire output is to be put into a contract C. Under
> Poon-Dryja, we create the below symmetrical series of transactions, with
> only the anchoring transaction existing onchain:
>
> [/*arbitrary*/, A && B] -> [signA signB, (revoke) || (A && B && C)] ->
> [signA signB witnessCbyA, revoke || (A && CSV)] /* held by A */
>
> [/*arbitrary*/, A && B] -> [signA signB, (revoke) || (A && B && C)] ->
> [signA signB witnessCbyB, revoke || (B && CSV)] /* held by B */
>
> Where (revoke) is the revocation key, whose derivation requires both A and
> B, and whose half is kept secret by the A (resp. B) until they both agree
> to revoke the old state.
>
> Of note is that the only additional condition added to C is (A && B),
> which makes sense since the contract is between nodes A and B (and which
> would be implicitly required by the funding transaction anyway). The
> (revoke) || does not affect the enforcement of C if the revocation key is
> not yet revealed; once the revocation key is revealed, that revokes the
> entire sequence of transactions (which is why (revoke) || appears in both
> the second and third transactions above). In particular, the
> CSV-encumberance does not affect claiming of C; it encumbers the claiming
> of the money, but does not interact with C itself. Thus, any CLTV
> conditions in C will not be interefered with by the CSV-encumberance on the
> *next* transaction.
>
> Note also that only signA and signB for the final transaction needs to be
> shared; the witnessC can presumably be fulfilled by each side themselves
> automatically.
>
> On the other hand, under Decker-Osuntokun-Russell eltoo, the transaction
> series is:
>
> [/*arbitrary*/, A && B] -> [signA signB, (CSV && A && B) || (CLTV && A &&
> B)] -> [nSequence signA signB, C]
>
> Now the above is massively simpler with no additional SCRIPT that needs to
> be written, around the transported contract C --- but the CSV in the second
> transaction, is now potentially interfering with the operation of the
> contract C, as the final transaction cannot be enforced onchain until the
> CSV has been satisfied. This is in contrast with the Poon-Dryja case,
> where the contract C appears immediately on the second transaction in the
> sequence, and can be enforced, as soon as it appears onchain.
>
> (In eltoo, the (CTLV && A && B) branch of the intermediate contract is the
> "update" path, and the CLTV required is always a past Unix Epoch time, so
> this CLTV cannot interfere with the contract C).
>
> The above consideration, is why I suppose that, *for arbitrary contracts*,
> Poon-Dryja is superior.
>
> Simply, the conclusion is that Decker-Osuntokun-Russell channels require a
> CSV that may interfere with the contract C if C is time-sensitive (i.e. has
> a CLTV or CSV itself), whereas Poon-Dryja requires CSV only for
> revocability, and the CSV cannot prevent the enforcement of time-sensitive
> C.
>
> Indeed, as I pointed out, even when transporting HTLCs,
> Decker-Osuntokun-Russell will require consideration of the CSV on top of
> the CLTV-deltas imposed by intermediary nodes, with weights complicated by
> the fact that CLTV-deltas are summed together but the highest CSV is added
> to the CLTV total, which does not mix well with typical route-finding
> algorithms (most of which assume a simple summing of costs, which
> CLTV-deltas use but CSVs on Decker-Osuntokun-Russell do not since highest
> is used).
>
> In almost all other ways, Poon-Dryja is inferior:
>
> 1. Does not use nLockTime in a sufficiently clever way.
> 2. Dangerous "toxic waste" (old revoked transactions) which (1) you
> should not recover from your backups and (2) you should not let your worst
> enemy find, because they can publish those onchain and make you LOSE MONEY.
> 3. Symmetrical chains of transactions, different for both parties,
> instead of a single chain.
>
> In addition, arbitrary contracts are not really particularly useful.
> HTLCs seem to me an important building block for digital value transfers,
> and they (and their equivalents under scriptless) are sufficient for most
> practical transfers. Thus, moving forward, Decker-Osuntokun-Russell
> remains a superior technology over Poon-Dryja.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180801/47c76b51/attachment-0001.html>;

📅 Original date posted:2023-05-11 🗒️ Summary of this ...

2023-06-08T01:21:42+02:00

In reply to nevent1q…cn8r
_________________________

📅 Original date posted:2023-05-11
🗒️ Summary of this message: The process of reporting vulnerabilities in Bitcoin Core through a small group of individuals may not be scalable for all bug reports, and public reporting may be appropriate in some cases. Delicate trade-offs exist between wider collaboration and keeping knowledge of the issue within a smaller group.
📝 Original message: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 example being the 2018 inflation bug [1]. However, it doesn't scale for all bug reports and investigations to go through this tiny funnel. For an issue that isn't going to result in loss of onchain funds and doesn't seem to present a systemic issue (e.g. network DoS attack, inflation bug) I'm of the view that opening a public issue was appropriate in this case especially as the issue initially assumed it was only impacting nodes running in debug mode (not a mode a node in production is likely to be running in).

An interesting question though and I'm certainly happy to be corrected by those who have been investigating the issue. Some delicate trade-offs involved including understanding and resolving the issue faster through wider collaboration versus keeping knowledge of the issue within a smaller group.

Thanks
Michael

[0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
[1]: https://bitcoincore.org/en/2018/09/20/notice/

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There is an open issue in bitcoin core repository which was created last week: https://github.com/bitcoin/bitcoin/issues/27586
>
> I think this should have been reported privately as vulnerability instead of creating a GitHub issue even if it worked only in debug mode. Some users in the comments have also experienced similar issues without debug build used for bitcoind. I have not noticed any decline in the number of listening nodes on bitnodes.io in last 24 hours so I am assuming this is not an issue with majority of bitcoin core nodes. However, things could have been worse and there is nothing wrong in reporting something privately if there is even 1% possibility of it being a vulnerability. I had recently reported something to LND security team based on a closed issue on GitHub which eventually was not considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449
>
> In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or try other things shared in the issue by everyone.
>
> This isn't the first time either when vulnerability was reported publicly: https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even exploited on mainnet which affected some projects.
>
> This email is just a request to consider the impact of any vulnerability if gets exploited could affect lot of things. Even the projects with no financial activity involved follow better practices.
>
> /dev/fd0
> floppy disk guy
>
> Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230511/021610dd/attachment.html>;

📅 Original date posted:2023-05-01 🗒️ Summary of this ...

2023-06-08T01:21:10+02:00

In reply to nevent1q…h52d
_________________________

📅 Original date posted:2023-05-01
🗒️ Summary of this message: A proposal to add new opcode functionality to existing scripts with no deeper introspection needed, similar to APO and CTV proposals.
📝 Original message: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 there are CISA like proposals that would need a new SegWit version (e.g. SegWit version 2). It looks to me like your proposal is in the first bucket (same as APO, CTV etc) as it is just introducing new opcode functionality to existing script with no deeper introspection needed but previous and current discussion of fraud proofs, MATT frameworks etc made me initially think it was going to require more than that.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

------- Original Message -------
On Monday, April 24th, 2023 at 20:37, Salvatore Ingala via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello list,
>
> TL;DR: the core opcodes of MATT can build vaults with a very similar design
> to OP_VAULT. Code example here:
>
> https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
>
> In my previous emails about the MATT proposal for smart contracts in
> bitcoin [1], I mostly focused on proving its generality; that is, it
> allows arbitrary smart contracts thanks to fraud proofs.
>
> While I still find this "completeness" result compelling, I spent more time
> thinking about the framework itself; the construction is not very interesting
> if it turns simple things into complicated ones. Luckily, this is not the case.
> In particular, in this email we will not merkleize anything (other than taptrees).
>
> This post describes some progress into formalizing the semantics of the core
> opcodes, and demonstrates how they could be used to create vaults that seem
> comparable to the ones built with OP_VAULT [2], despite using general purpose
> opcodes.
>
> An implementation and some minimal tests matching the content of this
> e-mail can be found in the link above, using the bitcoin-inquisition as the
> base branch.
>
> Note that the linked code is not well tested and is only intended for
> exploratory and demonstrative purposes; therefore, bugs are likely at this
> stage.
>
> ##########################
> # PART 1: MATT's core
> ##########################
>
> In this section, I will discuss plausible semantics for the core opcodes for MATT.
>
> The two core opcodes are defined below as OP_CHECKINPUTCONTRACTVERIFY and
> OP_CHECKOUTPUTCONTRACTVERIFY.
>
> (the initial posts named them OP_CHECK{INPUT,OUTPUT}COVENANTVERIFY)
>
> They enhance Script with the following capabilities:
> - decide the taptree of the output
> - embed some (dynamically computed) data in the output
> - access the embedded data in the current UTXO (if any)
>
> The opcodes below are incomplete, as they only control the output's Script and
> not the amounts; more on that below.
>
> Other than that, the semantics should be quite close to the "right" one for
> the MATT framework.
>
> ### The opcodes
>
> case OP_CHECKINPUTCONTRACTVERIFY:
> {
> // OP_CHECKINPUTCONTRACTVERIFY is only available in Tapscript
> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> // (x d -- )
> if (stack.size() < 2)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> valtype& x = stacktop(-2);
> valtype& d = stacktop(-1);
> if (x.size() != 32 || d.size() != 32)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> const XOnlyPubKey nakedXOnlyKey{Span<const unsigned char>{x.data(), x.data() + 32}};
> const uint256 data(d);
> if (!execdata.m_internal_key.has_value())
> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
> // Verify that tweak(lift_x(x), d) equals the internal pubkey
> if (!execdata.m_internal_key.value().CheckDoubleTweak(nakedXOnlyKey, &data, nullptr))
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> popstack(stack);
> popstack(stack);
> }
> break;
> case OP_CHECKOUTPUTCONTRACTVERIFY:
> {
> // OP_CHECKOUTPUTCONTRACTVERIFY is only available in Tapscript
> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> // (out_i x taptree d -- )
> if (stack.size() < 4)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> int out_i = CScriptNum(stacktop(-4), fRequireMinimal).getint();
> valtype& x = stacktop(-3);
> valtype& taptree = stacktop(-2);
> valtype& d = stacktop(-1);
> auto outps = checker.GetTxvOut();
> // Return error if the evaluation context is unavailable
> if (!outps)
> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
> if (x.size() != 32 || taptree.size() != 32 || (d.size() != 0 && d.size() != 32))
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> if (out_i < 0 || out_i >= (int)outps->size())
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> const XOnlyPubKey nakedXOnlyKey{Span<const unsigned char>{x.data(), x.data() + 32}};
> const uint256 data(d);
> const uint256 *data_ptr = (d.size() == 0 ? nullptr : &data);
> const uint256 merkle_tree(taptree);
> CScript scriptPubKey = outps->at(out_i).scriptPubKey;
> if (scriptPubKey.size() != 1 + 1 + 32 || scriptPubKey[0] != OP_1 || scriptPubKey[1] != 32)
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> const XOnlyPubKey outputXOnlyKey{Span<const unsigned char>{scriptPubKey.data() + 2, scriptPubKey.data() + 34}};
> // Verify that taptweak(tweak(lift_x(x), d), taptree) equals the internal pubkey
> if (!outputXOnlyKey.CheckDoubleTweak(nakedXOnlyKey, data_ptr, &merkle_tree))
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> popstack(stack);
> popstack(stack);
> popstack(stack);
> popstack(stack);
> }
> break;
>
> ### Commentary
>
> CheckDoubleTweak function (implemented in the branch) gets an x-only pubkey,
> optionally some data, and optionally taptree's merkle root.
> It verifies that the x-only pubkey being tested equals the given naked pubkey,
> optionally tweaked with the embedded data, optionally tweaked with the tagged
> hash of the merkle tree per BIP-0341 [3].
> Making both the tweaks optional allows to simplify the code, and also to obtain
> more compact scripts in some spending paths.
>
> In words:
>
> - OP_CHECKINPUTCONTRACTVERIFY: verify that the current input's internal key
> contains some embedded data (which would typically be passed through the
> witness stack)
> - OP_CHECKOUTPUTCONTRACTVERIFY: verify that a given output is a certain P2TR
> output script containing the desired embedded data.
>
> TBD if the tweaking used for the embedded data tweak should use a tagged hash;
> omitted for simplicity in this demo implementation.
>
> ### Amount preservation
>
> In the code above and in the linked demo implementation, the opcodes only
> operate on the scriptPubkey; a complete implementation would want to make sure
> that amounts are correctly preserved.
>
> The most direct and general way to address this would be to allow direct
> introspection on the output amounts. This has the complication that output
> amounts require 64-bits arithmetics, as discussed in the context of other
> proposals, for example: [4].
>
> One more limited approach that works well for many interesting contracts
> is that of the deferred checks, implemented in OP_VAULT [2].
> The idea is that all the amounts of the inputs that commit to the same output
> script with OP_CHECKOUTPUTCONTRACTVERIFY are added together, and the script
> interpreter requires that the amount of that output is not smaller than the
> total amount of those inputs. This check is therefore transaction-wide rather
> than being tested during the input's script evaluation.
>
> This behaviour is adequate for vaults and likely suitable for many other
> applications; however, it's not the most general approach. I didn't try to
> implement it yet, and defer the decision on the best approach to a later time.
>
> ### Extensions
>
> The opcodes above are not enough for the full generality of MATT: one would
> need to add an opcode like OP_SHA256CAT to allow the data embedding to commit
> to multiple pieces of data.
> This is not used in today's post, therefore I left it out of these code examples.
>
> It would be easy to extend OP_CHECKOUTPUTCONTRACTVERIFY to also apply for
> an arbitrary input (typically, different from the currently executed one); there
> are likely use cases for that, allowing to define contracts with more complex
> cross-input semantics, but I preferred to keep things simple.
>
> Of course, one could also entirely replace CICV/COCV with generic full
> introspection on inputs/output's program, plus opcodes for elliptic curve math
> and tagged hashes.
>
> ##########################
> # PART 2: Vaults with MATT
> ##########################
>
> In the rest of this post, I will document the first attempt at creating a vault
> using the opcodes described.
>
> While not an attempt at cloning exactly the functionality of OP_VAULT [2],
> it borrows heavily from the excellent work that was done there.
>
> In particular, it also inherits the choice of using OP_CTV as a primitive,
> building on top of the bitcoin-inquisition's current branch that has already
> merged OP_CTV. Reasonable vaults would be possible without CTV, but they
> would be less efficient, particularly in the case of sending to many addresses
> in a single unvaulting flow.
>
> ### Distilling OP_VAULT
>
> Abstracting from the implementation details, I mentally model a vault as a
> simple state machine with 2 states: [V] and [U]:
>
> [V]: the initial vault UTXO(s);
> [U]: the utxo produced by the "trigger transaction" during unvaulting.
>
> On the typical path: one or more [V] UTXOs are sent to the [U] state, and after
> a timelock set on [U] expires, [U] is spent to one or several destinations.
> Crucially, the destination outputs and amounts are already decided when [V] is
> spent into [U].
>
> At any time before the funds are spent from [U], they can always be spent by
> sending them to some specified recovery path.
>
> There are two key elements that are part of OP_VAULT's semantics, and could be
> generalized:
>
> − Forcing the script/amount of the next stepon
> − Storing some data for future Script's access (in the vault's case, a hash
> that commits to the final withdrawal transaction).
>
> CICV/COCV generalize both to arbitrary scripts (taptrees) and state machines,
> and to dynamical and witness-dependent data embedded in the pubkey of a P2TR
> output.
>
> ### Vault parameters
>
> A contract that represents a vault has the following parameters (hardcoded in
> the script when the vault is created):
>
> - alternate_pk: a key that can be used any time.
> - spend_delay: the relative timelock before the withdrawal can be finalized;
> - recover_pk: a pubkey for a P2TR output where funds can be sent at any time.
>
> The alternate_pk is a pubkey that can optionally be used as the key-path
> spending condition for both states [V] and [U]. If such a spending condition is not
> desired, it can be replaced with a NUMS point, making the key-path unspendable.
>
> The spend_delay is the number of blocks that must be mined before the final
> withdrawal transaction
>
> In this example we also use an unvault_pk needed to authorize the unvaulting
> process (that is, spend [V] into [U]); this could be replaced with any miniscript
> or other conditions expressible in Script.
>
> ### P2TR structure for [V] (vault)
>
> internal key: alternate_pk
>
> Script 1: "trigger"
> # witness: <out_i> <ctv-hash>
> {
> <alternate_pk>,
> <merkle root of U's taptree>,
> 2, OP_ROLL,
> OP_CHECKOUTPUTCONTRACTVERIFY,
>
> <unvault_pk>
> OP_CHECKSIG
> }
>
> Script 2: "recover"
> # witness: <out_i>
> {
> recover_pk,
> OP_0, # no data tweak
> OP_0, # no taptweak
> OP_CHECKOUTPUTCONTRACTVERIFY,
> OP_TRUE
> }
>
> The "trigger" script requires in the witness an output index and the ctv-hash
> that describes the withdrawal transaction.
> COCV forces the output to contain the ctv-hash as embedded data.
> That's followed by the unvaulting condition − in this example, a simple
> signature check.
>
> The "recover" script doesn't require any signature, and it simply forces
> the output specified in the witness to be a P2TR output with recover_pk as its
> pubkey.
>
> (Omitting the "recover" script in [V] would reduce the size of the witness by
> 32 bytes in the expected case, and might be preferred for some users)
>
> ### P2TR structure for [U] (unvaulting state)
>
> internal key: alternate_pk (tweaked with ctv_hash)
>
> Script 1: "withdrawal"
> # witness: <ctv_hash>
> {
> OP_DUP,
>
> # check that the top of the stack is the
> # embedded data in the current input
> <alternate_pk>, OP_SWAP,
> OP_CHECKINPUTCONTRACTVERIFY,
>
> # Check timelock
> <spend_delay>,
> OP_CHECKSEQUENCEVERIFY,
> OP_DROP,
>
> # Check that the transaction output is as expected
> OP_CHECKTEMPLATEVERIFY
> }
>
> Script 2: "recover"
> # witness: <out_i>
> {
> <recover_pk>,
> OP_0,
> OP_0,
> OP_CHECKOUTPUTCONTRACTVERIFY,
> OP_TRUE
> }
>
> The "withdrawal" finalizes the transaction, by checking that the timelock expired and
> the outputs satisfy the CTV hash that was committed to in the previous transaction.
>
> The "recover" script is identical as before.
>
> ### Differences with OP_VAULT vaults
>
> Here I refer to the latest version of OP_VAULT at the time of writing. [5]
> It is not a thorough analysis.
>
> Unlike the implementation based on OP_VAULT, the [V] utxos don't have an option
> to add an additional output that is sent back to the same exact vault.
> Supporting this use case seems to require a more general way of handling the
> distribution of amounts than what I discussed in the section above: that would
> in fact need to be generalized to the case of multiple
> OP_CHECKOUTPUTCONTRACTVERIFY opcodes executed for the same input.
>
> By separating the ctv-hash (which is considered "data") from the scripts in the
> taptree, one entirely avoids the need to dynamically create taptrees and
> replace leaves in the covenant-encumbered UTXOs; in fact, the taptrees of [V]
> and [U] are already set in stone when [V] utxos are created, and only the
> "data" portion of [U]'s scriptPubKey is dynamically computed. In my opinion,
> this makes it substantially easier to program "state machines" that control the
> behavior of coins, of which vaults are a special case.
>
> I hope you'll find this interesting, and look forward to your comments.
>
> Salvatore Ingala
>
> [1] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021223.html
> [2] - https://github.com/bitcoin/bips/pull/1421
> [3] - https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
> [4] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html
> [5] - https://github.com/bitcoin/bips/blob/7112f308b356cdf0c51d917dbdc1b98e30621f80/bip-0345.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/6f94a2a7/attachment-0001.html>;

📅 Original date posted:2023-04-19 🗒️ Summary of this ...

2023-06-08T01:20:37+02:00

In reply to nevent1q…dd7l
_________________________

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Communication on merge decisions in Bitcoin Core is important to avoid frustration and chaos. Defining "enough" reviews and ACKs is crucial, especially for high-risk pull requests. Lack of communication can lead to controversial decisions and potential harm to the project's value. Creating a nonprofit to fund Bitcoin Core contributors is a solution, but it's irrelevant if current maintainers refuse to discuss merge decisions and block long-term contributors from becoming maintainers.
📝 Original message:Hi alicexbt

> I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.

The problem is defining what is "enough". "Enough" is determined by the quality of the review, the expertise of the reviewer(s), the complexity of the pull request and most importantly what risks a merge of the pull request poses. When there is zero communication on merge decisions (both merging and not merging over a long period of time) it creates frustration and worse vacuums and soft fork activation chaos. It is a complete black box. The vast majority of merge decisions are uncontroversial but it would still be nice to have a comment saying something like:

"This pull request only has 2 ACKs but it is low risk, relatively simple and is unlikely to be reviewed by anybody else in the near term"

"This pull request is a consensus change, extremely high risk and is unlikely to be merged in the near term"

On the rare occasions when merge decisions are controversial communication becomes a lot more important. If some maintainers aren't responsive on IRC and refuse to discuss merge decisions what can we expect in future? We wake up one day, a contentious consensus change has been merged with little review in advance of a release window and the maintainer won't discuss why they have merged it. This isn't a toy anymore, it is supporting hundreds of billions of dollars of value and could end up supporting a lot more. It is surely completely unreasonable to let maintainers merge or not merge whatever they like with no explanation and no willingness to discuss their merge decisions.

> So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core."

As I responded on the pull request if any long term contributor from this alternative nonprofit is blocked from being a maintainer and current maintainers refuse to discuss merge decisions it is irrelevant. To contribute you need a maintainer to merge your pull request(s) and to spend your review time wisely you need to know what pull request(s) could viably be merged by a maintainer. Otherwise you're just wasting your time. We not only have opacity on merge decisions for normal pull requests (e.g. code) we also now have opacity on decisions for the addition of new maintainers. I was always under the impression that any long term contributor who demonstrated over time that they were sufficiently competent, qualified and able to contribute both through opening pull requests and reviewing other people's pull requests could become a maintainer. To me and many others (until it was blocked by two maintainers for 5 months) Vasil met this criteria. This not only impacts Vasil's and others' commitment to the project but it impacts what pull requests are ultimately reviewed and merged. What is the point of spending time opening or reviewing a pull request if the current maintainers won't look at it or are unqualified to review it and hence won't merge it?

Gloria's advice effectively boils down to spend months setting up a non-profit, spend years becoming a long term contributor to the project and then you can have the honor of being blocked from becoming a maintainer and have your contributions stunted by the current maintainers with no recourse or ability to discuss their merge decisions. So yeah thanks for repeating that advice but I'm sure most would rather pass and do something else.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Wednesday, April 19th, 2023 at 13:24, alicexbt <alicexbt at protonmail.com> wrote:

> Hi Michael,
>
> I was initially sad about the politics in Vasil's pull request, written about it and also tried to document the process. Still think he deserves to be a maintainer. Although I have some counter arguments:
>
> > Maintainers merge a pull request and provide no commentary on why they’ve merged it.
>
>
> I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.
>
> > Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it
>
>
> This could be considered normal in pull requests that involve code changes.
>
> > The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC.
>
>
> Unfair to expect every human to behave the same or work similarly. Sometimes the unresponsiveness could be to avoid controversies and heated debates that go off-topic.
>
> > One farcical recent example 0 was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>
>
> - Maintainers should be free to avoid involvement in a pull request. As long as a subset of maintainers have an opinion on the pull request, things should be fine.
> - I agree with Gloria's comment: "I had not NACKed this either because my opinion could change over time, NACKs are sometimes needlessly interpreted as personal attacks, and Brink has been antagonized on Twitter each time multiple grantees have similar opinions about this. So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core." Last part of this comment also solves the problem shared in other thread related to new bitcoin implementation. Brink needs some competition and bitcoin core needs more reviewers.
> - I also agree with Andrew's comment: "frankly, I think opinions aren't being shared because of potential backlash from aggressive users such as yourself and bytes1440000"
>
> > Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
>
>
> - I don't see anything wrong with sharing honest opinion if someone agrees with the concept. It does not make a pull request ready to get merged.
> - utxos.org is an external site maintained by Jeremy with opinions on BIP 119. Everyone is free to maintain such lists and I think you had also created one as GitHub gist.
>
> > I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that 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
>
> 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
> 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > 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 commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example 0 was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
> >
> > A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
> >
> > Another farcical recent(ish) example was the CTV pull request 1 that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious 3 but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
> >
> > I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition 5) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
> >
> > As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

📅 Original date posted:2023-04-19 🗒️ Summary of this ...

2023-06-08T01:20:35+02:00

In reply to nevent1q…j95g
_________________________

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Discussion on BIP 118 and BIP 119 for Bitcoin covenant tech. James O'Beirne needs BIP 119/OP_CTV for his latest vault design. More experimentation needed.
📝 Original message:Hi Erik

> yes, the code itself was far less contentious than the weird stab at forking the network
>
> there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant 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

This is moving off the intended subject of the email although latest thoughts on BIP 118 and BIP 119 are an interesting separate topic. Perhaps start a new thread? The latest afaik is that both have been merged in bitcoin-inquisition [0] (default signet) and James O'Beirne concluded that he needed BIP 119/OP_CTV for his latest vault design that includes a new proposed opcode OP_VAULT (BIP 345) [1]. Designing and building vaults with the various proposed opcodes and sighash flags (and Simplicity when it is ready) is definitely what I hoped to see after the chaos of the attempted CTV activation. Hopefully more people will be drawn into this research and development area, I think it is a really interesting one [2] so I'm a bit bemused more people aren't following James and the Revault team and doing their own research and experimentation. I think darosior's (Revault) current view [3] is BIP 118/APO is sufficient for the vaults he wants to build. But yeah needs more informed views and you only really get a more informed view by trying to design and build things and realizing what you need or what is missing. It isn't convincing to embark on a soft fork activation process just because a couple of informed individuals want it.

Thanks
Michael

[0]: https://github.com/bitcoin-inquisition/bitcoin
[1]: https://github.com/bitcoin/bips/pull/1421
[2]: https://www.youtube.com/watch?v=S2lTfS5qMJE
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020276.html

--
Michael Folkson
Email: michaelfolkson 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 01:56, Erik Aronesty <erik at q32.com> wrote:

> yes, the code itself was far less contentious than the weird stab at forking the network
>
> there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant 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 <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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 commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>>
>> A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
>>
>> Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.
>>
>> I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
>>
>> As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
>>
>> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>>
>> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>>
>> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>>
>> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>
>> [4]: https://utxos.org/signals/
>>
>> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>>
>> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230419/77bcfdc9/attachment-0001.html>;

📅 Original date posted:2023-04-18 🗒️ Summary of this ...

2023-06-08T01:20:34+02:00

In reply to nevent1q…yqcw
_________________________

📅 Original date posted:2023-04-18
🗒️ Summary of this message: Communication has been a long-standing issue in Bitcoin Core, with maintainers often failing to provide rationale for merge decisions or engage in discussion. This can lead to frustration and delays for pull request authors.
📝 Original message: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 commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.

A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.

Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.

I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.

As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.

[0]: https://github.com/bitcoin/bitcoin/pull/25871

[1]: https://github.com/bitcoin/bitcoin/pull/21702

[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html

[3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

[4]: https://utxos.org/signals/

[5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html

[6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230418/dd827725/attachment-0001.html>;

📅 Original date posted:2023-02-08 🗒️ Summary of this ...

2023-06-08T01:19:27+02:00

In reply to nevent1q…p0gs
_________________________

📅 Original date posted:2023-02-08
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated multiple times, incurring different Tapfee rates. The countermeasure is to know the entire Taptree.
📝 Original message: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's Tapspend.

I wouldn't say it is a "bug" unless there is a remedy for the bug that wasn't (and retrospectively should have been) included in the Taproot design. In retrospect and assuming you could redesign the Taproot consensus rules again today would you prevent spending from a valid P2TR address if a repeated Tapleaf hash was used to prove that a spending path was embedded in a Taproot tree? That's the only thing I can think of to attempt to remedy this "bug" and it would only be a partial protection as proving a spending path exists within a Taproot tree only requires a subset of the Tapleaf hashes.

I only point this out because there seems to be a push to find "bugs" and "accidental blowups" in the Taproot design currently. No problem with this if there are any, they should definitely be highlighted and discussed if they do exist. The nearest to a possible inferior design decision thus far that I'm aware of is x-only pubkeys in BIP340 [0].

Thanks
Michael

[0]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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's Tapspend.
>
> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>>>
>>> <snip>
>>>
>>> [1] https://bitcoin.sipa.be/miniscript/
>>> [2] In Taproot, if you want to prevent signatures migrating to another
>>> branch or within a branch, you can use the CODESEPARATOR opcode
>>> which was redisegned in Taproot for exactly this purpose... we
>>> really did about witness malleation in its design!
>>
>> In Taproot the tapleaf hash is always covered by the signature (though
>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>> between tapbranches.
>>
>> I had thought this was the case, but then I re-confused myself by
>> reading BIP 341 .... which has much of the sighash specified, but not
>> all of it! The tapleaf hash is added in BIP 342.
>>
>>>
>>> If you want to prevent signatures from moving around *within* a
>>> branch,
>>>
>>
>> And this sentence I just meant to delete :)
>>
>> --
>> Andrew Poelstra
>> Director of Research, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/6a71e08e/attachment.html>;

📅 Original date posted:2023-01-14 🗒️ Summary of this ...

2023-06-08T01:18:38+02:00

In reply to nevent1q…lvut
_________________________

📅 Original date posted:2023-01-14
🗒️ Summary of this message: Michael Folkson suggests that a bare bones Knots style Bitcoin implementation integrated with Core Lightning may be the future due to dysfunction in Bitcoin Core's management.
📝 Original message: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 new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.

The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.

Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.

I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.

Thanks
Michael

[0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230114/306cd5ac/attachment-0001.html>;

📅 Original date posted:2022-12-05 📝 Original message:> ...

2023-06-08T01:17:21+02:00

In reply to nevent1q…fvu9
_________________________

📅 Original date posted:2022-12-05
📝 Original message:> 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 turning a mempool policy issue (users have always been free to choose whatever policy they like with zero chain split risk) into a consensus issue and a contentious soft fork issue at that would not be advised. I highly doubt any of the long term Muun contributors would want to support a contentious soft fork and fight a consensus rule war on this.

[0]: https://coingeek.com/gap600-ceo-daniel-lipshitz-talks-bsv-powered-stablecoins-on-coingeek-backstage-video/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Monday, December 5th, 2022 at 16:12, Rijndael via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand a transaction to a miner privately. I hand a transaction to a miner with some reasonable fee, and then I go and broadcast a different transaction with a minimal fee that spends the same inputs. The whole network (including the miner I handed the tx to) could all be running with a strict first-seen mempool policy, but we can still have a situation where the miner creates a block with a different transaction from what you see in your mempool. If anytime this happens, the nodes running your proposed rule drop the block, then anyone can fork those nodes off the network whenever they want.
>
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt to) promise consistency across mempools. Making a consensus rule that enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
> - rijndael
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
>> The only option I see against the attack Peter Todd is doing to opt-in RBF and 0Conf bitcoin usage is working on a bitcoin core implementation that stops propagation of full-rbf replaced blocks. Running multiple of such nodes on the network will add a risk to miners that enable full-rbf that would work as an incentive against that.
>>
>> Obviously that would require adding an option on bitcoin core (that is not technically but politically difficult to implement as Petter Todd already have commit access to the main repository).
>>
>> 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. As far as I understand the percolation model, with 10 to 20 nodes running such a rule would create a significant risk for full-rbf miners.
>>
>> Regards.
>>
>> --- Eloy
>>
>> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev wrote:
>>>> On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote:
>>>> > FYI I've gotten a few hundred dollars worth of donations to this effort, and
>>>> > have raised the reward to about 0.02 BTC, or $400 USD at current prices.
>>>>
>>>> Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>>
>>> I'm turning it back on when (if) the mempool settles down. I've got more than
>>> enough donations to give another run at it (the majority was donated privately
>>> FWIW). There's a risk of the mempool filling up again of course; hard to avoid
>>> that.
>>>
>>> Right now of course it's really easy to double spend with the obvious
>>> low-fee/high-fee method as the min relay fee keeps shifting.
>>>
>>>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>>>>
>>>> The block it was claimed in seems to have been about an hour after the
>>>> default mempool filled up:
>>>>
>>>> https://twitter.com/murchandamus/status/1592274621977477120
>>>>
>>>> That block actually seems to have included two
>>>> alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>>>> (309sat/vb):
>>>>
>>>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>>
>>> The second is because I turned down the full-rbf reward to more normal fee
>>> levels. There's also another full-rbf double-spend from the Bob calendar, along
>>> the same lines: 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>>
>>> I double-spent the txin of the high fee tx that got mined. But I mistakenly had
>>> RBF enabled in that double-spend, so while it propagated initially, I believe
>>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb tx.
>>>
>>>> Timeline (utc) to me looks like:
>>>>
>>>> - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb
>>>> - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>>>> is announced and propogates widely (1.2sat/vb)
>>>> - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>>>> is announced and propogates widely (1.2sat/vb)
>>>> - 21:52 - ba967010 tx is announced and propogates widely, since
>>>> conflicting tx 746daab9 has been removed from default
>>>> mempools
>>>> - 21:53 - murch tweets about default mempool filling up
>>>> - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>>>> conflicting tx f503868 has already been removed from default
>>>> mempools
>>>
>>> Is that 22:03 time for 397 from your node's logs? It was originally announced
>>> hours earlier. From one of my full-rbf nodes:
>>>
>>> 2022-11-14T14:08:37Z [mempool] replacing tx 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for 0.00468 additional fees, -1 delta bytes
>>>
>>>> - 22:35 - block 763189 is mined
>>>> - 22:39 - block 763190 is mined
>>>> - 23:11 - block 763191 is mined
>>>> - 23:17 - block 763192 is mined including 397dcbe4
>>>>
>>>> miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>>>> first three blocks, and gives similar mempool ages for those txs to what
>>>> my logs report:
>>>>
>>>> https://miningpool.observer/template-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>>>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>>>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>>>>
>>>> That presumably means those pools (AntPool twice and "unknown") are
>>>> running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>>
>>> To be clear, you think that AntPool and that other exchange is running with a
>>> larger than normal max mempool size limit? You mean those miners *did* keep the
>>> earlier 1.2sat/vb tx?
>>>
>>>> The txs were mined by Foundry:
>>>>
>>>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>>>>
>>>> This seems to be pretty good evidence that we currently don't have any
>>>> significant hashrate mining with fullrbf policies (<0.5% if there was a
>>>> high fee replacement available prior to every block having been mined),
>>>> despite the bounty having been collected.
>>>
>>> Oh, we can put much lower bounds on that. I've been running OTS calendars with
>>> full-rbf replacements for a few months without clear evidence of a full-rbf
>>> replacement. While there was good reason to think some miners were mining
>>> full-rbf before a few years back, they probably didn't bother to reapply their
>>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/60f49caa/attachment-0001.html>;

📅 Original date posted:2022-09-12 📝 Original message:Hi Ali ...

2023-06-08T01:13:19+02:00

In reply to nevent1q…44qa
_________________________

📅 Original date posted:2022-09-12
📝 Original message: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_CHECKMULTISIG, OP_CHECKSIGADD) or key aggregation multisig with only a single signature going onchain (e.g. OP_CHECKSIG), requires private key(s) and hence has concerns with regards to security and theft of those private keys. Clearly funds locked behind any kind multisig arrangement is better than no multisig arrangement as otherwise theft of a single private key can result in loss of funds.

With regards to connectivity or interactivity key aggregation multisig does increase the interactivity requirements so if you wanted to minimize interactivity requirements you'd probably stick to OP_CHECKMULTISIG, OP_CHECKSIGADD that only requires you to generate a signature and then pass it onto the next signer.

> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.

I'm not sure what you mean here. In the realm of generating signatures there isn't really a concept of a "lite node". That makes more sense in the realm of verification where you may or may not be doing full verification. In the generating signatures realm you are either contributing to the aggregated signature or generating a standalone signature yourself. If you are not doing either of those and aren't doing some kind of coordination then you are entirely irrelevant to the scheme. In the case of Liquid there is a 11-of-15 threshold signature arrangement where currently 11 signatures go onchain when funds are moved but if Liquid used a key aggregation scheme like FROST only a single signature would need to go onchain. With regards to centralization/decentralization you could increase the 11-of-15 to say a 22-of-30. Or you could have a nested MuSig/FROST scheme behind one of the 11 signers of the 11-of-15. But you can't get around the fact that you are either generating a signature that ultimately contributes to the moving of the funds or you aren't. If you aren't generating a signature then you are just verifying the signature(s) that go onchain like all other full nodes on the network.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Sunday, September 11th, 2022 at 08:43, Ali Sherief <ali at notatether.com> wrote:

> Hi Michael.
>
> I read the transcript of the Socratic and I have to say that it is quite detailed and touches a lot of problems including the well-known theft/offline problems which also has forms elsewhere such as for passwords.
>
> My question is, 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?
>
> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.
>
> - Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220912/f261ff41/attachment.html>;

📅 Original date posted:2022-09-08 📝 Original message:Hi We ...

2023-06-08T01:13:19+02:00

In reply to nevent1q…le06
_________________________

📅 Original date posted:2022-09-08
📝 Original message: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 reading list collecting together a number of resources on MuSig(2), FROST, ROAST etc is here [3].

We discussed a retrospective look at BIP340, handling x-only public keys in MuSig2 and the proposed TLUV covenant opcode, the history from initially broken MuSig1 through MuSig-DN to MuSig2, how MuSig2 and FROST compare for multisig schemes (i.e. n-of-n), why MuSig2 doesn't use proofs of possession and the current state of the draft MuSig2 BIP.

We covered a lot of topics and it was rather long (~2.5 hours) so check out the transcript or video if you are interested in any of the above topics. Many thanks to those who participated.

Jonas Nick recently tweeted [4] that the MuSig2 BIP [5] is approaching a stable version 1.0 which should be helpful to those who are interested (or already!) using it in the wild.

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020772.html
[1]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/
[2]: https://www.youtube.com/watch?v=TpyK_ayKlj0
[3]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c
[4}: https://twitter.com/n1ckler/status/1567168267025874944
[5]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220908/f6918882/attachment.html>;

📅 Original date posted:2022-07-23 📝 Original message:Hi ...

2023-06-08T01:12:02+02:00

In reply to nevent1q…quts
_________________________

📅 Original date posted:2022-07-23
📝 Original message: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 the effects of burn out from the activation drama earlier in the year. No process can guarantee community consensus at the end of it especially if some of those who we consider experts in this area only tentatively participate. The personal attacks and ignoring of views counter to those who were pushing an activation attempt really should not be repeated. (Especially if this process is seeking to include those who we consider experts in this area and don't want their participation to be perceived as tacit approval of whatever is attempted next.)

As long as this is understood and agreed by participants I can only see positives coming out of this. But please let's not repeat the activation drama from earlier in the year because a process with a subset of those who we would consider experts in this area come to a view and then try to ram that view down everyone's throats by attempting activation at the end of it. Maybe this will result in community consensus on covenant proposal(s) going forward but also maybe it won't. Either outcome is fine. At the very least research will progress and work will be carried out that moves us in a positive direction.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Wednesday, July 20th, 2022 at 21:42, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> Discussions on covenants have been prolific and intense on this mailing list and within the wider Bitcoin technical circles, I believe however without succeeding to reach consensus on any new set of contracting primitives satisfying the requirements of known covenant-enabled use-cases. I think that's a fact to deplore as covenants would not only offer vast extensions of the capabilities of Bitcoin as a system, i.e enabling new types of multi-party contract protocols. But also empowering Bitcoin on its fundamental value propositions of store of value (e.g by making vaults more flexible) and payment system (e.g by making realistic channel factories/payment pools).
>
> If we retain as a covenant definition, a spending constraint restricting the transaction to which the spent UTXO can be spent, and enabling to program contracts/protocols at the transaction-level instead of the script-level, the list of Script primitives proposed during the last years has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all the listed primitives are at different states of formalization, some already fully fleshed-out in BIPs, other still ideas on whiteboard, yet they all extend the range of workable multi-party contract protocols.
>
> Indeed this range has grown wild. Without aiming to be exhaustive (I'm certainly missing some interesting proposals lost in the abyss of bitcointalk.org), we can mention the following use-cases: multi-party stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" layered commitments [14], programmable vaults [15], multi-events contracts [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral lending [19], ...
>
> Minding all those facts, I would say the task of technical evaluation of any covenant proposal sounds at least two fold. There is first reasoning about the enabled protocols on a range of criterias such as scalability, efficiency, simplicity, extensibility, robustness, data confidentiality, etc. Asking questions like what are the interactions between layers, if any ? Or how robust is the protocol, not just interactivity failure between participant nodes but in the face of mempools spikes or internet disruption ? Or if the performance is still acceptable on shared resources like blockspace or routing tables if everyone is using this protocol ? Or if the protocol minimizes regulatory attack surface or centralization vectors ?
>
> Though once this step is achieved, there is still more reasoning work to evaluate how good a fit is a proposed Script primitive, the efficiency/simplicity/ease to use trade-offs, but also if there are no functionality overlap or hard constraints on the use-cases design themselves or evolvability w.rt future Script extensions or generalization of the opcode operations.
>
> Moreover, if you would like your evaluation of a covenant proposal to be complete, I don't believe you can squeeze the implications with the mempool rules and combination with any consistent fee-bumping strategy. To say things politely, those areas have been a quagmire of vulnerabilities, attacks and defects for second-layers Bitcoin protocols during the last years [20].
>
> Considering the abundant problem-space offered by covenants, I believe there is a reasonable groundwork to pursue in building the use-cases understanding (e.g prototype, pseudo-specification, documentation, ...) and building consensus on the framework of criterias on which to evaluate them [21]. It might raise a really high bar for any covenant proposal compared to previous softforks, however I think it would adequately reflect the growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open specification process, in the same spirit as we have with the BOLTs or dlcspecs. We would have regular meetings (biweekly/monthly ?), an open agenda where topics of discussion can be pinned in advance and documentation artifacts would be built with time driven by consensus (e.g 1st phase could be to collect, pseudo-specify and find champion(s) for known use-cases ?) and no timeframe. Starting date could be September / October / November (later, 2023 ?), giving time for anyone interested in such a covenant process to allocate development and contribution bandwidth in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2 onchain support meetings last year, I think it would be better to keep the agenda open, loose and free as much we can in a "burn-the-roadmap" spirit, avoiding to create a sense of commitment or perceived signaling in the process participants towards any covenant solution. I would guess things to be experimental and evolutionary and folks to spend the first meetings actually to express what they would like the covenant process to be about (and yes that means if you're a domain expert and you find the pace of things too slow sometimes, you have to learn to handle your own frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to have rotating meeting chairs and multiple covenant documentation archivists. I'm super happy to spend the time and energy bootstrapping well such covenant process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look like. We might end up concluding that complex covenants are too unsafe by enabling sophisticated MEV-attacks against LN [22]. Or even if there is an emergent technical consensus, it doesn't mean there is a real market interest for such covenant solutions. That said, I'm not sure if it's really a subject of concern when you're reasoning as a scientist/engineer and you value technical statements in terms of accuracy, systematic relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact that covenants are required building blocks to enable scalable payments pools design like CoinPool. I believe payments pools are a) cool and b) a good shot at scaling Bitcoin as a payment system once we have reached scalability limits of Lightning, still under the same security model for users. However, as a community we might sense it's not the good timing for a covenant process. I'm really fine with that outcome as there are still holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft forks, the hard part isn't about coming up with the best technical solution to a set of problems but in the iterative process where all voices are listened to reach (or not) consensus on what is actually meant by "best" and if the problems are accurate. The real physics of Bitcoin is the physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant specification process looks like. As usual, all opinions and mistakes are my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
> [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
> [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
> [9] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
> [12] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
> [13] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
> [14] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16] https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18] https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220723/7b57f683/attachment-0001.html>;

📅 Original date posted:2022-07-17 📝 Original message:Thanks ...

2023-06-08T01:11:19+02:00

In reply to nevent1q…4wpv
_________________________

📅 Original date posted:2022-07-17
📝 Original message: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 signature batch verification (no aggregation of signatures) can be done today but half aggregation and CISA would need a soft fork and potentially a new output type in addition.

(I know this work is in its early stages and won't be proposed for a soft fork anytime soon. A few of us are just trying to get a basic sketch in our heads of what they require and whether they could be enabled in the same upgrade.)

[0]: https://bitcoin.stackexchange.com/questions/106240/will-cross-input-signature-aggregation-need-a-new-output-type/

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Friday, July 8th, 2022 at 16:53, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Half-aggregation has been mentioned several times on this list in various
> contexts. To have a solid basis for discussing applications of half-aggregation,
> I think it's helpful to have a concrete specification of the scheme and a place
> for collecting supplemental information like references to cryptographic
> security proofs. You can find the BIP draft at
>
> https://github.com/ElementsProject/cross-input-aggregation/blob/master/half-aggregation.mediawiki
>
> Similar to BIP-340, this BIP draft specifies only the cryptographic scheme and
> does not prescribe specific applications. It has not received an extensive
> security review yet. Thanks to Elliott Jin and Tim Ruffing for the review so
> far. One new feature that the specified scheme has is "incremental aggregation"
> which allows aggregating additional BIP-340 signatures into an existing
> half-aggregate signature.
>
> While BIP-340 has a pseudocode specification and a reference implementation in
> python, this BIP draft has a formal specification written in hacspec [0] and
> auxiliary pseudocode. The formal specification is a mathematically precise
> description of the scheme, which paves the way for computer-aided formal proofs.
> Software tools ("proof assistants") allow proving properties about the formal
> specification ("no integer overflow") and apply formal software verification
> ("implementation is behaviorally equivalent to the spec"). I don't have concrete
> plans (nor the skillset) to use these techniques. Still, I think this is an
> exciting area to explore because it has the potential to increase the Bitcoin
> ecosystem's robustness significantly and has little downside. Since hacspec's
> syntax is a subset of Rust's syntax, one can use the standard rust toolchain to
> compile, execute and test the specification.
>
> You can find a blog post that gives a broader context at
> https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/
>
> [0] https://github.com/hacspec/hacspec
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-04-24 📝 Original message:Hi ...

2023-06-08T01:07:54+02:00

In reply to nevent1q…q6kv
_________________________

📅 Original date posted:2022-04-24
📝 Original message:Hi Jorge

> Can we agree now that resisting a bip8 proposal is simpler and cleaner than resisting a speedy trial proposal?

Personally I'd rather stick to one challenge at a time :) Currently we are facing a contentious soft fork activation attempt of CTV using an alternative client which we expect [1] to be a Speedy Trial deployment. Once this is resolved we can discuss the lessons and observations that come out of this.

> Is there any PR to actively resist the proposal on bitcoin core?

Not currently. Unless this becomes really, really messy and starts to pose a true existential threat to Bitcoin itself I think it best that attempts to actively resist the proposal are done outside of Bitcoin Core in an alternative client(s). Contrary to what some CTV proponents say getting anything consensus related into Bitcoin Core is extremely difficult (especially at short notice). There is no BDFL or Linus Torvalds like figure, there are a large number of contributors (and maintainers) who all have differing personal views. Hence directing people to have this discussion on a particular PR in the Bitcoin Core repo seems to me to be counterproductive and a massive distraction to other work that is going on on Bitcoin Core. We've already started to see online attacks on Bitcoin Core by CTV proponents [2] claiming an "old guard trying to assert dictatorship over the Bitcoin protocol". It is nonsense of course but directing that nonsense to the Bitcoin Core repo is surely not the right way to go.

As I've said in previous emails there is a Libera (and Freenode now) IRC channel ##ursf that has been set up to discuss an alternative client. We'll get a conversation log up too. And of course we wait for confirmation on what the Speedy Trial deployment parameters for this attempted CTV soft fork are going to be.

[1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/
[2]: https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Saturday, April 23rd, 2022 at 21:40, Jorge Timón <jtimon at jtimon.cc> wrote:

> I've been calling them "controversial softforks" for long.
> I hate to be right some times, but I guess I'm happy that I'm not the only one who distrusts jeremy rubin anymore.
>
> Can we agree now that resisting a bip8 proposal is simpler and cleaner than resisting a speedy trial proposal?
> I guess now we don't need 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 <bitcoin-dev at lists.linuxfoundation.org> 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 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 skeptical.)
>>
>> Understandably this has angered and surprised a few people including some of those who have voiced opposition to a CTV soft fork activation being attempted in the first place [2].
>>
>> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate (and older versions) does not include any CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some chance CTV was to activate through some other software release Bitcoin Core releases would not apply CTV rules but they also wouldn't reject blocks that apply CTV rules. Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
>>
>> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm open to better names. I certainly don't want to discourage those who dislike or oppose UASFs from contributing to this effort and potentially ultimately running a URSF release. If you don't want this rushed CTV soft fork to activate we are all on the same side whatever we call it.
>>
>> For now I've set up a ##ursf channel on Libera IRC to monitor developments and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
>>
>> The intention of this would be to provide additional direction and incentive to miners that the community does not want this soft fork to be activated. To repeat running a Bitcoin Core release will not signal for a CTV soft fork out the box. If a miner runs a Bitcoin Core release it will not signal for CTV.
>>
>> Apologies that this is rushed. But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>> [2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/18ffef7b/attachment-0001.html>;

📅 Original date posted:2022-04-22 📝 Original ...

2023-06-08T01:07:53+02:00

In reply to nevent1q…eqjy
_________________________

📅 Original date posted:2022-04-22
📝 Original message:I'm going to keep this short as I'm sure you are not interested in discussion on supposedly "unhinged" takes. Plus I know you support this soft fork activation attempt, you have heard the arguments from various people against attempting it and if you don't believe by now that soft forks should have community consensus before they are attempted nothing will convince you.

> Resisting changes that don't affect you

The consensus rules are essentially what define Bitcoin. Bitcoin is nothing without well defined and rarely changing consensus rules. If they can be changed by a subset of the community against the wishes of another subset of the community then we may as well accept that all soft fork proposals will eventually get activated because all soft fork proposals will be able to get a subset of the community to support them. (There are a lot of proposals out there.) Decentralized decision making requires that we collectively set high bars when considering making changes to the most important and dangerous part of Bitcoin. Once consensus rules are changed they generally need a hard fork to revert. This is Bitcoin 101. I really shouldn't need to explain this to you. There was a lot of work done by a large number of people to slowly build community consensus around Taproot. You seem to be arguing that that work was pointless because ultimately Taproot doesn't affect the community. If you don't like it don't use it right? Just keep quiet? Nothing to do with you? Gosh....

> You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement.

Can you provide a link? If there was community consensus a single NACK from me would be pointless. I'm assuming that's the context in which it was said. I've been consistent on wanting community consensus before any soft fork is attempted. If there is community consensus it doesn't matter what I think. This is not a proposal that currently has community consensus and you are seeking to attempt to activate it anyway. Look at some of the individuals on this list. Only yesterday Matt Corallo, Adam Back, Murch, Bob McElrath etc were arguing online this should not be attempted. Perhaps you want to call their takes "unhinged" too?

https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

I'm happy to discuss anything with those who are on the fence or who are genuinely trying to come to a view on this. But I won't be responding again to people like Jeremy, Keagan etc who I know perfectly well understand these arguments, ignore them and proceed regardless.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Friday, April 22nd, 2022 at 12:36 AM, Keagan McClelland <keagan.mcclelland at gmail.com> wrote:

> Good day Michael,
>> and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
> This seems silly to me.
>
> The structure of CTV is imbuing an OP_NOP with script semantics. Resisting changes that don't affect you is not consistent with the ideals of people being able to structure their own private agreements as they see fit...aka freedom. It seems needlessly coercive to try and resist CTV in this way. CTV is ultimately an opt-in proposal. If you don't like the risk/benefit ratio, you can simply not generate scripts that contain CTV checks. Conservatism and apathy are something I can understand, but resisting CTV via an escalating soft fork is not conservatism or apathy, it's fundamental opposition. What is it that you hope to accomplish by blocking others from using a new opcode? According to your formal statement, you haven't really opposed CTV on fundamental grounds so much as vaguely questioning whether or not it is the "best tool for the job"...as if anyone really has the capacity to judge that for a diverse group with varying interests and use cases that may differ substantially from their own.
>
> There are really two ways to effectively resist this change: 1. reject all blocks during the lockin period, 2. reject all blocks that include OP_CTV in the script.
>
> Regardless of which method you choose, it is ultimately going to be a far more forceful/invasive consensus change than CTV was in the first place. So have fun trying to explain yourself out of that one. You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement. Did you change your mind or something?
>> Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
>
> Making the statement that "the community doesn't want this to activate" as if it's some kind of foregone conclusion is a pretty bold claim. I think you'll be surprised at how broad support actually is. To contrast your second citation, here's the set of people who have endorsed the proposal, along with a handful of people opposed (such as yourself): https://utxos.org/signals/. If you are aware of others who are opposed, it would be worth your time to solicit a statement from them that can be put on the signals page. Absent that, it seems appropriate to assume that the overwhelming majority of people who have opined on the subject are for it.
>> But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
>
> What an unhinged take. The level of effort put into gathering consensus for CTV has set the bar higher than Taproot. Taproot didn't have the level of outreach effort that CTV does, and the complexity in taproot is significantly larger than for CTV. You didn't seem to have a problem organizing that activation process. That proposal was opened for public discussion in Jan'20, merged in Oct'20, and you were organizing activation discussions as early as Jan'21. The design of CTV has been *final* since Feb'20, a month after Taproot was opened for public discussion. There's a ton of Proof-of-Concept code that has been written to test out use cases for CTV, but for Taproot it still doesn't look like we'll have MuSig for a while longer (I heard a year, but someone can correct me on that if I'm wrong), and wallet support for Taproot wasn't fleshed out until after activation. Characterizing Jeremy's efforts as throwing caution and conservatism out the window is hypocritical at best and malicious at worst.
>
> Finally, I think it is worth stating that if Bitcoin adopts a culture where a willfully ignorant set of people can block changes that have no impact on them, despite a large constituency wanting those changes, then Bitcoin kind of deserves the slow deterioration that will result from that. I don't really find that future appealing and so I think that trying to find ways to activate non-invasive changes should be everyone's goal, *even if* they personally may not have an immediate use case, or have a slight preference for alternate solutions. The exception to this is any introduction of systemic 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. 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 it is the globally optimal solution (to a problem that cannot be globally defined due to diverse interests) is not persuasive to me and many others in the community.
> Keagan
>
> On Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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 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 skeptical.)
>>
>> Understandably this has angered and surprised a few people including some of those who have voiced opposition to a CTV soft fork activation being attempted in the first place [2].
>>
>> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate (and older versions) does not include any CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some chance CTV was to activate through some other software release Bitcoin Core releases would not apply CTV rules but they also wouldn't reject blocks that apply CTV rules. Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
>>
>> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm open to better names. I certainly don't want to discourage those who dislike or oppose UASFs from contributing to this effort and potentially ultimately running a URSF release. If you don't want this rushed CTV soft fork to activate we are all on the same side whatever we call it.
>>
>> For now I've set up a ##ursf channel on Libera IRC to monitor developments and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
>>
>> The intention of this would be to provide additional direction and incentive to miners that the community does not want this soft fork to be activated. To repeat running a Bitcoin Core release will not signal for a CTV soft fork out the box. If a miner runs a Bitcoin Core release it will not signal for CTV.
>>
>> Apologies that this is rushed. But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>> [2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/f136410f/attachment-0001.html>;

📅 Original date posted:2022-04-20 📝 Original message:Ok ...

2023-06-08T01:07:19+02:00

In reply to nevent1q…63sv
_________________________

📅 Original date posted:2022-04-20
📝 Original message: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 reason to favour a different proposal? Have you written any code?

You don't seem to quite understand the asymmetry here. I (and the rest of the community excluding Jeremy) am not a full time CTV developer or full time CTV advocate. There are a number of soft fork proposals I am interested in and attempting to follow in addition to all the work that is going around Taproot etc. But if you/Jeremy want to make a change to the consensus rules the onus is on you to get community review and community consensus. I am not demanding the consensus rules be changed. I am quite happy to wait until there is community consensus over a particular soft fork like there was with Taproot.

I have looked into CTV a considerable number of times now. I have asked 5 of the 6 CTV related questions on Bitcoin StackExchange at the time of writing [1], 2 of which I have attempted to answer. Does this mean I understand as much about Jeremy about CTV? Of course not. But if you believe that soft forks should have community consensus it is up to you/Jeremy to address concerns from curious, relatively informed, skeptical people like me. I am not convinced at the time of writing that CTV is the best tool for the job on any of its intended use cases. On this I don't think even Jeremy is convinced as when asked to compare CTV to alternatives he often just says it is ready and other proposals aren't.

> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.

I'm not entirely sure where you are going with this. That because Jeremy has worked really hard on it for a long time we should activate it without community consensus? I'm sorry that's not how consensus changes work or how they should work. Personally I very much doubt I will ever attempt to change the consensus rules with one of my proposals. I struggle to follow all of the work and the proposals others work on and at least for now believe others are much more qualified than me to design and code up consensus code changes. So again there is an asymmetry if you are going down the comparing Jeremy's goals with my own.

> I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119.

I think CTV is an immature proposal given what I've said already about it not being at all clear it is the best tool for any of its intended use cases.

> If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?

Others are currently working on alternative proposals to CTV (CAT, CSFS, TLUV, Simplicity, arguably APO depending on the use case etc). I haven't asked them to, they already are. As far as I know (they can correct me if wrong) those working on alternative proposals don't support an upcoming activation of CTV. You can try to make this personal all you want and write snide comments if it makes you feel better. But I doubt it is the right approach to getting more review of a soft fork proposal.

> Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.

If you have a magic wand to wave away activation drama and create an activation method that the entire community is happy with I'd love to see it. That magic wand would have got a few months of my life back in 2021 that I'll never get back.

As I said no more responses from me. I am going to go back to a transcript on FROST, one of the many exciting things people are working on that is Taproot related and what I believe the focus should be on at least until there is clear community consensus for a future soft fork.

[1]: https://bitcoin.stackexchange.com/questions/tagged/bip119-checktemplateverify

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Wednesday, April 20th, 2022 at 20:46, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Michael,
>
> Thank you for your reply. You wrote:
>
>> I have a better (and safer) way forward which is to continue to build out use cases of CTV, convince the community it is the best tool for the job (whatever use case(s) that is), compare it to other existing covenant enabling proposals on those use cases and then get to a point where the community is confident that it is activating a proposal(s) that will stand the test of time.
>
> 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 reason to favour a different proposal? Have you written any code?
>
> I've seen pages of text of you complaining about details of CTV activation but nothing tangible that would prove that you are actually interested in real progress on covenants.
> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.
>
>> You may not like that way forward because it requires a lot of work, a lot of time and a lot of patience.
>
> A lot of work, a lot of time and a lot of patience is exactly what Jeremy has been investing for years. I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119. If you could point me to essays of you thoughtfully comparing various covenant proposals then I could see your point, but you're only ranting on other people's work which requires no real effort and it doesn't contribute much. If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?
> Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.
>
> Looking forward to check out your contributions!
>
> Regards,
> Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/697e178e/attachment-0001.html>;

📅 Original date posted:2022-04-20 📝 Original message:Hi ...

2023-06-08T01:07:18+02:00

In reply to nevent1q…q3a4
_________________________

📅 Original date posted:2022-04-20
📝 Original message:Hi Robin

I was in two minds to respond because I feel I am just repeating myself from previous emails to this list [1], [2], [3]. I'm not sure whether you have read those posts or are just blocking them out because you disagree with them. I also don't think much (anything?) has changed since I wrote those emails a few months ago.

> Honestly, the reasons you mentioned here [1] do not make much sense to me and it feels like your attitude is not very constructive as you do not suggest a better way forward.

I have a better (and safer) way forward which is to continue to build out use cases of CTV, convince the community it is the best tool for the job (whatever use case(s) that is), compare it to other existing covenant enabling proposals on those use cases and then get to a point where the community is confident that it is activating a proposal(s) that will stand the test of time.

You may not like that way forward because it requires a lot of work, a lot of time and a lot of patience. It is certainly easier to agitate for a soft fork on a mailing list. But that would be "my" and other people's way forward who think only the best proposals should get into Bitcoin consensus rules and those worthy of taking on the chain split risk.

> It's not clear to me what you want because you just keep opposing CTV without trying to make better suggestions. What do you want?

There are a number of competing covenant enabling proposals out there. I don't know if they are better or not for specific use cases. I also don't think there is consensus on that yet. Mainnet should not be treated like testnet, signet or an altcoin. It isn't for experimenting with new consensus rules or proving that something is useful. That should be done elsewhere.

> Your other arguments mostly discuss soft forks in general. This is a different topic though. I think it is not a good idea to mix that up.

Any soft fork introduces chain split risk into the equation. Taproot had overwhelming community consensus so it had much less chain split risk. A contentious soft fork activation attempt contains a lot more chain split risk. When discussing whether to attempt to activate soft forks you have to appreciate that important fact. To ignore that seems bizarre to me.

But as I said I'm repeating myself. If we have to do this contentious soft fork activation attempt exercise we have to do it and get it over with. The kind of work and progress I was hoping to see on CTV use cases over many months (and/or years) doesn't seem to be happening. Instead we just have a flame war every couple of months on the mailing list over whether CTV should be activated or not and rehash all the same arguments in an environment in which nothing (anything?) has moved forward.

[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019731.html

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Wednesday, April 20th, 2022 at 18:13, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Dear Michael,
>
> Firstly, I think it is great that you do share enthusiasm for "vaults, eltoo constructions, payment pools etc". Many people see covenants (or covenant-like features) as one of the most important upgrades currently in the pipe line because it enables so many important use cases and interesting areas of research. In particular vaults and scalability solutions.
>
> However, I have tried to figure out why you invest so much time and effort to oppose CTV. Honestly, the reasons you mentioned here [1] do not make much sense to me and it feels like your attitude is not very constructive as you do not suggest a better way forward.
> You wrote "This research and experimentation should mature before considering activation" even though you know that BIP-119 has been finalised more than two years ago. Also the implementation has been reviewed extensively and it has matured for years. So, your framing of "experimentation" and "premature activation" just doesn't reflect the truth here. Even your argument is already more than a year old...
>
> Additionally, you do not address that CTV is intentionally designed to be the most simple and conservative upgrade towards full-featured covenants. CTV only enables a feature that is already possible today using a trusted party. Opposing this conservative approach means you are either in favour of activating a more powerful feature or you do not want covenants at all. It's not clear to me what you want because you just keep opposing CTV without trying to make better suggestions. What do you want?
> Your other arguments mostly discuss soft forks in general. This is a different topic though. I think it is not a good idea to mix that up. And claiming that CTV implies continuous soft forks is again dishonest framing. It suggests that covenants were just a random idea of Jeremy even though you know that many reputable bitcoin developers have been researching this topic for years. Truth is Jeremy does a great service to the community by facing this draining activation drama to make trustless covenants possible.
>
> Now, in your most recent email your main concern seems to be a potential chain split. This is again a weak argument against CTV because your concerns apply to any upgrade. Furthermore, you are increasing this risk by opposing CTV without trying to 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 because of opposition to soft forks in general.
>
> Regards,
> Robin
>
> [1] https://github.com/JeremyRubin/utxos.org/issues/27
>
> ------- Original Message -------
> On Wednesday, April 20th, 2022 at 3:24 PM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>> 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 Russian roulette style gamble with a chain split.
>>
>> But here's a summary of the basic facts:
>>
>> The latest Bitcoin Core release candidate (23.0) does not contain any new soft fork code, either CTV code or any new activation code. Running Bitcoin Core 23.0 out the box will not signal for any new soft fork and will not enforce any new soft fork rules (CTV or otherwise). Of course it will continue to enforce Taproot rules as Taproot activated last year.
>>
>> There are a number of individuals who have stated opposition to attempting to activate a CTV soft fork in the near term:
>>
>> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>
>> Most of those individuals haven't logged their opposition on Jeremy's site:
>> https://utxos.org/signals/
>>
>> Hence their views haven't been included or discussed in Jeremy's latest blog post.
>>
>> Chain split risk
>>
>> I can't predict how many full nodes and miners will run Jeremy's client attempting to activate CTV. One would expect that many will continue to run versions of Bitcoin Core that will not enforce CTV rules and will not activate it. But whether Jeremy's client will be a majority, significant minority, insignificant minority of full nodes and miners would be speculation on my part. (Personally I highly doubt those running Jeremy's client will be a majority which leaves a significant minority and insignificant minority as the most likely options).
>>
>> Jeremy's client is intending to use Speedy Trial presumably with similar parameters to that used for Taproot. That would mean seeking 90 percent of miners to signal for this CTV soft fork activation attempt.
>>
>> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial windows then the activation attempt will have failed and it will be back in Jeremy's court whether he tries again with a different activation attempt.
>>
>> Assuming 90 percent of miners do signal for it (unlikely in my opinion but presumably still a possibility) then the CTV soft fork could activate unless full nodes resist it. This resistance would most likely be in the form of a UASF style client which rejects blocks that apply the CTV rules and/or includes transactions that don't meet the CTV rules post activation. We would now be in chain split territory with two different assets and blockchains like we had with BTC and BCH.
>>
>> If I oppose this activation attempt and the associated chain split risk what should I do?
>>
>> Firstly, you can register your opposition to this soft fork activation attempt on Jeremy's site: https://utxos.org/signals/
>>
>> It seems Jeremy will continue this activation attempt regardless but it will be useful for others to see clearly that this a contentious soft fork activation attempt and act accordingly. So far only 3 individuals' opposition is registered on his site.
>>
>> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) of miners are going to signal for a CTV soft fork then you can consider joining a UASF style effort to resist the soft fork activation attempt. I will certainly seek to participate and will continue to inform this list of efforts in this direction.
>>
>> The saddest thing is that if Jeremy's soft fork activation attempt causes the uncertainty, confusion and disruption I fear it could it will make future soft forks that do have community consensus orders of magnitude harder to pull off. There are a number of soft fork proposals that I'm personally excited about (enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get with a sensible approach to only activating soft forks that have community consensus. But the more uncertainty, confusion and disruption we create over contentious soft forks the more dangerous any soft fork of any form will appear. The primary focus will need to be resisting soft forks that don't have community consensus and ensuring Bitcoin doesn't splinter into a large number of different assets/blockchains with different combinations of soft forks active.
>>
>> So if you oppose this soft fork activation attempt please voice your opposition, run full node software that doesn't include CTV and CTV activation code such as Bitcoin Core and if/when necessary and available run full node software that proactively rejects application of the CTV rules.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Devs,
>>>
>>> In advance of the CTV meeting today, I wanted to share what my next step is in advocating for CTV, as well as 7 theses for why I believe it to be the right course of action to take at this time.
>>>
>>> Please see the post at https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>>>
>>> As always, open to hear any and all feedback,
>>>
>>> Jeremy
>>>
>>> archived at: https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/87aa6c18/attachment-0001.html>;

📅 Original date posted:2022-04-20 📝 Original message:> ...

2023-06-08T01:07:17+02:00

In reply to nevent1q…usw0
_________________________

📅 Original date posted:2022-04-20
📝 Original message:> 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 Russian roulette style gamble with a chain split.

But here's a summary of the basic facts:

The latest Bitcoin Core release candidate (23.0) does not contain any new soft fork code, either CTV code or any new activation code. Running Bitcoin Core 23.0 out the box will not signal for any new soft fork and will not enforce any new soft fork rules (CTV or otherwise). Of course it will continue to enforce Taproot rules as Taproot activated last year.

There are a number of individuals who have stated opposition to attempting to activate a CTV soft fork in the near term:

https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

Most of those individuals haven't logged their opposition on Jeremy's site:
https://utxos.org/signals/

Hence their views haven't been included or discussed in Jeremy's latest blog post.

Chain split risk

I can't predict how many full nodes and miners will run Jeremy's client attempting to activate CTV. One would expect that many will continue to run versions of Bitcoin Core that will not enforce CTV rules and will not activate it. But whether Jeremy's client will be a majority, significant minority, insignificant minority of full nodes and miners would be speculation on my part. (Personally I highly doubt those running Jeremy's client will be a majority which leaves a significant minority and insignificant minority as the most likely options).

Jeremy's client is intending to use Speedy Trial presumably with similar parameters to that used for Taproot. That would mean seeking 90 percent of miners to signal for this CTV soft fork activation attempt.

Assuming 90 percent of miners don't signal for it in one of the Speedy Trial windows then the activation attempt will have failed and it will be back in Jeremy's court whether he tries again with a different activation attempt.

Assuming 90 percent of miners do signal for it (unlikely in my opinion but presumably still a possibility) then the CTV soft fork could activate unless full nodes resist it. This resistance would most likely be in the form of a UASF style client which rejects blocks that apply the CTV rules and/or includes transactions that don't meet the CTV rules post activation. We would now be in chain split territory with two different assets and blockchains like we had with BTC and BCH.

If I oppose this activation attempt and the associated chain split risk what should I do?

Firstly, you can register your opposition to this soft fork activation attempt on Jeremy's site: https://utxos.org/signals/

It seems Jeremy will continue this activation attempt regardless but it will be useful for others to see clearly that this a contentious soft fork activation attempt and act accordingly. So far only 3 individuals' opposition is registered on his site.

Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) of miners are going to signal for a CTV soft fork then you can consider joining a UASF style effort to resist the soft fork activation attempt. I will certainly seek to participate and will continue to inform this list of efforts in this direction.

The saddest thing is that if Jeremy's soft fork activation attempt causes the uncertainty, confusion and disruption I fear it could it will make future soft forks that do have community consensus orders of magnitude harder to pull off. There are a number of soft fork proposals that I'm personally excited about (enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get with a sensible approach to only activating soft forks that have community consensus. But the more uncertainty, confusion and disruption we create over contentious soft forks the more dangerous any soft fork of any form will appear. The primary focus will need to be resisting soft forks that don't have community consensus and ensuring Bitcoin doesn't splinter into a large number of different assets/blockchains with different combinations of soft forks active.

So if you oppose this soft fork activation attempt please voice your opposition, run full node software that doesn't include CTV and CTV activation code such as Bitcoin Core and if/when necessary and available run full node software that proactively rejects application of the CTV rules.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Devs,
>
> In advance of the CTV meeting today, I wanted to share what my next step is in advocating for CTV, as well as 7 theses for why I believe it to be the right course of action to take at this time.
>
> Please see the post at https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>
> As always, open to hear any and all feedback,
>
> Jeremy
>
> archived at: https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/e4f13a10/attachment.html>;

📅 Original date posted:2022-02-05 📝 Original message:Thanks ...

2023-06-08T01:03:12+02:00

In reply to nevent1q…3j7k
_________________________

📅 Original date posted:2022-02-05
📝 Original message: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 rest of Bitcoin's existence. I am sure people like Luke, Prayank etc will (rightfully) continue to raise that Lightning and other second layer protocols shouldn't demand that policy rules be changed if there is a reason (e.g. DoS vector) for those rules on the base network. But if there are rules that have no upside, introduce unnecessary complexity for no reason and make Lightning implementers like Bastien's life miserable attempting to deal with them I really hope we can make progress on removing or simplifying them.

This is why I think it is important to understand the rationales for introducing the rules in the first place (and why it is safe to remove them if indeed it is) and being as rigorous as possible on the rationales for introducing additional rules. It sounds like from Gloria's initial post we are still at a brainstorming phase (which is fine) but knowing what we know today I really hope we can learn from the mistakes of the original BIP 125, namely the Core implementation not matching the BIP and the sparse rationales for the rules. As Bastien says this is not criticizing the original BIP 125 authors, 7 years is a long time especially in Bitcoin world and they probably weren't thinking about Bastien sitting down to write an eclair PR in late 2021 (and reviewers of that PR) when they wrote the BIP in 2015.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Monday, January 31st, 2022 at 3:57 PM, Bastien TEINTURIER via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Gloria,
>
> Many thanks for raising awareness on these issues and constantly pushing
> towards finding a better model. This work will highly improve the
> security of any multi-party contract trying to build on top of bitcoin
> (because most multi-party contracts will need to have timeout conditions
> and participants will need to make some transactions confirm before a
> timeout happens - otherwise they may lose funds).
>
> For starters, let me quickly explain why the current rules are hard to
> work with in the context of lightning (but I believe most L2 protocols
> will have the same issues). Feel free to skip this part if you are
> already convinced.
>
> ## Motivation
>
> The biggest pain point is BIP 125 rule 2.
> If I need to increase the fees of a time-sensitive transaction because
> the feerate has been rising since I broadcast it, I may need to also pay
> high fees just to produce a confirmed utxo that I can use. I'm actually
> paying a high fee twice instead of once (and needlessly using on-chain
> space, our scarcest asset, because we could have avoided that additional
> transaction!).
>
> It also has some annoying "non-determinism".
> Imagine that my transaction has been evicted from my mempool because its
> feerate was too low. I could think "Great, that means I don't have to
> apply BIP 125 restrictions, I can just fund this transaction as if it
> were a new one!". But actually I do, because my transaction could still
> be in miner's mempools and I have no way of knowing it...this means that
> whenever I have broadcast a transaction, I must assume that I will
> always need to abide by whatever replacement rules the network applies.
>
> Fortunately, as far as I understand it, this rule only exists because of
> a previous implementation detail of bitcoin core, so there's simply no
> good reason to keep it.
>
> The second biggest pain point is rule 3. It prevents me from efficiently
> using my capital while it's unconfirmed. Whenever I'm using a big utxo
> to fund a transaction, I will get a big change output, and it would
> really be a waste to be unable to use that change output to fund other
> transactions. In order to be capital-efficient, I will end up creating
> descendant trees for my time-sensitive transactions. But as Gloria
> explained, replacing all my children will cost me an absurdly large
> amount of fees. So what I'm actually planning to do instead is to RBF
> one of the descendants high enough to get the whole tree confirmed.
> But if those descendants' timeouts were far in the future, that's a
> waste, I paid a lot more fees for them than I should have. I'd like to
> just replace my transaction and republish the invalidated children
> independently.
>
> Rule 4 doesn't hurt as much as the two previous ones, I don't have too
> much to say about it.
>
> To be fair to the BIP 125 authors, all of these scenarios were very hard
> to forecast at the time this BIP was created. We needed years to build
> on those rules to get a better understanding of their limitations and if
> the rationale behind them made sense in the long term.
>
> ## Proposals
>
> I believe that now is a good time to re-think those, and I really like
> Gloria's categorization of the design constraints.
>
> I'd like to propose a different way of looking at descendants that makes
> it easier to design the new rules. The way I understand it, limiting the
> impact on descendant transactions is only important for DoS protection,
> not for incentive compatibility. I would argue that after evictions,
> descendant transactions will be submitted again (because they represent
> transactions that people actually want to make), so evicting them does
> not have a negative impact on mining incentives (in a world where blocks
> are full most of the time).
>
> I'm curious to hear other people's thoughts on that. If it makes sense,
> I would propose the following very simple rules:
>
> 1. The transaction's ancestor absolute fees must be X% higher than the
> previous transaction's ancestor fees
> 2. The transaction's ancestor feerate must be Y% higher than the
> previous transaction's ancestor feerate
>
> I believe it's completely ok to require increasing both the fees and
> feerate if we don't take descendants into account, because you control
> your ancestor set - whereas the descendant set may be completely out of
> your control.
>
> This is very easy to use by wallets, because the ancestor set is easy to
> obtain. And an important point is that the ancestor set is the same in
> every mempool, whereas the descendant set is not (your mempool may have
> rejected the last descendants, while other people's mempools may still
> contain them).
>
> Because of that reason, I'd like to avoid having a rule that relies on
> some size of the replaced descendant set: it may be valid in your
> mempool but invalid in someone else's, which makes it exploitable for
> pinning attacks.
>
> I believe these rules are incentive compatible (again, if you accept
> the fact that the descendants will be re-submitted and mined as well,
> so their fees aren't lost).
>
> Can we choose X and Y so that these two rules are also DoS-resistant?
> Unfortunately I'm not sure, so maybe we'll need to add a third rule to
> address that. But before we do, can someone detail what it costs for a
> node to evict a descendant tree? Given that bitcoin core doesn't allow
> chains of more than 25 transactions, the maximum number of transactions
> being replaced will be bounded by 25 * N (where N is the number of
> outputs of the transaction being replaced). If it's just O(n) pruning of
> a graph, maybe that's ok? Or maybe we make X or Y depend on the number
> of outputs of the transaction being replaced (this would need very
> careful thoughts)?
>
> If you made it this far, thanks for reading!
> A couple of comments on the previous messages:
>
>> Currently, if we see a transaction
>> that has the same txid as one in the mempool, we reject it as a
>> duplicate, even if the feerate is much higher. It's unclear to me if
>> we have a very strong reason to change this, but noting it as a
>> limitation of our current replacement policy.
>
> I don't see a strong reason from an L2 protocol's point of view yet, but
> there are many unkown unknowns. But from a miner incentive's point of
> view, we should keep the transaction with the higher feerate, shouldn't
> we? In that case it's also a more efficient use of on-chain space, which
> is a win, right?
>
>> We might have a more-or-less long transition period during which we support both...
>
> Yes, this is a long term thing.
> Even if bitcoin core releases a new version with updated RBF rules, as a
> wallet you'll need to keep using the old rules for a long time if you
> want to be safe.
>
> But it's all the more reason to try to ship this as soon as possible,
> this way maybe our grand-children will be able to benefit from it ;)
> (just kidding on the timespan obviously).
>
> Cheers,
> Bastien
>
> Le lun. 31 janv. 2022 à 00:11, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi Gloria,
>>
>> Thanks for this RBF sum up. Few thoughts and more context comments if it can help other readers.
>>
>>> For starters, the absolute fee pinning attack is especially
>>> problematic if we apply the same rules (i.e. Rule #3 and #4) in
>>> Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
>>> LN channel. The mempool is rather full, so their pre-negotiated
>>> commitment transactions' feerates would not be considered high
>>> priority by miners. Bob broadcasts his commitment transaction and
>>> attaches a very large child (100KvB with 100,000sat in fees) to his
>>> anchor output. Alice broadcasts her commitment transaction with a
>>> fee-bumping child (200vB with 50,000sat fees which is a generous
>>> 250sat/vB), but this does not meet the absolute fee requirement. She
>>> would need to add another 50,000sat to replace Bob's commitment
>>> transaction.
>>
>> Solving LN pinning attacks, what we're aiming for is enabling a fair feerate bid between the counterparties, thus either forcing the adversary to overbid or to disengage from the confirmation competition. If the replace-by-feerate rule is adopted, there shouldn't be an incentive for Bob to
>> pick up the first option. Though if he does, that's a winning outcome for Alice, as one of the commitment transactions confirms and her time-sensitive second-stage HTLC can be subsequently confirmed.
>>
>>> It's unclear to me if
>>> we have a very strong reason to change this, but noting it as a
>>> limitation of our current replacement policy. See [#24007][12].
>>
>> Deployment of Taproot opens interesting possibilities in the vaults/payment channels design space, where the tapscripts can commit to different set of timelocks/quorum of keys. Even if the pre-signed states stay symmetric, whoever is the publisher, the feerate cost to spend can fluctuate.
>>
>>> While this isn't completely broken, and the user interface is
>>> secondary to the safety of the mempool policy
>>
>> I think with L2s transaction broadcast backend, the stability and clarity of the RBF user interface is primary. What we could be worried about is a too-much complex interface easing the way for an attacker to trigger your L2 node to issue policy-invalid chain of transactions. Especially, when we consider that an attacker might have leverage on chain of transactions composition ("force broadcast of commitment A then commitment B, knowing they will share a CPFP") or even transactions size ("overload commitment A with HTLCs").
>>
>>> * If the original transaction is in the top {0.75MvB, 1MvB} of the
>>> mempool, apply the current rules (absolute fees must increase and
>>> pay for the replacement transaction's new bandwidth). Otherwise, use a
>>> feerate-only rule.
>>
>> How this new replacement rule would behave if you have a parent in the "replace-by-feerate" half but the child is in the "replace-by-fee" one ?
>>
>> If we allow the replacement of the parent based on the feerate, we might decrease the top block absolute fees.
>>
>> If we block the replacement of the parent based on the feerate because the replacement absolute fees aren't above the replaced package, we still preclude a pinning vector. The child might be low-feerate junk and even attached to a low ancestor-score branch.
>>
>> If I'm correct on this limitation, maybe we could turn off the "replace-by-fee" behavior as soon as the mempool is fulfilled with a few blocks ?
>>
>>> * Rate-limit how many replacements we allow per prevout.
>>
>> Depending on how it is implemented, though I would be concerned it introduces a new pinning vector in the context of shared-utxo. If it's a hardcoded constant, it could be exhausted by an adversary starting at the lowest acceptable feerate then slowly increasing while still not reaching
>> the top of the mempool. Same if it's time-based or block-based, no guarantee the replacement slot is honestly used by your counterparty.
>>
>> Further, an above-the-average replacement frequency might just be the reflection of your confirmation strategy reacting to block schedule or mempools historical data. As long as the feerate penalty is paid, I lean to allow replacement.
>> (One solution could be to associate per-user "tag" to the LN transactions, where each "tag" would have its own replacement slots, but privacy?)
>>
>>> * Rate-limit transaction validation in general, per peer.
>>
>> I think we could improve on the Core's new transaction requester logic. Maybe we could bind the peer announced flow based on the feerate score (modulo validation time) of the previously validated transactions from that peer ? That said, while related to RBF, it sounds to me that enhancing Core's rate-limiting transaction strategy is a whole discussion in itself [0]. Especially ensuring it's tolerant to the specific requirements of LN & consorts.
>>
>>> What should they be? We can do some arithmetic to see what happens if
>>> you start with the biggest/lowest feerate transaction and do a bunch
>>> of replacements. Maybe we end up with values that are high enough to
>>> prevent abuse and make sense for applications/users that do RBF.
>>
>> That's a good question.
>>
>> One observation is that the attacker can always renew the set of DoSy utxos to pursue the attack. So maybe we could pick up constants scaled on the block size ? That way an attacker would have to burn fees, thus deterring them from launching an attack. Even if the attackers are miners, they have to renounce their income to acquire new DoSy utxos. If a low-fee period, we could scale up the constants ?
>>
>> Overall, I think there is the deployment issue to warn of. Moving to a new set of RBF rules implies for a lot of Bitcoin applications to rewrite their RBF logics. We might have a more-or-less long transition period during which we support both...
>>
>> Cheers,
>> Antoine
>>
>> [0] https://github.com/bitcoin/bitcoin/pull/21224
>>
>> Le jeu. 27 janv. 2022 à 09:10, Gloria Zhao via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Hi everyone,
>>>
>>> This post discusses limitations of current Bitcoin Core RBF policy and
>>> attempts to start a conversation about how we can improve it,
>>> summarizing some ideas that have been discussed. Please reply if you
>>> have any new input on issues to be solved and ideas for improvement!
>>>
>>> Just in case I've screwed up the text wrapping again, another copy can be
>>> found here: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff
>>>
>>> ## Background
>>>
>>> Please feel free to skip this section if you are already familiar
>>> with RBF.
>>>
>>> Nodes may receive *conflicting* unconfirmed transactions, aka
>>> "double spends" of the same inputs. Instead of always keeping the
>>> first transaction, since v0.12, Bitcoin Core mempool policy has
>>> included a set of Replace-by-Fee (RBF) criteria that allows the second
>>> transaction to replace the first one and any descendants it may have.
>>>
>>> Bitcoin Core RBF policy was previously documented as BIP 125.
>>> The current RBF policy is documented [here][1]. In summary:
>>>
>>> 1. The directly conflicting transactions all signal replaceability
>>> explicitly.
>>>
>>> 2. The replacement transaction only includes an unconfirmed input if
>>> that input was included in one of the directly conflicting
>>> transactions.
>>>
>>> 3. The replacement transaction pays an absolute fee of at least the
>>> sum paid by the original transactions.
>>>
>>> 4. The additional fees pays for the replacement transaction's
>>> bandwidth at or above the rate set by the node's *incremental relay
>>> feerate*.
>>>
>>> 5. The sum of all directly conflicting transactions' descendant counts
>>> (number of transactions inclusive of itself and its descendants)
>>> does not exceed 100.
>>>
>>> We can split these rules into 3 categories/goals:
>>>
>>> - **Allow Opting Out**: Some applications/businesses are unable to
>>> handle transactions that are replaceable (e.g. merchants that use
>>> zero-confirmation transactions). We (try to) help these businesses by
>>> honoring BIP125 signaling; we won't replace transactions that have not
>>> opted in.
>>>
>>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>> accept replacement transactions which would decrease fee profits
>>> of a miner. In general, if our mempool policy deviates from what is
>>> economically rational, it's likely that the transactions in our
>>> mempool will not match the ones in miners' mempools, making our
>>> fee estimation, compact block relay, and other mempool-dependent
>>> functions unreliable. Incentive-incompatible policy may also
>>> encourage transaction submission through routes other than the p2p
>>> network, harming censorship-resistance and privacy of Bitcoin payments.
>>>
>>> - **DoS Protection**: Limit two types of DoS attacks on the node's
>>> mempool: (1) the number of times a transaction can be replaced and
>>> (2) the volume of transactions that can be evicted during a
>>> replacement.
>>>
>>> Even more abstract: our goal is to make a replacement policy that
>>> results in a useful interface for users and safe policy for
>>> node operators.
>>>
>>> ## Motivation
>>>
>>> There are a number of known problems with the current RBF policy.
>>> Many of these shortcomings exist due to mempool limitations at the
>>> time RBF was implemented or result from new types of Bitcoin usage;
>>> they are not criticisms of the original design.
>>>
>>> ### Pinning Attacks
>>>
>>> The most pressing concern is that attackers may take advantage of
>>> limitations in RBF policy to prevent other users' transactions from
>>> being mined or getting accepted as a replacement.
>>>
>>> #### SIGHASH_ANYONECANPAY Pinning
>>>
>>> BIP125#2 can be bypassed by creating intermediary transactions to be
>>> replaced together. Anyone can simply split a 1-input 1-output
>>> transaction off from the replacement transaction, then broadcast the
>>> transaction as is. This can always be done, and quite cheaply. More
>>> details in [this comment][2].
>>>
>>> In general, if a transaction is signed with SIGHASH\_ANYONECANPAY,
>>> anybody can just attach a low feerate parent to this transaction and
>>> lower its ancestor feerate. Even if you require SIGHASH\_ALL which
>>> prevents an attacker from changing any outputs, the input can be a
>>> very low amount (e.g. just above the dust limit) from a low-fee
>>> ancestor and still bring down the ancestor feerate of the transaction.
>>>
>>> TLDR: if your transaction is signed with SIGHASH\_ANYONECANPAY and
>>> signals replaceability, regardless of the feerate you broadcast at, an
>>> attacker can lower its mining priority by adding an ancestor.
>>>
>>> #### Absolute Fee
>>>
>>> The restriction of requiring replacement transactions to increase the
>>> absolute fee of the mempool has been described as "bonkers." If the
>>> original transaction has a very large descendant that pays a large
>>> amount of fees, even if it has a low feerate, the replacement
>>> transaction must now pay those fees in order to meet Rule #3.
>>>
>>> #### Package RBF
>>>
>>> There are a number of reasons why, in order to enable Package RBF, we
>>> cannot use the same criteria.
>>>
>>> For starters, the absolute fee pinning attack is especially
>>> problematic if we apply the same rules (i.e. Rule #3 and #4) in
>>> Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
>>> LN channel. The mempool is rather full, so their pre-negotiated
>>> commitment transactions' feerates would not be considered high
>>> priority by miners. Bob broadcasts his commitment transaction and
>>> attaches a very large child (100KvB with 100,000sat in fees) to his
>>> anchor output. Alice broadcasts her commitment transaction with a
>>> fee-bumping child (200vB with 50,000sat fees which is a generous
>>> 250sat/vB), but this does not meet the absolute fee requirement. She
>>> would need to add another 50,000sat to replace Bob's commitment
>>> transaction.
>>>
>>> Disallowing new unconfirmed inputs (Rule #2) in Package RBF would be
>>> broken for packages containing transactions already in the mempool,
>>> explained [here][7].
>>>
>>> Note: I originally [proposed][6] Package RBF using the same Rule #3
>>> and #4 before I realized how significant this pinning attack is. I'm
>>> retracting that proposal, and a new set of Package RBF rules would
>>> follow from whatever the new individual RBF rules end up being.
>>>
>>> #### Same Txid Different Witness
>>>
>>> Two transactions with the same non-witness data but different
>>> witnesses have the same txid but different wtxid, and the same fee but
>>> not necessarily the same feerate. Currently, if we see a transaction
>>> that has the same txid as one in the mempool, we reject it as a
>>> duplicate, even if the feerate is much higher. It's unclear to me if
>>> we have a very strong reason to change this, but noting it as a
>>> limitation of our current replacement policy. See [#24007][12].
>>>
>>> ### User Interface
>>>
>>> #### Using Unconfirmed UTXOs to Fund Replacements
>>>
>>> The restriction of only allowing confirmed UTXOs for funding a
>>> fee-bump (Rule #2) can hurt users trying to fee-bump their
>>> transactions and complicate wallet implementations. If the original
>>> transaction's output value isn't sufficient to fund a fee-bump and/or
>>> all of the user's other UTXOs are unconfirmed, they might not be able
>>> to fund a replacement transaction. Wallet developers also need to
>>> treat self-owned unconfirmed UTXOs as unusable for fee-bumping, which
>>> adds complexity to wallet logic. For example, see BDK issues [#144][4]
>>> and [#414][5].
>>>
>>> #### Interface Not Suitable for Coin Selection
>>>
>>> Currently, a user cannot simply create a replacement transaction
>>> targeting a specific feerate or meeting a minimum fee amount and
>>> expect to meet the RBF criteria. The fee amount depends on the size of
>>> the replacement transaction, and feerate is almost irrelevant.
>>>
>>> Bitcoin Core's `bumpfee` doesn't use the RBF rules when funding the
>>> replacement. It [estimates][13] a feerate which is "wallet incremental
>>> relay fee" (a conservative overestimation of the node's incremental
>>> relay fee) higher than the original transaction, selects coins for
>>> that feerate, and hopes that it meets the RBF rules. It never fails
>>> Rule #3 and #4 because it uses all original inputs and refuses to
>>> bump a transaction with mempool descendants.
>>>
>>> This is suboptimal, but is designed to work with the coin selection
>>> engine: select a feerate first, and then add fees to cover it.
>>> Following the exact RBF rules would require working the other way
>>> around: based on how much fees we've added to the transaction and its
>>> current size, calculate the feerate to see if we meet Rule #4.
>>>
>>> While this isn't completely broken, and the user interface is
>>> secondary to the safety of the mempool policy, we can do much better.
>>> A much more user-friendly interface would depend *only* on the
>>> fee and size of the original transactions.
>>>
>>> ### Updates to Mempool and Mining
>>>
>>> Since RBF was first implemented, a number of improvements have been
>>> made to mempool and mining logic. For example, we now use ancestor
>>> feerates in mining (allowing CPFP), and keep track of ancestor
>>> packages in the mempool.
>>>
>>> ## Ideas for Improvements
>>>
>>> ### Goals
>>>
>>> To summarize, these seem to be desired changes, in order of priority:
>>>
>>> 1. Remove Rule #3. The replacement should not be *required* to pay
>>> higher absolute fees.
>>>
>>> 2. Make it impossible for a replacement transaction to have a lower
>>> mining score than the original transaction(s). This would eliminate
>>> the `SIGHASH\_ANYONECANPAY` pinning attack.
>>>
>>> 3. Remove Rule #2. Adding new unconfirmed inputs should be allowed.
>>>
>>> 4. Create a more helpful interface that helps wallet fund replacement
>>> transactions that aim for a feerate and fee.
>>>
>>> ### A Different Model for Fees
>>>
>>> For incentive compatibility, I believe there are different
>>> formulations we should consider. Most importantly, if we want to get
>>> rid of the absolute fee rule, we can no longer think of it as "the
>>> transaction needs to pay for its own bandwidth," since we won't always
>>> be getting additional fees. That means we need a new method of
>>> rate-limiting replacements that doesn't require additional fees every
>>> time.
>>>
>>> While it makes sense to think about monetary costs when launching a
>>> specific type of attack, given that the fees are paid to the miner and
>>> not to the mempool operators, maybe it doesn't make much sense to
>>> think about "paying for bandwidth". Maybe we should implement
>>> transaction validation rate-limiting differently, e.g. building it
>>> into the P2P layer instead of the mempool policy layer.
>>>
>>> Recently, Suhas gave a [formulation][8] for incentive compatibility
>>> that made sense to me: "are the fees expected to be paid in the next
>>> (N?) blocks higher or lower if we process this transaction?"
>>>
>>> I started by thinking about this where N=1 or `1 + p`.
>>> Here, a rational miner is looking at what fees they would
>>> collect in the next block, and then some proportion `p` of the rest of
>>> the blocks based on their hashrate. We're assuming `p` isn't *so high*
>>> that they would be okay with lower absolute fees in the next 1 block.
>>> We're also assuming `p` isn't *so low* that the miner doesn't care
>>> about what's left of the mempool after this block.
>>>
>>> A tweak to this formulation is "if we process this transaction, would
>>> the fees in the next 1 block higher or lower, and is the feerate
>>> density of the rest of the mempool higher or lower?" This is pretty
>>> similar, where N=1, but we consider the rest of the mempool by feerate
>>> rather than fees.
>>>
>>> ### Mining Score of a Mempool Transaction
>>>
>>> We are often interested in finding out what
>>> the "mining score" of a transaction in the mempool is. That is, when
>>> the transaction is considered in block template building, what is the
>>> feerate it is considered at?
>>>
>>> Obviously, it's not the transaction's individual feerate. Bitcoin Core
>>> [mining code sorts][14] transactions by their ancestor feerate and
>>> includes them packages at a time, keeping track of how this affects the
>>> package feerates of remaining transactions in the mempool.
>>>
>>> *ancestor feerate*: Ancestor feerate is easily accessible information,
>>> but it's not accurate either, because it doesn't take into account the
>>> fact that subsets of a transaction's ancestor set can be included
>>> without it. For example, ancestors may have high feerates on their own
>>> or we may have [high feerate siblings][8].
>>>
>>> TLDR: *Looking at the current ancestor feerate of a transaction is
>>> insufficient to tell us what feerate it will be considered at when
>>> building a block template in the future.*
>>>
>>> *min(individual feerate, ancestor feerate)*: Another
>>> heuristic that is simple to calculate based on current mempool tooling
>>> is to use the [minimum of a transaction's individual score and its
>>> ancestor score][10] as a conservative measure. But this can
>>> overestimate as well (see the example below).
>>>
>>> *min ancestor feerate(tx + possible ancestor subsets)* We can also
>>> take the minimum of every possible ancestor subset, but this can be
>>> computationally expensive since there can be lots and lots of ancestor
>>> subsets.
>>>
>>> *max ancestor feerate(tx + possible descendant subsets)*: Another idea
>>> is to use the [maximum ancestor score of the transaction + each of its
>>> descendants][9]. This doesn't work either; it has the same blindspot
>>> of ancestor subsets being mined on their own.
>>>
>>> #### Mining Score Example
>>>
>>> Here's an example illustrating why mining score is tricky to
>>> efficiently calculate for mempool transactions:
>>>
>>> Let's say you have same-size transactions A (21sat/vB), B (1sat/vB),
>>> C(9sat/vB), D(5sat/vB).
>>> The layout is: grandparent A, parent B, and two children C and D.
>>>
>>> ```
>>> A
>>> ^
>>> B
>>> ^ ^
>>> C D
>>> ```
>>>
>>> A miner using ancestor packages to build block templates will first
>>> include A with a mining score of 21. Next, the miner will include B and
>>> C with a mining score of 6. This leaves D, with a mining score of 5.
>>>
>>> Note: in this case, mining by ancestor feerate results in the most
>>> rational decisions, but [a candidate set-based approach][10] which
>>> makes ancestor feerate much less relevant could
>>> be more advantageous in other situations.
>>>
>>> Here is a chart showing the "true" mining score alongside the values
>>> calculating using imperfect heuristics described above. All of them
>>> can overestimate or underestimate.
>>>
>>> ```
>>> A B C D
>>> mining score | 21 | 6 | 6 | 5 |
>>> ancestor feerate | 21 | 11 | 10.3 | 9 |
>>> min(individual, ancestor) | 21 | 1 | 9 | 5 |
>>> min(tx + ancestor subsets) | 21 | 1 | 5 | 3 |
>>> max(tx + descendants subsets) | 21 | 9 | 9 | 5 |
>>>
>>> ```
>>>
>>> Possibly the best solution for finding the "mining score" of a
>>> transaction is to build a block template, see what feerate each
>>> package is included at. Perhaps at some cutoff, remaining mempool
>>> transactions can be estimated using some heuristic that leans
>>> {overestimating, underestimating} depending on the situation.
>>>
>>> Mining score seems to be relevant in multiple places: Murch and I
>>> recently [found][3] that it would be very important in
>>> "ancestor-aware" funding of transactions (the wallet doesn't
>>> incorporate ancestor fees when using unconfirmed transactions in coin
>>> selection, which is a bug we want to fix).
>>>
>>> In general, it would be nice to know the exact mining priority of
>>> one's unconfirmed transaction is. I can think of a few block/mempool
>>> explorers who might want to display this information for users.
>>>
>>> ### RBF Improvement Proposals
>>>
>>> After speaking to quite a few people, here are some suggestions
>>> for improvements that I have heard:
>>>
>>> * The ancestor score of the replacement must be {5, 10, N}% higher
>>> than that of every original transaction.
>>>
>>> * The ancestor score of the replacement must be 1sat/vB higher than
>>> that of every original transaction.
>>>
>>> * If the original transaction is in the top {0.75MvB, 1MvB} of the
>>> mempool, apply the current rules (absolute fees must increase and
>>> pay for the replacement transaction's new bandwidth). Otherwise, use a
>>> feerate-only rule.
>>>
>>> * If fees don't increase, the size of the replacement transaction must
>>> decrease by at least N%.
>>>
>>> * Rate-limit how many replacements we allow per prevout.
>>>
>>> * Rate-limit transaction validation in general, per peer.
>>>
>>> Perhaps some others on the mailing list can chime in to throw other
>>> ideas into the ring and/or combine some of these rules into a sensible
>>> policy.
>>>
>>> #### Replace by Feerate Only
>>>
>>> I don't think there's going to be a single-line feerate-based
>>> rule that can incorporate everything we need.
>>> On one hand, a feerate-only approach helps eliminate the issues
>>> associated with Rule #3. On the other hand, I believe the main concern
>>> with a feerate-only approach is how to rate limit replacements. We
>>> don't want to enable an attack such as:
>>>
>>> 1. Attacker broadcasts large, low-feerate transaction, and attaches a
>>> chain of descendants.
>>>
>>> 2. The attacker replaces the transaction with a smaller but higher
>>> feerate transaction, attaching a new chain of descendants.
>>>
>>> 3. Repeat 1000 times.
>>>
>>> #### Fees in Next Block and Feerate for the Rest of the Mempool
>>>
>>> Perhaps we can look at replacements like this:
>>>
>>> 1. Calculate the directly conflicting transactions and, with their
>>> descendants, the original transactions. Check signaling. Limit the
>>> total volume (e.g. can't be more than 100 total or 1MvB or something).
>>>
>>> 2. Find which original transactions would be in the next ~1 block. The
>>> replacement must pay at least this amount + X% in absolute fees. This
>>> guarantees that the fees of the next block doesn't decrease.
>>>
>>> 3. Find which transactions would be left in the mempool after that ~1
>>> block. The replacement's feerate must be Y% higher than the maximum
>>> mining score of these transactions. This guarantees that you now have
>>> only *better* candidates in your after-this-block mempool than you did
>>> before, even if the size and fees the transactions decrease.
>>>
>>> 4. Now you have two numbers: a minimum absolute fee amount and a
>>> minimum feerate. Check to see if the replacement(s) meet these
>>> minimums. Also, a wallet would be able to ask the node "What fee and
>>> feerate would I need to put on a transaction replacing this?" and use
>>> this information to fund a replacement transaction, without needing to
>>> guess or overshoot.
>>>
>>> Obviously, there are some magic numbers missing here. X and Y are
>>> TBD constants to ensure we have some kind of rate limiting for the
>>> number of replacements allowed using some set of fees.
>>>
>>> What should they be? We can do some arithmetic to see what happens if
>>> you start with the biggest/lowest feerate transaction and do a bunch
>>> of replacements. Maybe we end up with values that are high enough to
>>> prevent abuse and make sense for applications/users that do RBF.
>>>
>>> ### Mempool Changes Need for Implementation
>>>
>>> As described in the mining score section above,
>>> we may want additional tooling to more accurately assess
>>> the economic gain of replacing transactions in our mempool.
>>>
>>> A few options have been discussed:
>>>
>>> * Calculate block templates on the fly when we need to consider a
>>> replacement. However, since replacements are [quite common][11]
>>> and the information might be useful for other things as well,
>>> it may be worth it to cache a block template.
>>>
>>> * Keep a persistent block template so that we know what transactions
>>> we would put in the next block. We need to remember the feerate
>>> at which each transaction was included in the template, because an
>>> ancestor package may be included in the same block template in
>>> multiple subsets. Transactions included earlier alter the ancestor
>>> feerate of the remaining transactions in the package. We also need
>>> to keep track of the new feerates of transactions left over.
>>>
>>> * Divide the mempool into two layers, "high feerate" and "low
>>> feerate." The high feerate layer contains ~1 block of packages with
>>> the highest ancestor feerates, and the low feerate layer contains
>>> everything else. At the edge of a block, we have a Knapsacky problem
>>> where the next highest ancestor feerate package might not fit, so we
>>> would probably want the high feerate layer ~2MvB or something to avoid
>>> underestimating the fees.
>>>
>>> ## Acknowledgements
>>>
>>> Thank you to everyone whose RBF-related suggestions, grievances,
>>> criticisms and ideas were incorporated in this document:
>>> Andrew Chow, Matt Corallo, Suhas Daftuar, Christian Decker,
>>> Mark Erhardt, Lloyd Fournier, Lisa Neigut, John Newbery,
>>> Antoine Poinsot, Antoine Riard, Larry Ruane,
>>>
>>> S3RK and Bastien Teinturier.
>>>
>>> Thanks for reading!
>>>
>>> Best,
>>> Gloria
>>> [1]: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
>>> [2]: https://github.com/bitcoin/bitcoin/pull/23121#issuecomment-929475999
>>> [3]: https://github.com/Xekyo/bitcoin/commit/d754b0242ec69d42c570418aebf9c1335af0b8ea
>>> [4]: https://github.com/bitcoindevkit/bdk/issues/144
>>> [5]: https://github.com/bitcoindevkit/bdk/issues/414
>>> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
>>> [7]: https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#new-unconfirmed-inputs-rule-2
>>> [8]: https://github.com/bitcoin/bitcoin/pull/23121#discussion_r777131366
>>> [9]: https://github.com/bitcoin/bitcoin/pull/22290#issuecomment-865887922
>>> [10]: https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
>>> [11]: https://github.com/bitcoin/bitcoin/pull/22539#issuecomment-885763670
>>> [12]: https://github.com/bitcoin/bitcoin/pull/24007
>>> [13]: https://github.com/bitcoin/bitcoin/blob/1a369f006fd0bec373b95001ed84b480e852f191/src/wallet/feebumper.cpp#L114
>>>
>>> [14]: https://github.com/bitcoin/bitcoin/blob/cf5bb048e80d4cde8828787b266b7f5f2e3b6d7b/src/node/miner.cpp#L310-L320
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220205/3641f38d/attachment-0001.html>;

📅 Original date posted:2021-10-11 📝 Original message:I was ...

2023-06-08T01:00:00+02:00

In reply to nevent1q…xckd
_________________________

📅 Original date posted:2021-10-11
📝 Original message: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 leverage the upcoming Taproot soft fork that risks getting drowned out by speculating on the next soft fork.

There is clearly nothing wrong with some individuals continuously working on, designing and refining new possible consensus changes and whoever is interested is free to follow and participate in those discussions. This is Bitcoin, no one let alone me can decide what people should focus on. Indeed I intend to allocate a portion of my time to following and understanding the trade-offs of current and future soft fork proposals. However, in this post I will argue against frequent soft forks with a single or minimal set of features and instead argue for infrequent soft forks with batches of features.

I fully understand the desire and motivation to get consensus changes into Bitcoin as quickly as possible when certain use cases depend on them. However, the robustness, security and ability to resist harmful or suboptimal changes to the system is clearly the ultimate priority. The more frequently soft forks are attempted the harder it is for the community to ensure harmful or suboptimal changes don’t creep into the consensus rules. I am well aware of how much community mindshare Taproot activation demanded this year. This is how it should be. The community should be informed and vigilant when the consensus rules are changed. Every full node will either immediately on activation or in future enforce these consensus rule changes and so it is in the interests of every full node operator that these changes have been subject to the ultimate levels of community review and rigorous testing. Attempting them frequently either requires continuous community monitoring or an acceptance that an unneeded or harmful consensus change could easily creep into Bitcoin. Neither of these options seem acceptable to me. It is not reasonable to ask all the different segments of the community to dedicate full time resources to stay on top of proposed consensus changes. Hence treating a pull request to a Bitcoin implementation that requires a soft fork like any other pull request is shortsighted.

Merging soft fork code into a Bitcoin implementation

The code for a soft fork should not be merged into a Bitcoin implementation, let alone activation parameters (discussed later), until the maintainers of that implementation are comfortable that the entirety of that soft fork has sufficient community consensus. This includes what many consider the reference implementation and dominant implementation on the network, Bitcoin Core. A soft fork pull request cannot and should not be treated like any other pull request which can be merged with anything from 1 to 10 ACKs from long term or newer contributors. The act of merging a pull request that is part of a proposed soft fork is an acknowledgement by the maintainer(s) of that implementation that they consider the entirety of that proposed soft fork to have community consensus. That includes what is included in that soft fork as well as what isn’t. If there is a prevailing view that the current design could be improved, could feasibly be replaced by something superior in future or merely hasn’t been subject to sufficient community review it should not be merged.

Of course there is no ultimate authority to enforce that this happens, Bitcoin is an entirely voluntary system. A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources.

Soft fork activation

Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork. Merging activation parameters or encouraging miner signaling before it is clear there is community consensus on the entirety of the soft fork is putting the cart before the horse.

Taproot showed it was possible through the sustained efforts of many individuals and many organizations to achieve overwhelming community consensus for a soft fork. It is obviously impossible to get 100 percent consensus but Taproot appeared to get close to that. I did not identify any resistance whatsoever to merging Taproot PRs or the objective of getting Taproot activated although there was one long term contributor who effectively NACKed Taproot based on quantum resistance concerns.

Activation method and activation parameters ended up being more challenging to obtain overwhelming community consensus. Although I and a number of others participated in multiple open IRC meetings and spent months on IRC trying to find a way to get Taproot activated with at least rough consensus a number of disagreements remain. I don’t think these are necessarily showstoppers for future soft forks and assuming Taproot activates safely next month they ended up not being showstoppers for Taproot. However, it is clear the bar that was achieved regarding community consensus for the Taproot soft fork wasn’t met for the activation method and activation parameters. In a world where there isn’t overwhelming community consensus on the activation method, the activation parameters and what to do if the first activation attempt fails we have to accept that soft fork activations contain downside risk on top of the already acknowledged risks of bugs, consensus divergences and botched implementations of soft fork features. To layer on top a level of uncertainty over whether there is community consensus for the actual soft fork seems unacceptable to me.

This is an important additional argument for infrequent soft forks with batches of features rather than frequent soft forks with a single feature. If there is a chain split risk every time you attempt a soft fork you should not casually attempt a soft fork frequently or with abandon. There has to be community consensus that the upsides of the soft fork are sufficient to take on these downside risks of disruption or worse chain splits. I was of the strong personal view that the upsides outweighed the downside risks for Taproot activation in 2021 but this is a judgment we as a community will have to make for each and every future proposed soft fork. It is easy to get excited about shiny new features. It is harder to ensure harmful or suboptimal changes don’t creep into the consensus rules and harder yet to minimize the risk of chain splits if soft forks are attempted frequently.

--

Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211011/500ca9d1/attachment.html>;

📅 Original date posted:2021-04-10 📝 Original message:Hi ...

2023-06-07T20:31:32+02:00

In reply to nevent1q…zj5y
_________________________

📅 Original date posted:2021-04-10
📝 Original message: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
in Core.

We can discuss in the meeting what we think the cut off date should be
for when Core should no longer be a consideration. Personally I think
(and hope) we will see progress on #21377 in the coming days.

For the sake of the mailing list Bitcoin Mechanic has set up a meeting
to discuss an alternative release to Core with Taproot activation
code.

Thanks
Michael

> Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

> The focus of the meeting will be ratifying the Taproot activation plan previously discussed at the March 16th meeting (aka 2021-03 Plan Y as summarized here):

https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0

> While there was never any consensus reached on the LOT parameter, there appears to be consensus on BIP8 and the remaining parameters, and more than sufficient support for LOT=True to proceed safely.

> Miners will have 18 months in which to signal and accelerate activation. If not, taproot will activate regardless.

> With a majority of the economy running this it will guarantee eventual lock-in of taproot with the smallest chance of a chain split.

> As a reminder, the channel is also open for ongoing discussion 24/7, and there is a web chat client here:

> https://webchat.freenode.net/?channel=##taproot-activation

> Best,

> Bitcoin Mechanic

> Sent with [ProtonMail](https://protonmail.com/) Secure Email.

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

📅 Original date posted:2021-02-18 📝 Original message:> ...

2023-06-07T20:28:50+02:00

In reply to nevent1q…w7kt
_________________________

📅 Original date posted:2021-02-18
📝 Original message:> 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 important as bad short term PR?
That is a depressing outlook if that is what you believe.

Even in that worst case scenario exchanges should not lose money if they
are competent and are able to manage that risk.

On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> 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 a huge
> improvement and am looking forward to being able to
> use it, 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.
>
> Matt
>
> On 2/18/21 09:26, Michael Folkson wrote:
> > 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 of it) greatly benefit from upgrades such as
> > Taproot. To say we shouldn't do Taproot or any future soft forks because
> there is a small but real risk of chain splits
> > I think is shortsighted. Indeed I think even if we collectively decided
> not to do any future soft fork upgrades ever
> > again on this mailing list that wouldn't stop soft fork attempts from
> other people in future.
> >
> > I don't think there is anything else we can do to minimize that risk for
> the Taproot soft fork at this point though I'm
> > open to ideas. To reiterate that risk will never be zero. I don't think
> I see Bitcoin as fragile as you seem to (though
> > admittedly you have a much better understanding than me of what happened
> in 2017).
> >
> > The likely scenario for the Taproot soft fork is LOT turns out to be
> entirely irrelevant and miners activate Taproot
> > before it becomes relevant. And even the unlikely worst case scenario
> would only cause short term disruption and
> > wouldn't kill Bitcoin long term.
> >
> > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists at mattcorallo.com
> <mailto:lf-lists at mattcorallo.com>> wrote:
> >
> > 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 absolute worst outcome at all
> possible is to have it fall out of consensus.
> >
> > Matt
> >
> >> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >>
> >>
> >> 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 they are allowed to use Bitcoin Core.
> >>
> >> My current understanding is that roasbeef is planning to set
> LOT=false on btcd (an alternative protocol
> >> implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided
> on Bitcoin Knots.
> >>
> >>
> >>
> >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com
> <mailto:ZmnSCPxj at protonmail.com>> wrote:
> >>
> >> 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 decide.
> >>
> >> A thing that could be done, without mandating either LOT=true
> or LOT=false, would be to have a release that
> >> requires a `taprootlot=1` or `taprootlot=0` and refuses to
> start if the parameter is not set.
> >>
> >> This assures everyone 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 at lists.linuxfoundation.org
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >> >
> >> > > 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 from a naive assumption that users
> MUST upgrade to the choice that is submitted into
> >> code. But in fact this isn't true and some voices in this
> discussion need to be more humble about what users
> >> must or must not run.
> >> > >
> >> > > I personally have never made this assumption. Of course
> users aren't forced to run any particular software
> >> version, quite the opposite. Defaults set in software versions
> matter though as many users won't change them.
> >> > >
> >> > > > Does no one realize that it is a very possible outcome
> that if LOT=true is released there may be only a
> >> handful of people that begin running it while everyone else
> delays their upgrade (with the very good reason of
> >> not getting involved in politics) and a year later those
> handful of people just become stuck at the moment of
> >> MUST_SIGNAL, unable to mine new blocks?
> >> > >
> >> > > It is a possible outcome but the likely outcome is that
> miners activate Taproot before LOT is even
> >> relevant. I think it is prudent to prepare for the unlikely but
> possible outcome that miners fail to activate
> >> and hence have this discussion now rather than be unprepared
> for that eventuality. If LOT is set to false in a
> >> software release there is the possibility (T2 in
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >> <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>;)
> of individuals or a
> >> proportion of the community changing LOT to true. In that sense
> setting LOT=false in a software release
> >> appears to be no more safe than LOT=true.
> >> > >
> >> > > > The result: a wasted year of waiting and a minority of
> people who didn't want to be lenient with miners
> >> by default.
> >> > >
> >> > > There is the (unlikely but possible) possibility of a
> wasted year if LOT is set to false and miners fail
> >> to activate. I'm not convinced by this perception that LOT=true
> is antagonistic to miners. I actually think it
> >> offers them clarity on what will happen over a year time period
> and removes the need for coordinated or
> >> uncoordinated community UASF efforts on top of LOT=false.
> >> > >
> >> > > > 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.
> >> > >
> >> > > I don't know what you are recommending here to avoid "this
> darkest timeline". Open discussions have
> >> occurred and are continuing and in my mailing list post that
> you responded to **I recommended we propose
> >> LOT=false be set in protocol implementations such as Bitcoin
> Core**. I do think this apocalyptic language
> >> isn't particularly helpful. In an open consensus system
> discussion is healthy, we should prepare for bad or
> >> worst case scenarios in advance and doing so is not
> antagonistic or destructive. Mining pools have pledged
> >> support for Taproot but we don't build secure systems based on
> pledges of support, we build them to minimize
> >> trust in any human actors. We can be grateful that people like
> Alejandro have worked hard on
> >> taprootactivation.com <http://taprootactivation.com>; (and this
> effort has informed the discussion) without
> >> taking pledges of support as cast iron guarantees.
> >> > >
> >> > > TL;DR It sounds like you agree with my recommendation to
> set LOT=false in protocol implementations in my
> >> email :)
> >> > >
> >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
> arielluaces at gmail.com
> >> <mailto:arielluaces at gmail.com>> wrote:
> >> > >
> >> > > > 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".
> >> > > > A UASF can consist of a single node, ten nodes, a
> thousand, half of all nodes, all business' nodes, or
> >> even all the non mining nodes. On another dimension it can have
> zero mining support, 51% support, 49% support,
> >> or any support right up against a miner activation threshold.
> >> > > > Hell a UASF doesn't even need code or even a single node
> running as long as it exists as a possibility
> >> in people's minds.
> >> > > > The only thing a UASF doesn't have is miner support above
> an agreed activation threshold (some number
> >> above %51).
> >> > > > I say this because it strikes me when people say that
> they are for LOT=true with the logic that since a
> >> UASF is guaranteed to happen then it's better to just make it
> default from the beginning. Words like
> >> coordination and safety are sometimes sprinkled into the
> argument.
> >> > > > The argument comes from a naive assumption that users
> MUST upgrade to the choice that is submitted into
> >> code. But in fact this isn't true and some voices in this
> discussion need to be more humble about what users
> >> must or must not run.
> >> > > > Does no one realize that it is a very possible outcome
> that if LOT=true is released there may be only a
> >> handful of people that begin running it while everyone else
> delays their upgrade (with the very good reason of
> >> not getting involved in politics) and a year later those
> handful of people just become stuck at the moment of
> >> MUST_SIGNAL, unable to mine new blocks? Or attracting a
> minority of miners, activating, and forking off into a
> >> minority fork. Then a lot=false could be started that ends up
> activating the feature now that the stubborn
> >> option has ran its course.
> >> > > > The result: a wasted year of waiting and a minority of
> people who didn't want to be lenient with miners
> >> by default. The chains could be called BitcoinLenient and
> BitcoinStubborn.
> >> > > > How is that strictly safer or more coordinated?
> >> > > > I may be in the minority, or maybe a silent majority, or
> maybe a majority that just hasn't considered
> >> this as a choice but honestly if there is contention about
> whether we're going to be stubborn or lenient with
> >> miners for Taproot and in the future then I prefer to just not
> activate anything at all. I'm fine for calling
> >> bitcoin ossified, accepting that segwit is Bitcoin's last
> network upgrade. Taproot is amazing but no new
> >> feature is worth a network split down the middle.
> >> > > > Maybe in 10 or 20 years, when other blockchains implement
> features like Taproot and many more, we will
> >> become envious enough to put aside our differences on how to
> behave towards miners and finally activate Taproot.
> >> > > > 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.
> >> > > > Cheers
> >> > > > Ariel Lorenzo-Luaces
> >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >> > > >
> >> > > > > 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 follow up meeting
> almost entirely
> >> > > > > focused on whether LOT (lockinontimeout) should be set
> to true or
> >> > > > > false.
> >> > > > >
> >> > > > > The meeting was announced here:
> >> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >> <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >
> >> > > > >
> >> > > > > In that mailing list post I outlined the arguments for
> LOT=true (T1 to
> >> > > > > T6) and arguments for LOT=false (F1 to F6) in their
> strongest form I
> >> > > > > could. David Harding responded with an additional
> argument for
> >> > > > > LOT=false (F7) here:
> >> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> >> <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> >
> >> > > > >
> >> > > > > These meetings are very challenging given they are open
> to all, you
> >> > > > > don’t know who will attend and you don’t know most
> people’s views in
> >> > > > > advance. I tried to give time for both the LOT=true
> arguments and the
> >> > > > > LOT=false arguments to be discussed as I knew there was
> support for
> >> > > > > both. We only tried evaluating which had more support
> and which had
> >> > > > > more strong opposition towards the end of the meeting.
> >> > > > >
> >> > > > > The conversation log is here:
> >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log <
> http://gnusha.org/taproot-activation/2021-02-16.log>;
> >> > > > >
> >> > > > > (If you are so inclined you can watch a video of the
> meeting here.
> >> > > > > Thanks to the YouTube account “Bitcoin” for setting up
> the livestream:
> >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <
> https://www.youtube.com/watch?v=vpl5q1ovMLM>;)
> >> > > > >
> >> > > > > A summary of the meeting was provided by Luke Dashjr on
> Mastodon here:
> >> > > > >
> https://bitcoinhackers.org/@lukedashjr/105742918779234566
> >> <https://bitcoinhackers.org/@lukedashjr/105742918779234566>;
> >> > > > >
> >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely
> unproductive, but we
> >> > > > > did manage to come to consensus on everything but
> LockinOnTimeout.
> >> > > > >
> >> > > > > Activation height range: 693504-745920
> >> > > > >
> >> > > > > MASF threshold: 1815/2016 blocks (90%)
> >> > > > >
> >> > > > > Keep in mind only ~100 people showed for the meetings,
> hardly
> >> > > > > representative of the entire community.
> >> > > > >
> >> > > > > So, these details remain JUST a proposal for now.
> >> > > > >
> >> > > > > It seems inevitable that there won't be consensus on
> LOT.
> >> > > > >
> >> > > > > Everyone will have to choose for himself. :/
> >> > > > >
> >> > > > > Personally I agree with most of this. I agree that
> there wasn’t
> >> > > > > overwhelming consensus for either LOT=true or
> LOT=false. However, from
> >> > > > > my perspective there was clearly more strong opposition
> (what would
> >> > > > > usually be deemed a NACK in Bitcoin Core review
> terminology) from
> >> > > > > Bitcoin Core contributors, Lightning developers and
> other community
> >> > > > > members against LOT=true than there was for LOT=false.
> Andrew Chow
> >> > > > > tried to summarize views from the meeting in this
> analysis:
> >> > > > >
> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> >> <
> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>;
> >> > > > >
> >> > > > > I am also aware of other current and previous Bitcoin
> Core
> >> > > > > contributors and Lightning developers who didn’t attend
> the meeting in
> >> > > > > person who are opposed to LOT=true. I don’t want to put
> them in the
> >> > > > > spotlight for no reason but if you go through the
> conversation logs of
> >> > > > > not only the meeting but the weeks of discussion prior
> to this meeting
> >> > > > > you will see their views evaluated on the
> ##taproot-activation
> >> > > > > channel. In addition, on taprootactivation.com <
> http://taprootactivation.com>; some mining pools
> >> > > > > expressed a preference for lot=false though I don’t
> know how strong
> >> > > > > that preference was.
> >> > > > >
> >> > > > > I am only one voice but it is my current assessment
> that if we are to
> >> > > > > attempt to finalize Taproot activation parameters and
> propose them to
> >> > > > > the community at this time our only option is to
> propose LOT=false.
> >> > > > > Any further delay appears to me counterproductive in
> our collective
> >> > > > > aim to get the Taproot soft fork activated as early as
> possible.
> >> > > > >
> >> > > > > Obviously others are free to disagree with that
> assessment and
> >> > > > > continue discussions but personally I will be
> attempting to avoid
> >> > > > > those discussions unless prominent new information
> comes to light or
> >> > > > > various specific individuals change their minds.
> >> > > > >
> >> > > > > Next week we are planning a code review of the Bitcoin
> Core PR #19573
> >> > > > > which was initially delayed because of this LOT
> discussion. As I’ve
> >> > > > > said previously that will be loosely following the
> format of the
> >> > > > > Bitcoin Core PR review club and will be lower level and
> more
> >> > > > > technical. That is planned for Tuesday February 23rd at
> 19:00 UTC on
> >> > > > > the IRC channel ##taproot-activation.
> >> > > > >
> >> > > > > Thanks to the meeting participants (and those who
> joined the
> >> > > > > discussion on the channel prior and post the meeting)
> for engaging
> >> > > > > productively and in good faith.
> >> > >
> >> > > --
> >> > > Michael Folkson
> >> > > Email: michaelfolkson at gmail.com <mailto:
> michaelfolkson at gmail.com>
> >> > > Keybase: michaelfolkson
> >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> > > _______________________________________________
> >> > > bitcoin-dev mailing list
> >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:
> bitcoin-dev at lists.linuxfoundation.org>
> >> > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >>
> >>
> >>
> >>
> >> --
> >> Michael Folkson
> >> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com>
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:
> bitcoin-dev at lists.linuxfoundation.org>
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> >
> >
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com>
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210218/6d75f9dd/attachment-0001.html>;

📅 Original date posted:2021-02-18 📝 Original message:Thanks ...

2023-06-07T20:28:48+02:00

In reply to nevent1q…h0jp
_________________________

📅 Original date posted:2021-02-18
📝 Original message: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
of it) greatly benefit from upgrades such as Taproot. To say we shouldn't
do Taproot or any future soft forks because there is a small but real risk
of chain splits I think is shortsighted. Indeed I think even if we
collectively decided not to do any future soft fork upgrades ever again on
this mailing list that wouldn't stop soft fork attempts from other people
in future.

I don't think there is anything else we can do to minimize that risk for
the Taproot soft fork at this point though I'm open to ideas. To reiterate
that risk will never be zero. I don't think I see Bitcoin as fragile as you
seem to (though admittedly you have a much better understanding than me of
what happened in 2017).

The likely scenario for the Taproot soft fork is LOT turns out to be
entirely irrelevant and miners activate Taproot before it becomes relevant.
And even the unlikely worst case scenario would only cause short term
disruption and wouldn't kill Bitcoin long term.

On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> 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 absolute worst outcome at all possible
> is to have it fall out of consensus.
>
> Matt
>
> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> 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 they are allowed to use Bitcoin Core.
>
> My current understanding is that roasbeef is planning to set LOT=false on
> btcd (an alternative protocol implementation to Bitcoin Core) and Luke
> Dashjr hasn't yet decided on Bitcoin Knots.
>
>
>
> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> 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 decide.
>>
>> A thing that could be done, without mandating either LOT=true or
>> LOT=false, would be to have a release that requires a `taprootlot=1` or
>> `taprootlot=0` and refuses to start if the parameter is not set.
>>
>> This assures everyone 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 at lists.linuxfoundation.org> wrote:
>> >
>> > > 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 from a naive assumption that users MUST upgrade
>> to the choice that is submitted into code. But in fact this isn't true and
>> some voices in this discussion need to be more humble about what users must
>> or must not run.
>> > >
>> > > I personally have never made this assumption. Of course users aren't
>> forced to run any particular software version, quite the opposite. Defaults
>> set in software versions matter though as many users won't change them.
>> > >
>> > > > Does no one realize that it is a very possible outcome that if
>> LOT=true is released there may be only a handful of people that begin
>> running it while everyone else delays their upgrade (with the very good
>> reason of not getting involved in politics) and a year later those handful
>> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
>> new blocks?
>> > >
>> > > It is a possible outcome but the likely outcome is that miners
>> activate Taproot before LOT is even relevant. I think it is prudent to
>> prepare for the unlikely but possible outcome that miners fail to activate
>> and hence have this discussion now rather than be unprepared for that
>> eventuality. If LOT is set to false in a software release there is the
>> possibility (T2 in
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
>> of individuals or a proportion of the community changing LOT to true. In
>> that sense setting LOT=false in a software release appears to be no more
>> safe than LOT=true.
>> > >
>> > > > The result: a wasted year of waiting and a minority of people who
>> didn't want to be lenient with miners by default.
>> > >
>> > > There is the (unlikely but possible) possibility of a wasted year if
>> LOT is set to false and miners fail to activate. I'm not convinced by this
>> perception that LOT=true is antagonistic to miners. I actually think it
>> offers them clarity on what will happen over a year time period and removes
>> the need for coordinated or uncoordinated community UASF efforts on top of
>> LOT=false.
>> > >
>> > > > 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.
>> > >
>> > > I don't know what you are recommending here to avoid "this darkest
>> timeline". Open discussions have occurred and are continuing and in my
>> mailing list post that you responded to **I recommended we propose
>> LOT=false be set in protocol implementations such as Bitcoin Core**. I do
>> think this apocalyptic language isn't particularly helpful. In an open
>> consensus system discussion is healthy, we should prepare for bad or worst
>> case scenarios in advance and doing so is not antagonistic or destructive.
>> Mining pools have pledged support for Taproot but we don't build secure
>> systems based on pledges of support, we build them to minimize trust in any
>> human actors. We can be grateful that people like Alejandro have worked
>> hard on taprootactivation.com (and this effort has informed the
>> discussion) without taking pledges of support as cast iron guarantees.
>> > >
>> > > TL;DR It sounds like you agree with my recommendation to set
>> LOT=false in protocol implementations in my email :)
>> > >
>> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
>> arielluaces at gmail.com> wrote:
>> > >
>> > > > 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".
>> > > > A UASF can consist of a single node, ten nodes, a thousand, half of
>> all nodes, all business' nodes, or even all the non mining nodes. On
>> another dimension it can have zero mining support, 51% support, 49%
>> support, or any support right up against a miner activation threshold.
>> > > > Hell a UASF doesn't even need code or even a single node running as
>> long as it exists as a possibility in people's minds.
>> > > > The only thing a UASF doesn't have is miner support above an agreed
>> activation threshold (some number above %51).
>> > > > I say this because it strikes me when people say that they are for
>> LOT=true with the logic that since a UASF is guaranteed to happen then it's
>> better to just make it default from the beginning. Words like coordination
>> and safety are sometimes sprinkled into the argument.
>> > > > The argument comes from a naive assumption that users MUST upgrade
>> to the choice that is submitted into code. But in fact this isn't true and
>> some voices in this discussion need to be more humble about what users must
>> or must not run.
>> > > > Does no one realize that it is a very possible outcome that if
>> LOT=true is released there may be only a handful of people that begin
>> running it while everyone else delays their upgrade (with the very good
>> reason of not getting involved in politics) and a year later those handful
>> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
>> new blocks? Or attracting a minority of miners, activating, and forking off
>> into a minority fork. Then a lot=false could be started that ends up
>> activating the feature now that the stubborn option has ran its course.
>> > > > The result: a wasted year of waiting and a minority of people who
>> didn't want to be lenient with miners by default. The chains could be
>> called BitcoinLenient and BitcoinStubborn.
>> > > > How is that strictly safer or more coordinated?
>> > > > I may be in the minority, or maybe a silent majority, or maybe a
>> majority that just hasn't considered this as a choice but honestly if there
>> is contention about whether we're going to be stubborn or lenient with
>> miners for Taproot and in the future then I prefer to just not activate
>> anything at all. I'm fine for calling bitcoin ossified, accepting that
>> segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
>> feature is worth a network split down the middle.
>> > > > Maybe in 10 or 20 years, when other blockchains implement features
>> like Taproot and many more, we will become envious enough to put aside our
>> differences on how to behave towards miners and finally activate Taproot.
>> > > > 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.
>> > > > Cheers
>> > > > Ariel Lorenzo-Luaces
>> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > > >
>> > > > > 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 follow up meeting almost entirely
>> > > > > focused on whether LOT (lockinontimeout) should be set to true or
>> > > > > false.
>> > > > >
>> > > > > The meeting was announced here:
>> > > > >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
>> > > > >
>> > > > > In that mailing list post I outlined the arguments for LOT=true
>> (T1 to
>> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest
>> form I
>> > > > > could. David Harding responded with an additional argument for
>> > > > > LOT=false (F7) here:
>> > > > >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
>> > > > >
>> > > > > These meetings are very challenging given they are open to all,
>> you
>> > > > > don’t know who will attend and you don’t know most people’s views
>> in
>> > > > > advance. I tried to give time for both the LOT=true arguments and
>> the
>> > > > > LOT=false arguments to be discussed as I knew there was support
>> for
>> > > > > both. We only tried evaluating which had more support and which
>> had
>> > > > > more strong opposition towards the end of the meeting.
>> > > > >
>> > > > > The conversation log is here:
>> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
>> > > > >
>> > > > > (If you are so inclined you can watch a video of the meeting here.
>> > > > > Thanks to the YouTube account “Bitcoin” for setting up the
>> livestream:
>> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM)
>> > > > >
>> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon
>> here:
>> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
>> > > > >
>> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive,
>> but we
>> > > > > did manage to come to consensus on everything but LockinOnTimeout.
>> > > > >
>> > > > > Activation height range: 693504-745920
>> > > > >
>> > > > > MASF threshold: 1815/2016 blocks (90%)
>> > > > >
>> > > > > Keep in mind only ~100 people showed for the meetings, hardly
>> > > > > representative of the entire community.
>> > > > >
>> > > > > So, these details remain JUST a proposal for now.
>> > > > >
>> > > > > It seems inevitable that there won't be consensus on LOT.
>> > > > >
>> > > > > Everyone will have to choose for himself. :/
>> > > > >
>> > > > > Personally I agree with most of this. I agree that there wasn’t
>> > > > > overwhelming consensus for either LOT=true or LOT=false. However,
>> from
>> > > > > my perspective there was clearly more strong opposition (what
>> would
>> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
>> > > > > Bitcoin Core contributors, Lightning developers and other
>> community
>> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
>> > > > > tried to summarize views from the meeting in this analysis:
>> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
>> > > > >
>> > > > > I am also aware of other current and previous Bitcoin Core
>> > > > > contributors and Lightning developers who didn’t attend the
>> meeting in
>> > > > > person who are opposed to LOT=true. I don’t want to put them in
>> the
>> > > > > spotlight for no reason but if you go through the conversation
>> logs of
>> > > > > not only the meeting but the weeks of discussion prior to this
>> meeting
>> > > > > you will see their views evaluated on the ##taproot-activation
>> > > > > channel. In addition, on taprootactivation.com some mining pools
>> > > > > expressed a preference for lot=false though I don’t know how
>> strong
>> > > > > that preference was.
>> > > > >
>> > > > > I am only one voice but it is my current assessment that if we
>> are to
>> > > > > attempt to finalize Taproot activation parameters and propose
>> them to
>> > > > > the community at this time our only option is to propose
>> LOT=false.
>> > > > > Any further delay appears to me counterproductive in our
>> collective
>> > > > > aim to get the Taproot soft fork activated as early as possible.
>> > > > >
>> > > > > Obviously others are free to disagree with that assessment and
>> > > > > continue discussions but personally I will be attempting to avoid
>> > > > > those discussions unless prominent new information comes to light
>> or
>> > > > > various specific individuals change their minds.
>> > > > >
>> > > > > Next week we are planning a code review of the Bitcoin Core PR
>> #19573
>> > > > > which was initially delayed because of this LOT discussion. As
>> I’ve
>> > > > > said previously that will be loosely following the format of the
>> > > > > Bitcoin Core PR review club and will be lower level and more
>> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC
>> on
>> > > > > the IRC channel ##taproot-activation.
>> > > > >
>> > > > > Thanks to the meeting participants (and those who joined the
>> > > > > discussion on the channel prior and post the meeting) for engaging
>> > > > > productively and in good faith.
>> > >
>> > > --
>> > > Michael Folkson
>> > > Email: michaelfolkson at gmail.com
>> > > Keybase: michaelfolkson
>> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev at lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
> --
> Michael Folkson
> Email: michaelfolkson at gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210218/7735bd99/attachment-0001.html>;

📅 Original date posted:2021-02-18 📝 Original message:Right, ...

2023-06-07T20:28:47+02:00

In reply to nevent1q…v39k
_________________________

📅 Original date posted:2021-02-18
📝 Original message: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 they are allowed to use Bitcoin Core.

My current understanding is that roasbeef is planning to set LOT=false on
btcd (an alternative protocol implementation to Bitcoin Core) and Luke
Dashjr hasn't yet decided on Bitcoin Knots.

On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> 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 decide.
>
> A thing that could be done, without mandating either LOT=true or
> LOT=false, would be to have a release that requires a `taprootlot=1` or
> `taprootlot=0` and refuses to start if the parameter is not set.
>
> This assures everyone 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 at lists.linuxfoundation.org> wrote:
> >
> > > 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 from a naive assumption that users MUST upgrade
> to the choice that is submitted into code. But in fact this isn't true and
> some voices in this discussion need to be more humble about what users must
> or must not run.
> > >
> > > I personally have never made this assumption. Of course users aren't
> forced to run any particular software version, quite the opposite. Defaults
> set in software versions matter though as many users won't change them.
> > >
> > > > Does no one realize that it is a very possible outcome that if
> LOT=true is released there may be only a handful of people that begin
> running it while everyone else delays their upgrade (with the very good
> reason of not getting involved in politics) and a year later those handful
> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
> new blocks?
> > >
> > > It is a possible outcome but the likely outcome is that miners
> activate Taproot before LOT is even relevant. I think it is prudent to
> prepare for the unlikely but possible outcome that miners fail to activate
> and hence have this discussion now rather than be unprepared for that
> eventuality. If LOT is set to false in a software release there is the
> possibility (T2 in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
> of individuals or a proportion of the community changing LOT to true. In
> that sense setting LOT=false in a software release appears to be no more
> safe than LOT=true.
> > >
> > > > The result: a wasted year of waiting and a minority of people who
> didn't want to be lenient with miners by default.
> > >
> > > There is the (unlikely but possible) possibility of a wasted year if
> LOT is set to false and miners fail to activate. I'm not convinced by this
> perception that LOT=true is antagonistic to miners. I actually think it
> offers them clarity on what will happen over a year time period and removes
> the need for coordinated or uncoordinated community UASF efforts on top of
> LOT=false.
> > >
> > > > 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.
> > >
> > > I don't know what you are recommending here to avoid "this darkest
> timeline". Open discussions have occurred and are continuing and in my
> mailing list post that you responded to **I recommended we propose
> LOT=false be set in protocol implementations such as Bitcoin Core**. I do
> think this apocalyptic language isn't particularly helpful. In an open
> consensus system discussion is healthy, we should prepare for bad or worst
> case scenarios in advance and doing so is not antagonistic or destructive.
> Mining pools have pledged support for Taproot but we don't build secure
> systems based on pledges of support, we build them to minimize trust in any
> human actors. We can be grateful that people like Alejandro have worked
> hard on taprootactivation.com (and this effort has informed the
> discussion) without taking pledges of support as cast iron guarantees.
> > >
> > > TL;DR It sounds like you agree with my recommendation to set LOT=false
> in protocol implementations in my email :)
> > >
> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
> arielluaces at gmail.com> wrote:
> > >
> > > > 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".
> > > > A UASF can consist of a single node, ten nodes, a thousand, half of
> all nodes, all business' nodes, or even all the non mining nodes. On
> another dimension it can have zero mining support, 51% support, 49%
> support, or any support right up against a miner activation threshold.
> > > > Hell a UASF doesn't even need code or even a single node running as
> long as it exists as a possibility in people's minds.
> > > > The only thing a UASF doesn't have is miner support above an agreed
> activation threshold (some number above %51).
> > > > I say this because it strikes me when people say that they are for
> LOT=true with the logic that since a UASF is guaranteed to happen then it's
> better to just make it default from the beginning. Words like coordination
> and safety are sometimes sprinkled into the argument.
> > > > The argument comes from a naive assumption that users MUST upgrade
> to the choice that is submitted into code. But in fact this isn't true and
> some voices in this discussion need to be more humble about what users must
> or must not run.
> > > > Does no one realize that it is a very possible outcome that if
> LOT=true is released there may be only a handful of people that begin
> running it while everyone else delays their upgrade (with the very good
> reason of not getting involved in politics) and a year later those handful
> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
> new blocks? Or attracting a minority of miners, activating, and forking off
> into a minority fork. Then a lot=false could be started that ends up
> activating the feature now that the stubborn option has ran its course.
> > > > The result: a wasted year of waiting and a minority of people who
> didn't want to be lenient with miners by default. The chains could be
> called BitcoinLenient and BitcoinStubborn.
> > > > How is that strictly safer or more coordinated?
> > > > I may be in the minority, or maybe a silent majority, or maybe a
> majority that just hasn't considered this as a choice but honestly if there
> is contention about whether we're going to be stubborn or lenient with
> miners for Taproot and in the future then I prefer to just not activate
> anything at all. I'm fine for calling bitcoin ossified, accepting that
> segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
> feature is worth a network split down the middle.
> > > > Maybe in 10 or 20 years, when other blockchains implement features
> like Taproot and many more, we will become envious enough to put aside our
> differences on how to behave towards miners and finally activate Taproot.
> > > > 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.
> > > > Cheers
> > > > Ariel Lorenzo-Luaces
> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > >
> > > > > 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 follow up meeting almost entirely
> > > > > focused on whether LOT (lockinontimeout) should be set to true or
> > > > > false.
> > > > >
> > > > > The meeting was announced here:
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > > >
> > > > > In that mailing list post I outlined the arguments for LOT=true
> (T1 to
> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form
> I
> > > > > could. David Harding responded with an additional argument for
> > > > > LOT=false (F7) here:
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> > > > >
> > > > > These meetings are very challenging given they are open to all, you
> > > > > don’t know who will attend and you don’t know most people’s views
> in
> > > > > advance. I tried to give time for both the LOT=true arguments and
> the
> > > > > LOT=false arguments to be discussed as I knew there was support for
> > > > > both. We only tried evaluating which had more support and which had
> > > > > more strong opposition towards the end of the meeting.
> > > > >
> > > > > The conversation log is here:
> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
> > > > >
> > > > > (If you are so inclined you can watch a video of the meeting here.
> > > > > Thanks to the YouTube account “Bitcoin” for setting up the
> livestream:
> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM)
> > > > >
> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon
> here:
> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
> > > > >
> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive,
> but we
> > > > > did manage to come to consensus on everything but LockinOnTimeout.
> > > > >
> > > > > Activation height range: 693504-745920
> > > > >
> > > > > MASF threshold: 1815/2016 blocks (90%)
> > > > >
> > > > > Keep in mind only ~100 people showed for the meetings, hardly
> > > > > representative of the entire community.
> > > > >
> > > > > So, these details remain JUST a proposal for now.
> > > > >
> > > > > It seems inevitable that there won't be consensus on LOT.
> > > > >
> > > > > Everyone will have to choose for himself. :/
> > > > >
> > > > > Personally I agree with most of this. I agree that there wasn’t
> > > > > overwhelming consensus for either LOT=true or LOT=false. However,
> from
> > > > > my perspective there was clearly more strong opposition (what would
> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
> > > > > Bitcoin Core contributors, Lightning developers and other community
> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
> > > > > tried to summarize views from the meeting in this analysis:
> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> > > > >
> > > > > I am also aware of other current and previous Bitcoin Core
> > > > > contributors and Lightning developers who didn’t attend the
> meeting in
> > > > > person who are opposed to LOT=true. I don’t want to put them in the
> > > > > spotlight for no reason but if you go through the conversation
> logs of
> > > > > not only the meeting but the weeks of discussion prior to this
> meeting
> > > > > you will see their views evaluated on the ##taproot-activation
> > > > > channel. In addition, on taprootactivation.com some mining pools
> > > > > expressed a preference for lot=false though I don’t know how strong
> > > > > that preference was.
> > > > >
> > > > > I am only one voice but it is my current assessment that if we are
> to
> > > > > attempt to finalize Taproot activation parameters and propose them
> to
> > > > > the community at this time our only option is to propose LOT=false.
> > > > > Any further delay appears to me counterproductive in our collective
> > > > > aim to get the Taproot soft fork activated as early as possible.
> > > > >
> > > > > Obviously others are free to disagree with that assessment and
> > > > > continue discussions but personally I will be attempting to avoid
> > > > > those discussions unless prominent new information comes to light
> or
> > > > > various specific individuals change their minds.
> > > > >
> > > > > Next week we are planning a code review of the Bitcoin Core PR
> #19573
> > > > > which was initially delayed because of this LOT discussion. As I’ve
> > > > > said previously that will be loosely following the format of the
> > > > > Bitcoin Core PR review club and will be lower level and more
> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC
> on
> > > > > the IRC channel ##taproot-activation.
> > > > >
> > > > > Thanks to the meeting participants (and those who joined the
> > > > > discussion on the channel prior and post the meeting) for engaging
> > > > > productively and in good faith.
> > >
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson at gmail.com
> > > Keybase: michaelfolkson
> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210218/726417ad/attachment-0001.html>;

📅 Original date posted:2021-02-18 📝 Original message:Thanks ...

2023-06-07T20:28:44+02:00

In reply to nevent1q…gjlg
_________________________

📅 Original date posted:2021-02-18
📝 Original message: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 from a naive assumption that users MUST upgrade to the
choice that is submitted into code. But in fact this isn't true and some
voices in this discussion need to be more humble about what users must or
must not run.

I personally have never made this assumption. Of course users aren't forced
to run any particular software version, quite the opposite. Defaults set in
software versions matter though as many users won't change them.

> Does no one realize that it is a very possible outcome that if LOT=true
is released there may be only a handful of people that begin running it
while everyone else delays their upgrade (with the very good reason of not
getting involved in politics) and a year later those handful of people just
become stuck at the moment of MUST_SIGNAL, unable to mine new blocks?

It is a possible outcome but the likely outcome is that miners activate
Taproot before LOT is even relevant. I think it is prudent to prepare for
the unlikely but possible outcome that miners fail to activate and hence
have this discussion now rather than be unprepared for that eventuality. If
LOT is set to false in a software release there is the possibility (T2 in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)
of individuals or a proportion of the community changing LOT to true. In
that sense setting LOT=false in a software release appears to be no more
safe than LOT=true.

> The result: a wasted year of waiting and a minority of people who didn't
want to be lenient with miners by default.

There is the (unlikely but possible) possibility of a wasted year if LOT is
set to false and miners fail to activate. I'm not convinced by this
perception that LOT=true is antagonistic to miners. I actually think it
offers them clarity on what will happen over a year time period and removes
the need for coordinated or uncoordinated community UASF efforts on top of
LOT=false.

> 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.

I don't know what you are recommending here to avoid "this darkest
timeline". Open discussions have occurred and are continuing and in my
mailing list post that you responded to **I recommended we propose
LOT=false be set in protocol implementations such as Bitcoin Core**. I do
think this apocalyptic language isn't particularly helpful. In an open
consensus system discussion is healthy, we should prepare for bad or worst
case scenarios in advance and doing so is not antagonistic or destructive.
Mining pools have pledged support for Taproot but we don't build secure
systems based on pledges of support, we build them to minimize trust in any
human actors. We can be grateful that people like Alejandro have worked
hard on taprootactivation.com (and this effort has informed the discussion)
without taking pledges of support as cast iron guarantees.

TL;DR It sounds like you agree with my recommendation to set LOT=false in
protocol implementations in my email :)

On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces at gmail.com>
wrote:

> 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".
>
> A UASF can consist of a single node, ten nodes, a thousand, half of all
> nodes, all business' nodes, or even all the non mining nodes. On another
> dimension it can have zero mining support, 51% support, 49% support, or any
> support right up against a miner activation threshold.
>
> Hell a UASF doesn't even need code or even a single node running as long
> as it exists as a possibility in people's minds.
>
> The only thing a UASF doesn't have is miner support above an agreed
> activation threshold (some number above %51).
>
> I say this because it strikes me when people say that they are for
> LOT=true with the logic that since a UASF is guaranteed to happen then it's
> better to just make it default from the beginning. Words like coordination
> and safety are sometimes sprinkled into the argument.
>
> The argument comes from a naive assumption that users MUST upgrade to the
> choice that is submitted into code. But in fact this isn't true and some
> voices in this discussion need to be more humble about what users must or
> must not run.
>
> Does no one realize that it is a very possible outcome that if LOT=true is
> released there may be only a handful of people that begin running it while
> everyone else delays their upgrade (with the very good reason of not
> getting involved in politics) and a year later those handful of people just
> become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or
> attracting a minority of miners, activating, and forking off into a
> minority fork. Then a lot=false could be started that ends up activating
> the feature now that the stubborn option has ran its course.
> The result: a wasted year of waiting and a minority of people who didn't
> want to be lenient with miners by default. The chains could be called
> BitcoinLenient and BitcoinStubborn.
> How is that strictly safer or more coordinated?
>
> I may be in the minority, or maybe a silent majority, or maybe a majority
> that just hasn't considered this as a choice but honestly if there is
> contention about whether we're going to be stubborn or lenient with miners
> for Taproot and in the future then I prefer to just not activate anything
> at all. I'm fine for calling bitcoin ossified, accepting that segwit is
> Bitcoin's last network upgrade. Taproot is amazing but no new feature is
> worth a network split down the middle.
>
> Maybe in 10 or 20 years, when other blockchains implement features like
> Taproot and many more, we will become envious enough to put aside our
> differences on how to behave towards miners and finally activate Taproot.
>
> 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.
>
> Cheers
> Ariel Lorenzo-Luaces
> On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 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 follow up meeting almost entirely
>> focused on whether LOT (lockinontimeout) should be set to true or
>> false.
>>
>> The meeting was announced here:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
>>
>> In that mailing list post I outlined the arguments for LOT=true (T1 to
>> T6) and arguments for LOT=false (F1 to F6) in their strongest form I
>> could. David Harding responded with an additional argument for
>> LOT=false (F7) here:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
>>
>> These meetings are very challenging given they are open to all, you
>> don’t know who will attend and you don’t know most people’s views in
>> advance. I tried to give time for both the LOT=true arguments and the
>> LOT=false arguments to be discussed as I knew there was support for
>> both. We only tried evaluating which had more support and which had
>> more strong opposition towards the end of the meeting.
>>
>> The conversation log is here:
>> http://gnusha.org/taproot-activation/2021-02-16.log
>>
>> (If you are so inclined you can watch a video of the meeting here.
>> Thanks to the YouTube account “Bitcoin” for setting up the livestream:
>> https://www.youtube.com/watch?v=vpl5q1ovMLM)
>>
>> A summary of the meeting was provided by Luke Dashjr on Mastodon here:
>> https://bitcoinhackers.org/@lukedashjr/105742918779234566
>>
>> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
>> did manage to come to consensus on everything but LockinOnTimeout.
>>
>> Activation height range: 693504-745920
>>
>> MASF threshold: 1815/2016 blocks (90%)
>>
>> Keep in mind only ~100 people showed for the meetings, hardly
>> representative of the entire community.
>>
>> So, these details remain JUST a proposal for now.
>>
>> It seems inevitable that there won't be consensus on LOT.
>>
>> Everyone will have to choose for himself. :/
>>
>> Personally I agree with most of this. I agree that there wasn’t
>> overwhelming consensus for either LOT=true or LOT=false. However, from
>> my perspective there was clearly more strong opposition (what would
>> usually be deemed a NACK in Bitcoin Core review terminology) from
>> Bitcoin Core contributors, Lightning developers and other community
>> members against LOT=true than there was for LOT=false. Andrew Chow
>> tried to summarize views from the meeting in this analysis:
>> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
>>
>> I am also aware of other current and previous Bitcoin Core
>> contributors and Lightning developers who didn’t attend the meeting in
>> person who are opposed to LOT=true. I don’t want to put them in the
>> spotlight for no reason but if you go through the conversation logs of
>> not only the meeting but the weeks of discussion prior to this meeting
>> you will see their views evaluated on the ##taproot-activation
>> channel. In addition, on taprootactivation.com some mining pools
>> expressed a preference for lot=false though I don’t know how strong
>> that preference was.
>>
>> I am only one voice but it is my current assessment that if we are to
>> attempt to finalize Taproot activation parameters and propose them to
>> the community at this time our only option is to propose LOT=false.
>> Any further delay appears to me counterproductive in our collective
>> aim to get the Taproot soft fork activated as early as possible.
>>
>> Obviously others are free to disagree with that assessment and
>> continue discussions but personally I will be attempting to avoid
>> those discussions unless prominent new information comes to light or
>> various specific individuals change their minds.
>>
>> Next week we are planning a code review of the Bitcoin Core PR #19573
>> which was initially delayed because of this LOT discussion. As I’ve
>> said previously that will be loosely following the format of the
>> Bitcoin Core PR review club and will be lower level and more
>> technical. That is planned for Tuesday February 23rd at 19:00 UTC on
>> the IRC channel ##taproot-activation.
>>
>> Thanks to the meeting participants (and those who joined the
>> discussion on the channel prior and post the meeting) for engaging
>> productively and in good faith.
>>
>>

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210218/e09ce26a/attachment-0001.html>;

📅 Original date posted:2021-02-17 📝 Original ...

2023-06-07T20:28:44+02:00

In reply to nevent1q…7jrw
_________________________

📅 Original date posted:2021-02-17
📝 Original message: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 follow up meeting almost entirely
focused on whether LOT (lockinontimeout) should be set to true or
false.

The meeting was announced here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html

In that mailing list post I outlined the arguments for LOT=true (T1 to
T6) and arguments for LOT=false (F1 to F6) in their strongest form I
could. David Harding responded with an additional argument for
LOT=false (F7) here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html

These meetings are very challenging given they are open to all, you
don’t know who will attend and you don’t know most people’s views in
advance. I tried to give time for both the LOT=true arguments and the
LOT=false arguments to be discussed as I knew there was support for
both. We only tried evaluating which had more support and which had
more strong opposition towards the end of the meeting.

The conversation log is here:
http://gnusha.org/taproot-activation/2021-02-16.log

(If you are so inclined you can watch a video of the meeting here.
Thanks to the YouTube account “Bitcoin” for setting up the livestream:
https://www.youtube.com/watch?v=vpl5q1ovMLM)

A summary of the meeting was provided by Luke Dashjr on Mastodon here:
https://bitcoinhackers.org/@lukedashjr/105742918779234566

Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
did manage to come to consensus on everything but LockinOnTimeout.

Activation height range: 693504-745920

MASF threshold: 1815/2016 blocks (90%)

Keep in mind only ~100 people showed for the meetings, hardly
representative of the entire community.

So, these details remain JUST a proposal for now.

It seems inevitable that there won't be consensus on LOT.

Everyone will have to choose for himself. :/

Personally I agree with most of this. I agree that there wasn’t
overwhelming consensus for either LOT=true or LOT=false. However, from
my perspective there was clearly more strong opposition (what would
usually be deemed a NACK in Bitcoin Core review terminology) from
Bitcoin Core contributors, Lightning developers and other community
members against LOT=true than there was for LOT=false. Andrew Chow
tried to summarize views from the meeting in this analysis:
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

I am also aware of other current and previous Bitcoin Core
contributors and Lightning developers who didn’t attend the meeting in
person who are opposed to LOT=true. I don’t want to put them in the
spotlight for no reason but if you go through the conversation logs of
not only the meeting but the weeks of discussion prior to this meeting
you will see their views evaluated on the ##taproot-activation
channel. In addition, on taprootactivation.com some mining pools
expressed a preference for lot=false though I don’t know how strong
that preference was.

I am only one voice but it is my current assessment that if we are to
attempt to finalize Taproot activation parameters and propose them to
the community at this time our only option is to propose LOT=false.
Any further delay appears to me counterproductive in our collective
aim to get the Taproot soft fork activated as early as possible.

Obviously others are free to disagree with that assessment and
continue discussions but personally I will be attempting to avoid
those discussions unless prominent new information comes to light or
various specific individuals change their minds.

Next week we are planning a code review of the Bitcoin Core PR #19573
which was initially delayed because of this LOT discussion. As I’ve
said previously that will be loosely following the format of the
Bitcoin Core PR review club and will be lower level and more
technical. That is planned for Tuesday February 23rd at 19:00 UTC on
the IRC channel ##taproot-activation.

Thanks to the meeting participants (and those who joined the
discussion on the channel prior and post the meeting) for engaging
productively and in good faith.

--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3