public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	 "lightning-dev\\\\@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>,
	dlc-dev@mailmanlists.org
Subject: [bitcoin-dev] On the recent softforks survey, forget to fulfill my answer!
Date: Mon, 21 Jun 2021 11:05:57 -0400	[thread overview]
Message-ID: <CALZpt+H7fbocEm0uuCo=Xm7OEq0uT-A0D3R0GfEA1TwphM0iYw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 11170 bytes --]

Hi,

I was super glad to see the recent survey on potential softforks for the
near-future of Bitcoin! I didn't have time to answer this one but will do
so for the future. I wanna to salute the grassroots involvement in bitcoin
protocol development, that's cool to see :)

Though softforks are what shine in the media and social networks, one
should not ignore they represent the aggregation of thousands of hours of
sweat from contributors all across the ecosystem with discussion extending
from IRC public or private chans, mailing list, medias, etc.

What makes softfork discussion especially hard is that no one is following
all those communications channels to collect the trace of information and
as such it can be hard to reason on the Big Picture(tm). That's why
soft-forks take time, and we might somehow be prepared for them to take
even more time in the future...

That said, where I would like to draw awareness of the community is about
the submerged part of bitcoin protocol development iceberg. Softforks are
sexy, though you have far more areas of Bitcoin dev who would benefit from
a gentle boost by happy hands :p

For e.g, if you take Bitcoin Core, you have few ongoing projects were folks
have a hard time moving forward, e.g assumeutxo/mempool
refactos/addr-relay/rebroadcasting module/mutation testing/
multiprocess/wallet external signer/GUI maintenance/libbitcoin_kernel[0]

Those projects start to be "softfork"-in-itself-size-of-engineering, and
for a lot of them might  require more than pure "coding" skills, such as
specification, simulations, extensive code coverage, up-to-date meeting
documents. See what is currently done with the Core wiki [1]

All those projects are modifying critical areas of Bitcoin such as the
validation engine or the p2p stack and AFAICT, they deserve more care.
Hopefully, by drawing the light there, more folks are going to understand
them, we'll have more skilled reviewers, reducing the reliance on a few
segments of the codebase being only understood by some seen experts and
ideally, ingenious, "Many Eyes Make All Bugs Shallow" :)

That said, it's only the technical ground and I believe the human layer of
Bitcoin dev might be the one where grassroots-involvement might be the most
fruitful.

I would say the Bitcoin dev stage has changed a bit since the last 18
months, especially w.r.t to few factors, the arrival of massive development
funding, the sudden mediatisation of protocol developers and the pursued
geographical spreading, diversification and education of the poolset of
contributors.

When I did arrive on the stage a few years ago, funding was still a hard
question, even for well-known, long-term contributors and only a few actors
were taking care of Bitcoin. Really differently, from what we have seen on
the last months, where we have seen a plethora of new organisations
entering the game and benefiting from the generosity of the Bitcoin
industry [2]

Things have been so fast that sometimes one can wonder if there isn't a
bubble around Bitcoin dev ? Few OGs might suggest we're back to 2017, with
ICO-like webpage pinning "developers-as-brands".  In reality, we see new
grant announcements every month or week, but still the number of reviewers
on Core doesn't seem to increase ? [3]

Hopefully, a lot of those new structures pretending to work for Bitcoin
betterness will get out of their childerness phase and slowly mature to
something as sound as Chaincode or Square Crypto. Small, friendly,
politics-free engineering teams with years-long stability, solving bitcoin
problems with a "forever" perspective mindset.

Though, as of today, you do have the opposite with the grant model. Being
funded on the rational that yours peers "appreciate" your work is more
going to generate implicit compliance at review time where you should
instead spot their errors. Bitcoin development process is highly contrarian
per nature, and constantly challenging your peers assumptions has been
preserving software robustness.

Time will separate the wheat from the chaff though how to make things
better in the short term ? I don't know, maybe those structures could be
exemplary and outsource their grant allocation decisions framework ? Or ask
them to publish grant contract under which contributors are engaging
themselves to observe if the usual independence provisions are present [4]

In another direction, I believe the ongoing mediatization increase of the
Bitcoin dev stage in the last months or so didn't improve the current state
of affairs. We now see technical proposals, of which the soundness have not
been thoroughly discussed in the traditional venues, being announced in big
pump as some kind of "done-deal", potentially sustaining the false belief
it has been already blessed or approved by the rest of the development
community.

And honestly, it's quite easy to approach any Bitcoin media today once
you're a bit technical, and rely on lingo to create a perception of
competency towards your interlocutors. In fact, your talking isn't going to
be debunked by your peers as most of the time they have other,
on-the-ground, engineering issues to care about. Or say differently, if
you're a Bitcoin journalist today, it's quite easy for smart ass like me to
hijack your production :p

Don't trust, verify :)

Another bottleneck in Bitcoin development is the ongoing spreading of
contributors around many geographical areas and timezones, making
intra-communication far harder. Lightning dev or Bitcoin Core technical
meetings might happen at the end of your local day but another attendee
might just get started, and with time you feel how divergence in level of
energies influences the serendipity of engineering discussions.

Communication might not flow smoothly through all the development
stakeholders and how do we make communications more distributed and
fault-tolerance without losing on the quality ? I don't have the
answers...Yes, the Earth isn't flat and that's an issue for Bitcoin dev :/

The ongoing increase in developer diversity is also something to salute.
Anyone is invited to contribute without regards to technical experience,
race, "expertise", OSS experience, age, gender, language or any other
social concern. I believe diversity is a force for Bitcoin development and
I would like to congrat my fellow female Bitcoin hackers of which the
continuous hard work and smartness should inspire more women to follow
their tracks in the coming years. Pioneering has always been hard :/

Another remaining issue is developer education. The development of
cryptocurrencies demands a high-level of rigor, adversarial thinking,
thorough testing and risk-minimization development strategy. Any bug may
cost users real money and disrupt folks' lives. We still have a lot to
learn from the Old Guard, which sadely are less and less active on the
daily ground and I would say the ecosystem infrastructure would be far more
sane with more security-oriented folks.

As a young developer, even armed with the best intentions it takes years to
adopt a security-first mindset and continuously extend and mature your
technical stack. One has to become fluent through a wide variety of areas
to be an efficient contributor, distributed systems, internet protocol,
applied cryptography, database, game theory, professional english,
quality-assurance best practices, the list is never ending and there is
always a nice chunk of knowledge to go after :)

Lastly, another uncomfortable issue to talk about is direct pressure
exercised on the developers themselves to bend their works, as the ongoing
CSW case sadly recalls. Flavors of those concerns  have been mentioned a
lot through Bitcoin archives [5].

So far, I've never heard about angry calls passed backstage to Bitcoin
contributors, deliberately made to influence the expression of their public
technical opinions. Though in the future, if that kind  of thorny situation
happens to you as a Bitcoin FOSS contributor, remember that you're always
free to discuss discretely about potential conflict of interests you
observe with folks of confidence around you. Or if you prefer to keep the
anonymity, reach out to some investigative journalists under a cover
identity.

Here is, I think that's all the area where I would be glad to see more
grassroot-engagement or even any coming from the industry with eager
motivation to help on those fronts.

Ask not what Bitcoin can do for you - ask what you can do for Bitcoin :)

Cheers,
Antoine

PS: oh, and SIGHAsH_PURPLE for the win :p

[0] That's a joke on mutation testing, it's a trillion-dollar codebase, but
we don't do
mutation testing. Sad :/

[1] See https://github.com/bitcoin-core/bitcoin-devwiki/wiki

[2] Disclaimer: I'm not open to outbound sponsorship proposals.

[3] As backed by data here :
https://adamjonas.com/bitcoin/coredev/retro/coredev-2020-retro/

[4] For e.g, a lot of grant legal frameworks don't have clauses
guaranteeing the independence of the
general Bitcoin Core or Lightning development, just a smaller subset around
validity of block rules,
inspired from the BitMex open one. Clearly a hole if you ask any competent
lawyer...

[5] Flavors of those concerns have been mentioned a lot through Bitcoin
archives:

See "Bitcoin in 2021":
https://www.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021

" After all, if you can replace all the people who would’ve objected to
what you want to do, there’s
no need to sneak it in and hope no one notices in review, you can just do
it, and even if you don’t
getrid of everyone who would object you at least lower the chances that
your patch will get a thorough
review by whoever remains. There are a variety of ways you can do that. One
is finding way of making
contributing unpleasant enough that your targets just leave on their own:
constant arguments about
hings that don’t really matter, slowing down progress so it feels like
you’re just wasting time,
and personal attacks in the media (or on social media), for instance.
Another is the cancel-culture
approach of trying to make them a pariah so no one else will have anything
to do with them."

Or see "Working on social contracts (was: Paper currency)" :
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005851.html

"I promise that if bad people show up with a sufficient pointy gun that
I'll do whatever they tell me to do. I'll make bad proposals, submit
backdoors, and argue with querulous folks on mailing lists, diverting
them from real development and review work, all as commanded. Maybe
I'll try to sneak out a warning of some kind, maybe... but with my
life or my families or friends lives on the line— probably not.

... and I think that anyone who tells you otherwise probably just
hasn't really thought it through.  So what is the point of commitments
like that?  People change, people go crazy, people are coerced. Crap
happens, justifications are made, life goes on— or so we hope."

[-- Attachment #2: Type: text/html, Size: 11846 bytes --]

                 reply	other threads:[~2021-06-21 15:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='CALZpt+H7fbocEm0uuCo=Xm7OEq0uT-A0D3R0GfEA1TwphM0iYw@mail.gmail.com' \
    --to=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dlc-dev@mailmanlists.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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