From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Nov 2025 09:33:41 -0800 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vIsFP-0008TA-2h for bitcoindev@gnusha.org; Tue, 11 Nov 2025 09:33:41 -0800 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-6569f275184sf1728087eaf.0 for ; Tue, 11 Nov 2025 09:33:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762882413; cv=pass; d=google.com; s=arc-20240605; b=HzbIsLkJ89I+ne7KE5+yn7JW+gV63FUxBOtjZxOTDpKayOn0/RbTXa5EgT0lzYhbG9 Adzlzt7+Ajss65FHPcdFph8FZ+eeJapOuskDCiP+bSoSJrUREaD4nnZRNPQA7anfNzAN DEjpmHqwxuiF216Xne7tUjy6jvGFDTko+ykDgbXZ9AEwjf5MhkzOL1BuwZZwwzN8VZsy IHRQKv/cXI09m8FeL8QXya9tDNp3VdoqMYov8grs+P30AFxL9locQVdP+tzukAVr5hhU 2N4yHU6sJku6prKty152ccn9lzqPvfFIfnhtOdO8ZCQp0cpxK5g5m+JT8kvuuNFs+J4G DnJA== 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=fmNVH0MxktLkphj4r0jurfWYqIcdmCXJ97drr1RKbAI=; fh=RLrysT/cItw/8RYLigoXqahFKGYStIEEuRno/cz2nPI=; b=DfM1vWAM2AJ4NrX0807Fv7t+ArEU1Ui/s3ET3iqs6JP9FBeo8DGLP17XhOp4s7qiJH pv391AKOG3amBvAWfArxxQ+Yz7HMf979PjIDLtJBDC95t0/5JCdCBQnquC9V8FQR36a3 SI9cx3o9nXs92obaQGx6A+PG2pN8XY/GBjgDVLmR5zuzIXuAsY5YqZDZqITYkV/FP+8V a9aKaJvNPFXdPDBsyaDTS2Ld0cxZeDafxuITLbEOAqv1mswpyWYv1SRWorbo8tBDmp3I uVLAVpTIf04zXfwe6hlzu89xjxyime9fy/L8Dzr04dz2AydxKo4F3xWirnwo2Yu+G0iN LaNw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yhyv0ufc; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::536 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=1762882413; x=1763487213; 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=fmNVH0MxktLkphj4r0jurfWYqIcdmCXJ97drr1RKbAI=; b=HGtiezLL1hUyiz/cyBxLCnFy5i323jPoPD6u3Euz7zRPYU46srfZat3HjQTn50eGVq WUzm1ZTTAmJC2mH0DKahhD/2neXg+CcnGAY951xfNwXLV9T1kvp2gVwSfAkxJ4C17/vU cW9pKgoY95eSAIRoUxVSSk3VGKXcXgmVomJKhKbNUqZRIdtXWbpG0AR9uKqZhoC93tE9 GQcU9iXS4RKrnBirWNQIsSO0ILRI0+Jl0yKpBvrGjJNYAKLF+jLcunLDj9UNxE08BYWH o19XENaHXTGut36weBYebX3WIDNBK8vmKRwAmpgB/uvmLpNMoRGkm49DWzTxC1maDC5/ BdOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762882413; x=1763487213; 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=fmNVH0MxktLkphj4r0jurfWYqIcdmCXJ97drr1RKbAI=; b=DQS2o+6kVv67vaLDP73Xlj+/pA/muKYWHYloUQWTt9SEU01DaQbvwB9DTs66vmntzI Ae4hEiDMLpjpSLyUqQ4Mbngw58cZXuDt8jxkSGnBV0AlLnPPo2UCSNFlOPRzMv/sG6w7 NA37NBylKXKEhT/BZJcKITvJlzgO4CRB6wvJPAY0Xr5GftvKbVjtCwKX+PV3XZAcl7IB OR6b3hKw8Xv4HciseW9YCFLoHHhb+PfxIARFcvO0JHO4VminMHT4+AMGeHtB1TJN2Sx0 S9JobED4yPkFEzaOPcFTLtx303xGcU2PchnZCWDD1hthhKTuwcbIimv6yVtyACdZxLDN lGGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762882413; x=1763487213; 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=fmNVH0MxktLkphj4r0jurfWYqIcdmCXJ97drr1RKbAI=; b=bwoDLV2Q/b8cRx7NfP7/AkvkMMdD5DLduBZRsrNX1kTt4x2VBU/59j3PDA1JLIStn0 681DY/dE/g3gxSXVbuF0n5C8xy7QhP/Oa5AIIkGo6VtnkrFy3gJITeEWiEBXDREUEBvi IBDPZrrTEhOjlCifo2gvi7W1i/VDFHjDOk4386odPirQ9EO0gmde9cDPW6/SsJ/vydAB lOEd0nLXxevHz38mOAdA6tcEk81udUToEW8QIaijP4QpnMDvk1tcnxFdPDvz+YG30it0 WFjCmYpuYvAtRCus6GnPZHBwXtDv7BVzbtzqBFsUYgfQ8XDqawcV/yJEljutGYANCWog PkSQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWiG4A9YfmdbS3HFRoVNiUpMOz0t8GfCrlmAQoSSoQUwDXKlKzIMwwZKj9i1idynhMsjp2Tz403aMqF@gnusha.org X-Gm-Message-State: AOJu0YwaBHoOLolFmNHDdNHnZBd/PByamimAXTrsJ0oi53+k8vFKytHO 5nuglUUo8Vxy2/Mid+bh0nPUQVmQh2EngLs5QzLCNokxbhcGW6/m8xkr X-Google-Smtp-Source: AGHT+IGFgb8YwQwOcj9F+uDWnMaf1fBjPaZSNyA91UrxYwdaDAKHx8AXlhzD9RT/jcv8nJZfn0uSMA== X-Received: by 2002:a05:6870:4687:b0:3d4:597:c164 with SMTP id 586e51a60fabf-3e815afaa2emr1988453fac.23.1762882412489; Tue, 11 Nov 2025 09:33:32 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a8B9QLFVMLwXOL/pGjQnYl6knyKivQqkomnrbJDSMWcw==" Received: by 2002:a05:6871:8759:20b0:374:de90:136b with SMTP id 586e51a60fabf-3e83285b557ls7571fac.2.-pod-prod-00-us-canary; Tue, 11 Nov 2025 09:33:28 -0800 (PST) X-Received: by 2002:a05:6808:3c4e:b0:44d:be50:6545 with SMTP id 5614622812f47-45073847754mr74796b6e.21.1762882408247; Tue, 11 Nov 2025 09:33:28 -0800 (PST) Received: by 2002:a05:620a:4d17:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8b28a368575ms85a; Tue, 11 Nov 2025 08:23:59 -0800 (PST) X-Received: by 2002:ad4:5aee:0:b0:882:36ab:ebfe with SMTP id 6a1803df08f44-8825e851f00mr42284216d6.27.1762878238214; Tue, 11 Nov 2025 08:23:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762878238; cv=none; d=google.com; s=arc-20240605; b=Wm0Qja1baU41tY7wm8kTPPm1DNpdbN7LHmIz4TFcasIeWxKUhD3llg3wjtaiz85COw V8opGAdDHflzAVhVtR9atk7IHrVXGum6ap6KAs3QNpDpfxzTmLqHpAI4KQ3a5Qq3FP9C Fqlfr34Y5r/l8sm1Us7mxEd3mR6xRMY8u0AphodqOcKC3jmZ1dYMabAzgZ0hu0kcDJw2 DdudVUADlZyCLCUuMQpP6UcP1FG8j+XoB6yntqj2a18N9hJwvkiACwSqbPR75tMGQ3Ix 6wKKe21IhpomKOoEQNANEegGBdUSvYQD9MHYXHWbyDrW8z3OAGJxl7tixFnetaiMObAu t5gQ== 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=OhebpVqu0o2WNjXQGMTbTwyIjaqq2l3EFcutY1+DETk=; fh=BJca6IWdtpZWVpa9wKCa1MHOUHVYlXizcJ3fji9ePmg=; b=FrySUrvv3tO3Bh1oYAiUSnBWJVtnQ8YKDbSTP07PLuZWClusoI1UpFJnfe37MJAwIA 2AxRzTm/woOtu3kgDUXN6TtAWLmhy7zLIySaGoD48ErGbv7jlc3DMTAEdNfpmtGz/oAr 3QFiD9pex0+laXvactnm5GcE5n8aS9NW6Q5gx+E3h8faLRVDFCq1F/io5gNeVUUmxerU GKAwak+XsQ5lhWgrtq05HnzIqSvG5oxHNAEHVK71t0ZurAtuZe4MiUmcmiYu5E6U17OA +Dly/t5BPJynVH9O+vqu5InowdtKO5qjWMLVvduzFZLs0kNyVpRU7k1Pbszl4aN+6vPL x6wA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yhyv0ufc; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::536 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-pg1-x536.google.com (mail-pg1-x536.google.com. [2607:f8b0:4864:20::536]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8823890951fsi8570676d6.2.2025.11.11.08.23.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Nov 2025 08:23:58 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::536 as permitted sender) client-ip=2607:f8b0:4864:20::536; Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-bbf2c3eccc9so7631a12.0 for ; Tue, 11 Nov 2025 08:23:57 -0800 (PST) X-Gm-Gg: ASbGnctKgO+/m+y6/kcNgNjVtaAaq37RN/ZIV0PBS0gnk5+LFCbyUHu0taqGyVatZlv r1Y9kkvUnda/bnnlcIxx3ffOFdb/haXGU3bQjXN7027Yb+Ux2/nlk/7vOuoeBq1KkdegiOWJzE2 762eQExgS1whXQBKmLdm3O4N//1atX2gQzOyVyy0041ZuYhWGkCTAussuTBxsXgrqxqMm7eAapy u6bd4MRHQj4gPvqSHztrL1zq8RTh9rWCfkId0nxRahpze/BeqUmy3uVyFbl9dGxbL8Y3iVcF4ID PlS3xVMx+di/PTXN1xvBUe2rbfP91cTXhRRM/PNg X-Received: by 2002:a17:902:cf43:b0:290:ad7a:bb50 with SMTP id d9443c01a7336-29840b4b13emr39282205ad.27.1762878237261; Tue, 11 Nov 2025 08:23:57 -0800 (PST) MIME-Version: 1.0 References: <4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY=@proton.me> <86d11552-36d8-46d7-998c-ed6875a5a84bn@googlegroups.com> In-Reply-To: <86d11552-36d8-46d7-998c-ed6875a5a84bn@googlegroups.com> From: Greg Maxwell Date: Tue, 11 Nov 2025 16:23:44 +0000 X-Gm-Features: AWmQ_bkB0YWCbaGkZjaLRBo4WQEDCF3QEXex2MGXBn1G7EajyNQpmk16vAYhFHQ Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork To: Bitcoin Eagle Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000001d4617064354136d" 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=Yhyv0ufc; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::536 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 (/) --0000000000001d4617064354136d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Presigned transactions are quite real and are used by people, e.g. for inheritance so you can allow your inheritors (or you) to recover your coins in the future via a more accessible file, while securing the wallet that can immediately spend to a level that might otherwise cause accidental funds loss. They're more flexible than having to stick a recovery alternative in script and though a relative locktime would be more reliable, unfortunately they can't be set much into the future under current consensus rules. Not everyone is luke-jr whose security practices are to keep a copy of his 'offline' wallet on an online system with a copy of the passphrase for it just stored in a file next to it. Had that file had presigned transactions set a couple years out, he probably wouldn't have turned into an involuntary nocoiner more interested in getting his way that preserving Bitcoin's value and stability and we wouldn't need to debate a proposal that lobotomizes Bitcoin's functionality and will seize users funds just to further his vanity project. Not everyone is eager to go into details about their own assets and security practices, potentially compromising their privacy and safety. -- and likely most impacted people have no idea of the risk it has for them, especially when the schemes author is online outright lying about its properties: https://x.com/LukeDashjr/status/1987267143612703150 (He could debate the degree of confiscation risk,-- though I know for a fact that it's a certainty-- but saying there is *none* is just a toxic lie that should cause us to reject his proposal on the principle that the proposals true creator is outright deceiving the public about it) On Tue, Nov 11, 2025 at 8:28=E2=80=AFAM 'Bitcoin Eagle' via Bitcoin Develop= ment Mailing List wrote: > "Okay, if you or anyone can show me an example of a "boring and > unconcerning thing" that involves pre-signed transactions that use > deep/OP_IF-containing Taptrees and timelocks, which predates the original > softfork proposal, I will be happy to update the BIP. Saying "someone mig= ht > be doing this" is simply frivolous obstructionism which, again, could be > used to stop any attempt to change the consensus rules." > > If we skip the pontential strawman of presigned transaction let's describ= e > realistic problem. > > 1. You have sensible multisig wallet which breaks one of the OP_IF or > merklepath restrictions. And you don't even know how it works inside. > 2. To avoid confiscation you need to create a new wallet which is > designed in compliance with BIP444. Is there new miniscript compiler > available in time? > 3. Migrate all UTXOs to new wallet > 4. The real risk of confiscation are change addresses. After > activation spending will work thanks to one time whitelist. But it cre= ates > a change which will be new UTXO unspendable > > > On Monday, November 10, 2025 at 6:34:39=E2=80=AFAM UTC+7 dath...@proton.m= e wrote: > >> Hi Greg - >> >> >It's not speculative-- nlocktime is a day one feature which *is* used i= n >> Bitcoin. >> >> Correct, I have not claimed otherwise. >> >> >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 tryi= ng >> to break themselves. >> >> Okay, if you or anyone can show me an example of a "boring and >> unconcerning thing" that involves pre-signed transactions that use >> deep/OP_IF-containing Taptrees and timelocks, which predates the >> original softfork proposal, I will be happy to update the BIP. Saying >> "someone might be doing this" is simply frivolous obstructionism which, >> again, could be used to stop any attempt to change the consensus rules. >> >> >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. >> >> I believe the utility of the strategy of "don't break any use cases, no >> matter how pathological" has finally worn out. The longer we continue do= wn >> this path, the more likely it is that Bitcoin will become *entirely* >> pathological use cases. >> >> Accordingly, this BIP *intentionally* disrupts all of the most harmful >> use cases, because they are making Bitcoin worse money and the problem i= s >> accelerating. But as stated before, the proposal also takes great pains = not >> to disrupt any non-pathological use cases, and again I'm open to revisin= g >> the spec if a concrete example that would be harmed by this softfork is >> found. >> >> >And indeed I haven't read a new version because your prior message >> provided no reference to it >> >> It is attached as a file to my email. Does your email client not support >> attachments? I'll be sure to include a browser-friendly link next time i= f >> that's the case. >> >> >I was responding to the summary. >> >> The summary mentioned that I had removed all references to legal risks. >> >> >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 t= hat >> 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). >> >> If you're referring to Andrew Poelstra's message here >> , >> that doesn't strike me as "opposition", and besides, note that this >> proposal implements a very similar mitigation suggestion, which was: >> >> >In any case, if confiscation is a worry, as always we can exempt the >> current UTXO set from the rule -- if you are only spending outputs that >> existed prior to the new rule, your new UTXOs are allowed to be large. >> >> The current proposal exempts *inputs* that spend from the current UTXO >> set, but does not allow such transactions to create outputs that violate >> the new rules. This should be fine, since the funds can just be sent to = a >> different wallet, (assuming there is actually wallet software somewhere >> that habitually creates outputs with scriptPubKeys larger than 34 bytes)= . >> >> Please let me know if this is not the "opposition" you were referring to= ; >> I searched for a while but it's possible I missed something. Again, I am >> eager to address all valid technical objections to this proposal, and so >> far I haven't seen any. >> >> >I think your proposal continues to have no serious prospect of activati= on >> >> I disagree. I think Bitcoin users are fed up with data spam and ready to >> coordinate to say "enough is enough". >> >> >should it activate in any form it will just be forked against >> >> That would be incredibly risky, but of course people are welcome to run >> whatever software they choose. >> >> >and its authors will likely find themselves mired in litigation by >> people harmed by it >> >> Just to clarify, are you saying that anyone who doesn't support the URSF >> will face legal risks? >> >> >I think you'll find that almost every significant bitcoin developer wil= l >> 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. >> >> I think you are mistaken. The Bitcoin community wants Bitcoin to be >> money, not data storage. >> >> Best, >> >> Dathon >> On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell < >> gmax...@gmail.com> wrote: >> >> 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 tryi= ng >> 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 'succe= ss' >> opcode would be inherently completely insecure-- an important improvemen= t >> in upgradability that your proposal permanently destroys without you eve= n >> 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 l= ist >> 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 t= hat >> 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 wit= h >> 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 violat= ions >>> of this rule. Those would appear to the network to be outputs created a= t 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 us= e >>> 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 tha= t >>> "use" any given feature of the Bitcoin protocol, including, for example= , >>> OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softf= ork >>> proposal that redefines the OP_NOP. That is, anyone could intentionally >>> lock funds into a pathological construction in order to obstruct any gi= ven >>> softfork. >>> >>> Thus, if taken to the extreme, the argument that no one should ever hav= e >>> funds "confiscated", or even temporarily frozen, means that we can neve= r >>> upgrade Bitcoin again. So, in the interest of avoiding permanent >>> ossification, it seems wise for us to compromise somewhere in the middl= e. 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-signe= d >>> transactions, then 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 presenti= ng >>> it under a false identity in order to conceal their involvement. Will y= ou >>> be correcting the record on the true authorship of this work and on who= se >>> 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 suppres= sed >>> 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 >>> BIP 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 'unlaw= ful' >>> 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 u= se >>> case, at the consensus level. >>> >>> It sounds like you haven't read the new version of the BIP, nor my >>> summary 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= .mediawiki >>> >>> >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 = also >>> agree the same for essentially all other forms-- that they'd simply mad= e a >>> few line of code changes and then evade these restrictions? >>> >>> Again, this is no longer applicable to the proposal. The new draft make= s >>> significant changes. >>> >>> >In light of that, how would the very real and significant reductions i= n >>> 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 force= d in >>> to an endless sequences of 'update' blocking actions, each carrying its= own >>> 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 ye= ars >>> 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 the= m >>> 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 thi= s. >>> >>> >I don't think your suggested revisions will move your proposal off fro= m >>> 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 i= t >>> might want to just be a database, over the new one where Bitcoin is mon= ey. >>> >>> Best regards, >>> >>> Dathon >>> On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell < >>> gmax...@gmail.com> wrote: >>> >>> On Sat, Nov 8, 2025 at 12:58=E2=80=AFAM dathonohm via Bitcoin Developme= nt >>> Mailing List wrote: >>> >>>> >>>> 1. "Funds confiscation": due to the presence of UTXOs that would be >>>> made temporarily unspendable by this proposal, commenters were conc= erned >>>> that this would set a precedent of "confiscation". This new draft r= esolves >>>> this concern by adding a UTXO height check to make sure *only UTXOs >>>> that are created while the softfork is active will be made temporar= ily >>>> unspendable*. The "OP_IF in Tapscript" and "257-byte control block >>>> limit" were the two main proposed rule changes that caused concern = here. >>>> >>>> >>> That doesn't address the confiscation problem (although any reduction i= n >>> the restriction does reduce it), as there likely exist chains of not ye= t >>> confirmed (and potentially timelocked) transactions that involve violat= ions >>> of this rule. Those would appear to the network to be outputs created a= t 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 ha= s >>> 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 presenti= ng >>> it under a false identity in order to conceal their involvement. Will y= ou >>> be correcting the record on the true authorship of this work and on who= se >>> 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" = and >>> could just as well be performed via a "less commonly abused" path? Woul= d >>> 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 restriction= s? >>> >>> 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 force= d in >>> to an endless sequences of 'update' 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 your proposal off from having essentially >>> zero risk of adoption, and if it were adopted (which I think is unlikel= y) I >>> think it's a certainty that there would be a countering fork to continu= e 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+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5= Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com >>> . >>> >>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+...@googlegroups.com. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTCFx2yvvUu9YWwcm-SSo= jT530Uwzi0b3sOG0%2BVZEcaAw%40mail.gmail.com >> . >> >> >> -- > 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/86d11552-36d8-46d7-998c-ed68= 75a5a84bn%40googlegroups.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/= CAAS2fgR7wKyV3vgwTrqidhyDz6CAU%3D4aGCT%3D6jr8fDM6UMQbrw%40mail.gmail.com. --0000000000001d4617064354136d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Presigned transactions are quite real and are used by= people, e.g. for inheritance so you can allow your inheritors (or you) to = recover your coins in the future via a more accessible file, while securing= the wallet that can immediately spend to a level that might otherwise caus= e accidental funds loss.=C2=A0 =C2=A0They're more flexible than having = to stick a recovery alternative in script and though a relative locktime wo= uld be more reliable, unfortunately they can't be set much into the fut= ure under current consensus rules.=C2=A0=C2=A0

Not= everyone is luke-jr whose security practices are to keep a copy of his = 9;offline' wallet on an online system with a copy of the passphrase for= it just stored in a file next to it.=C2=A0 Had that file had presigned tra= nsactions set a couple years out, he probably wouldn't have turned into= an involuntary nocoiner more interested in getting his way that preserving= Bitcoin's value and stability and we wouldn't need to debate a pro= posal that lobotomizes Bitcoin's functionality and will seize users fun= ds just to further his vanity project.

Not=C2=A0ev= eryone is eager to go into details about their own assets and security prac= tices, potentially compromising their privacy and safety.=C2=A0 -- and like= ly most impacted people have no idea of the risk it has for them, especiall= y when the schemes author is online outright lying about its properties: https://x.com= /LukeDashjr/status/1987267143612703150

(He cou= ld debate the degree of confiscation risk,-- though I know for a fact that = it's a certainty-- but saying there is *none* is just a toxic lie that = should cause us to reject his proposal on the principle that the proposals = true creator is outright deceiving the public about it)


On Tue, Nov 11, 2025 at 8:28=E2=80=AFAM 'Bitcoin= Eagle' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
"Okay, if you or anyone can sho= w me an example of a "boring and unconcerning thing" that involve= s=C2=A0pre-signed transactions that use deep/OP_IF-containing Taptrees and timelo= cks,=C2=A0which predates the original softfork proposal, I will be happy to= update the BIP. Saying "someone might be doing this" is simply f= rivolous obstructionism which, again, could be used to stop any attempt to = change the consensus rules."

If we skip the pontential strawman of presigned tran= saction let's describe realistic problem.
  1. You have sensible multisig w= allet which breaks one of the OP_IF or merklepath restrictions. And you don= 't even know how it works inside.
  2. To avoid confiscation you need to create a new= wallet which is designed in compliance with BIP444. Is there new miniscrip= t compiler available in time?=C2=A0
  3. Migrate all UTXOs to new wallet
  4. <= font color=3D"#000000" face=3D"Arial, sans-serif">The real risk of confisca= tion are change addresses. After activation spending will work thanks to on= e time whitelist. But it creates a change which will be new UTXO unspendabl= e

On Monday, November 10, 2025 at 6:34:39=E2=80=AFAM UTC+7= dath...@proton.me wrote:





<= /div>
>This is also not a new co= ncern being raised for your proposal, 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.

I believe t= he utility of the strategy of "don't break any use cases, no matte= r how pathological" has finally worn out. The longer we continue down = this path, the more likely it is that Bitcoin will become entirely p= athological use cases.

Accordingly, this BIP=C2=A0intentionall= y disrupts all of the most harmful use cases, because they are making B= itcoin worse money and the problem is accelerating. But as stated before, t= he proposal also takes great pains not to disrupt any non-pathological use = cases, and again I'm open to revising the spec if a concrete example th= at would be harmed by this softfork is found.

>And indeed I ha= ven't read a new version because your prior message provided no referen= ce to it

It is attached as a file to my email. Does your email cl= ient not support attachments? I'll be sure to include a browser-friendl= y link next time if that's the case.

>I was responding to = the summary.

The summary mentioned that I had removed all refer= ences to legal risks.

>Now looking at it, I see that you are s= till 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 ve= rsion, then simply dishonestly insisted there was no opposition to it, even= though opposition was immediately raised on the list).

If you= 9;re referring to Andrew Poelstra's message here, that do= esn't strike me as "opposition", and besides, note that this = proposal implements a very similar mitigation suggestion, which was:
<= div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);b= ackground-color:rgb(255,255,255)">
>In any case, if confiscation is a worry, as always we can exempt th= e
current UTXO set from the rule -- if you are only spending outputs that
existed prior to the new rule, your new UTXOs are allowed to be large.<= /div>

The current proposal exempts inputs that spend from the cu= rrent UTXO set, but does not allow such transactions to create outputs that= violate the new rules. This should be fine, since the funds can just be se= nt to a different wallet, (assuming there is actually wallet software somew= here that habitually creates outputs with scriptPubKeys larger than 34 byte= s).

Please let me know if this is not the "opposition" = you were referring to; I searched for a while but it's possible I misse= d something. Again, I am eager to address all valid technical objections to= this proposal, and so far I haven't seen any.

>I think yo= ur proposal continues to have no serious prospect of activation

I= disagree. I think Bitcoin users are fed up with data spam and ready to coo= rdinate to say "enough is enough".

>should it activa= te in any form it will just be forked against

That would be incre= dibly risky, but of course people are welcome to run whatever software they= choose.

>and its authors will likely find themselves mired in= litigation by people harmed by it
=
Just to clarify, are you sayin= g that anyone who doesn't support the URSF will face legal risks?
=

>I think you'll find that almost every significant bitcoin deve= loper will stand against such a change and will not work on a fork that ado= pts them, I also doubt the market would value your fork with such significa= nt limitations very highly.

I think you are mistaken. The Bitcoin= community wants Bitcoin to be money, not data storage.

Best,

Dathon
On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell <gmax...@gmail.com> wrote:
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 b= urned-- but they'd have to be trying, not just doing a boring and uncon= cerning 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 th= emselves.

This is also not a new concern bein= g raised for your proposal, 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 OP_SUCCESS = works the way it does: so that any script that prematurely uses a 'suc= cess' opcode would be inherently completely insecure-- an important imp= rovement in upgradability that your proposal permanently destroys without y= ou even understanding why it existed in the first place.

And indeed I haven't read a new version because your prior messa= ge provided no reference to it-- it said you were requested to update the l= ist and then you only provided a summary. I was responding to the summary.<= /div>

Now looking at it, I see that you are still limiti= ng scriptpubkey sizes strictly-- this will absolutely confiscate funds as w= as pointed out and not responded to even before your proposal. (because luk= e-jr proposed just that limit first-- actually a more relaxed version, then= simply dishonestly insisted there was no opposition to it, even though opp= osition was immediately raised on the list).

I thi= nk your proposal continues to have no serious prospect of activation, and s= hould it activate in any form it will just be forked against and its author= s will likely find themselves mired in litigation by people harmed by it. = I think you'll find that almost every significant bitcoin developer wil= l 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 limita= tions very highly.


On Sat, Nov 8, 2025 at 9:02=E2=80=AF= PM <dath...@proton.me> wr= ote:
Hi Greg -
=
>That doesn't address t= he confiscation problem (although any reduction in the restriction does red= uce it), as there likely exist chains of not yet confirmed (and potentially= timelocked) transactions that involve violations of this rule. Those woul= d appear to the network to be outputs created at a later time, although the= y really weren't. It's unclear to me why you haven't yet under= stood this point.

While I completely agree that "confiscatio= n" is a precedent we must avoid setting, I think my proposal neither c= onfiscates funds nor sets a bad precedent, as it takes pains to avoid causi= ng problems for all known use cases. I don't think it is reasonable nev= er to create problems for all unknown use cases, as this would neces= sarily imply permanent ossification.
To illustrate the point: it = is possible to design off-chain systems that "use" any given feat= ure of the Bitcoin protocol, including, for example, OP_NOPs. Funds locked = in such UTXOs would be "confiscated" by the softfork proposal tha= t redefines the OP_NOP. That is, anyone could intentionally lock funds into= a pathological construction in order to obstruct any given softfork.
=

Thus, if taken to the extreme, the argument that no one should ever ha= ve 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 signifi= cant funds locked into pre-signed transactions, then of course I will modif= y the proposal to accommodate them.

>Another issue raised whic= h you have not mentioned is that prior to you making this proposal I receiv= ed 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 orde= r to conceal their involvement. Will you be correcting the record on the t= rue authorship of this work and on whose behalf its being performed?
<= div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);b= ackground-color:rgb(255,255,255)">
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 suppressed by mode= rators.

I humbly request that moderators let the public see my re= sponse this time, otherwise I'm not sure how the record will ever be co= rrected:

Though I am in direct communication with some Ocean empl= oyees (and the BIP 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 gainin= g adoption.

I am acting solely on my own behalf and on the beh= alf of the Bitcoin community, because I and most Bitcoiners I know are = concerned about Bitcoin's future if it embraces data storage as a suppo= rted use case.

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

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

No, I think this p= roposal is the best way to achieve its stated purpose, which is to reject t= he standardization of data storage as a supported use case, at the consensu= s level.

It sounds like you haven't read the new version of t= he BIP, nor my summary 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 push= ed a copy of it to a non-PR branch, since the PR is still locked: http= s://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawi= ki

>As that concern as expressed has a threshold o= f "any at all" and could just as well be performed via a "le= ss commonly abused" path? Would you also agree the same for essentiall= y all other forms-- that they'd simply made a few line of code changes = and then evade these restrictions?
=
Again, this is no longer appli= cable to the proposal. The new draft makes significant changes.

&= gt;In light of that, how would the very real and significant reductions in = intentional functionality (such as efficient "few of dozens" mult= isigs or other such constructs) be justified? How could the confiscation ri= sk be justified? How could the deployment costs be justified? How could t= he "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 own 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 d= isrupt any use cases, no matter how pathological, is the fastest path to os= sification.

Indeed, Bitcoin has failed to make any consensus upgr= ades 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 proposal allows Bitcoiners to say "enough is enough", = re-affirm that Bitcoin is money rather than data storage by d= isabling all the most popular methods of data abuse, and move on to more ex= citing things. We could have new upgrades in one year if Bitcoiners focus o= n building them over the following months.

I honestly don't s= ee a better way out of this morass, but please let me know your reasoning i= f you disagree. Inaction is not going to solve this.

>I don= 9;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, be= sides fear of softforks in general, but I'm listening.

>I= think it's a certainty that there would be a countering fork to contin= ue a Bitcoin without these poorly justified (even essentially useless) rest= rictions.

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

Best regards,

Dathon
On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmax...@gmail.com> wrote:
On Sat, Nov 8, 2025 at 12:58= =E2=80=AFAM dathonohm via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
<= div class=3D"gmail_quote">
  1. "Funds con= fiscation": due to the presence of UTXOs that would be made temporaril= y unspendable by this proposal, commenters were concerned that this would s= et a precedent of "confiscation". This new draft resolves this co= ncern by adding a UTXO height check to make sure only UTXOs that are cre= ated while the softfork is active will be made temporarily unspendable.= The "OP_IF in Tapscript" and "257-byte control block limit&= quot; were the two main proposed rule changes that caused concern here.

That doesn't addres= s the confiscation problem (although any reduction in the restriction does = reduce it), as there likely exist chains of not yet confirmed (and potentia= lly timelocked) transactions that involve violations of this rule. Those w= ould 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 un= derstood this point.

I don't think this concer= n was in any way limited to the control block of op_if components either, e= ssentially every aspect of the proposal has confiscation issues.
=
Another issue raised which you have not mentioned is that pr= ior to you making this proposal I received minutes from a meeting which not= ed that Ocean Mining was the true author of this proposal and would be pres= enting it under a false identity in order to conceal their involvement. Wi= ll 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 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+...@googlegroups= .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 bitcoindev+...@googlegroups= .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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/86d11552-36d8-46d7-998c-ed6875a5a84bn%40googlegrou= ps.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/CAAS2fgR7wKyV3vgwTrqidhyDz6CAU%3D4aGCT%3D6jr8fDM6UMQbrw%= 40mail.gmail.com.
--0000000000001d4617064354136d--