[bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Subhead: "Nobody expects a Bitcoin Inquistion? C'mon man, *everyone* expects a Bitcoin Inquisition." As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier in the year [0], the question of "how to successfully get soft fork ideas from concept to deployment" doesn't really have a good answer today. Obviously, a centralised solution to this problem exists: we could establish a trusted group, perhaps one containing devs, industry representatives, investors, etc, have them review proposals and their implementations, and follow their lead when they decide that a proposal has met their standards and should be widely deployed. Some might even say "sipa is precisely that group". The problem with having a group of that nature isn't one of effectiveness, but rather that they are then vulnerable to pressure and corruption, which isn't desirable if we want everyone using Bitcoin to truly be peers, and often isn't desirable for the prospective members of the group either. So that's not something we should want people to volunteer for, nor is it a duty we should thrust on people. Or at least, that's my opinion, anyway. I think any alternative approach to doing consensus changes (while avoiding a chain split) has to look something like this: * propose an idea (research phase) * implement the idea (development phase) * demonstrate the idea is worthwhile (evaluation phase) * once everyone is convinced, activate (deployment phase) Without an evaluation phase that is thorough enough to convince (almost) everyone, I think deployment becomes controversial and perhaps effectively impossible (at least without some trusted leadership group). But with an evaluation phase that demonstrates to everyone who's interested that the proposal has actual value, minimal cost and no risk, I think activation could be fairly easy and straightforward. I contend that the most significant problem we have is in the "evaluation phase". How do you convince enough people that a change is sufficiently beneficial to justify the risk of messing with their money? If you're only trying to convince a few experts, then perhaps you can do that with papers and talks; but limiting the evaluation to only a few experts is effectively just falling back to the centralised approach. So I think that means that part of the "evaluation phase" should involve implementing real systems on top of the proposed change, so that you can demonstrate real value from the change. It's easy to say that "CTV can enable vaults" or "CTV can make opening a lightning channel non-interactive" -- but it's harder to go from saying something is possible to actually making it happen, so, at least to me, it seems reasonable to be skeptical of people claiming benefits without demonstrating they're achievable in practice. I contend the easiest way we could make it easy to demonstrate a soft fork working as designed is to deploy it on the default global signet, essentially as soon as it has a fully specified proposal and a reasonably high-quality implementation. The problem with that idea is that creates a conundrum: you can't activate a soft fork on the default signet without first merging the code into bitcoin core, you can't merge the code into bitcoin core until it's been fully evaluated, and the way you evaluate it is by activating it on the default signet? I think the weakest link in that loop is the first one: what if we did activate soft forks on the default signet prior to the code being merged into core? To that end, I'm proposing a fork of core that I'm calling "bitcoin-inquisition", with the idea that it branches from stable releases of core and adds support for proposed changes to consensus (CTV, ANYPREVOUT, TLUV, OP_CAT, etc...) and potentially also relay policy (relay changes are often implied by consensus changes, but also potentially things like package relay). https://github.com/bitcoin-inquisition/bitcoin/wiki https://github.com/bitcoin-inquisition/bitcoin/pulls The idea being that if you're trying to work on "upgrading lightning to support eltoo", you can iterate through changes needed to consensus (via bitcoin-inquisition) and client apps (cln, lnd, eclair etc), while testing them in public (on signet) and having any/all the pre-existing signet infrastructure available (faucets, explorers etc) without having to redeploy it yourself. Having multiple consensus changes deployed in one place also seems like it might make it easier to compare alternative approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc). So that's the concept. For practical purposes, I haven't yet merged either CTV or APO support into the bitcoin-inquisition 23.0 branch yet, and before actually mining blocks I want to make the signet miner able to automatically detect/recover if the bitcoin-inquisition node either crashes or starts producing incompatible blocks. Anyway, I wanted to post the idea publicly, both to give folks an opportunity to poke holes in the
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Apologies for any typos, somewhat jet-lagged atm. On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote: Subhead: "Nobody expects a Bitcoin Inquistion? C'mon man, *everyone* expects a Bitcoin Inquisition." As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier in the year [0], the question of "how to successfully get soft fork ideas from concept to deployment" doesn't really have a good answer today. I strongly disagree with this. Going back many, many years we've had many discussions about fork process, and the parts people (historically) agreed with tend to be: (1) come up with an idea (2) socialize the idea in the technical community, see if anyone comes up with any major issues or can suggest better ideas which solve the same use-cases in cleaner ways (3) propose the concrete idea with a more well-defined strawman, socialize that, get some kind of rough consensus in the loosely-defined, subjective, "technical community" (ie just ask people and adapt to feedback until you have found some kind of average of the opinions of people you, the fork-champion, think are reasonably well-informed!). (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there. Turns out, the issue today is a lack of champions following steps 1-3, we can debate what the correct answer is to step (4) once we actually have people who want to be champions who are willing to (humbly) push an idea forward towards rough agreement of the world of technical bitcoiners (without which I highly doubt you'd ever see broader-community consensus). Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Devrandom, > Agreed, anything that requires a phone number makes it difficult to be > pseudonymous. > > I recommend Matrix, since it doesn't require any privacy invasive > information and has e2ee by default for 1-1 conversations. Yeah sounds like people are opting for either Matrix or IRC and good to let cast open. If there are more things that the process could adopt to encourage or stay open to pseudonymous participation that's interesting to bookmark. Best, Antoine Le jeu. 15 sept. 2022 à 04:37, Devrandom via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev >> First just wanted to thank you >> for taking the initiative to >> > put this together. I think that as the community and >> > ecosystem continue to grow, it's going to be an important >> > part of the process to have groups like this develop. Hopefully >> > they allow us to resist the "Tyranny of Structurelessness" without >> > resorting to formalized governance processes and systems. >> >> Huh, lots of reading material behind that phrase. I'd heard it >> before, but hadn't looked it up. >> >> > > Defining a communication channel is still an open question: IRC, >> Slack, >> > Discord, Discourse, ... >> > >> > I would vote against Slack. IRC is probably the best but maybe too >> > high a barrier to entry? Publishing logs at least would counter >> > concerns of it being exclusive. Maybe discord as an alternative. >> >> I found Discord immediately wanted a phone number from me. I think >> IRC remains the lowest bar for participants to contribute. >> >> > Agreed, anything that requires a phone number makes it difficult to be > pseudonymous. > > I recommend Matrix, since it doesn't require any privacy invasive > information and has e2ee by default for 1-1 conversations. > > The Matrix room could optionally bridge to IRC if there is a significant > demand for that. > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Buck,
> First just wanted to thank you for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.
Thanks for the words. Effectively, organic WGs are likely good avenues for
the ecosystem to make steady and substantial progress during the coming
future. If there is any structure in the development of Bitcoin it's the
rich network of open, neutral and decentralized communication networks and
spaces that has been nurtured through the past decade and I hope that's a
tradition we'll keep maintaining.
> Defining a communication channel is still an open question: IRC, Slack,
Discord, Discourse, ...
I would vote against Slack. IRC is probably the best but maybe too high a
barrier to entry? Publishing logs at least would counter concerns of it
being exclusive. Maybe discord as an alternative.
I would say I really like IRC too. The strong text-based format, the lack
of avatar emoji, the low-bar to participate pseudonymously, the leveling
field for non-native speakers contrary to audio and the easiness to grab
the mics, all features valuable for such a process I think.
If IRC is still considered a technical high-bar for a standard
communication organ by many community stakeholders, discord is an
alternative.
> I understand the reason for this but I do have some concerns that
> it's not as off-topic as most of us would like. It shouldn't
> be a priority but how any of these primitives end up getting activated
> is part of the proposal itself in my opinion.
>
> I think it also became clear in some of the discussions over the past
> ~year that maybe there were more concerns than people realized about
> even the taproot activation process, whether the method used or if it
> was done too quickly. An example of where there might be
> some intersection with the WG as proposed is the question of how much
> research, security audits, etc. are "enough" before it should be
> considered for activation?
>From my understanding, how any of these primitives end up getting activated
is more a deployment methodology concern. What is more interesting is why
any of those primitives would be valuable as a Bitcoin upgrade. Beyond
proposing and refining primitives design and associated use-cases, there is
significant work to collect feedback on many dimensions and set of
criterias that matters to community stakeholders to achieve a consistent
and sound "why".
Where I believe there is an interaction between the "why" and "how" is that
during activation discussion some participant might bring new information
about shortcomings of a proposal, and as such if it's estimated relevant
could induce a step back to the "R&D" whiteboard phase, in a circular
feedback loop fashion. As those steps back are not free in terms of
community engineering resources, especially if deployment code starts to be
already disseminated across the ecosystem, I hope in the future we'll leave
reasonable time (in function of the complexity of the proposal) between
upgrade phases for grounded objections to raise.
>From my memory, about the taproot activation process it's correct that a
lot of people had discussions about producing more proof-of-work, e.g back
in 2019, LN devs were excited to PoC PTLC in the context of the structured
taproot review.
It didn't happen because it would have implied good refactoring works in
all implementations for that to happen and coordination with cryptographic
libraries dependencies.
In fact, it's likely the difficulty target for consensus upgrades to be
dynamic with the complexity of the ecosystem and stakes at risk increasing
modulo the amount of Bitcoin engineering resources dedicated.
> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.
I think it could be interesting for activation to have its own WG. I
wouldn't call myself super knowledgeable in upgrades activation. I believe
it could be worthy for such WG to do the archival work of documentation and
referencing well all
the previous upgrades discussions, the set of signals and data points that
has been deemed as valuable by the community, etc.
> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin softf
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote: > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote: > > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier > > in the year [0], the question of "how to successfully get soft fork > > ideas from concept to deployment" doesn't really have a good answer today. > I strongly disagree with this. Okay? "X is good" is obviously just a statement of opinion, so if you want to disagree, that's obviously allowed. I also kind of feel like that's the *least* interesting paragraph in the entire email to talk further about; if you think the current answer's already good, then the rest of the mail's just about (hopefully) making it better, which would be worthwhile anyway? > Going back many, many years we've had many > discussions about fork process, and the parts people (historically) agreed > with tend to be: > (1) come up with an idea > (2) socialize the idea in the technical community, see if anyone comes up > with any major issues or can suggest better ideas which solve the same > use-cases in cleaner ways > (3) propose the concrete idea with a more well-defined strawman, socialize > that, get some kind of rough consensus in the loosely-defined, subjective, > "technical community" (ie just ask people and adapt to feedback until you > have found some kind of average of the opinions of people you, the > fork-champion, think are reasonably well-informed!). > (4) okay, admittedly beyond this is a bit less defined, but we can deal with > it when we get there. > Turns out, the issue today is a lack of champions following steps 1-3, we > can debate what the correct answer is to step (4) once we actually have > people who want to be champions who are willing to (humbly) push an idea > forward towards rough agreement of the world of technical bitcoiners > (without which I highly doubt you'd ever see broader-community consensus). Personally, I think this is easily refuted by contradiction. 1) If we did have a good answer for how to progress a soft-fork, then the great consensus cleanup [0] would have made more progress over the past 3.5 years. Maybe not all of the ideas in it were unambiguously good [1], but personally, I'm convinced at least some of them are, and I don't think I'm alone in thinking that. Even if the excuse is that its original champion wasn't humble enough, there's something wrong with the process if there doesn't exist some other potential champion with the right balance of humility, confidence, interest and time who could have taken it over in that timeframe. 2) Many will argue that CTV has already done steps (1) through (3) above: certainly there's been an idea, it's been socialised through giving talks, having discussion forums, having research workshops [2], documenting use cases use cases; there's been a concrete implementation for years now, with a test network that supports the proposed feature, and new tools that demonstrate some of the proposed use cases, and while alternative approaches have been suggested [3], none of them have even really made it to step (2), let alone step (3). So that leaves a few possibilities to my mind: * CTV should be in step (4), and its lack of definition is a problem, and trying the "deal with it when we get there" approach is precisely what didn't work back in April. * The evaluation process is too inconclusive: it should either be saying "CTV is not good enough, fix these problems", or "CTV hasn't sufficiently demonstrated its value/cost, work on X next", but it isn't. * Parts (2) to (3) are too hard, and that's preventing alternatives from making progress, which in turn is preventing people from being able to decide whether CTV is the superior approach, or some alternative is. But each of those possibilities indicates a significant problem with our answer for developing soft forks. I guess my belief is that it's mostly (2) and (3) being too hard (which taproot overcame because many were excited about it, and CTV overcame because Jeremy's put a lot of effort into it; but consensus cleanup, APO, simplicity, TXHASH, etc have not similarly overcome at this point), which leads to the evaluation process being inconclusive when plausible alternatives exist. (In particular, I think having the process be massively difficult is going to naturally cause any "humble" champion to decide that they're not up to the task of following the process through to completion) Anyway, that's some additional reasons why I believe what I said above, in case that's interesting. But like I said at the start, if you still disagree, that's fine of course. Cheers, aj [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html https://github.com/bitcoin/bitcoin/pull/15481 https://github.com/bitcoin/bitcoin/pull/15482 [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016765.html https://lists
