📅 Original date posted:2022-09-18
📝 Original message:Hi alicexbt
> Good to see some positivity, finally.
I had enthusiasm for this concept of enabling proposed soft fork functionality on signet 2 years ago [0]. Nothing has changed, still enthusiastic :) Not enthusiastic about the months wasted on unnecessary contentious soft fork drama since but can't change the past.
> 1)Nobody uses Liquid. Signet has more activity than Liquid.
2)Testing something on Liquid will be completely different as its
a separate blockchain with some similarities.
Perhaps you should take your own advice with regards to positivity (or at least have more of an open mind) with regards Liquid and sidechains. Signet Bitcoin are totally free [1] and experimentation doesn't ever result in loss of real monetary value so you would expect more experimentation on signet versus Liquid long term. However, building protocols and prototypes with real monetary value is a step up from doing so with worthless signet coins. So I don't really see them as direct competitors. Some things take a lot longer to come to fruition than others but the original vision [2] of sidechains still makes perfect sense to me. Competing sets of consensus rules aren't possible on a single mainnet blockchain. Hence you either go the sidechain(-like) route or you go the altcoin route if you want to take the step up from signet/testnet and start using real monetary value. I much prefer the sidechain model to the altcoin route myself. Especially when in say vaults you do want the equivalent of Bitcoin to be locked up rather than a more volatile altcoin.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining
[1]: https://signetfaucet.com/
[2]: https://blockstream.com/sidechains.pdf
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, September 18th, 2022 at 13:27, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Michael,
>
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time" 0 and "it was the lack of process that was the problem" the better.
>
>
> The linked gist cannot be taken seriously and I am not sure why you keep sharing it as some document to prove there was no technical consensus for BIP 119. Nadav has already mentioned this in the comments. If you care about community consensus, maybe feedback about the links in that gist should also be respected. There was chaos, misinformation and lot of drama on twitter. Some people that opposed CTV on twitter still have no clue what CTV actually does and a few were super enthusiastic because of the author for BIP 119.
>
> > I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it 1 whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it.
>
>
> Good to see some positivity, finally. Because tx introspection aka covenants would help everyone involved in bitcoin. This idea of experimenting with soft forks on signet together with research and meetings suggested by Antoine should help in better evaluation phase with less drama, politics etc. and more technical discussions to reach a goal.
>
> > I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled 2 there but maybe there is more happening than I'm aware of.
>
>
> 1)Nobody uses Liquid. Signet has more activity than Liquid.
> 2)Testing something on Liquid will be completely different as its a separate blockchain with some similarities.
>
> I have summarized a few other positives of testing soft forks on signet based on AJ's email:
>
> a)Better evaluation
> b)PR implementing soft fork could be reviewed and merged outside core
> c)Testing on signet with pre-existing signet infrastructure
> d)Can deploy multiple consensus changes so easier to compare alternative approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)
> e)Pre-baked ability to abandon the soft fork
> f)No need to regularly rebase consensus changes against bitcoin core's master branch
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time" 0 and "it was the lack of process that was the problem" the better. If people don't care about lack of community consensus there is no process in a permissionless, open source community that can stop them or direct them down a more patient, productive path (I tried). I think it is a shame because I think (maybe I'm wrong) at least in the technical community there is an understanding that long term Bitcoin is far from finished in exhausting its potential and we do need people who will work on changes that we'll need in the long term.
> >
> > There are a few interesting things in here though. I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it 1 whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it. I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled 2 there but maybe there is more happening than I'm aware of. Protocols or use cases built out and demonstrated on signet (and/or Liquid/sidechains) seem an obvious stepping stone to me for convincing the community that it is potentially worth taking the chain split risk for a particular upgrade. It is a long slog to get community consensus on an upgrade (Taproot certainly was a slog) but I think the vast majority of us think Taproot was worth that slog and Bitcoin would be poorer today without it.
> >
> > The Great Consensus Cleanup is an interesting example in that I get Matt doesn't have time to champion it or focus on it with his LDK commitments but I have no idea where it would rank on his long term priority list if he wasn't working on LDK. Similarly I have no idea what people who understand this evolving system much better than I do are thinking with regards to say adding new opcodes, sighash flags versus say waiting on Simplicity and possibly adding new functionality within that potential upgrade. For people like me who are extremely unlikely to propose their own consensus change(s) getting some signal on what to spend time digging into would be useful rather than second guessing what people are thinking. There is a danger that you flirt with perceived public roadmaps when possible authority figures stick their necks out and effectively say "I'm not in charge but in an imaginary world where I was this is my current thinking of the ordering in which we could improve this system
> > long term. But this could change depending on x, y and z and possible upgrades are only ready when they're ready and they have community consensus." There is no way people don't play these exercises in their minds. I do, I just have very few answers :) I personally think APO is in prime position to improve Lightning channel state management with eltoo and if it enables some covenant schemes too that seems like an added bonus. On APO versus waiting for APO like functionality in Simplicity I have no idea. Work on APO/eltoo and Simplicity both seem to be progressing in parallel so the APO versus Simplicity discussion perhaps rests on whether people think certain covenants should only really be enabled once we have the security guarantees of Simplicity 3 (if at all).
> >
> > Antoine's covenant R&D effort 4 seems really promising and I hope the shenanigans from earlier in the year don't put people off from engaging with that. Hopefully we can see more exploration, development and research in covenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways to Control the Future" 5) and we can foster a community which has very high standards, is open to new ideas and new research but can avoid these months long resisting chain split fights. I think the discussion would be much more interesting and much more productive if people didn't have to think "If I express a view now it will be used to attack me personally later" or worse "If I express a view now it will be used to justify an upcoming chain split".
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >
> > ------- Original Message -------
> > On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > On 9/17/22 2:14 AM, Anthony Towns wrote:
> > >
> > > > 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?
> > >
> > > No, I think its at least a good chunk of the "statement of problem". Yes, more testing is good, and
> > > this project is a way to get that. Cool. But implying that lack of test frameworks is in any
> > > material way part of the lack of movement on forks in Bitcoin I think is very wrong, so its worth
> > > pointing out, whether the particular project is useful or not is separate.
> > >
> > > > > 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
> > >
> > > No? Who is the champion for it? I haven't been. No one else is obliged to take up the reins and run
> > > with it, that's not how open-source works. And no one has emerged who has strong interest in doing
> > > so, and that's totally fine. It means it hasn't made any progress, but that's an indication that no
> > > one feels strongly enough about it that its risen to the top of their personal priority list so
> > > clearly doesn't need to make progress.
> > >
> > > > 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.
> > >
> > > No? Its not up to the community to find a champion for someone who wants a fork to happen. Either
> > > someone thinks its a good enough idea that they step up, or no one does. If no one does, then so be
> > > it. If the original proper (me, in this case) thought it was that important then its their
> > > responsibility to be the champion, no one else's.
> > >
> > > > 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).
> > >
> > > I don't really see how you can make this argument seriously. Honestly, if a soft-fork BIP only has
> > > one author on the list, then I'm not sure one can argue that step (3) has really been completed, and
> > > maybe not even step (2).
> > >
> > > > 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.
> > >
> > > I think this is most of it, but its not that they're too hard, its that people are too busy. There
> > > seemed to be more positive feedback, for example, to Rusty's proposal, but being the champion for a
> > > soft-fork is a full-time job for months on end, and last I checked Rusty has a lightning
> > > implementation to maintain, which tends to be a more-than-full-time job already.
> > >
> > > To my knowledge, no one but Jeremy has made any serious attempt at being the champion for a
> > > soft-fork since Taproot, and before that Segwit (if someone reading this who contributes to Core
> > > already wants to, and isn't sure how to, there's lots of people who would happily mentor you! I'm
> > > sure you can figure out who to reach out to!).
> > >
> > > Matt
> > > _______________________________________________
> > > 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
Michael Folkson [ARCHIVE] /
npub103…2kpam
2023-06-07 23:13:33
in reply to nevent1q…pc9t
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpamPublished at
2023-06-07 23:13:33Event JSON
{
"id": "819e3980130d1ada600e87fd22ea738563e0ff2353bd9f198f8eb4f4cbfc7b0d",
"pubkey": "7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a",
"created_at": 1686179613,
"kind": 1,
"tags": [
[
"e",
"2ac589e49ebcf69e5e0c0f74981f090043414ccce35cc1264b0db21e4f35bbfa",
"",
"root"
],
[
"e",
"4c0798dac6804bef63cfc91a86cb3ee9f2dd525bdc74a2816b052b62ed103070",
"",
"reply"
],
[
"p",
"745e2723e72d7ded3f0dd293d710b706cd302ab8476983c292d4bdb7f9c5d366"
]
],
"content": "📅 Original date posted:2022-09-18\n📝 Original message:Hi alicexbt\n\n\u003e Good to see some positivity, finally.\n\nI had enthusiasm for this concept of enabling proposed soft fork functionality on signet 2 years ago [0]. Nothing has changed, still enthusiastic :) Not enthusiastic about the months wasted on unnecessary contentious soft fork drama since but can't change the past.\n\n\u003e 1)Nobody uses Liquid. Signet has more activity than Liquid.\n 2)Testing something on Liquid will be completely different as its \n a separate blockchain with some similarities.\n\nPerhaps you should take your own advice with regards to positivity (or at least have more of an open mind) with regards Liquid and sidechains. Signet Bitcoin are totally free [1] and experimentation doesn't ever result in loss of real monetary value so you would expect more experimentation on signet versus Liquid long term. However, building protocols and prototypes with real monetary value is a step up from doing so with worthless signet coins. So I don't really see them as direct competitors. Some things take a lot longer to come to fruition than others but the original vision [2] of sidechains still makes perfect sense to me. Competing sets of consensus rules aren't possible on a single mainnet blockchain. Hence you either go the sidechain(-like) route or you go the altcoin route if you want to take the step up from signet/testnet and start using real monetary value. I much prefer the sidechain model to the altcoin route myself. Especially when in say vaults you do want the equivalent of Bitcoin to be locked up rather than a more volatile altcoin.\n\nThanks\nMichael\n\n[0]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining\n[1]: https://signetfaucet.com/\n[2]: https://blockstream.com/sidechains.pdf\n\n--\nMichael Folkson\nEmail: michaelfolkson at protonmail.com\nKeybase: michaelfolkson\nPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\n\n------- Original Message -------\nOn Sunday, September 18th, 2022 at 13:27, alicexbt \u003calicexbt at protonmail.com\u003e wrote:\n\n\n\u003e Hi Michael,\n\u003e \n\u003e \u003e I agree with Matt. The less said about the \"Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time\" 0 and \"it was the lack of process that was the problem\" the better.\n\u003e \n\u003e \n\u003e The linked gist cannot be taken seriously and I am not sure why you keep sharing it as some document to prove there was no technical consensus for BIP 119. Nadav has already mentioned this in the comments. If you care about community consensus, maybe feedback about the links in that gist should also be respected. There was chaos, misinformation and lot of drama on twitter. Some people that opposed CTV on twitter still have no clue what CTV actually does and a few were super enthusiastic because of the author for BIP 119.\n\u003e \n\u003e \u003e I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it 1 whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it.\n\u003e \n\u003e \n\u003e Good to see some positivity, finally. Because tx introspection aka covenants would help everyone involved in bitcoin. This idea of experimenting with soft forks on signet together with research and meetings suggested by Antoine should help in better evaluation phase with less drama, politics etc. and more technical discussions to reach a goal.\n\u003e \n\u003e \u003e I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled 2 there but maybe there is more happening than I'm aware of.\n\u003e \n\u003e \n\u003e 1)Nobody uses Liquid. Signet has more activity than Liquid.\n\u003e 2)Testing something on Liquid will be completely different as its a separate blockchain with some similarities.\n\u003e \n\u003e I have summarized a few other positives of testing soft forks on signet based on AJ's email:\n\u003e \n\u003e a)Better evaluation\n\u003e b)PR implementing soft fork could be reviewed and merged outside core\n\u003e c)Testing on signet with pre-existing signet infrastructure\n\u003e d)Can deploy multiple consensus changes so easier to compare alternative approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)\n\u003e e)Pre-baked ability to abandon the soft fork\n\u003e f)No need to regularly rebase consensus changes against bitcoin core's master branch\n\u003e \n\u003e /dev/fd0\n\u003e \n\u003e Sent with Proton Mail secure email.\n\u003e \n\u003e ------- Original Message -------\n\u003e On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e \n\u003e \n\u003e \n\u003e \u003e I agree with Matt. The less said about the \"Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time\" 0 and \"it was the lack of process that was the problem\" the better. If people don't care about lack of community consensus there is no process in a permissionless, open source community that can stop them or direct them down a more patient, productive path (I tried). I think it is a shame because I think (maybe I'm wrong) at least in the technical community there is an understanding that long term Bitcoin is far from finished in exhausting its potential and we do need people who will work on changes that we'll need in the long term.\n\u003e \u003e \n\u003e \u003e There are a few interesting things in here though. I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it 1 whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it. I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled 2 there but maybe there is more happening than I'm aware of. Protocols or use cases built out and demonstrated on signet (and/or Liquid/sidechains) seem an obvious stepping stone to me for convincing the community that it is potentially worth taking the chain split risk for a particular upgrade. It is a long slog to get community consensus on an upgrade (Taproot certainly was a slog) but I think the vast majority of us think Taproot was worth that slog and Bitcoin would be poorer today without it.\n\u003e \u003e \n\u003e \u003e The Great Consensus Cleanup is an interesting example in that I get Matt doesn't have time to champion it or focus on it with his LDK commitments but I have no idea where it would rank on his long term priority list if he wasn't working on LDK. Similarly I have no idea what people who understand this evolving system much better than I do are thinking with regards to say adding new opcodes, sighash flags versus say waiting on Simplicity and possibly adding new functionality within that potential upgrade. For people like me who are extremely unlikely to propose their own consensus change(s) getting some signal on what to spend time digging into would be useful rather than second guessing what people are thinking. There is a danger that you flirt with perceived public roadmaps when possible authority figures stick their necks out and effectively say \"I'm not in charge but in an imaginary world where I was this is my current thinking of the ordering in which we could improve this system\n\u003e \u003e long term. But this could change depending on x, y and z and possible upgrades are only ready when they're ready and they have community consensus.\" There is no way people don't play these exercises in their minds. I do, I just have very few answers :) I personally think APO is in prime position to improve Lightning channel state management with eltoo and if it enables some covenant schemes too that seems like an added bonus. On APO versus waiting for APO like functionality in Simplicity I have no idea. Work on APO/eltoo and Simplicity both seem to be progressing in parallel so the APO versus Simplicity discussion perhaps rests on whether people think certain covenants should only really be enabled once we have the security guarantees of Simplicity 3 (if at all).\n\u003e \u003e \n\u003e \u003e Antoine's covenant R\u0026D effort 4 seems really promising and I hope the shenanigans from earlier in the year don't put people off from engaging with that. Hopefully we can see more exploration, development and research in covenants (e.g. this excellent research paper \"Bitcoin Covenants: Three Ways to Control the Future\" 5) and we can foster a community which has very high standards, is open to new ideas and new research but can avoid these months long resisting chain split fights. I think the discussion would be much more interesting and much more productive if people didn't have to think \"If I express a view now it will be used to attack me personally later\" or worse \"If I express a view now it will be used to justify an upcoming chain split\".\n\u003e \u003e \n\u003e \u003e --\n\u003e \u003e Michael Folkson\n\u003e \u003e Email: michaelfolkson at protonmail.com\n\u003e \u003e Keybase: michaelfolkson\n\u003e \u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e \u003e \n\u003e \u003e ------- Original Message -------\n\u003e \u003e On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e \u003e \n\u003e \u003e \u003e On 9/17/22 2:14 AM, Anthony Towns wrote:\n\u003e \u003e \u003e \n\u003e \u003e \u003e \u003e On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote:\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e \u003e On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:\n\u003e \u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e \u003e \u003e As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier\n\u003e \u003e \u003e \u003e \u003e \u003e in the year 0, the question of \"how to successfully get soft fork\n\u003e \u003e \u003e \u003e \u003e \u003e ideas from concept to deployment\" doesn't really have a good answer today.\n\u003e \u003e \u003e \u003e \u003e \u003e I strongly disagree with this.\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e Okay? \"X is good\" is obviously just a statement of opinion, so if you\n\u003e \u003e \u003e \u003e want to disagree, that's obviously allowed.\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e I also kind of feel like that's the least interesting paragraph in the\n\u003e \u003e \u003e \u003e entire email to talk further about; if you think the current answer's\n\u003e \u003e \u003e \u003e already good, then the rest of the mail's just about (hopefully) making\n\u003e \u003e \u003e \u003e it better, which would be worthwhile anyway?\n\u003e \u003e \u003e \n\u003e \u003e \u003e No, I think its at least a good chunk of the \"statement of problem\". Yes, more testing is good, and\n\u003e \u003e \u003e this project is a way to get that. Cool. But implying that lack of test frameworks is in any\n\u003e \u003e \u003e material way part of the lack of movement on forks in Bitcoin I think is very wrong, so its worth\n\u003e \u003e \u003e pointing out, whether the particular project is useful or not is separate.\n\u003e \u003e \u003e \n\u003e \u003e \u003e \u003e \u003e Going back many, many years we've had many\n\u003e \u003e \u003e \u003e \u003e discussions about fork process, and the parts people (historically) agreed\n\u003e \u003e \u003e \u003e \u003e with tend to be:\n\u003e \u003e \u003e \u003e \u003e (1) come up with an idea\n\u003e \u003e \u003e \u003e \u003e (2) socialize the idea in the technical community, see if anyone comes up\n\u003e \u003e \u003e \u003e \u003e with any major issues or can suggest better ideas which solve the same\n\u003e \u003e \u003e \u003e \u003e use-cases in cleaner ways\n\u003e \u003e \u003e \u003e \u003e (3) propose the concrete idea with a more well-defined strawman, socialize\n\u003e \u003e \u003e \u003e \u003e that, get some kind of rough consensus in the loosely-defined, subjective,\n\u003e \u003e \u003e \u003e \u003e \"technical community\" (ie just ask people and adapt to feedback until you\n\u003e \u003e \u003e \u003e \u003e have found some kind of average of the opinions of people you, the\n\u003e \u003e \u003e \u003e \u003e fork-champion, think are reasonably well-informed!).\n\u003e \u003e \u003e \u003e \u003e (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there.\n\u003e \u003e \u003e \u003e \u003e Turns out, the issue today is a lack of champions following steps 1-3, we\n\u003e \u003e \u003e \u003e \u003e can debate what the correct answer is to step (4) once we actually have\n\u003e \u003e \u003e \u003e \u003e people who want to be champions who are willing to (humbly) push an idea\n\u003e \u003e \u003e \u003e \u003e forward towards rough agreement of the world of technical bitcoiners\n\u003e \u003e \u003e \u003e \u003e (without which I highly doubt you'd ever see broader-community consensus).\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e Personally, I think this is easily refuted by contradiction.\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e 1) If we did have a good answer for how to progress a soft-fork, then\n\u003e \u003e \u003e \u003e the great consensus cleanup 0 would have made more progress over the\n\u003e \u003e \u003e \u003e past 3.5 years\n\u003e \u003e \u003e \n\u003e \u003e \u003e No? Who is the champion for it? I haven't been. No one else is obliged to take up the reins and run\n\u003e \u003e \u003e with it, that's not how open-source works. And no one has emerged who has strong interest in doing\n\u003e \u003e \u003e so, and that's totally fine. It means it hasn't made any progress, but that's an indication that no\n\u003e \u003e \u003e one feels strongly enough about it that its risen to the top of their personal priority list so\n\u003e \u003e \u003e clearly doesn't need to make progress.\n\u003e \u003e \u003e \n\u003e \u003e \u003e \u003e Maybe not all of the ideas in it were unambiguously good\n\u003e \u003e \u003e \u003e 1, but personally, I'm convinced at least some of them are, and I\n\u003e \u003e \u003e \u003e don't think I'm alone in thinking that. Even if the excuse is that its\n\u003e \u003e \u003e \u003e original champion wasn't humble enough, there's something wrong with\n\u003e \u003e \u003e \u003e the process if there doesn't exist some other potential champion with\n\u003e \u003e \u003e \u003e the right balance of humility, confidence, interest and time who could\n\u003e \u003e \u003e \u003e have taken it over in that timeframe.\n\u003e \u003e \u003e \n\u003e \u003e \u003e No? Its not up to the community to find a champion for someone who wants a fork to happen. Either\n\u003e \u003e \u003e someone thinks its a good enough idea that they step up, or no one does. If no one does, then so be\n\u003e \u003e \u003e it. If the original proper (me, in this case) thought it was that important then its their\n\u003e \u003e \u003e responsibility to be the champion, no one else's.\n\u003e \u003e \u003e \n\u003e \u003e \u003e \u003e 2) Many will argue that CTV has already done steps (1) through (3) above:\n\u003e \u003e \u003e \u003e certainly there's been an idea, it's been socialised through giving talks,\n\u003e \u003e \u003e \u003e having discussion forums, having research workshops 2, documenting use\n\u003e \u003e \u003e \u003e cases use cases; there's been a concrete implementation for years now,\n\u003e \u003e \u003e \u003e with a test network that supports the proposed feature, and new tools\n\u003e \u003e \u003e \u003e that demonstrate some of the proposed use cases, and while alternative\n\u003e \u003e \u003e \u003e approaches have been suggested 3, none of them have even really made\n\u003e \u003e \u003e \u003e it to step (2), let alone step (3).\n\u003e \u003e \u003e \n\u003e \u003e \u003e I don't really see how you can make this argument seriously. Honestly, if a soft-fork BIP only has\n\u003e \u003e \u003e one author on the list, then I'm not sure one can argue that step (3) has really been completed, and\n\u003e \u003e \u003e maybe not even step (2).\n\u003e \u003e \u003e \n\u003e \u003e \u003e \u003e So that leaves a few possibilities\n\u003e \u003e \u003e \u003e to my mind:\n\u003e \u003e \u003e \n\u003e \u003e \u003e \u003e * CTV should be in step (4), and its lack of definition is a problem,\n\u003e \u003e \u003e \u003e and trying the \"deal with it when we get there\" approach is precisely\n\u003e \u003e \u003e \u003e what didn't work back in April.\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e * The evaluation process is too inconclusive: it should either be\n\u003e \u003e \u003e \u003e saying \"CTV is not good enough, fix these problems\", or \"CTV hasn't\n\u003e \u003e \u003e \u003e sufficiently demonstrated its value/cost, work on X next\", but it\n\u003e \u003e \u003e \u003e isn't.\n\u003e \u003e \u003e \u003e \n\u003e \u003e \u003e \u003e * Parts (2) to (3) are too hard, and that's preventing alternatives\n\u003e \u003e \u003e \u003e from making progress, which in turn is preventing people from\n\u003e \u003e \u003e \u003e being able to decide whether CTV is the superior approach, or some\n\u003e \u003e \u003e \u003e alternative is.\n\u003e \u003e \u003e \n\u003e \u003e \u003e I think this is most of it, but its not that they're too hard, its that people are too busy. There\n\u003e \u003e \u003e seemed to be more positive feedback, for example, to Rusty's proposal, but being the champion for a\n\u003e \u003e \u003e soft-fork is a full-time job for months on end, and last I checked Rusty has a lightning\n\u003e \u003e \u003e implementation to maintain, which tends to be a more-than-full-time job already.\n\u003e \u003e \u003e \n\u003e \u003e \u003e To my knowledge, no one but Jeremy has made any serious attempt at being the champion for a\n\u003e \u003e \u003e soft-fork since Taproot, and before that Segwit (if someone reading this who contributes to Core\n\u003e \u003e \u003e already wants to, and isn't sure how to, there's lots of people who would happily mentor you! I'm\n\u003e \u003e \u003e sure you can figure out who to reach out to!).\n\u003e \u003e \u003e \n\u003e \u003e \u003e Matt\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e \n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "7466168925bdce03293ddcb953c485e6ac5d11e1470f57a099cc33dcc841d1ecdedfdb8ca3986fb6ea5bb5f86b94f3678e3776b426fe578731db6ff81da1e8a7"
}