From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Nov 2025 13:58:55 -0800 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHqxR-0005Q3-OL for bitcoindev@gnusha.org; Sat, 08 Nov 2025 13:58:55 -0800 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-4503d40ed91sf415738b6e.0 for ; Sat, 08 Nov 2025 13:58:53 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762639127; cv=pass; d=google.com; s=arc-20240605; b=KSvztJeDmezV1o51losI+o5yoCvtMnucnxz3pQ0eamMsbumDBAUZ/tzGolKBLxRxWY sLoE7CDAIFGuG9kjM65CuKIdzlVyjfX2ygiL2TNE1APGShbC0ditlu/byAFgDcLcVek7 DhkMzlzBZs5fpfeGUx/w2MLhwaWH+xjbrQi6/3OPYLOT5TPdUXbNDmezgJru48PP5gTK 5rOBDOyP4p7xgRrAMzNqNyb++GDPlXz6yUmFlPaCI1J92EdKgoFIsTrcKCczk9M9PCcY UWnVD+gQWb0lZ28XVLXcm3yUZniYUQ/dVW2ssiImULtgmdVRQUsEzCkyo6VsrbK3DaWe O36A== 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=HsDf7RBwQwGGYXvxdrcx7L1p5RmIW6BzQZ3zOIhu3B4=; fh=UHKXpwyYhz5k7muT1dkgyWrJUTNXCN4LtXgDeNpV7dk=; b=VaAJor6kGP9QMiwv8LlYCI5qiymcAbkADnL/NO9oAAiZPg2Hn7b2a1eKDhS/hLAukh cO69M6Gx26TU0gc2RxMMs9ag5Hsfoxx8VBTPMbsAr8lsU5T11wN+fHSRPfhdHGlO0/xR 8W/5BjS/lEjRNpMBqDPHQzfkHySbQGhr2xh+1tIzdX+r8ev3QFWj0SL1fbP/B1aQfMFk iiekzB0i2On0HoUhfAwJ/vSQsiCDBKX9fpMm+JdgRPPtz7/GW8ldIJNgCIBKZaJStqrB Hxhi5kw77sJYv9ftgtYEk0+zFwsb9ZnaXiNCSJpxo2jCa0i9BjzehR3dWJa+KkRz8kIJ VYgg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YZp9hJuE; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=gmaxwell@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=1762639127; x=1763243927; 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=HsDf7RBwQwGGYXvxdrcx7L1p5RmIW6BzQZ3zOIhu3B4=; b=j8PFsD5hV4n62aXJXkeG8ZT4/DHg5E2KiRhyQSuOg4ymQiD32Bb2Vh26+tYcMaGoGo ChsSqVZEAVMEacWn9OujBhEuyGQzN22nNNWJj6gjgzm1RkpUmDyuucVCXcu8e7uSDSr1 JfACpb/o85XQwK94qBLu0QPXhHsgO6wZf8fpz/JLwcKJWHVnmP516cPU6IKXQXwJIWys y3+Iode6DZm5pnYvvmaUmvD+B9LtiOhlIBsITDOR7NWGseUyuvGiVbCkXWGaQ9s395U+ IgCSjyYep1m+Aw41QQt7d12Gw9+l7YaRf+P52O+Puf+HT2VkeYqS+tF452JS6ADWhWBD bz3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762639127; x=1763243927; 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=HsDf7RBwQwGGYXvxdrcx7L1p5RmIW6BzQZ3zOIhu3B4=; b=bkfhV6etOrsGGeKM8B/O8S03spN+S4iEHT7vEDPriiw4zOLaB4WucRJLWo2ci8aeyw CHQwnzKPQZ0ZXyc0KoizP0pQzdenpwRXGr0ObqYF6u1/DvfFC+vZlFY4Ty8WuHQSyvkA 5WopwzkUUU9bCJ7NIMwrJpnWB3VPk273iPciJ0Yd2HQq8RtxxB3wL5FrdtEGNVHvozZz 600NQXLGq/tKt1UWAEimAieTl02A4DQ6tnLGd3PR2ytA4FJzf4DkxR11Pf62OzzHP7jS dWtxGmOqoBzzt8x+nnev8tpR555u47UmIKqqCv2YJd2WaNI8Yp1kQPX3cBzK9YgeYIF6 EExA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762639127; x=1763243927; 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-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=HsDf7RBwQwGGYXvxdrcx7L1p5RmIW6BzQZ3zOIhu3B4=; b=WAT1+1rIVuVCo/CJen2f/bKS586EOVl8Nlfi1sag95J+QTP1owUD1En9zsc7Y7s9oH gkfjmOZf072mmEboeu60AyS1Gji8HqY7qp8rC37O7YMcgU/0/mRgUIKgxggDpIFFWCh7 SnrUaqrNcFr5Ap0rUuEiFYtXoqRXHkaidRxw0tHN6CKpxpRaWTBY1pPFjRS5n/5V//aO x9uQemYEXzLuJ6pRhfgfTE6VsoJKOVUUX2EscsdlL59/c3BZVSEiA5VHZkIB3IKVYDX2 WZNZmtBaO/+7QzrzILfYesHhkdd9BFvJk58CSKzsQ1Aj7f4CzPX8cuSlFsHmbSrpCPl3 X93w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXtQcZGfk2mhyHghCsc03KoZkgLi0wOX3EsAb6QyANYFQvQjU/T+uVdOf+Y+auRCPfQSx4f6Z6XmN28@gnusha.org X-Gm-Message-State: AOJu0YxCnvnhrz8aOy1O/hAuTzIV267aAXOIhMf6sYv4PnL/4BSqZ322 8Q6SS9pAFeYIr4rF/xPxcJoz11J1r4aE+aJnO2uVJg9yf7w81T43k+zq X-Google-Smtp-Source: AGHT+IE0L5jZTodrUKyZuPGMmSqx1ZVV3ygz8Vlb38Tg0NUVTs33VzJ0QZyK5Q6/hIHGgYWdXVBifA== X-Received: by 2002:a05:6808:21a6:b0:450:5f:7941 with SMTP id 5614622812f47-4502a38938cmr1940981b6e.61.1762639127081; Sat, 08 Nov 2025 13:58:47 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YYFOG6q+Zl2BtUbFqLE9v0vyp0SalpZ4xcnEiZyXHIOg==" Received: by 2002:a05:6871:8a3:b0:3d6:eb45:2889 with SMTP id 586e51a60fabf-3e2f58803ffls2113907fac.1.-pod-prod-05-us; Sat, 08 Nov 2025 13:58:43 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXDe9qw+REsyhGONY5FJ/qrKCGw/raUAB3Occ52+0HtvphT36R/PWa+m0Jz6k37+zwUEk7WnVea68kh@googlegroups.com X-Received: by 2002:a05:6808:190f:b0:44f:6ab9:4aee with SMTP id 5614622812f47-4502a38ae6cmr1692616b6e.63.1762639123363; Sat, 08 Nov 2025 13:58:43 -0800 (PST) Received: by 2002:a05:620a:5e1a:b0:892:e292:65ef with SMTP id af79cd13be357-8b22191f9a0ms85a; Sat, 8 Nov 2025 13:40:03 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVLO6tZkOdwXjy9u6uVA+Y8dwacvYLjZruZaC+iSpWSFL8KnbzhDCPMxN69VIQ9XKELRb2Pk2h+02LG@googlegroups.com X-Received: by 2002:ad4:5b8e:0:b0:87c:20b5:6685 with SMTP id 6a1803df08f44-882386f8011mr49975046d6.55.1762638002081; Sat, 08 Nov 2025 13:40:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762638002; cv=none; d=google.com; s=arc-20240605; b=cYrY+3jeaNRIaDIreDHgxL1131y/mu4CjtNUCCuvtNTtvJCqM/vXcPEyYr/QMKYuF/ l+kk8lI6r9mejDRy58m512hY7wU0+rru3gGzDuhhKj0KgNvAi76SIBfcF02y8Vfe6rjd CwlHYH5M86RWsnRjUM4y2PIucndicCSYhOvmUwFVmFcUtZP7pzipknNkWeahUalgknh1 srz1KxYFIeNKLJkJqHsmDpSXZ1CBnCJeHfP5PL4rnNTnu8gaDta7cklztWZZiEi59cGU LqasaDoRklSjvo83BG8M6w1Dlv6NBmIzhYr71JM2QcVGOVPG8+M1kzpH7VKxNNOk6hPW kHSg== 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=YgOEk2WOV2LHQ9dKRwLZzWjJfqD/JdryQDV7/W8WMlE=; fh=+CIrZrIxB9j7wGROJFPt1O8t2lYH02W7JmjXv4ZHyc4=; b=MSXQTyZ99zG0fy8LCFvbggz8UZIRTPUjZiVGdf//mOsxlXekX8YNoWOoGscK8piIYf eI1/Rl4moeTJSQjueHhq76R7Tj7ZnW6c9ytuHmh0VaalPCzqhUBGdRNseCkLfakWbHS+ 76BBbJl/1FWu+I20JLhPV/07Vw6qAicYE+78octcSuseM9Em2+8T9fsuh80MNC1ETQqI 0gbnIgUUwfOSljr6xtcGL8JZF69xR5TuzCNiaNTc6qphNwZY9Q5b+Sp9pFAg+QbHB2QS rfgQA8sa0QqOvF658Qb8BKn4nHP4GSV+R3w3jPhhyj9k8D0I3T1R95o1SrwchSznXn3Y kgQQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YZp9hJuE; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com. [2607:f8b0:4864:20::630]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-88238b8345fsi537806d6.9.2025.11.08.13.40.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Nov 2025 13:40:02 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) client-ip=2607:f8b0:4864:20::630; Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-28a5b8b12a1so16489205ad.0 for ; Sat, 08 Nov 2025 13:40:02 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCX+Q3kpzhlRLBLxLGgwSXlAYMxY0sgWmeUm81E0vsLPu8wtMczPZziPGT9TptKwcssC4ZkOg31008oq@googlegroups.com X-Gm-Gg: ASbGncuw8e7oUAEbYLQ8E2F4Qgi+KJ63FXVjq8x939DGpoBR4wr9UK8An8aqny8uN7T 4iCHRbrNDJPoGymte91kqhawkQh8rXlnICDF8pY/z7+/ICzairUINsO1uPJ9+n3q7c6/zvewGpR qjstdHffp4R3Ln9apQ3mMN/zixe5ofZHZ3Qtn0MT4OH9u3wu0qwNSnKcKrkzDPRsunWsE7GJlES ioEmTnICcO1Hx5xjnFLOWNK5nruclw3Q9Z3fo7j0bXgAG7linnWT0a71RDPAWXC819Yujfa9RPf 9YSGWdFGzKevxRSzwJYeSWcSfe7YRh8UqUBE93vPLLmuGKNQUUc= X-Received: by 2002:a17:903:40c9:b0:295:275d:21d8 with SMTP id d9443c01a7336-297e4bff754mr46071175ad.0.1762638001147; Sat, 08 Nov 2025 13:40:01 -0800 (PST) MIME-Version: 1.0 References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> In-Reply-To: From: Greg Maxwell Date: Sat, 8 Nov 2025 21:39:49 +0000 X-Gm-Features: AWmQ_bmGjOPLDcLQh6mAc03-n0YRPzsRyXPjohaJAAFoI4mUqIOfYoZ8COQuB_A Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork To: dathonohm@proton.me Cc: Erik Aronesty , Antoine Riard , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000ed137d06431c239a" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YZp9hJuE; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --000000000000ed137d06431c239a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's not speculative-- nlocktime is a day one feature which *is* used in Bitcoin. Sure someone could footgun themselves by intentionally using a transaction field which is expressly intended for forward compatibility and get themselves burned-- but they'd have to be trying, not just doing a boring and unconcerning thing because those fields don't do anything so the only reason to use them would be an outright error or intentionally trying to break themselves. This is also not a new concern being raised for your proposal, every softfork post P2SH has been analyzed under this lens so it's quite concerning to see the proposal here simply ignore the concern. Even the intentional forward compat features have caused some lack of comfort in the past in this respect, which is why tapscript OP_SUCCESS works the way it does: so that any script that prematurely uses a 'success' opcode would be inherently completely insecure-- an important improvement in upgradability that your proposal permanently destroys without you even understanding why it existed in the first place. And indeed I haven't read a new version because your prior message provided no reference to it-- it said you were requested to update the list and then you only provided a summary. I was responding to the summary. Now looking at it, I see that you are still limiting scriptpubkey sizes strictly-- this will absolutely confiscate funds as was pointed out and not responded to even before your proposal. (because luke-jr proposed just that limit first-- actually a more relaxed version, then simply dishonestly insisted there was no opposition to it, even though opposition was immediately raised on the list). I think your proposal continues to have no serious prospect of activation, and should it activate in any form it will just be forked against and its authors will likely find themselves mired in litigation by people harmed by it. I think you'll find that almost every significant bitcoin developer will stand against such a change and will not work on a fork that adopts them, I also doubt the market would value your fork with such significant limitations very highly. On Sat, Nov 8, 2025 at 9:02=E2=80=AFPM wrote: > Hi Greg - > > >That doesn't address the confiscation problem (although any reduction in > the restriction does reduce it), as there likely exist chains of not yet > confirmed (and potentially timelocked) transactions that involve violatio= ns > of this rule. Those would appear to the network to be outputs created at = a > later time, although they really weren't. It's unclear to me why you > haven't yet understood this point. > > While I completely agree that "confiscation" is a precedent we must avoid > setting, I think my proposal neither confiscates funds nor sets a bad > precedent, as it takes pains to avoid causing problems for all known use > cases. I don't think it is reasonable never to create problems for all > *unknown* use cases, as this would necessarily imply permanent > ossification. > > To illustrate the point: it is possible to design off-chain systems that > "use" any given feature of the Bitcoin protocol, including, for example, > OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfor= k > proposal that redefines the OP_NOP. That is, anyone could intentionally > lock funds into a pathological construction in order to obstruct any give= n > softfork. > > Thus, if taken to the extreme, the argument that no one should ever have > funds "confiscated", or even temporarily frozen, means that we can never > upgrade Bitcoin again. So, in the interest of avoiding permanent > ossification, it seems wise for us to compromise somewhere in the middle.= I > think my proposal strikes a good balance. > > Of course, if people are reporting that there are known, non-pathological > use cases with significant funds locked into pre-signed transactions, the= n > of course I will modify the proposal to accommodate them. > > >Another issue raised which you have not mentioned is that prior to you > making this proposal I received minutes from a meeting which noted that > Ocean Mining was the true author of this proposal and would be presenting > it under a false identity in order to conceal their involvement. Will you > be correcting the record on the true authorship of this work and on whose > behalf its being performed? > > It sounds like you have fallen victim to some false rumors. > > I already attempted to correct the record on this, both here on this > mailing list and on the BIP PR, but both times my messages were suppresse= d > by moderators. > > I humbly request that moderators let the public see my response this time= , > otherwise I'm not sure how the record will ever be corrected: > > Though I am in direct communication with some Ocean employees (and the BI= P > was originally drafted by one of them), *I am not affiliated with Ocean > in any way*. I am just a Bitcoin dev who is concerned about the > implications of Core 30 having been released and gaining adoption. > > *I am acting solely on my own behalf and on the behalf of the Bitcoin > community*, because I and most Bitcoiners I know are concerned about > Bitcoin's future if it embraces data storage as a supported use case. > > This proposal is also a significant departure from the original BIP draft= . > > >Would you then agree that this proposal will fail at its stated purpose, > particularly with respect to concerns about potentially 'unlawful' materi= al? > > No, I think this proposal is the best way to achieve its stated purpose, > which is to reject the standardization of data storage as a supported use > case, at the consensus level. > > It sounds like you haven't read the new version of the BIP, nor my summar= y > above. I attached the document in my previous email message if you are > interested. It removes all references to legal risks. > > For those who prefer viewing the proposal in a browser, I have pushed a > copy of it to a non-PR branch, since the PR is still locked: > https://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.m= ediawiki > > >As that concern as expressed has a threshold of "any at all" and could > just as well be performed via a "less commonly abused" path? Would you al= so > agree the same for essentially all other forms-- that they'd simply made = a > few line of code changes and then evade these restrictions? > > Again, this is no longer applicable to the proposal. The new draft makes > significant changes. > > >In light of that, how would the very real and significant reductions in > intentional functionality (such as efficient "few of dozens" multisigs or > other such constructs) be justified? How could the confiscation risk be > justified? How could the deployment costs be justified? How could the > "policy risk" be justified? (E.g. that bitcoin could be driven or forced = in > to an endless sequences of 'update' blocking actions, each carrying its o= wn > risk and disruptions) > > I don't see this softfork as an "update-blocking action"; on the contrary= , > I see it as an update-enabling one. As I stated previously, attempting to > never disrupt any use cases, no matter how pathological, is the fastest > path to ossification. > > Indeed, Bitcoin has failed to make any consensus upgrades at all since > Taproot in 2021. The community has been going in circles now for two year= s > because of pathological use cases introduced by that fork, and this > proposal allows Bitcoiners to say "enough is enough", re-affirm that > Bitcoin is *money* rather than *data storage* by disabling all the most > popular methods of data abuse, and move on to more exciting things. We > could have new upgrades in one year if Bitcoiners focus on building them > over the following months. > > I honestly don't see a better way out of this morass, but please let me > know your reasoning if you disagree. Inaction is not going to solve this. > > >I don't think your suggested revisions will move your proposal off from > having essentially zero risk of adoption, and if it were adopted (which I > think is unlikely) > > I don't see much reason *not* to adopt it, besides fear of softforks in > general, but I'm listening. > > >I think it's a certainty that there would be a countering fork to > continue a Bitcoin without these poorly justified (even essentially > useless) restrictions. > > I don't see why anyone in their right mind would choose to bet on the old > fork where Bitcoin is filled with spam and confused about whether it migh= t > want to just be a database, over the new one where Bitcoin is money. > > Best regards, > > Dathon > On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell < > gmaxwell@gmail.com> wrote: > > On Sat, Nov 8, 2025 at 12:58=E2=80=AFAM dathonohm via Bitcoin Development= Mailing > List wrote: > >> >> 1. "Funds confiscation": due to the presence of UTXOs that would be >> made temporarily unspendable by this proposal, commenters were concer= ned >> that this would set a precedent of "confiscation". This new draft res= olves >> this concern by adding a UTXO height check to make sure *only UTXOs >> that are created while the softfork is active will be made temporaril= y >> unspendable*. The "OP_IF in Tapscript" and "257-byte control block >> limit" were the two main proposed rule changes that caused concern he= re. >> >> > That doesn't address the confiscation problem (although any reduction in > the restriction does reduce it), as there likely exist chains of not yet > confirmed (and potentially timelocked) transactions that involve violatio= ns > of this rule. Those would appear to the network to be outputs created at = a > later time, although they really weren't. It's unclear to me why you > haven't yet understood this point. > > I don't think this concern was in any way limited to the control block of > op_if components either, essentially every aspect of the proposal has > confiscation issues. > > Another issue raised which you have not mentioned is that prior to you > making this proposal I received minutes from a meeting which noted that > Ocean Mining was the true author of this proposal and would be presenting > it under a false identity in order to conceal their involvement. Will you > be correcting the record on the true authorship of this work and on whose > behalf its being performed? > > > "This doesn't block all possible methods of arbitrary data insertion": > This was already addressed in the previous draft, but to reiterate: this > proposal's goal is not to block *all* methods of arbitary data insertion, > just the most commonly abused ones. > > Would you then agree that this proposal will fail at its stated purpose, > particularly with respect to concerns about potentially 'unlawful' > material? As that concern as expressed has a threshold of "any at all" an= d > could just as well be performed via a "less commonly abused" path? Would > you also agree the same for essentially all other forms-- that they'd > simply made a few line of code changes and then evade these restrictions? > > In light of that, how would the very real and significant reductions in > intentional functionality (such as efficient "few of dozens" multisigs or > other such constructs) be justified? How could the confiscation risk be > justified? How could the deployment costs be justified? How could the > "policy risk" be justified? (E.g. that bitcoin could be driven or forced = in > to an endless sequences of 'update' blocking actions, each carrying its o= wn > risk and disruptions) > > Although your description of changes is vague and it's not possible to > tell for sure without seeing the actual updates-- I don't think your > suggested revisions will move your proposal off from having essentially > zero risk of adoption, and if it were adopted (which I think is unlikely)= I > think it's a certainty that there would be a countering fork to continue = a > Bitcoin without these poorly justified (even essentially useless) > restrictions. > > > > > > -- > 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/CAAS2fgQy%2BqiRv%3DwGHB5_5Hg= xmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com > . > > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%40mail.gmail.com. --000000000000ed137d06431c239a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's not speculative-- nlocktime is a day one fea= ture which *is* used in Bitcoin.

Sure someone coul= d footgun themselves by intentionally using a transaction field which is ex= pressly intended for forward compatibility=C2=A0and get themselves burned--= but they'd have to be trying, not just doing a boring and unconcerning= thing because those fields don't do anything so the only reason to use= them would be an outright error or intentionally trying to break themselve= s.

This is also not a new concern being raise= d for your proposal,=20 every softfork post P2SH has been analyzed under this lens so it's quit= e concerning to see the proposal here simply ignore the concern.

Even the intentional forward compat features have caused some lack= of comfort in the past in this respect, which is why tapscript=C2=A0OP_SUC= CESS works the way it does:=C2=A0 so that any script that prematurely uses = a 'success' opcode would be inherently completely insecure-- an imp= ortant improvement in upgradability that your proposal permanently destroys= without you even understanding why it existed in the first place.

And indeed I haven't read a new version because your p= rior message provided no reference to it-- it said you were requested to up= date the list and then you only provided a summary. I was responding to the= summary.

Now looking at it, I see that you are st= ill limiting scriptpubkey sizes strictly-- this will absolutely=C2=A0confis= cate funds as was pointed out and not responded to even before your proposa= l. (because luke-jr proposed just that limit first-- actually a more relaxe= d version, then simply dishonestly insisted there was no opposition to it, = even though opposition was immediately raised on the list).

<= /div>
I think your proposal continues to have no serious prospect of ac= tivation, and should it activate in any form it will just be forked against= and its authors will likely find themselves mired in litigation by people = harmed by it.=C2=A0 I think you'll find that almost every significant b= itcoin developer will stand against such a change and will not work on a fo= rk that adopts them, I also doubt the market would value your fork with suc= h significant limitations very highly.


On Sat, Nov 8, 2= 025 at 9:02=E2=80=AFPM <dathonohm@proton.me> wrote:
Hi Greg -

>That doesn't address the confiscation problem (although any= reduction in the restriction does reduce it), as there likely exist chains= of not yet confirmed (and potentially timelocked) transactions that involv= e violations of this rule. Those would appear to the network to be outputs= created at a later time, although they really weren't. It's uncle= ar to me why you haven't yet understood this point.

While I c= ompletely agree that "confiscation" is a precedent we must avoid = setting, I think my proposal neither confiscates funds nor sets a bad prece= dent, as it takes pains to avoid causing problems for all known use cases. = I don't think it is reasonable never to create problems for all unkn= own use cases, as this would necessarily imply permanent ossification.<= /div>

To illustrate the point: it is possible to design off-chain syste= ms that "use" any given feature of the Bitcoin protocol, includin= g, for example, OP_NOPs. Funds locked in such UTXOs would be "confisca= ted" by the softfork proposal that redefines the OP_NOP. That is, anyo= ne could intentionally lock funds into a pathological construction in order= to obstruct any given softfork.
Thus, if taken to the extreme, t= he argument that no one should ever have funds "confiscated", or = even temporarily frozen, means that=C2=A0we can never upgrade Bitcoin again= . So, in the interest of avoiding permanent ossification, it seems wise for= us to compromise somewhere in the middle. I think my proposal strikes a go= od balance.

Of course, if people are reporting that there are kno= wn, non-pathological use cases with significant funds locked into pre-signe= d transactions, then of course I will modify the proposal to accommodate th= em.

>Another issue raised which you have not mentioned is that= prior to you making this proposal I received minutes from a meeting which = noted that Ocean Mining was the true author of this proposal and would be p= resenting it under a false identity in order to conceal their involvement. = Will you be correcting the record on the true authorship of this work and = on whose behalf its being performed?
It sounds like you have fall= en victim to some false rumors.
I already attempted to correct th= e record on this, both here on this mailing list and on the BIP PR, but bot= h times my messages were suppressed by moderators.

I humbly reque= st that moderators let the public see my response this time, otherwise I= 9;m not sure how the record will ever be corrected:

Though I am i= n direct communication with some Ocean employees (and the BIP was originall= y drafted by one of them), I am not affiliated with Ocean in any wa= y. I am just a Bitcoin dev who is concerned about the implications= of Core 30 having been released and gaining adoption.

I am ac= ting solely=C2=A0on my own behalf and on the behalf of the Bitcoin communit= y, because I and most Bitcoiners I know are concerned about Bitcoin'= ;s future if it embraces data storage as a supported use case.

Th= is proposal is also a significant departure from the original BIP draft.

>Would you then agree that this proposal will fail at its stated= purpose, particularly with respect to concerns about potentially 'unla= wful' material?

No, I think this proposal is the best way to = achieve its stated purpose, which is to reject the standardization of data = storage as a supported use case, at the consensus level.

It sound= s like you haven't read the new version of the BIP, nor my summary abov= e. I attached the document in my previous email message if you are interest= ed. It removes all references to legal risks.

For those who prefe= r viewing the proposal in a browser, I have pushed a copy of it to a non-PR= branch, since the PR is still locked:=C2=A0https://github.com/dathono= hm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki


Again, this is no longer applicable to the propo= sal. The new draft makes significant changes.

>In light of tha= t, how would the very real and significant reductions in intentional functi= onality (such as efficient "few of dozens" multisigs or other suc= h constructs) be justified? How could the confiscation risk be justified? = How could the deployment costs be justified? How could the "policy ri= sk" be justified? (E.g. that bitcoin could be driven or forced in to a= n endless sequences of 'update' blocking actions, each carrying its= own risk and disruptions)

I don't see this softfork as an &q= uot;update-blocking action"; on the contrary, I see it as an update-en= abling one. As I stated previously, attempting to never disrupt any use cas= es, no matter how pathological, is the fastest path to ossification.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);b= ackground-color:rgb(255,255,255)">
Indeed, Bitcoin has failed to make any consensus upgrades at all since = Taproot in 2021. The community has been going in circles now for two years = because of pathological use cases introduced by that fork, and this proposa= l allows Bitcoiners to say "enough is enough", re-affirm that Bit= coin is money rather than data storage by disabling all the m= ost popular methods of data abuse, and move on to more exciting things. We = could have new upgrades in one year if Bitcoiners focus on building them ov= er the following months.

=
I honestly don't see a better way ou= t of this morass, but please let me know your reasoning if you disagree. In= action is not going to solve this.
=
>I don't think your sug= gested revisions will move your proposal off from having essentially zero r= isk of adoption, and if it were adopted (which I think is unlikely)

I don't see much reason not to adopt it, besides fear of soft= forks in general, but I'm listening.

>I think it's a c= ertainty that there would be a countering fork to continue a Bitcoin withou= t these poorly justified (even essentially useless) restrictions.

I don't see why anyone in their right mind would choose to bet on the = old fork where Bitcoin is filled with spam and confused about whether it mi= ght want to just be a database, over the new one where Bitcoin is money.

Best regards,

Dathon
On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmaxwell@gmail.com>= ; wrote:
On Sat, Nov 8, 2025 at 12:58= =E2=80=AFAM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
    <= li style=3D"list-style-type:"1) "">"Funds confiscation= ": due to the presence of UTXOs that would be made temporarily unspend= able by this proposal, commenters were concerned that this would set a prec= edent of "confiscation". This new draft resolves this concern by = adding a UTXO height check to make sure only UTXOs that are created whil= e the softfork is active will be made temporarily unspendable. The &quo= t;OP_IF in Tapscript" and "257-byte control block limit" wer= e the two main proposed rule changes that caused concern here.<= /ol>

That doesn't address the con= fiscation problem (although any reduction in the restriction does reduce it= ), as there likely exist chains of not yet confirmed (and potentially timel= ocked) transactions that involve violations of this rule. Those would appe= ar to the network to be outputs created at a later time, although they real= ly weren't. It's unclear to me why you haven't yet understood = this point.

I don't think this concern was in = any way limited to the control block of op_if components either, essentiall= y every aspect of the proposal has confiscation issues.

Another issue raised which you have not mentioned is that prior to yo= u making this proposal I received minutes from a meeting which noted that O= cean Mining was the true author of this proposal and would be presenting it= under a false identity in order to conceal their involvement. Will you be= correcting the record on the true authorship of this work and on whose beh= alf its being performed?

> "This doe= sn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block all methods of a= rbitary data insertion, just the most commonly abused ones.

Would you then agree that this proposal= will fail at its stated purpose, particularly with respect to concerns abo= ut potentially 'unlawful' material? As that concern as expressed h= as a threshold of "any at all" and could just as well be performe= d via a "less commonly abused" path? Would you also agree the sa= me for essentially all other forms-- that they'd simply made a few line= of code changes and then evade these restrictions?
=
In light of that, how would the very real and s= ignificant reductions in intentional functionality (such as efficient "= ;few of dozens" multisigs or other such constructs) be justified? How = could the confiscation risk be justified? How could the deployment costs b= e justified? How could the "policy risk" be justified? (E.g. tha= t bitcoin could be driven or forced in to an endless sequences of 'upda= te' blocking actions, each carrying its own risk and disruptions)

Although your description of = changes is vague and it's not possible to tell for sure without seeing = the actual updates-- I don't think your suggested revisions will move y= our proposal off from having essentially zero risk of adoption, and if it w= ere adopted (which I think is unlikely) I think it's a certainty that t= here would be a countering fork to continue a Bitcoin without these poorly = justified (even essentially useless) restrictions.
<= br>




--
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 bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://gr= oups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PX= pd1VbiUFPwATg-g%40mail.gmail.com.

--
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/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%40ma= il.gmail.com.
--000000000000ed137d06431c239a--