path: root/9d/f3bba3f3cfa886130714789834dcc31d44e66b

Delivery-date: Thu, 08 May 2025 01:17:07 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBB56Q6HAAMGQEFZJUFVA@googlegroups.com>)
	id 1uCwRF-0007XV-Ce
	for bitcoindev@gnusha.org; Thu, 08 May 2025 01:17:07 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-708aead74d2sf10851497b3.0
        for <bitcoindev@gnusha.org>; Thu, 08 May 2025 01:17:05 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746692219; cv=pass;
        d=google.com; s=arc-20240605;
        b=HKk3fPMiaoA5UY2SRY42TAx5CC0QMrt2tGVHm0AKeE87+9QeuDPJ4wp3IhSE8yTHtp
         XmMNE3CixDmumWM2UbQZ+hiTa88JG6TlC4Glcw8Xy8S+b6/4Qx7KHfs7ot90703UxERw
         xDo7E+I32OLV8UjcUEMsEMC0pvwzCnHGaUulwsjYhf3RbAbzNH88QnbBQ1skkaLJkF+S
         nX/sreWsW9s6S1B0wJmN0Ao17HfmGu3PFOf8s18OAdJPN4E7x4sl5YiqnjYhp+YXGBxP
         9KvKqdS8iuHoAHtVd5re28bZXirBetufFi5Woxo1KoyzllZhIxXdjWicbZ96edZadxSu
         7TvQ==
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=+uRpisiuurTTkv5q1Xnh5gY0sAUDqcBPn+fO4dtR7qo=;
        fh=egfNJjrfBgQjgeLxQ4r+76uoWb9wcZKiyjdYEj5Utj4=;
        b=ENYRxFdVlrRns+n4X082BQdQdbkNjzUppWl0ky3jakBavDUqmKGGs6jlYgg2bfM+gG
         7PryUPMZaT/iX5sUYYipE7U9xiLPiQ0JNRfGMkh05P3WX2bx/HrAnBZruuBwqy8nFunA
         rqvG0hsYHTpOkaL388/rEb8GgHkT/6nNnsKRdatbsYnJ2bNvVGUJjTw13cSs2zUbNwjK
         U8BlshFthBRy3G+iFGtPJViiYzh81J2D+cYMaffXYJO+FsqMar1RroCp9e9DqlIg3aO0
         WSE7yWVyJSP72/28OgAQGKa9eTeaS6g6xHHBFJFvbbqmDnncM1rd47iiUlg0WQ0HabXv
         bWhA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=WoS9WvrZ;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c 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=1746692219; x=1747297019; 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=+uRpisiuurTTkv5q1Xnh5gY0sAUDqcBPn+fO4dtR7qo=;
        b=iVmFtlGt3CDXM/lqgI3ymIcN2HIBYzr4+BEzdnJ4TKPKAYZhgvJentjaJfFxxn88FE
         /21pwG76VUoYl6Imdy4kCMvujmdBj9KuU6lEpLxNMVGRlR6KBMT8oeffB13NBCylrPbS
         uxLQ+9CHISWJlg9x49Wyg80oX/VlQreumXIxJxpmXkh5wr51uwfqt/wT112Vrwg2DvCf
         GKHVMYjT0jDDvUjqDW9YgLCRE3gAPRAA90gGqq2z1BafeO1r8xYdzF/1Pcyo+WHubx4c
         fl/Xx8XHOZdfBXGb1pz+vXoxw+zi27b5sfhkatb6GrIXjBOtA7uA+9bl3jVPpavqWa/q
         ql6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746692219; x=1747297019; 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=+uRpisiuurTTkv5q1Xnh5gY0sAUDqcBPn+fO4dtR7qo=;
        b=NsZZUNe2VsIAvZJ9mOSjiu8o8H0WiV/PV9DwHryON5pFmS1B9XHa0q9c0i18XzpID4
         dOyi+dy5e3rh4uSYpZHEsGJgBZZNJ7+n+GwNtdasQp+8iGYVgYhxlSXFrGCRWmEy7Gn2
         KFkIdC+UIO+ndKMcy2xBIqCF1LT1OVbPazqcJ/EnLPP4G8fT4rLI3wGNJJ142pg3bdXM
         t1ao3P+ZSmf+RsScw+g6QfyUhmSvFAG+QCz4bgtHRRWT1uttvvF8cjX7bGz4vsOfUO2w
         kTe2SF0Y49A5pbsQaIB72B7CuqQrOZzRsQ/IE38cgeMi3ptP8P/8Gfgs2SZiXDqvaJI6
         luJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746692219; x=1747297019;
        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=+uRpisiuurTTkv5q1Xnh5gY0sAUDqcBPn+fO4dtR7qo=;
        b=vYMKaPTSWfgfELS4fIbc75vQ2Xw5QG+N2dF5ejRJaBTsBE45dg9mxub+HXnSxRGWaC
         GgtO51z57IolL3F86+bqRNTgUSS7/4AyvakC4x6sF8u9cbqn5sZ4PaBx8+xFcxppyAqr
         GkEY9JOUUuE/7DtNXUI8kCgQlCSTmGt3WY7T1KJyWN2IwiOWbfY+RVb4cJy5LHMdrE1s
         96G8xLm35r370prtcyz6z7kY+jgqc3QvI+oe68jkKxAk8v28MA13h6wPdH+hnBABV3c/
         iUkGq4l9c9CVGfp7uO1dKiKCdgTGp6Bnn+hscjCE5qzIXgpJxWK+Z9ShLQbyNghA32zS
         Xozw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXju+iI5P1N6VV1nobuEwRuyPw1LB6rlzWGYYZMvMa/DS9y/Ku85PDd4f1rO/ccVva96MHDE9IfiyO9@gnusha.org
X-Gm-Message-State: AOJu0YwjBbeb4V4oTXWFAEq6s/XgPeRrC+HsnZC8OMncOrdpDl18dAAY
	uHez2CjIqcOKbf41K4MACIzoY/Uya0ELr+IVU1CP1JKQYQXADSot
X-Google-Smtp-Source: AGHT+IFvI/JMIWk/0mfCbtEoWGItBgTk6Cnfuzgybn7UbiHgUhn1d7t5dv+wgtZrXjxsy4M3yYOjKQ==
X-Received: by 2002:a05:6902:4791:b0:e74:f068:4dea with SMTP id 3f1490d57ef6-e78811f50e9mr8243736276.24.1746692218981;
        Thu, 08 May 2025 01:16:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFZBhgXMoy2vx7yxC2CdKOQxRv9XcTePpd/4oMVcFa6zw==
Received: by 2002:a25:dc4e:0:b0:e75:c614:eba9 with SMTP id 3f1490d57ef6-e78ede1755fls782918276.0.-pod-prod-01-us;
 Thu, 08 May 2025 01:16:55 -0700 (PDT)
X-Received: by 2002:a05:690c:6c05:b0:6fb:b907:d965 with SMTP id 00721157ae682-70a1da3d22emr89429207b3.3.1746692214908;
        Thu, 08 May 2025 01:16:54 -0700 (PDT)
Received: by 2002:a05:690c:6a01:b0:709:1e86:f347 with SMTP id 00721157ae682-70a1ec34dc7ms7b3;
        Wed, 7 May 2025 04:33:19 -0700 (PDT)
X-Received: by 2002:a05:6902:240f:b0:e75:c51e:5bbf with SMTP id 3f1490d57ef6-e7880fc6352mr3780561276.14.1746617598231;
        Wed, 07 May 2025 04:33:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746617598; cv=none;
        d=google.com; s=arc-20240605;
        b=Vn6fvZHIl+SczS4odOwvtAdGzbe349NzsgblZoesA1sIQXgzFpv6DCdlSo4Ra2InnN
         1f9O45ptFpl+VUtKlfjD0VMZm6/+hWUQfwcoq66wwBS/11J9cIDodBIt6BNCURqo5N8K
         qMGqUWFpSiBFk3kySZ6wwmV50ad3HMw6vpfD29Xm9pWuH0Jf/8MdwNiuH0tl4DVEngSE
         Tdey8MSaAbaQau/XAAVF6hFQtRTNR1cTbwNQSiYLQiWpxw8+FTb2NWbO6lj989+3MEPb
         FCC4XsdIpg8gIQNMH5YNaXVTYENkZ57lvZDV+qNelRlK5s7amz8gAS6NRLB4O5QZwEHu
         p+TQ==
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=jLmO3I9Wl0wY/IjwlQaQlM5SqnwAWbx+Kmh+uUwbcak=;
        fh=CsEUNJ5L4/CRHemyOmorbj1EDejUhRw9KbwQMGJ2wEQ=;
        b=YNy8Jxiw5qgjF62pYTVvgI6fOrngVFI7g7tgc4qz65605w17O53H2vbZUyOQF4Whxr
         QqBteAXEsUxN6ATtx4ZgQ9uAzpJeilgXwnh0ELPwThp+dGBoA8Z8XP2KrQLsKNGX+9Tm
         Ly+LCiSUER2OOszGQji85dhYauM6V4Fnpt/xDQZ6eud+2eg0IuvkqVgEVZHBR38KBt26
         8SUj8VhBdvNlv9mscDp8MF8o7X2T3wdK3hw0BhSeVLS5T4MsG4MFaoRrEMJL/sydflbT
         hne83iIv8R892Z/PDWOTLjYUPhkZAS7eUARK2OBTc7PRZB2VEgi5XohCoUFeHGKK0d4y
         1dAQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=WoS9WvrZ;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c 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-x52c.google.com (mail-pg1-x52c.google.com. [2607:f8b0:4864:20::52c])
        by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e75bcea1256si189480276.4.2025.05.07.04.33.18
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 07 May 2025 04:33:18 -0700 (PDT)
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c as permitted sender) client-ip=2607:f8b0:4864:20::52c;
Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-ae727e87c26so4257445a12.0
        for <bitcoindev@googlegroups.com>; Wed, 07 May 2025 04:33:18 -0700 (PDT)
X-Gm-Gg: ASbGnctOZGMivS2y1ca4BMRWCWS3kkqUSUfX1F6B6whAYNXpMSzcUn7K72nwqpPbV2S
	xStdbDWsPI8377UVh/54eIIYBwkRb+BoN2qQj+b+KvZk9yRa/v5/r5xZAsGC4sAabWPft20D3nf
	/Mo5wMYJoUpafP7aR1XM+SGQ==
X-Received: by 2002:a17:90b:2d06:b0:2ee:d371:3227 with SMTP id
 98e67ed59e1d1-30aac19ca0amr5439414a91.17.1746617597092; Wed, 07 May 2025
 04:33:17 -0700 (PDT)
MIME-Version: 1.0
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <20250502064744.92B057C0EE2@smtp.postman.i2p> <20250507012038.3EAE07C10F1@smtp.postman.i2p>
In-Reply-To: <20250507012038.3EAE07C10F1@smtp.postman.i2p>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Wed, 7 May 2025 11:32:53 +0000
X-Gm-Features: ATxdqUFwRTWL6JyIEeGriBlFmaV0XxS8ucEXF_o0gpkSReGOGK4_YaUAYtjRxVM
Message-ID: <CAAS2fgQsQNmKLbaFDoee2yT_KwpvA7P3GnHy3=yhHUnEXma-NQ@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
To: pithosian <pithosian@i2pmail.org>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="0000000000006eebf306348a1933"
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=WoS9WvrZ;       spf=pass
 (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c
 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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--0000000000006eebf306348a1933
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

That creates a withholding attack where you announce a block then withhold
some transactions entirely.

It does already relay to other full nodes before validating everything, but
the nodes need to have the data.

Of course the recipient's mining is also still delayed until validation so
even if not for the withholding issue it would only reduce the hop by hop
component.  (As the recipient would presumably not have the transaction
either with its relay blocked in the network and the transaction submitted
directly to the party that included.)

There are, of course, numerous optimizations that could be done to reduce
the impact... but none so effective as actually having the transaction and
even having already validated it, and all with considerable development
effort.




On Wed, May 7, 2025 at 10:49=E2=80=AFAM pithosian <pithosian@i2pmail.org> w=
rote:

> On Fri,  2 May 2025 06:47:44 +0000 (UTC)
> Greg Maxwell <gmaxwell@gmail.com> wrote:
>
> >
> > On Thursday, April 17, 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot w=
rote:
> >
> >
> > Since the restrictions on the usage of OP_RETURN outputs encourage
> > harmful practices while being ineffective in deterring unwanted
> > usage, i propose to drop them.
> >
> >
> > The situation is even somewhat worse than that:  There are a number
> > of design decisions where it's generally assumed that relay and
> > mining policy generally match, or at least that mismatches are short
> > lived.
> >
> > When relay policy is more restrictive than what is actually being
> > mined there are at least two serious negative effects.
> >
> > The first is that the latency of block propagation is greatly harmed,
> >  a single missed transaction causes a tripling of the per hop
> > transmission delay.  If the missed transaction(s) are larger than the
> > TCP window then the increase may be many round trip times.  Also if
> > the missed data is large the currently unused prefill mechanism in
> > compact blocks wouldn't help (and would instead likely make things
> > worse as then nodes will get several times the same transaction data
> > from different peers and you cannot decode the compact block until
> > all the prefill data has been received due to the message checksum.
> > Delays in block propagation can have a disproportionate effect on
> > mining centralization because they cause larger miners to have
> > improved profitability over smaller ones. This happens regardless of
> > which party was on which side of the delay, no matter which side is
> > delayed its the smaller miner's expected profits that are diminisned
> > and the nature of mining competition means that less profitable
> > miners go bankrupt.
> >
> > This also encourages the establishment of direct miner submission
> > which can undermine the permissionless nature of bitcoin and in
> > particular again shifts profits towards larger miners because e.g.
> > few would bother connecting to a 1% miner's direct submission
> > interface (if they could even afford to make one).
> >
> > There are also a number of less significant harms, e.g. more
> > restrictive relay policy makes fee estimation less accurate/complete
> > (though at least estimation is designed to be fairly robust in that
> > direction).
> >
> > So on this basis I suggest a principle for these sorts of policy:
> > Relay rules should admit all transactions which are reliably being
> > mined.
> >
> > I think node software should adopt this principal as a general rule.
> >
> > Admitting the transactions is not endorsing them, it's just a
> > recognition of reality.  This policy or equivalent is also the
> > requirement to not suffer from the downsides of relay being more
> > restrictive than mining.   If we imagine that a miner is mining some
> > kind of harmful attack transaction e.g. a validation DOS attack, then
> > the miner needs to be convinced to stop, the implementation changed
> > to not have bad performance, and/or consensus rules must be changed
> > ... but relay policy can't address it.
> >
> > By general rule I mean that should something like a miner begin
> > mining e.g. quadratic hashing bloat legacy txn, or using unused
> > opcode/successcode/version number or whatever by mistake or technical
> > ignorance there is no need to rush off enabling their relay. A
> > general rule isn't a suicide pact.  But if it were the case that
> > transactions misusing a particular forward compatibility feature were
> > reliably getting mined then that feature would just no longer be
> > useful for forward compatibility regardless of what relay policy says
> > about it and it would be better to relay them than have the downsides
> > of not doing so.
> >
> > As Antoine Poinsot points out, the existent rule is entirely
> > ineffectual: Parties current bypass these rules with other
> > transaction forms (such as very harmful address stuffing which is
> > impossible to block) or by direct miner submission, which will
> > continue considering the millions of dollars miners have received
> > mining transactions with violate the relay rules. Because of this it
> > will not become effectual with time or tweaking.  It is a dead
> > parrot^policy.  This is no surprise, since it's a product of
> > Bitcoin's anti-censorship properties that *generally* filtering will
> > not work except on the fringes.  As such there isn't practical upside
> > to keeping filtering beyond what miners currently perform.
> >
> > Some Bitcoiners are of the opinion that they still want a knob, I
> > think doing so is a disrespectful placebo[*] but I don't have a
> > strong opinion if an option remains-- the code is safer and cleaner
> > without some filtering rules that few users would use but that really
> > just a question between software maintainers and users.  That said,
> > Bitcoin core has generally not had knobs to adjust relay policy as
> > distinct from mining policy in large part because of the design
> > assumption that the two need to be the same. But in this case if
> > there were a knob here I think would make more sense for it to
> > control mining policy rather than relay policy, since it would
> > actually have some effect in the mining context (in excluding the txn
> > from your own blocks) while as a relay only thing it is impotent.
> >
> > [*] It doesn't even conserve their resources meaningfully.  They'll
> > still receive and process the txn, then discard.  Then they likely
> > have to fetch it a second time when it shows up in a block.  Although
> > they may save re-transmitting it, on average network wide each
> > transaction is sent once and received once so the extra transmission
> > for the block should offset the relay savings.
> >
> >
> >
>
> On block propagation:
> > When relay policy is more restrictive than what is actually being
> > mined there are at least two serious negative effects.
> > The first is that the latency of block propagation is greatly harmed,
> >  a single missed transaction causes a tripling of the per hop
> > transmission delay.
>
> If I'm reading this correctly (and there's every chance I'm not):
>
> 1. When a node receives a compact block, it completely checks the
> block's validity before relying it.
> 2. If the block includes txs which aren't in the node's mempool, it
> needs to request those txs from peers before it can validate (and
> subsequently relay) it.
> 3. This can slow down propagation of blocks significantly (as this cost
> can, in the worst case, be incurred 'per hop').
>
> If my above understanding is correct, then as far as I can tell, this
> problem has nothing to do with mempool tx relay policy, and can be
> solved by tweaking block relay policy.
>
> On receiving a block:
> 1. Check whether the block meets the POW target.
> 2. If it does, relay it.
> 3. Validate the contents of the block.
> 4. Apply it.
>
> This removes the 'per hop' block propagation delay caused by retrieving
> missing transactions, and the only threat, so far as I can tell, is
> that someone might waste a lot of money mining an invalid block to get
> nodes to relay it (but then quickly discard it), which doesn't seem
> particularly worth it.
>
> Of course, if a miner doesn't have an included transaction locally,
> they still need to go get it before they can safely include txs in
> their next block, but the propagation delay is removed, and that miner
> can always make sure to run, and connect to peers running permissive
> relay policy, such as librerelay, to decrease the odds of that
> happening.
>
> --
> 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/20250507012038.3EAE07C10F1%4=
0smtp.postman.i2p
> .
>

--=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/=
CAAS2fgQsQNmKLbaFDoee2yT_KwpvA7P3GnHy3%3DyhHUnEXma-NQ%40mail.gmail.com.

--0000000000006eebf306348a1933
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That creates a withholding attack where you announce =
a block then withhold some transactions entirely.</div><div><br></div><div>=
It does already relay to other full nodes before validating everything, but=
 the nodes need to have the data.</div><div><br></div><div>Of course the re=
cipient&#39;s mining is also still delayed until validation so even if not =
for the withholding issue it would only reduce the hop by hop component.=C2=
=A0 (As the recipient would presumably not have the transaction either with=
 its relay blocked in the network and the transaction submitted directly to=
 the party that included.)</div><div><br></div><div>There are, of course, n=
umerous optimizations that could be done to reduce the impact... but none s=
o effective as actually having the transaction and even having already vali=
dated it, and all with considerable development effort.</div><div><br></div=
><div><br></div><div><br></div></div><br><div class=3D"gmail_quote gmail_qu=
ote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 7, 2025 at=
 10:49=E2=80=AFAM pithosian &lt;<a href=3D"mailto:pithosian@i2pmail.org">pi=
thosian@i2pmail.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On Fri,=C2=A0 2 May 2025 06:47:44 +0000 (UTC)<br>
Greg Maxwell &lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gm=
axwell@gmail.com</a>&gt; wrote:<br>
<br>
&gt; <br>
&gt; On Thursday, April 17, 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot =
wrote:<br>
&gt; <br>
&gt; <br>
&gt; Since the restrictions on the usage of OP_RETURN outputs encourage<br>
&gt; harmful practices while being ineffective in deterring unwanted<br>
&gt; usage, i propose to drop them. <br>
&gt; <br>
&gt; <br>
&gt; The situation is even somewhat worse than that:=C2=A0 There are a numb=
er<br>
&gt; of design decisions where it&#39;s generally assumed that relay and<br=
>
&gt; mining policy generally match, or at least that mismatches are short<b=
r>
&gt; lived.<br>
&gt; <br>
&gt; When relay policy is more restrictive than what is actually being<br>
&gt; mined there are at least two serious negative effects.<br>
&gt; <br>
&gt; The first is that the latency of block propagation is greatly harmed,<=
br>
&gt;=C2=A0 a single missed transaction causes a tripling of the per hop<br>
&gt; transmission delay.=C2=A0 If the missed transaction(s) are larger than=
 the<br>
&gt; TCP window then the increase may be many round trip times.=C2=A0 Also =
if<br>
&gt; the missed data is large the currently unused prefill mechanism in<br>
&gt; compact blocks wouldn&#39;t help (and would instead likely make things=
<br>
&gt; worse as then nodes will get several times the same transaction data<b=
r>
&gt; from different peers and you cannot decode the compact block until<br>
&gt; all the prefill data has been received due to the message checksum.<br=
>
&gt; Delays in block propagation can have a disproportionate effect on<br>
&gt; mining centralization because they cause larger miners to have<br>
&gt; improved profitability over smaller ones. This happens regardless of<b=
r>
&gt; which party was on which side of the delay, no matter which side is<br=
>
&gt; delayed its the smaller miner&#39;s expected profits that are diminisn=
ed<br>
&gt; and the nature of mining competition means that less profitable<br>
&gt; miners go bankrupt.<br>
&gt; <br>
&gt; This also encourages the establishment of direct miner submission<br>
&gt; which can undermine the permissionless nature of bitcoin and in<br>
&gt; particular again shifts profits towards larger miners because e.g.<br>
&gt; few would bother connecting to a 1% miner&#39;s direct submission<br>
&gt; interface (if they could even afford to make one).<br>
&gt; <br>
&gt; There are also a number of less significant harms, e.g. more<br>
&gt; restrictive relay policy makes fee estimation less accurate/complete<b=
r>
&gt; (though at least estimation is designed to be fairly robust in that<br=
>
&gt; direction). <br>
&gt; <br>
&gt; So on this basis I suggest a principle for these sorts of policy:<br>
&gt; Relay rules should admit all transactions which are reliably being<br>
&gt; mined.<br>
&gt; <br>
&gt; I think node software should adopt this principal as a general rule.<b=
r>
&gt; <br>
&gt; Admitting the transactions is not endorsing them, it&#39;s just a<br>
&gt; recognition of reality.=C2=A0 This policy or equivalent is also the<br=
>
&gt; requirement to not suffer from the downsides of relay being more<br>
&gt; restrictive than mining.=C2=A0 =C2=A0If we imagine that a miner is min=
ing some<br>
&gt; kind of harmful attack transaction e.g. a validation DOS attack, then<=
br>
&gt; the miner needs to be convinced to stop, the implementation changed<br=
>
&gt; to not have bad performance, and/or consensus rules must be changed<br=
>
&gt; ... but relay policy can&#39;t address it.<br>
&gt; <br>
&gt; By general rule I mean that should something like a miner begin<br>
&gt; mining e.g. quadratic hashing bloat legacy txn, or using unused <br>
&gt; opcode/successcode/version number or whatever by mistake or technical =
<br>
&gt; ignorance there is no need to rush off enabling their relay. A<br>
&gt; general rule isn&#39;t a suicide pact.=C2=A0 But if it were the case t=
hat<br>
&gt; transactions misusing a particular forward compatibility feature were<=
br>
&gt; reliably getting mined then that feature would just no longer be<br>
&gt; useful for forward compatibility regardless of what relay policy says<=
br>
&gt; about it and it would be better to relay them than have the downsides<=
br>
&gt; of not doing so.<br>
&gt; <br>
&gt; As Antoine Poinsot points out, the existent rule is entirely<br>
&gt; ineffectual: Parties current bypass these rules with other<br>
&gt; transaction forms (such as very harmful address stuffing which is<br>
&gt; impossible to block) or by direct miner submission, which will<br>
&gt; continue considering the millions of dollars miners have received<br>
&gt; mining transactions with violate the relay rules. Because of this it<b=
r>
&gt; will not become effectual with time or tweaking.=C2=A0 It is a dead<br=
>
&gt; parrot^policy.=C2=A0 This is no surprise, since it&#39;s a product of<=
br>
&gt; Bitcoin&#39;s anti-censorship properties that *generally* filtering wi=
ll<br>
&gt; not work except on the fringes.=C2=A0 As such there isn&#39;t practica=
l upside<br>
&gt; to keeping filtering beyond what miners currently perform. <br>
&gt; <br>
&gt; Some Bitcoiners are of the opinion that they still want a knob, I<br>
&gt; think doing so is a disrespectful placebo[*] but I don&#39;t have a<br=
>
&gt; strong opinion if an option remains-- the code is safer and cleaner<br=
>
&gt; without some filtering rules that few users would use but that really<=
br>
&gt; just a question between software maintainers and users.=C2=A0 That sai=
d,<br>
&gt; Bitcoin core has generally not had knobs to adjust relay policy as<br>
&gt; distinct from mining policy in large part because of the design<br>
&gt; assumption that the two need to be the same. But in this case if<br>
&gt; there were a knob here I think would make more sense for it to<br>
&gt; control mining policy rather than relay policy, since it would<br>
&gt; actually have some effect in the mining context (in excluding the txn<=
br>
&gt; from your own blocks) while as a relay only thing it is impotent. <br>
&gt; <br>
&gt; [*] It doesn&#39;t even conserve their resources meaningfully.=C2=A0 T=
hey&#39;ll<br>
&gt; still receive and process the txn, then discard.=C2=A0 Then they likel=
y<br>
&gt; have to fetch it a second time when it shows up in a block.=C2=A0 Alth=
ough<br>
&gt; they may save re-transmitting it, on average network wide each<br>
&gt; transaction is sent once and received once so the extra transmission<b=
r>
&gt; for the block should offset the relay savings.<br>
&gt; <br>
&gt; <br>
&gt; <br>
<br>
On block propagation:<br>
&gt; When relay policy is more restrictive than what is actually being<br>
&gt; mined there are at least two serious negative effects.<br>
&gt; The first is that the latency of block propagation is greatly harmed,<=
br>
&gt;=C2=A0 a single missed transaction causes a tripling of the per hop<br>
&gt; transmission delay.<br>
<br>
If I&#39;m reading this correctly (and there&#39;s every chance I&#39;m not=
):<br>
<br>
1. When a node receives a compact block, it completely checks the<br>
block&#39;s validity before relying it.<br>
2. If the block includes txs which aren&#39;t in the node&#39;s mempool, it=
<br>
needs to request those txs from peers before it can validate (and<br>
subsequently relay) it.<br>
3. This can slow down propagation of blocks significantly (as this cost<br>
can, in the worst case, be incurred &#39;per hop&#39;).<br>
<br>
If my above understanding is correct, then as far as I can tell, this<br>
problem has nothing to do with mempool tx relay policy, and can be<br>
solved by tweaking block relay policy.<br>
<br>
On receiving a block:<br>
1. Check whether the block meets the POW target.<br>
2. If it does, relay it.<br>
3. Validate the contents of the block.<br>
4. Apply it.<br>
<br>
This removes the &#39;per hop&#39; block propagation delay caused by retrie=
ving<br>
missing transactions, and the only threat, so far as I can tell, is<br>
that someone might waste a lot of money mining an invalid block to get<br>
nodes to relay it (but then quickly discard it), which doesn&#39;t seem<br>
particularly worth it.<br>
<br>
Of course, if a miner doesn&#39;t have an included transaction locally,<br>
they still need to go get it before they can safely include txs in<br>
their next block, but the propagation delay is removed, and that miner<br>
can always make sure to run, and connect to peers running permissive<br>
relay policy, such as librerelay, to decrease the odds of that<br>
happening.<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/20250507012038.3EAE07C10F1%40smtp.postman.i2p" rel=3D"noreferrer=
" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/2025050701=
2038.3EAE07C10F1%40smtp.postman.i2p</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgQsQNmKLbaFDoee2yT_KwpvA7P3GnHy3%3DyhHUnEXma-NQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAS2fgQsQNmKLbaFDoee2yT_KwpvA7P3GnHy3%3DyhHUnEXma-NQ%40ma=
il.gmail.com</a>.<br />

--0000000000006eebf306348a1933--