Date: Sun, 18 Sep 2022 18:44:31 +0000
To: alicexbt <alicexbt@protonmail.com>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <O1zZVzh-olGF235lSIT4Y2C-Q91IACK1qhZbi4jOP5WMYOTD0-Zw9aqHs_1VKBn96h6kTiIRvQS10RkREaKAAQqMz-I58jW6nxr5HjmZlG4=@protonmail.com>
In-Reply-To: <T4meYqm1urcpCDED6kZjkjDt4hWkmRGKdRNMC2Y6SBHGqNm1t5id4v2GChIlCQwRiy20O9bR2PaT_jCCYEeG4sCkOp77fraTlunN7teZldQ=@protonmail.com>
References: <YyQioS3F942wu1HW@erisian.com.au>
 <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
 <YyVlra0AMIFO9Xid@erisian.com.au>
 <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com>
 <8cU3OEEtb7Q8CRBHqeWV6qe4JSRnOeMjh2PRdYj4rsnxF4DxzQd1Bo-1DAPMWGNxjXsZQuSuPrDK5TF4ez6tONZ5ACoLJ_FqV6Y1q7ybSwI=@protonmail.com>
 <T4meYqm1urcpCDED6kZjkjDt4hWkmRGKdRNMC2Y6SBHGqNm1t5id4v2GChIlCQwRiy20O9bR2PaT_jCCYEeG4sCkOp77fraTlunN7teZldQ=@protonmail.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
	signet
Precedence: list

Hi alicexbt

> Good to see some positivity, finally.

I had enthusiasm for this concept of enabling proposed soft fork functional=
ity on signet 2 years ago [0]. Nothing has changed, still enthusiastic :) N=
ot enthusiastic about the months wasted on unnecessary contentious soft for=
k 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=20
  a separate blockchain with some similarities.

Perhaps you should take your own advice with regards to positivity (or at l=
east have more of an open mind) with regards Liquid and sidechains. Signet =
Bitcoin are totally free [1] and experimentation doesn't ever result in los=
s of real monetary value so you would expect more experimentation on signet=
 versus Liquid long term. However, building protocols and prototypes with r=
eal 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 lo=
nger to come to fruition than others but the original vision [2] of sidecha=
ins still makes perfect sense to me. Competing sets of consensus rules aren=
't possible on a single mainnet blockchain. Hence you either go the sidecha=
in(-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 v=
olatile 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@protonmail.com=
> wrote:


> Hi Michael,
>=20
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't kno=
w that CTV didn't have community consensus at the time" 0 and "it was the l=
ack of process that was the problem" the better.
>=20
>=20
> 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 B=
IP 119. Nadav has already mentioned this in the comments. If you care about=
 community consensus, maybe feedback about the links in that gist should al=
so be respected. There was chaos, misinformation and lot of drama on twitte=
r. Some people that opposed CTV on twitter still have no clue what CTV actu=
ally does and a few were super enthusiastic because of the author for BIP 1=
19.
>=20
> > I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpain=
t, 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 tha=
t requires more of the signet code to be moved out of the Core repo so be i=
t.
>=20
>=20
> Good to see some positivity, finally. Because tx introspection aka covena=
nts would help everyone involved in bitcoin. This idea of experimenting wit=
h soft forks on signet together with research and meetings suggested by Ant=
oine should help in better evaluation phase with less drama, politics etc. =
and more technical discussions to reach a goal.
>=20
> > I'm surprised more isn't being done on Liquid already with what possibl=
e future functionality is (and could be) enabled 2 there but maybe there is=
 more happening than I'm aware of.
>=20
>=20
> 1)Nobody uses Liquid. Signet has more activity than Liquid.
> 2)Testing something on Liquid will be completely different as its a separ=
ate blockchain with some similarities.
>=20
> I have summarized a few other positives of testing soft forks on signet b=
ased on AJ's email:
>=20
> 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 ma=
ster branch
>=20
> /dev/fd0
>=20
> Sent with Proton Mail secure email.
>=20
> ------- Original Message -------
> On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin=
-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=20
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't kno=
w that CTV didn't have community consensus at the time" 0 and "it was the l=
ack 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, pro=
ductive path (I tried). I think it is a shame because I think (maybe I'm wr=
ong) at least in the technical community there is an understanding that lon=
g term Bitcoin is far from finished in exhausting its potential and we do n=
eed people who will work on changes that we'll need in the long term.
> >=20
> > 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 t=
he moment) but I do like the idea of signet having soft fork proposals enab=
led on it 1 whether that be CTV, APO etc and if that requires more of the s=
ignet code to be moved out of the Core repo so be it. I'm surprised more is=
n'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 t=
he 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 upg=
rade (Taproot certainly was a slog) but I think the vast majority of us thi=
nk Taproot was worth that slog and Bitcoin would be poorer today without it=
.
> >=20
> > The Great Consensus Cleanup is an interesting example in that I get Mat=
t 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 sa=
y adding new opcodes, sighash flags versus say waiting on Simplicity and po=
ssibly adding new functionality within that potential upgrade. For people l=
ike 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 rath=
er than second guessing what people are thinking. There is a danger that yo=
u flirt with perceived public roadmaps when possible authority figures stic=
k their necks out and effectively say "I'm not in charge but in an imaginar=
y 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 u=
pgrades 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 wa=
iting 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 ver=
sus Simplicity discussion perhaps rests on whether people think certain cov=
enants should only really be enabled once we have the security guarantees o=
f Simplicity 3 (if at all).
> >=20
> > Antoine's covenant R&D effort 4 seems really promising and I hope the s=
henanigans from earlier in the year don't put people off from engaging with=
 that. Hopefully we can see more exploration, development and research in c=
ovenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways=
 to Control the Future" 5) and we can foster a community which has very hig=
h standards, is open to new ideas and new research but can avoid these mont=
hs 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 "I=
f I express a view now it will be used to attack me personally later" or wo=
rse "If I express a view now it will be used to justify an upcoming chain s=
plit".
> >=20
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >=20
> > ------- Original Message -------
> > On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-de=
v bitcoin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > On 9/17/22 2:14 AM, Anthony Towns wrote:
> > >=20
> > > > On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-=
dev wrote:
> > > >=20
> > > > > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > > > >=20
> > > > > > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activat=
ion earlier
> > > > > > in the year 0, the question of "how to successfully get soft fo=
rk
> > > > > > ideas from concept to deployment" doesn't really have a good an=
swer today.
> > > > > > I strongly disagree with this.
> > > >=20
> > > > Okay? "X is good" is obviously just a statement of opinion, so if y=
ou
> > > > want to disagree, that's obviously allowed.
> > > >=20
> > > > 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) ma=
king
> > > > it better, which would be worthwhile anyway?
> > >=20
> > > 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 te=
st 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 sepa=
rate.
> > >=20
> > > > > Going back many, many years we've had many
> > > > > discussions about fork process, and the parts people (historicall=
y) 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, su=
bjective,
> > > > > "technical community" (ie just ask people and adapt to feedback u=
ntil you
> > > > > have found some kind of average of the opinions of people you, th=
e
> > > > > fork-champion, think are reasonably well-informed!).
> > > > > (4) okay, admittedly beyond this is a bit less defined, but we ca=
n 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 actuall=
y have
> > > > > people who want to be champions who are willing to (humbly) push =
an idea
> > > > > forward towards rough agreement of the world of technical bitcoin=
ers
> > > > > (without which I highly doubt you'd ever see broader-community co=
nsensus).
> > > >=20
> > > > Personally, I think this is easily refuted by contradiction.
> > > >=20
> > > > 1) If we did have a good answer for how to progress a soft-fork, th=
en
> > > > the great consensus cleanup 0 would have made more progress over th=
e
> > > > past 3.5 years
> > >=20
> > > No? Who is the champion for it? I haven't been. No one else is oblige=
d 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, bu=
t 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.
> > >=20
> > > > 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 wit=
h
> > > > the process if there doesn't exist some other potential champion wi=
th
> > > > the right balance of humility, confidence, interest and time who co=
uld
> > > > have taken it over in that timeframe.
> > >=20
> > > No? Its not up to the community to find a champion for someone who wa=
nts a fork to happen. Either
> > > someone thinks its a good enough idea that they step up, or no one do=
es. If no one does, then so be
> > > it. If the original proper (me, in this case) thought it was that imp=
ortant then its their
> > > responsibility to be the champion, no one else's.
> > >=20
> > > > 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 n=
ow,
> > > > with a test network that supports the proposed feature, and new too=
ls
> > > > that demonstrate some of the proposed use cases, and while alternat=
ive
> > > > approaches have been suggested 3, none of them have even really mad=
e
> > > > it to step (2), let alone step (3).
> > >=20
> > > 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).
> > >=20
> > > > So that leaves a few possibilities
> > > > to my mind:
> > >=20
> > > > * CTV should be in step (4), and its lack of definition is a proble=
m,
> > > > and trying the "deal with it when we get there" approach is precise=
ly
> > > > what didn't work back in April.
> > > >=20
> > > > * 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.
> > > >=20
> > > > * 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.
> > >=20
> > > I think this is most of it, but its not that they're too hard, its th=
at 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 Ru=
sty has a lightning
> > > implementation to maintain, which tends to be a more-than-full-time j=
ob already.
> > >=20
> > > To my knowledge, no one but Jeremy has made any serious attempt at be=
ing the champion for a
> > > soft-fork since Taproot, and before that Segwit (if someone reading t=
his who contributes to Core
> > > already wants to, and isn't sure how to, there's lots of people who w=
ould happily mentor you! I'm
> > > sure you can figure out who to reach out to!).
> > >=20
> > > Matt
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >=20
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev