From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Jun 2025 08:23:39 -0700 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uP0p8-00089J-Dl for bitcoindev@gnusha.org; Tue, 10 Jun 2025 08:23:39 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-60f3ceb14bbsf4086287eaf.1 for ; Tue, 10 Jun 2025 08:23:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749569013; cv=pass; d=google.com; s=arc-20240605; b=h81LG8VRWUEVYGYR/A15oxVBt6ZXD8zFBYnsYIIhlPBEqYzUKmKvaP6WG8PDfYv4AT 7vKN8j1E2BddWVpHcoUHQPutcrNhlrHRkXCJ67EBaIzFz5jYCbxl8FWF4coK+Xz/9Fn6 3nWzyfieHws9qjRwJmv9WbtOJGz+wxmUJ13OFRtYfdJi7SDJKzbzJLgszBrdd6jiLCQ7 e/bZ6MrSga65MYJapUzYSNdMNLFuS895UH2Bc2aDpa5DQs0KodEgC5FVs4Hc8fW7LOXD JzOYnzGESQ07KgjK7lKtt3NVn4h1osLRabJGTTFPVLtKzzbEmxMER5QQYuRHDzMKlzZJ 6iAw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=JyxdqwZ1Fu1Bw6PJvOhvMEk/7+qVKi8ZzjlHCnvYhSA=; fh=EWEiyoMEbOWCwGdzO4iSMAnBt4EJdbMGdsKg1jgnfwI=; b=ZhcIH1NXIXtDWuySm/8m5RH08gAyh4l7e9Tntr2iqalaz0RwO56oM3HeeWyscge89H 1EkZBpOLpIiL3LZu60++TZWTeAmcybXIOCVMY4Vk1cAwm3I64b19Fakq0SxSIhBF+Aaa 8+rf2n7duef33owybSQeFMV6S4M7fqtElH+haD/XVN7BqKYnCl1NFBjVYpcINpTiRXBE ybBN3cg8pi4MD+xamlg6i2EsGtdBdxmxT4jijN6p5dkR1hmgmCE6nu3jgHuxKzUIFEi9 xltYhpH5YhqGH1iCCI1AyR6YpgAfZ7GtpmbgXwNBKnzSxJ8zvN0FSUpf6ouK7/pOp7Qs Snpg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=X1MoC5Mv; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) smtp.mailfrom=james.obeirne@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749569013; x=1750173813; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=JyxdqwZ1Fu1Bw6PJvOhvMEk/7+qVKi8ZzjlHCnvYhSA=; b=DFprQS9w3F/QK3HTu2lKSeeXxEEoWs+qDd5bTwMmmVGlxJk7ZdFn7zmFl9Z/gTyr8q ApTeE+mVL+YMrkJYisJTGPrXpeMsss/eIMFulhhamOKDAEFTHwsqYu44y1wtOjLEBdT6 +aXDMgeuf7pX41xH9Qns1IMiWS2WK8x4x6bkUW2Pnh4qC8iGPx2pzxJjXy+6N2ofVN1I ftAiuvxRAipk9zengIICKJVgHRxvYu/KB95qKtKGAK4ww86zhs9SNBUomZ/UbEhlZlZF KGLNOK5PSrPXBnmsv2lLkAFvwpbJ4vatW4GETzCg2xQ0rh0UTfezyeYxrcXbV0m450Jz JgOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749569013; x=1750173813; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JyxdqwZ1Fu1Bw6PJvOhvMEk/7+qVKi8ZzjlHCnvYhSA=; b=mJElz3/ZsNlCEsdKUiTO4TdYITR+dunO3vxELMcUhu+9s43MsAJIreA6w7nIuaUqz6 ceH70LQOcC09kfkROUHWiiIJbNdVZDr1ky/B9ozoaOoqn9Uw+S6Lr/oDzzVw0Iw7Qt9j 0oXcVvQlq5BuAAZccvVWldLN9DsOx8+B8LHqYrvI2Qk3WJBpZRaGz1R5fYBjhi06jDMt nH4nonqjFSOJPeVS9HfAZUGgx8WaAQhBpw69eVwHqWm6URYRzRJey86hRcnA7uDhBkWk LCIwvWrtVjs92RXAsxUhV7bk+CVG/az7m/1bP2D7EMf+88+VjMinUtDYVjrvlgxSENcy rxqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749569013; x=1750173813; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=JyxdqwZ1Fu1Bw6PJvOhvMEk/7+qVKi8ZzjlHCnvYhSA=; b=LGxGEb9+uyXAASbS9IpkWMgeNmxda5e52nwxdUPff1AtWhzjipD3KuiZMHGduKp+ow 4S0aM7qH4JwPqQbeuyJl/fGI4Bb2MaV/P7xNMqP60Nqjel37/tnkhgmWQFi9Pz06R2ek 9pX5vmc94T3EmnjIGa5jG1Kw/JdIgEDnaCUvQlBC2R8IXU4xiz6/DjEWUro+dlVKxy++ c5WNUZAMUVoU1vgGRf82cVkHn4eJy6ab3Ni9IKvnwelM8Bk2kxABCXyu4gd0BM8hSiAF 5sXGySGgynmKneBoUb/NFeiAQX/2aUONCLppqbICcE9y/v1SxXnLVFNH1lZkRHX5E9Cg w+Yg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWyXogkUePBk1K3dmPvGRoEkieFGA1sHXuhEnunbbAB0WrdsFrlsBzC86yJdfdm+T2zq7owL1k7EvBj@gnusha.org X-Gm-Message-State: AOJu0Yw/hCp/3TbNGSrmBB/04eEEO4TKlMgmFxnnEVzgmHyQKE6+IsQY eNuduNrGfS6tbIamfHBdbQ97aw2pU9p1vjFL3iEbeI9F8iDn+5/oUPVH X-Google-Smtp-Source: AGHT+IF/raoRwZ5mt4tSxaS8tpUEDe5rDYCGYfDT53zqwPMVWCKzdkgMdGMVGwp2CRFw3PnuDcR4VA== X-Received: by 2002:a05:6820:3102:b0:60f:3442:96b5 with SMTP id 006d021491bc7-610e2d525c5mr1948024eaf.8.1749569012441; Tue, 10 Jun 2025 08:23:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcVp1c0WxEu1/gGwa5DlB1Ldv3dX5Bx2sqboSMXNOOr6w== Received: by 2002:a4a:d810:0:b0:60b:e31f:50c9 with SMTP id 006d021491bc7-60f283af795ls733652eaf.1.-pod-prod-03-us; Tue, 10 Jun 2025 08:23:29 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCV2B+mLK+rgp61AwtGA1wBVGbEeHH6kDA6v58WWkwSupeYYLDo6kOgsFtQVpDP15yLJBwXQV6EOAYvo@googlegroups.com X-Received: by 2002:a05:6808:179e:b0:403:31a4:f3fe with SMTP id 5614622812f47-40a56b83315mr2220164b6e.32.1749569009142; Tue, 10 Jun 2025 08:23:29 -0700 (PDT) Received: by 2002:a05:6808:2a85:b0:3fa:da36:efcd with SMTP id 5614622812f47-40906044811msb6e; Tue, 10 Jun 2025 07:03:37 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVl3wzDWQ8yPXqyS3QFGL+wOJmxqzJAVVgh1NYefakYyijCmZdBvFp1zC7JO7q4g+DIotrNSl0dzpm7@googlegroups.com X-Received: by 2002:a17:903:19eb:b0:234:8eeb:d824 with SMTP id d9443c01a7336-23638358b77mr44163315ad.48.1749564216082; Tue, 10 Jun 2025 07:03:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749564216; cv=none; d=google.com; s=arc-20240605; b=HHYu2gSk1o2otVaT+1nWn6z4bo8j0iZoFcOZyDwZOyV7JHktgm757xpwddC3rtvUMr 7WweU4QAaFb6tKfo7C9KJ3pVny1krMYVbo89QT2rbUpUCjpOE+kfy6h4MoixTBLash/K RLt6fHisQStAk6g17GJkURj3I8NSl6JQMQcizJ7ANfsjyHPAy4pa9VNWat9ddBn/fiOu D1AkKKnC784YKv4BZZxWDsdjy5QR166iTX8QEnhdNHyoVcJ488QqbMl8Sop3Vun6scWM Nlg1Vbj+vdWuQxHnQvY4IQyl7eGjtUxmQaWGLujTIRvluOllAIbwnT4cpq7+XouDWbCt U5VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gpRLMwcZXY7v4COyw7+FZ5DLjT7ZuV8A1g8EqTSYGmc=; fh=UiZ2ApPzsjy9vCKlecMH0Lr0JoUN4mzCrEq3znGvb7k=; b=Nl9FEPwjzn7f5WdYZDZLWd825vE+C1vIrKX3hTejJ3/x+i8A2zz6ZnRcclq8ug7ymt 3TYS0KMendHeBkZjV2om0yTY5RaUjRF6pgwVI5DrI6qdR1GkRqA6h+0+WU+/QjoJpFI2 ayoKWz3UYHB3KjOYwXe8/JcL926lGK3zI7Fze5CJmNlrctm2zwUNkK+Mzl5G19Mpnxxo pxf29nRQwIphOBqpDCaOqUIeBuFWQ2EELvY3FYGm1phj9YwNbka5NovQn8mtNmhU+OYV +ub3R7ZWM2u7uxaYczjbmxTQjcg8QJQG0nIxUcrwpNlmycZkxOsiUedkoDgyDWDquM4P B5Kw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=X1MoC5Mv; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) smtp.mailfrom=james.obeirne@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com. [2607:f8b0:4864:20::535]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3134a777e0dsi736578a91.0.2025.06.10.07.03.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jun 2025 07:03:36 -0700 (PDT) Received-SPF: pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) client-ip=2607:f8b0:4864:20::535; Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-b26d7ddbfd7so5837964a12.0 for ; Tue, 10 Jun 2025 07:03:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVnIUSNO1ONURmPBMSJ+k2wEKe9Ae9SaUOnJo8isg/pnuQ9M1ZNF7rRA2D50t3lvyxCYZOfkvxBPmzV@googlegroups.com X-Gm-Gg: ASbGncuhME8Qj+Nba/SqSzFA+wq3fsbQUtt4WVBRhQKuYLZM6A4Dwlm3e0BtoeGHYlJ G0pFJSWJceSy2/+sX0DShf1D9+AhG/GKjh3pas7OrH3mZ2vqljxS2b5xG0d3Z87dJFOHFWbDXxC O/jE8oUPaV7RCNaiLrRPzb1euWmE8PCDpV1P9akpPZzQ== X-Received: by 2002:a17:90b:6c7:b0:313:1a8c:c2c6 with SMTP id 98e67ed59e1d1-313a1695527mr4627775a91.16.1749564214941; Tue, 10 Jun 2025 07:03:34 -0700 (PDT) MIME-Version: 1.0 References: <195051b7c393b9a28727e87647ac002b@dtrt.org> In-Reply-To: <195051b7c393b9a28727e87647ac002b@dtrt.org> From: "James O'Beirne" Date: Tue, 10 Jun 2025 10:03:23 -0400 X-Gm-Features: AX0GCFtepNiDyGkhU4uLvX4MshrSaKmRdC1nlwHiAkgMlukYZg1o5bULn3mJvFo Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: "David A. Harding" Cc: Andrew Poelstra , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000008b1be5063738293c" X-Original-Sender: james.obeirne@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=X1MoC5Mv; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) smtp.mailfrom=james.obeirne@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000008b1be5063738293c Content-Type: text/plain; charset="UTF-8" Hi Dave, > Why do you think nobody in Core wants to engage at all with consensus > changes (or, at least, specifically the proposals for CTV & CSFS)? For evidence of this, we need look no further than what the regulars of the project themselves are saying. Mike Schmidt published the results of the 2024 year-end Core contributors survey, and the aggregated answers to "goals/priorities for 2025" were (https://archive.is/M8bln): > - Cluster mempool completion and deployment +9 > - Enhanced wallet functionality +9 > - Testing infrastructure improvements +8 > - Security hardening initiatives +2 > - P2P layer improvements +2 > - Build system modernization +1 The "highlights from 2024" were also revealing (https://archive.is/YNtcP). On both lists, questions of script functionality or softforks are nowhere to be found, and this is consistent with my personal experience in the project. Another fact ready at hand is that while Core participants have dished out a lot of soft, negative feedback about various proposals, or put forth lofty posts about proposals of their own with no code (e.g. GSR, TLUV), they have written no code toward any of the workable proposals under consideration. The single exception to this is instagibbs, who has generated (valuable) code contributions toward VAULT, APO, and CSFS. All prototyping and proposal construction have been done almost exclusively outside of Core for the last 5 years. --- More anecdotally, back when I was a regular (<2024) and casually talked with some of the maintainers privately in Signal, there was open ridicule for developers (myself included) who would open pull requests related to precursors for possible softforks. As of just a few months ago, in a private Core signal group Antoine Poinsot joked (presumably?) that if contributors simply let the recent CHECKTEMPLATEVERIFY pull request[0] go unmoderated for a week, the repo could close it on grounds of spam. [0]: https://github.com/bitcoin/bitcoin/pull/31989 The message verbatim reads: > Antoine Poinsot: At this point we could even just suspend moderation, > all mute this thread, come back to the firehose in a week and have > enough ground to close the PR. Most attendees from the last CoreDev event should be able to attest to the faithfulness of this transcript. This instance, in conjunction with the fact that Poinsot is probably the most active Core regular (of 2 or 3) actively engaged in covenants discussions now, is not grounds for optimism for me personally. This is all to say nothing of the reception that Jeremy Rubin was given by Core regulars during 2020-2024. Project internals aside, the plain fact is that despite changes that have been stable for many years and significant community support, the Core project does not feel meaningfully closer to merging even precurors (e.g. regtest-only implementation) to improvements in script functionality today than it did 3 years ago. The more senior contributors in Core used to swap emails about graftroot and APO (circa 2018), but now the major output from the project seems to concern itself with policy, mempool design, performance optimization, build systems -- areas that are much more permanently malleable and (while important) are ultimately less impactful than consensus changes. >From the standpoint of an informed outsider, it matters not so much *why* there hasn't been progress, but simply that there hasn't been. It doesn't really matter where the blame for this lays. What does matter is addressing it. In my view, clearly broadcasting a widespread desire among technical stakeholders to see a shift in focus on the part of the de facto monopoly project seems like a necessary step for "outsiders" of the project who are concerned about the lack of progress. > The usual purpose of an open letter is to generate public pressure > against the target (otherwise, if you didn't want to generate public > pressure, you would send a private letter). I think there's somewhat of an excluded middle here. While there could be many reasons for this letter, I would guess that one of the most widely shared among the co-signers is that a public letter of this sort creates the opportunity for a technical Schelling point around the proposal. It demonstrates publicly and in one place that there is considerable support among the technical bitcoin community, and it creates a single "working draft" that can be built around. Many of the signers are builders capable of evaluating the proposals, but don't necessarily have the time to opine on Delving threads or write prototypes because they are, well, building things for actual end use. This letter gives them a substrate to express an informed technical view without having to construct from whole cloth a way to do that. As we all know this takes time and is, in the case of bitcoin, fraught with social peril. So one of the core functions of the letter is as a single way that engineers can demonstrate a unified agreement on a plausible next step, and the letter exists as a public artifact of that consensus. My own thinking was that such a unified statement would be a valuable signal for Core contributors, indicating that a lot of the ecosystem is serious about these changes. This creates a kind of "pressure" perhaps, but it's the same kind of "pressure" that is created when consumers demonstrate to a company that there's demand for a product. The letter serves a few functions, but this optimistic one is likely the most widely shared. All that said, one of my personal goals in the letter, not shared by all co-signers but likely many, is to clearly indicate dissatisfaction with the observable status quo as of the last few years. A few people who have suggested "if that's the case, instead of a letter why not just release an activation client?" I think we all know how that would have been received. This letter is a less drastic move that both unambiguously signals dissatisfaction but stops short of acting rashly and ineffectively. Warm regards, James -- 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 visit https://groups.google.com/d/msgid/bitcoindev/CAPfvXf%2B0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA%40mail.gmail.com. --0000000000008b1be5063738293c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

> Why do you think nob= ody in Core wants to engage at all with consensus
> changes (or, at l= east, specifically the proposals for CTV & CSFS)?

For evidence o= f this, we need look no further than what the regulars of
the project th= emselves are saying. Mike Schmidt published the results of
the 2024 year= -end Core contributors survey, and the aggregated answers
to "goals/priorities for 2025" were (https://archive.is/M8bln):

> - Cluster mempool = completion and deployment +9
> - Enhanced wallet functionality +9
= > - Testing infrastructure improvements +8
> - Security hardening = initiatives +2
> - P2P layer improvements +2
> - Build system m= odernization +1

The "highlights from 2024" were also revea= ling
(https://archive.is/YNtcP)= . On both lists, questions of script
functionality or softforks are nowh= ere to be found, and this is
consistent with my personal experience in t= he project.

Another fact ready at hand is that while Core participan= ts have dished
out a lot of soft, negative feedback about various propos= als, or put
forth lofty posts about proposals of their own with no code = (e.g. GSR, TLUV),
they have written no code toward any of the workable p= roposals under
consideration. The single exception to this is instagibbs= , who has
generated (valuable) code contributions toward VAULT, APO, and= CSFS.

All prototyping and proposal construction have been done almo= st
exclusively outside of Core for the last 5 years.

---

M= ore anecdotally, back when I was a regular (<2024) and casually talked
with some of the maintainers privately in Signal, ther= e was open ridicule for
developers (myself included) who would open pull= requests related to
precursors for possible softforks.

As of jus= t a few months ago, in a private Core signal group Antoine
Poinsot joked= (presumably?) that if contributors simply let the recent
CHECKTEMPLATEV= ERIFY pull request[0] go unmoderated for a
week, the repo could close it= on grounds of spam.

[0]: https://github.com/bitcoin/bitcoin/pull/31989

T= he message verbatim reads:

> Antoine Poinsot: At this point we co= uld even just suspend moderation,
> all mute this thread, come back t= o the firehose in a week and have
> enough ground to close the PR.
Most attendees from the last CoreDev event should be able to attest to= the
faithfulness of this transcript.

This instance, in conjuncti= on with the fact that Poinsot is probably the
most active Core regular (= of 2 or 3) actively engaged in covenants
discussions now, is not grounds= for optimism for me personally.

This is all to say nothing of the r= eception that Jeremy Rubin was given
by Core regulars during 2020-2024.<= br>
Project internals aside, the plain fact is that despite changes that=
have been stable for many years and significant community support, the<= br>Core project does not feel meaningfully closer to merging even precurors=
(e.g. regtest-only implementation) to improvements in script
functio= nality today than it did 3 years ago.=C2=A0

The more senior contributors in Core used to swap emails = about
graftroot and APO (circa 2018), but now the major output from the<= br>project seems to concern itself with policy, mempool design, performance=
optimization, build systems -- areas that are much more permanently
= malleable and (while important) are ultimately less impactful than
conse= nsus changes.

From the standpoint of an informed outsider, it matter= s not so much
*why* there hasn't been progress, but simply that ther= e hasn't been.

It doesn't really matter where the blame for = this lays. What
does matter is addressing it. In my view, clearly broadc= asting a
widespread desire among technical stakeholders to see a shift i= n focus
on the part of the de facto monopoly project seems like a necess= ary step
for "outsiders" of the project who are concerned abou= t the lack of
progress.


> The usual purpose of an open let= ter is to generate public pressure
> against the target (otherwise, i= f you didn't want to generate public
> pressure, you would send a= private letter). =C2=A0

I think there's somewhat of an exclude= d middle here.

While there could be many reasons for this letter, I = would guess that
one of the most widely shared among the co-signers is t= hat a public
letter of this sort creates the opportunity for a technical= Schelling
point around the proposal. It demonstrates publicly and in on= e place
that there is considerable support among the technical bitcoincommunity, and it creates a single "working draft" that can be = built
around.

Many of the signers are builders capable of evaluat= ing the proposals,
but don't necessarily have the time to opine on D= elving threads or write
prototypes because they are, well, building thin= gs for actual end use.

This letter gives them a substrate to express= an informed technical view
without having to construct from whole cloth= a way to do that. As we all
know this takes time and is, in the case of= bitcoin, fraught with social
peril.

So one of the core functions= of the letter is as a single way that
engineers can demonstrate a unifi= ed agreement on a plausible
next step, and the letter exists as a public= artifact of that consensus.
My own thinking was that such a unified sta= tement would be a valuable
signal for Core contributors, indicating that= a lot of the ecosystem is
serious about these changes. This creates a k= ind of "pressure" perhaps,
but it's the same kind of &quo= t;pressure" that is created when consumers
demonstrate to a company= that there's demand for a product.

The letter serves a few func= tions, but this optimistic one is
likely the most widely shared.

= All that said, one of my personal goals in the letter, not shared by allco-signers but likely many, is to clearly indicate dissatisfaction withthe observable status quo as of the last few years.

A few people wh= o have suggested "if that's the case, instead of a letter
why n= ot just release an activation client?" I think we all know how thatwould have been received. This letter is a less drastic move that both
= unambiguously signals dissatisfaction but stops short of acting rashly
a= nd ineffectively.

Warm regards,
James

--
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 visit https://groups.google.com/d/= msgid/bitcoindev/CAPfvXf%2B0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA%40ma= il.gmail.com.
--0000000000008b1be5063738293c--