From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 23 Jul 2024 17:46:08 -0700 Received: from mail-yb1-f187.google.com ([209.85.219.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWQ8t-0004s9-8Q for bitcoindev@gnusha.org; Tue, 23 Jul 2024 17:46:08 -0700 Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-e087d3d0a8csf7619925276.2 for ; Tue, 23 Jul 2024 17:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721781961; x=1722386761; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=Vkh2CxQadj7LdlI68JVdCwTx/W5/TgY3FeKrFscN4ZM=; b=UgUq7H2MnKVFB9CsTQL7xiXpgkKiMJ2AKlJh8NjvH8xVGvCZ4wCipm8ICl01HsN45Y 9HACioXhdhlvrRfYvx+GV2+zFrEqlgaPT4FV0KxMEAKmr6nUe2y+GpKMXAXMl8L5FsCw i/zwnhHW1NkPhTpK1Z3twdBuVxERIpdvim5oRNU+d+vKk53Ti7T1lNxo4gqOm2kHZgIR 5Ni5casUFf+8cp1yHZiMo58Mz3C5a4Z+zS31vZN0cvKmK+6TrT8JVVDbKoMPoI0P0LRn RNwmXOiP8Zvcn3a7Ge5x7DQKiUqvcTGx/OitS1tSdtAb+/2+Cfv6d5mSkusFNNyJbjwi 7qSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721781961; x=1722386761; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=Vkh2CxQadj7LdlI68JVdCwTx/W5/TgY3FeKrFscN4ZM=; b=HLL0oS3s8XY28rOIUZ41AGIy0MGz9KBnTPg8RO7wGrkazIQhSa8lReYlnvNlykYfMP 6mfYETNZHHGbkZ3OxuyRT6U9EI/df1v0fXAogbjaPtj1cNFSYGDHEyFjPIgXSVyKvzgV Jujkk0wkk8nCP1bMAwlyN1JpWhIMlDIS3l0u184UsMaYFGvyBzPVO1/WGL6gQL9ZUf6i 8WoMOTSskfD2qGxa/H7939nJ/JNqyJW14YkC4ep1F4buX8fr9/YCuub9WTV2JJkVyZCI rK9dZ6qPjXqn5zMa7jWANfHvzP04HIZB1NDF64z70OPkYHZIll6ECJ79kVdvPviKgqrB Mazw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721781961; x=1722386761; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=Vkh2CxQadj7LdlI68JVdCwTx/W5/TgY3FeKrFscN4ZM=; b=vCGYYYmGCdpt0Bja6Dsev8wrAY9GaKPAgLnYjTe84mohyL/WHsoL10RdQOV47Xun0c ifP9E1YVbF4kVijd4jIaRjH+kfEliC1bovY+xB4O4o5S4v6yZsjZE0EUcYvNYXfleL+e yeEK181zBcsBNqfwhPoaRaC3t72xZfwYvvUPHno5POy+Cdy3Itqu7OmYbNlqHjDS3eQo petsoUQAKaEh3uiFNnQa4/sBtttw+3pbHg7CSDs1YT9U0GbTvf4tv+PaBs+swm9dYmu5 Sx83kuZfnqP5oxHJSFWA0o6hCc2L0Glm3zfl5OBHChuPjlIdj2zKqGzCLeaBAila8cHu UTyA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV4U2BhkS5xqbAPkgINYaKNoLzdWNPAV/CLzLrCTNioqzsCtTIoBfNMEbKdNBDJVNX+uGz64jutJocF4H4YS0y4q61sXL0= X-Gm-Message-State: AOJu0Yzftys4hdFtvO5FyXtP32eBq9+soUOec62fAriwxvKG8KJDieCB +zjqli+CvlaCPIRV5ecVw3szoNSKRFm4AvUofJOsABixN+LPUYlP X-Google-Smtp-Source: AGHT+IFgT3Ow7wnMFJuTnEIDgTA0k9VH0MlKFGH6BfiQZdmMLCkX4SghVRx/rtVrTDuJrVP8lFNxsg== X-Received: by 2002:a05:6902:727:b0:e08:5951:9788 with SMTP id 3f1490d57ef6-e0b0985ba8cmr1644751276.46.1721781961072; Tue, 23 Jul 2024 17:46:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a5b:74b:0:b0:e02:b40e:8e90 with SMTP id 3f1490d57ef6-e05fdb6f80dls9587616276.2.-pod-prod-09-us; Tue, 23 Jul 2024 17:45:59 -0700 (PDT) X-Received: by 2002:a05:690c:97:b0:62d:42d:5f63 with SMTP id 00721157ae682-66a6644e8b2mr10816557b3.5.1721781959886; Tue, 23 Jul 2024 17:45:59 -0700 (PDT) Received: by 2002:a05:690c:3104:b0:664:87b6:d9e0 with SMTP id 00721157ae682-66918fcc18cms7b3; Tue, 23 Jul 2024 17:44:21 -0700 (PDT) X-Received: by 2002:a81:b201:0:b0:65c:2536:be7f with SMTP id 00721157ae682-671f494197bmr467707b3.7.1721781860446; Tue, 23 Jul 2024 17:44:20 -0700 (PDT) Date: Tue, 23 Jul 2024 17:44:20 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <1f6d6917-01f1-496d-9c97-8513fce24149n@googlegroups.com> In-Reply-To: <3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.com> References: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com> <4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com> <4f7eddff-9e2d-4beb-bcc6-832584cb939d@achow101.com> <2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn@googlegroups.com> <3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.com> Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_933414_432050491.1721781860217" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_933414_432050491.1721781860217 Content-Type: multipart/alternative; boundary="----=_Part_933415_390350297.1721781860217" ------=_Part_933415_390350297.1721781860217 Content-Type: text/plain; charset="UTF-8" Hi Anonymous, Let's add more characterization by zooming out on a 15 years timeline on the situation for an external observer less versed in usual bitcoin core development. Historically, the project has been cared of by veteran of open-source projects, old cypherpunks and other contributors used to security system engineering. While qualms on technical proposals have always been heated even in the early days (e.g the infamous OP_EVAL or bloom-filters bip37), at the very least protagonists in the conversation were taking technical arguments at their sound value and killing weak ideas when a majority of contributors have came to the same conclusion. The resistant to the arguments, if they did not have the intellectual honesty to fully appreciate arguments, were slowly moving out of contributing to bitcoin or projects around to go work on fork-coins or something else. From my experience, historically bitcoin had some of the most scientifically grounded and software skilled contributors sweating hard and ready to risk their professional careeers to make the bitcoin core codebase advance. There is a bit of subjectivity involved here though I worked on code changes and review with some people since the early days and if you take the "old guard" the level is here. With time, especially after the block size war which have been intense whatever the camp you have followed, some more "senior" core contributors have take a more or less step back, without necessarily taking the time to fully transmit the same level of technical and ethical standard to newcomers making their dents on the project. This trend has only been worsen with the Faketoshi lawsuits, where even more "senior" contributors have take a step back. All those "senior" folks, of which Peter is a good specimen, where very okay when you yelled at them that code was broken or a significant low-level proposal was weak and it was better to fix them before to move forward. Without always necessarily caring about following the utmost courtesy and politeness. At the very same time of the end of the block size war and when faketoshi lawsuits where taking the most of their toll among the contributors, there has been more the growth of a culture of "professionalizing" the bitcoin core space. That have translated in a number of dimensions, e.g we have started to seen a myriad of "money-helicopter" open-source grants (most of the times attributed to hard working folks, sometimes giving the impression that attribution has been done on more external "social" factors). In parallel, there has been an emphasis in the core developnment process to ship complex code in low-level subsystems, whatever the thoroughness of the design and code review, as landing complex code not only make good story to tell on podcasts and twitter but it has also become a self-sustaining argument to grap more open-source grants for some less regarding contributors. (I don't know if a lot of folks are familiar with the school of public choice in economics and the concept of rent-seeking capture, one can wonder if it's not a phenomena affecting bitcoin open-source stage too. This is not saying that it's great to have folks on open-source grants to handle releases, refactor the old parts of the codebase or write more tests, I think just to be more far conservative when it comes to implementation of new mechanism and minimizing the impact of incentives nurturing complacency). With that accumulation of uncoordinated cultural changes, and open-source grants becoming the norm as a mode of compensation among the majority of bitcoin core contributors (rather than exercising their skills on the market or being good with their btc stack), in my impression there has been more and more a wind of spontanous self-censorship arising among the current generation of contributors. After all, what one would take the risk of being far too negative or adverserial in the review of one's co-contributors patchset, when that very co-contributor might judge for your grant re-attribution at the end of the year ? Better to not take the risk, and if it's coupled with having a small btc stack even if there is a major security failure X years from now, you wouldn't personally pay the cost as your fiat-denominated grant will be still dump on you. All you have to do in case of security failure is run away from any responsibility and engage in a heavy public relationship effort saying everything is all right, bragging about the fact that you're a maintainer or that you've seen worst in the past (were indeed you were not the ones doing the hard work at the time). It might be a very personal opinion, though I think there have been a serious downgrade in bitcoin core culture about technical proposals, where it was estimated that the code was broken to a more current culture of first not making wawe and to be always "constructive" (even if no ones knows exactly what does it mean to be constructive when a technical proposal has been analyzed to be broken and when it's reasonably wiser to abandon months of engineering effort rather to jeopardize end users funds safety) [0]. [0] https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md Quote: "One can just have a look on the newer moderation rules, where it is explicitly said "on the understanding that it is easier to rephrase deleted comments to be constructive and respectful than to replace long term contributors who are burnt out from a discussion culture that is unnecessarily contentious and overbearing" [0]. I think here some astute minds could observe that progress in the domain of scientific ideas if one complete history on few centuries are driven a lot by controversy, overbearing experiments done again and again and argumentation layout repeated multiple times in front of many audiences, as some brilliant ideas might be counter-intuitive at first. With all said and joining on your suggestion to fork core or have in-place multiple security mailing lists. On the former this does not abstract from gathering enough dedicated experts behind the same codebase, though more importantly maintaining a culture of collaboration among the different full-node implementation. If it's go back to the situation of Bitcoin XT fork and Bitcoin Segwit2X, where experts are fighting each other to "dictate" the consensus rules this is not worth it. New civil war in bitcoin is a situation where everyone will be at loss. On the latter suggestion, multiple security list is more or less already the current dynamics as historically you had coordination among lightning implementations or with the mining ecosystem. Whatever the reality of a single endpoint, at the end of the day it's more a "peer-to-peer" dynamic, after a while you know you can personally trust and who is very skilled in area X or area Y or bitcoin. Degree and goodwill of collaboration is more important that the communication channel itself, as some bitcoin core contributors reveals publicly recently what was more or less known in internal circles about the project management of security issues [1]: [1] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w Quote: "The project has historically done a poor job at publicly disclosing security-critical bugs, whether externally reported or found by contributors. This has led to a situation where a lot of users perceive Bitcoin Core as never having bugs. This perception is dangerous and, unfortunately, not accurate." I hope certainly there will be some cultural electro shocks, of which Peter's present disclosure email can consistute an opportunity for a lot of people to medidate on, that we improve the security of the bitcoin ecosystem at large by adopting good security issues handling process. And that before we're seeing massively contract protocols and second layers being p0wned by North Korea sponsored hacking groups -- if the evidences gathered by the wider cybersecurity community is correct on this front. Reader beware - All those historical considerations on the evolution of bitcoin core culture only represents my own opinion, this is necessarily the reflect of my subjective experience as a contributor and there is no need to trust me. Best, Antoine ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com. ------=_Part_933415_390350297.1721781860217 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Anonymous,

Let's add more characterization by zooming out on = a 15 years timeline on
the situation for an external observer less ver= sed in usual bitcoin core development.

Historically, the project= has been cared of by veteran of open-source projects,
old cypherpunks= and other contributors used to security system engineering. While
qua= lms on technical proposals have always been heated even in the early days (= e.g
the infamous OP_EVAL or bloom-filters bip37), at the very least pr= otagonists in
the conversation were taking technical arguments at thei= r sound value and killing
weak ideas when a majority of contributors h= ave came to the same conclusion.

The resistant to the arguments,= if they did not have the intellectual honesty to
fully appreciate arg= uments, were slowly moving out of contributing to bitcoin or
projects = around to go work on fork-coins or something else. From my experience,
historically bitcoin had some of the most scientifically grounded and soft= ware
skilled contributors sweating hard and ready to risk their profes= sional careeers
to make the bitcoin core codebase advance. There is a = bit of subjectivity involved
here though I worked on code changes and = review with some people since the early
days and if you take the "old = guard" the level is here.

With time, especially after the block = size war which have been intense whatever
the camp you have followed, = some more "senior" core contributors have take a more
or less step bac= k, without necessarily taking the time to fully transmit the same
leve= l of technical and ethical standard to newcomers making their dents on the = project.
This trend has only been worsen with the Faketoshi lawsuits, = where even more "senior"
contributors have take a step back.

All those "senior" folks, of which Peter is a good specimen, where very o= kay when you
yelled at them that code was broken or a significant low-= level proposal was weak and
it was better to fix them before to move f= orward. Without always necessarily caring
about following the utmost c= ourtesy and politeness.

At the very same time of the end of the = block size war and when faketoshi lawsuits where
taking the most of th= eir toll among the contributors, there has been more the growth
of a c= ulture of "professionalizing" the bitcoin core space. That have translated = in a
number of dimensions, e.g we have started to seen a myriad of "mo= ney-helicopter" open-source
grants (most of the times attributed to ha= rd working folks, sometimes giving the impression
that attribution has= been done on more external "social" factors). In parallel, there
has = been an emphasis in the core developnment process to ship complex code in l= ow-level
subsystems, whatever the thoroughness of the design and code = review, as landing complex
code not only make good story to tell on po= dcasts and twitter but it has also become a
self-sustaining argument t= o grap more open-source grants for some less regarding contributors.
<= br />(I don't know if a lot of folks are familiar with the school of public= choice in economics
and the concept of rent-seeking capture, one can = wonder if it's not a phenomena affecting
bitcoin open-source stage too= . This is not saying that it's great to have folks on open-source
gran= ts to handle releases, refactor the old parts of the codebase or write more= tests,
I think just to be more far conservative when it comes to impl= ementation of new mechanism and
minimizing the impact of incentives nu= rturing complacency).

With that accumulation of uncoordinated cu= ltural changes, and open-source grants becoming
the norm as a mode of = compensation among the majority of bitcoin core contributors (rather
t= han exercising their skills on the market or being good with their btc stac= k), in my
impression there has been more and more a wind of spontanous= self-censorship arising among
the current generation of contributors.= After all, what one would take the risk of being
far too negative or = adverserial in the review of one's co-contributors patchset, when that
very co-contributor might judge for your grant re-attribution at the end o= f the year ?

Better to not take the risk, and if it's coupled wi= th having a small btc stack even if there
is a major security failure = X years from now, you wouldn't personally pay the cost as your
fiat-de= nominated grant will be still dump on you. All you have to do in case of se= curity failure
is run away from any responsibility and engage in a hea= vy public relationship effort saying
everything is all right, bragging= about the fact that you're a maintainer or that you've seen
worst in = the past (were indeed you were not the ones doing the hard work at the time= ).

It might be a very personal opinion, though I think there hav= e been a serious downgrade in
bitcoin core culture about technical pro= posals, where it was estimated that the code was broken
to a more curr= ent culture of first not making wawe and to be always "constructive" (even = if no
ones knows exactly what does it mean to be constructive when a t= echnical proposal has been analyzed
to be broken and when it's reasona= bly wiser to abandon months of engineering effort rather to
jeopardize= end users funds safety) [0].

[0] https://github.com/bitcoin-cor= e/meta/blob/main/MODERATION-GUIDELINES.md

Quote: "One can just h= ave a look on the newer moderation rules, where it is explicitly said "on t= he
understanding that it is easier to rephrase deleted comments to be = constructive and respectful
than to replace long term contributors who= are burnt out from a discussion culture that is
unnecessarily content= ious and overbearing" [0].

I think here some astute minds could = observe that progress in the domain of scientific ideas if one
complet= e history on few centuries are driven a lot by controversy, overbearing exp= eriments done again
and again and argumentation layout repeated multip= le times in front of many audiences, as some brilliant
ideas might be = counter-intuitive at first.

With all said and joining on your su= ggestion to fork core or have in-place multiple security
mailing lists= . On the former this does not abstract from gathering enough dedicated expe= rts
behind the same codebase, though more importantly maintaining a cu= lture of collaboration among
the different full-node implementation. I= f it's go back to the situation of Bitcoin XT fork
and Bitcoin Segwit2= X, where experts are fighting each other to "dictate" the consensus rulesthis is not worth it. New civil war in bitcoin is a situation where eve= ryone will be at loss.

On the latter suggestion, multiple securi= ty list is more or less already the current dynamics
as historically y= ou had coordination among lightning implementations or with the mining ecos= ystem.
Whatever the reality of a single endpoint, at the end of the da= y it's more a "peer-to-peer" dynamic,
after a while you know you can p= ersonally trust and who is very skilled in area X or area Y or bitcoin.
Degree and goodwill of collaboration is more important that the co= mmunication channel itself, as some
bitcoin core contributors reveals = publicly recently what was more or less known in internal circles about
the project management of security issues [1]:

[1] https://gro= ups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Quote: "The project ha= s historically done a poor job at publicly disclosing security-critical bug= s, whether externally
reported or found by contributors. This has led = to a situation where a lot of users perceive Bitcoin Core as
never hav= ing bugs. This perception is dangerous and, unfortunately, not accurate."
I hope certainly there will be some cultural electro shocks, of w= hich Peter's present disclosure email
can consistute an opportunity fo= r a lot of people to medidate on, that we improve the security of the bitco= in
ecosystem at large by adopting good security issues handling proces= s. And that before we're seeing massively
contract protocols and secon= d layers being p0wned by North Korea sponsored hacking groups -- if the evi= dences
gathered by the wider cybersecurity community is correct on thi= s front.

Reader beware - All those historical considerations on = the evolution of bitcoin core culture only represents
my own opinion, = this is necessarily the reflect of my subjective experience as a contributo= r and there is no need
to trust me.

Best,
Antoine
ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891=

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com.=
------=_Part_933415_390350297.1721781860217-- ------=_Part_933414_432050491.1721781860217--