MIME-Version: 1.0
References: <mailman.51682.1651459425.8511.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92z3HaTu47O_3metXAhFEVN3QnLdug1BVt66a9GZGx6t=Q@mail.gmail.com>
 <CAGpPWDbRp8ZoT+JWV6mKBPQT=86rxcSD9vELFsTMyU96S3D4kw@mail.gmail.com>
In-Reply-To: <CAGpPWDbRp8ZoT+JWV6mKBPQT=86rxcSD9vELFsTMyU96S3D4kw@mail.gmail.com>
From: John Carvalho <john@synonym.to>
Date: Tue, 3 May 2022 06:24:23 +0100
Message-ID: <CAHTn92xn9nr3n4wvFWfc6g=zVNceaRprZsHMSML0DC5JqnKFJw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>,
 bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000061837305de14b97a"
Subject: Re: [bitcoin-dev] Working Towards Consensus
Precedence: list

--00000000000061837305de14b97a
Content-Type: text/plain; charset="UTF-8"

>
> > The path to consensus is to propose things that everyone needs.
> If there's an insight here, it isn't clear what it is to me. As stated,
> this is something I can only 100% disagree with. Its possible that
> literally nothing about bitcoin is something that "everyone needs". Its
> pretty clear that not "everyone needs" taproot. Its even questionable
> whether "everyone needs" bitcoin. Are you really saying that no change
> should be added to bitcoin unless it is something literally all bitcoin
> users are currently asking for, or maybe just will want to use sometime
> soon? The majority of bitcoin users don't even custody their own funds, so
> practically all features are something those users aren't using. If you
> want to convince people of whatever argument you're making, you're going to
> have to get a little more specific and rather less hyperbolic.


Billy, the insight is quite simple: it is easier to get everyone to agree
when everyone has something to gain. Taproot getting activated is not proof
of a sound consensus process, it is proof that most users are either
apathetic or trusting in the developers that initiated it being activated.
This is a dangerous dynamic to lean on. I'm not trying to convince anyone
of anything, I'm trying to provide insight into Bitcoin's dynamics and
qualities so as to save everyone some time. Take it or leave it, but I'm
confident about how things will play out within this model.

> Designers (engineers) solve problems with designs, but when they
> speculate and lead the process, they create problems instead.
> How do you expect any improvement to ever happen to bitcoin if designers
> can't design things unless end-users have asked for it. Every good product
> designer knows that users do not know how to design products. Users have
> problems, designers create solutions. Companies that have implemented
> features that users directly ask for end up with awful bloated confusing
> products. Surely this isn't what you're suggesting we do in bitcoin, right?


I do not "expect" improvement by any other means than is typical in life:
competition and adaptation in response to an adverse and changing
environment. Designers can design whatever they please, they just need to
understand the dynamics at play and the risks they are taking in that they
are likely to waste their own time, and others, if they miss the mark on
providing for the greater good. Anyone can be a designer, like anyone can
be a Bitcoin user. Engineers are only special if their specialization
allows them to solve a problem faster than someone else might. Why are you
talking about companies and bloat while I am speaking about being
conservative?

> Seek simplicity and efficiency, not complication.
> This is an extraordinarily ironic thing to say to Jeremy Rubin, who
> designed CTV with exactly that in mind. It is an incredibly simple opcode
> that doesn't allow recursive covenants or various other things that people
> have been worried about in the past about covenants. I'm 99% confident that
> there is no simpler, more efficient, and less complicated covenant opcode
> than CTV that can even possibly be designed. The only one on par is
> TXHASH+CSFS and that has more complex implications than CTV.


No, you're ironic in thinking that adding complication to Bitcoin's base
layer is somehow a means of valuing simplicity. I don't know who you are,
and since you and Jeremy have no reputation with me, I have no reason to
care about your "99%" confidence in something that I cannot distinguish
from an attack and have no personal need for. This is how trust and
incentives work!

There are MANY people out there that would like more complex, more powerful
> covenants. "The market" is  in fact demanding it. And yet because we must
> move carefully in Bitcoin, CTV is a compromise that focuses on simplicity
> and incremental change rather than radical change. Do you really disagree
> that CTV was intended to be as simple as possible and achieves that goal?


Speaking for myself, and likely the great majority of the market: "Don't
know, don't care." Your self-ascribed ability to assess the market is
objectively overconfident because we all know there is no way to
confidently measure this market by polling or analysis, and that most of
this market does not even know CTV exists, and the portion that does know
of CTV is barely competent enough to audit or bless it. That is just
reality.

> There is simply no urgency or problem that any of the proposed soft fork
> features are trying to address.
> That is pretty subjective, and very debatable. But ignoring the
> debatableness of it, why is urgency even necessary for an improvement to
> bitcoin? Should we wait until a problem is urgent to fix it? Or should we
> get ahead of it so we don't risk making hasty mistakes?


What is necessary is demand. All forms of scale and complexity come at a
cost to Bitcoin users. That cost is only offset AFTER the feature has
reached saturation of usage. Not even Segwit has achieved saturation yet.
Taproot is dying on the vine so far. This is not a judgment of either
design so much as an observation that we might be too aggressive in our
pace of feature speculation. If we keep piling on features, we have more
chances of making a mistake, adding technical debt, and abstractly debasing
users. Complexity can yield centralization, we should be more careful.

> Your aggression to your purpose is the antithesis of consensus, as it
> indicates your incentives are external to it.
> This is a personal attack John, and there have been too many of those
> lately. This is a completely unacceptable thing to say on this mailing
> list. I ask that you take your words back and apologize. Please be more
> objective and temper your strong emotions.
> You know what is antithetical to consensus? People throwing around
> personal attacks, asserting that consensus is something without evidence,
> and failing to acknowledge the many opinions out there that are different
> from theirs. You write your email as if there's only one person in this
> world who wants CTV. You know this isn't the case.


Cry harder. Jeremy is his own champion and my assessment that his
incentives are external to consensus is based on analyzing the game and
dynamics at play. It is evident to anyone capable of being objective, and
your being offended is not important to this topic. However many people in
the world that may want CTV, that number is surely less than 1% of the
Bitcoin user base.

--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

--00000000000061837305de14b97a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">&gt; The path to consensus is to propose things that everyone ne=
eds.<br>If there&#39;s an insight here, it isn&#39;t clear what it is to me=
. As stated, this is something I can only 100% disagree with. Its possible =
that literally nothing about bitcoin is something=C2=A0that &quot;everyone =
needs&quot;. Its pretty clear that not &quot;everyone needs&quot; taproot. =
Its even questionable whether &quot;everyone needs&quot; bitcoin. Are you r=
eally saying that no change should be added to bitcoin unless it is somethi=
ng literally all bitcoin users are currently asking for, or maybe just will=
 want to use sometime soon? The majority of bitcoin users don&#39;t even cu=
stody their own funds, so practically all features are something those user=
s aren&#39;t using. If you want to convince people of whatever argument you=
&#39;re making, you&#39;re going to have to get a little more specific and =
rather less hyperbolic.=C2=A0</blockquote><div><br></div><div>Billy, the in=
sight is quite simple: it is easier to get everyone to agree when everyone =
has something to gain. Taproot getting activated is not proof of a sound co=
nsensus process, it is proof that most users are either apathetic or trusti=
ng in the developers that initiated it being activated. This is a dangerous=
 dynamic to lean on. I&#39;m not trying to convince anyone of anything, I&#=
39;m trying to provide insight into Bitcoin&#39;s dynamics and qualities so=
 as to save everyone some time. Take it or leave it, but I&#39;m confident =
about how things will play out within this model.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">&gt; Designers (engineers) sol=
ve problems with designs, but when they speculate and lead the=C2=A0process=
, they create problems instead.=C2=A0<br>How do you expect any improvement =
to ever happen to bitcoin if designers can&#39;t design things unless end-u=
sers have asked for it. Every good product designer knows that users do not=
 know how to design products. Users have problems, designers create solutio=
ns. Companies that have implemented features that users directly ask for en=
d up with awful bloated confusing products. Surely this isn&#39;t what you&=
#39;re suggesting we do in bitcoin, right?</blockquote><div><br></div><div>=
I do not &quot;expect&quot; improvement by any other means than is typical =
in life: competition and adaptation in response to an adverse and changing =
environment. Designers can design whatever they please, they just need to u=
nderstand the dynamics at play and the risks they are taking in that they a=
re likely to waste their own time, and others, if they miss the mark on pro=
viding for the greater good. Anyone can be a designer, like anyone can be a=
 Bitcoin user. Engineers are only special if their specialization allows th=
em to solve a problem faster than someone else might. Why are you talking a=
bout companies and bloat while I am speaking about being conservative?=C2=
=A0<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">&gt; Seek simplicity and efficiency, not complication.<br>This is an ext=
raordinarily ironic thing to say to Jeremy Rubin, who designed CTV with exa=
ctly that in mind. It is an incredibly simple opcode that doesn&#39;t allow=
 recursive covenants or various other things that people have been worried =
about in the past about covenants. I&#39;m 99% confident that there is no s=
impler, more efficient, and less complicated covenant opcode than CTV that=
=C2=A0can even possibly be designed. The only one on par is TXHASH+CSFS and=
 that has more complex implications than CTV.</blockquote><div><br></div><d=
iv>No, you&#39;re ironic in thinking that adding complication to Bitcoin=
9;s base layer is somehow a means of valuing simplicity. I don&#39;t know w=
ho you are, and since you and Jeremy have no reputation with me, I have no =
reason to care about your &quot;99%&quot; confidence in something that I ca=
nnot distinguish from an attack and have no personal need for. This is how =
trust and incentives work!=C2=A0</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">There are MANY people out there that would like=
 more complex, more powerful covenants. &quot;The market&quot; is=C2=A0 in =
fact demanding it. And yet because we must move carefully in Bitcoin, CTV i=
s a compromise that focuses on simplicity and incremental change rather tha=
n radical change.=C2=A0Do you really disagree that CTV was intended to be a=
s simple as possible and achieves that goal?=C2=A0</blockquote><div><br></d=
iv><div>Speaking for myself, and likely the great majority of the market: &=
quot;Don&#39;t know, don&#39;t care.&quot; Your self-ascribed ability to as=
sess the market is objectively overconfident because we all know there is n=
o way to confidently measure this market by polling or analysis, and that m=
ost of this market does not even know CTV exists, and the portion that does=
 know of CTV is barely competent=C2=A0enough to audit or bless it. That is =
just reality.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">&gt; There is simply no urgency or problem that any of the p=
roposed soft fork features are trying to address.<br>That is pretty subject=
ive, and very debatable. But ignoring the debatableness of it, why is urgen=
cy even necessary for an improvement to bitcoin? Should we wait until a pro=
blem is urgent to fix it? Or should we get ahead of it so we don&#39;t risk=
 making hasty mistakes?=C2=A0</blockquote><div><br></div><div>What is neces=
sary is demand. All forms of scale and complexity come at a cost to Bitcoin=
 users. That cost is only offset AFTER the feature has reached saturation o=
f usage. Not even Segwit has achieved saturation yet. Taproot is dying on t=
he vine so far. This is not a judgment of either design so much as an obser=
vation that we might be too aggressive in our pace of feature speculation. =
If we keep piling on features, we have more chances of making a mistake, ad=
ding technical debt, and abstractly debasing users. Complexity can yield ce=
ntralization, we should be more careful.</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">&gt; Your aggression to your purpose is=
 the antithesis of consensus, as it indicates your incentives are external =
to it.<br>This is a personal attack John, and there have been too many of t=
hose lately. This is a completely unacceptable thing to say on this mailing=
 list. I ask that you take your words back and apologize. Please be more ob=
jective and temper your strong emotions.=C2=A0<br>You know what is antithet=
ical to consensus? People throwing around personal attacks, asserting that =
consensus is something without evidence, and failing to acknowledge the man=
y opinions out there that are different from theirs. You write your email a=
s if there&#39;s only one person in this world who wants CTV. You know this=
 isn&#39;t the case.=C2=A0</blockquote><div><br></div><div>Cry harder. Jere=
my is his own champion and my assessment that his incentives are external t=
o consensus is based on analyzing the game and dynamics at play. It is evid=
ent to anyone capable of being objective, and your being offended is not im=
portant to this topic. However many people in the world that may want CTV, =
that number is surely less than 1% of the Bitcoin user base.=C2=A0</div><di=
v>=C2=A0<br></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smar=
tmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(34,34,3=
4)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"co=
lor:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">CEO=
,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" target=
=3D"_blank">Synonym.to</a></div></div></div></div></div></div></div>

--00000000000061837305de14b97a--