From: John Carvalho <john@synonym•to>
To: Billy Tetrud <billy.tetrud@gmail•com>,
bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Working Towards Consensus
Date: Tue, 3 May 2022 06:24:23 +0100 [thread overview]
Message-ID: <CAHTn92xn9nr3n4wvFWfc6g=zVNceaRprZsHMSML0DC5JqnKFJw@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDbRp8ZoT+JWV6mKBPQT=86rxcSD9vELFsTMyU96S3D4kw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6586 bytes --]
>
> > 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/>
[-- Attachment #2: Type: text/html, Size: 8114 bytes --]
next prev parent reply other threads:[~2022-05-03 5:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.51682.1651459425.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-05-02 8:37 ` John Carvalho
2022-05-03 0:04 ` Billy Tetrud
2022-05-03 5:24 ` John Carvalho [this message]
[not found] ` <PS2P216MB1089155348699F63A49A9D9D9DC39@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
2022-05-08 17:36 ` Billy Tetrud
2022-05-02 2:43 Jeremy Rubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHTn92xn9nr3n4wvFWfc6g=zVNceaRprZsHMSML0DC5JqnKFJw@mail.gmail.com' \
--to=john@synonym$(echo .)to \
--cc=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox