path: root/fe/4ac97954cbf5c7456d8a2700d72c532a1f093f

Delivery-date: Wed, 07 May 2025 03:49:30 -0700
Received: from mail-qt1-f183.google.com ([209.85.160.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBLXV5TAAMGQEIE2TY2A@googlegroups.com>)
	id 1uCcLB-0005NQ-HL
	for bitcoindev@gnusha.org; Wed, 07 May 2025 03:49:30 -0700
Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-4768a1420b6sf130108381cf.1
        for <bitcoindev@gnusha.org>; Wed, 07 May 2025 03:49:29 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746614964; cv=pass;
        d=google.com; s=arc-20240605;
        b=dR2SuqQb6FrMIjVx+0jL1I/FevZTuEfIKg6laP8VB0RBi27TebmSIMITEVLst2Q9mI
         DrTKiz/yiJrm6UB3ZYawa0VMsBctmcQjINTcafymmA+sNtzc85sdDXvw/Z0nAxd4JtOf
         L/mU0plvd1z2UlNKOPq26umbW9EYeQqLSWr782+HOdM7VGyRgGYwcThYqqWM59PnWx09
         3gYj1bsU2TYsy6oCY6KFzqR/rhEKiZP6lCgcf+O+WJ2LJJ1SWZ4AtOWh60dh0cu+YpA/
         DCnUT6BXi40rW83RBjuD/Wx6wuaEbXcPpgSVAiJb73IKQrfudu4Wu0vaDThMhbm2/2wr
         7AMQ==
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:date:message-id:mime-version
         :references:in-reply-to:subject:to:from:sender:dkim-signature;
        bh=4LcSNZ3SPNbrBxw6xNTTsbkm/bMr53lGHAEXBuNXtdg=;
        fh=Y+d0vMTZPGVYP8/2Pv9yOQ6RR5ZPRiG3lr0npkSOw5g=;
        b=OecKn/r2iV0R0wIjK1UB/Eb+CADMEjuQuydLm905a75e8Nkpqa1kGAEBT8+0kNSoMG
         A0j0fdBu4VLD35cMgwJLsq5mxN6fz0INzyqtduzusCaOVjDlQnlLjNnIzllsuaDoc0J/
         UPKUQfsrYaqib+LGz/rERrhhKC6ymMqnFFfeP7bOTqxqmkS69cP67jFkPjPEkoYS78Kq
         utVuXpDHzBFTSi4AVky/QZGspGHONQBRHXAne/Hmwgf5tcY1He/6r4Lz5gmn/gkVVqZZ
         7yKW1XsvG3Co5IRdrYPmv5e/AkDU9nrbQrbxIJOyKiYQxR/GuZ+kKdjBxBiaNigh+gNi
         bN6g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746614964; x=1747219764; 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:date:message-id:mime-version:references
         :in-reply-to:subject:to:from:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4LcSNZ3SPNbrBxw6xNTTsbkm/bMr53lGHAEXBuNXtdg=;
        b=cM1UxfWV6ehXVkqKMEgFdefyqWNfkCtThBuD1MubP5g+wjMk4jY0kzdql1G6dGDLiW
         ywN46truollaReAsWQbPhBh33Lt/5v0CiFA15mdsmCP0Uzw2UzbvNwEjuiwD3yibwtDi
         6958bhTmwXVQfJtB4oDYqOxOz6AIcVeVATmfrTD7PTpmDmf7vI7LmhIl+9BUF+vxf1gn
         eValHr+/dYsikigzfaZIXLfre3sAR+P7VpwkGZlNlMPVDPWcgMfCv0RHxi2sj6CAJwiO
         j6xHyq6HsVZZS8TzNarV0D67G6Z4FZTolErYJ3t7LV2FksnHNiH7L8kpDFidC7WLiO7+
         3jDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746614964; x=1747219764;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:date:message-id:mime-version:references
         :in-reply-to:subject:to:from:x-beenthere:x-gm-message-state:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4LcSNZ3SPNbrBxw6xNTTsbkm/bMr53lGHAEXBuNXtdg=;
        b=nbvb/i5j7jE3qNEqlNN+NkvWrOvfhdRLcLZZRbDxbMNfaEdT6sRO7WDYD9CjeafkUL
         NNG3NPwvxr/rdYgP/8QK9JIVXv1Ove3nykpT/L6iOyTY5S9g320e86No7HmgZs1i49qG
         io2CRlJouf0bIJK22H4AiYVpPF2dqQoYN6s5YFX9WIQlAAY4VitSllShvLknDgSRMlof
         XNWFhAVltPJWyQnC+j1+48wbO7q2FWZpXwTRgonuAjOOxcnGn/zaYY9lOCShLOG35JLG
         GvHpWIVjkQYlaZmlpZRx3iHXVE83flALLsxHC++e9rX2sIRBb+784ABQGBQ0ztWXdKPb
         pQ2w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVUKmP+S/Bf7hHxpZJ03i7FVVARIsKYJuWkH9oXzr3zAY37Vw/v/vjVeKFHwW+/jgQV6RwcJYZ5g+Ok@gnusha.org
X-Gm-Message-State: AOJu0YxE/LhbKhFt74I/3TctBDUTfv8SJab17IDgT/NWelNhRrNm2Egx
	9GhwCV1CVVUxhW18SMcnq/9l+DukupFJeUIRK0w7Jn9rriBeG9Si
X-Google-Smtp-Source: AGHT+IH60Fq/YLCrozPy16ryNB/PX/b4a5dpSfDUJQfHhXMVqOZyFpyKbfIy1TrGqjruQR04ZJ1j7w==
X-Received: by 2002:ac8:598b:0:b0:477:29f5:53eb with SMTP id d75a77b69052e-49225a3f6f4mr34823551cf.6.1746614963530;
        Wed, 07 May 2025 03:49:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBH1T6LrifcYMcJkUazqvampMiHUpw9bVqWwEtE9vHJp7Q==
Received: by 2002:a05:622a:a019:b0:477:5ddb:625a with SMTP id
 d75a77b69052e-48ad89b5697ls29468361cf.1.-pod-prod-03-us; Wed, 07 May 2025
 03:49:18 -0700 (PDT)
X-Received: by 2002:a05:620a:439e:b0:7c5:5883:8fbf with SMTP id af79cd13be357-7caf739b2f3mr481061885a.21.1746614958031;
        Wed, 07 May 2025 03:49:18 -0700 (PDT)
Received: by 2002:ab3:5796:0:b0:293:32b4:31b9 with SMTP id a1c4a302cd1d6-2adf8d88f60msc7a;
        Tue, 6 May 2025 18:32:58 -0700 (PDT)
X-Received: by 2002:a05:6512:3d86:b0:545:cc2:acd7 with SMTP id 2adb3069b0e04-54fb9605e8fmr419597e87.27.1746581576069;
        Tue, 06 May 2025 18:32:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746581576; cv=none;
        d=google.com; s=arc-20240605;
        b=evEJrF29ji0U9d5MTqUAU/pPvTw0QtYpdOPaf824tt0RQV/FCvHI6hxcXrqxlieTZ5
         sEFBqzjU90W/g/tmbid67Ic2T/SwBRD7dD2YJ5M21D1rEG79ckO3qUIBwbgbthY9GmJn
         aOZfu3S51SxKkzc8Q1Xw2plCjDqNovDayX6+eAgyDVlI6edVpc/EHnz+ix3gocitbCdN
         ttHEFTA5X199qe8WGNqbyt2wGozpD7fAdnyiAH1SxjH/be2Snh4MJ/U4SlQW35B9PaSu
         xx0hpNJHqVmHx6l34LE5EV+vZC1hp/rjFQv+YYlpCzfZ8HJRZ8QbBFufzfpo+Y/GKDzt
         bk5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=date:message-id:mime-version:references:in-reply-to:subject:to:from;
        bh=VGfA2viVTRzghiX+yDY3Oq7m8eHtoW/R5MZIixU4LX8=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=AXc9JOwFNyVlxGtcItIwSC3OROUG1C23HBt303C9ZK6Tfs5FLqHEVGMyJRjARZ0eJL
         rQR3LTeHdKj7cC/6/zw/cblgCLMXV4nTqje6pmrVXzTGMrcSjcWsIsnNQ699nT+geEN4
         LDg3VZWtfmO/lJdKAbMAiZUL6wTUQWlsgD74ouWA8fcjsx9c19Qe3tnS1eMa1bg4lO2f
         CxlVfw4S7vPYSSKLOxMjRWc1yShqnSDbnXWbagqNamoPjHrFOBzNU3B6Z7ugWiDVE+RF
         0dzfwxIuqFVkF2scBBxE4C3XaiNWjRE+8NZdQBzZgzLxU+UIZGJuFwg7SWUM1+ksKsjw
         bONw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
Received: from mail.i2pproject.net (mail.i2pproject.net. [91.143.83.7])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-54ea94b22basi369581e87.1.2025.05.06.18.32.55
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 06 May 2025 18:32:55 -0700 (PDT)
Received-SPF: pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) client-ip=91.143.83.7;
Received: from i2prouter.i2p.net ([81.7.8.99] helo=smtp.postman.i2p)
	by mail.i2pproject.net with esmtp (Exim 4.96)
	(envelope-from <pithosian@i2pmail.org>)
	id 1uCTeW-000LgP-2v
	for bitcoindev@googlegroups.com;
	Wed, 07 May 2025 03:32:55 +0200
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: pithosian <pithosian@i2pmail.org>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
In-Reply-To: <20250502064744.92B057C0EE2@smtp.postman.i2p>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <20250502064744.92B057C0EE2@smtp.postman.i2p>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/JzE4jY9/oHVAAJ9BIwZcyyg";
 protocol="application/pgp-signature"; micalg=pgp-sha256
X-Virus-Scanned: clamav-milter 0.103.X on milter.postman.i2p
Message-Id: <20250507012038.3EAE07C10F1@smtp.postman.i2p>
Date: Wed,  7 May 2025 01:20:38 +0000 (UTC)
X-Spam-Score: -4.4 (----)
X-Original-Sender: pithosian@i2pmail.org
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as
 permitted sender) smtp.mailfrom=pithosian@i2pmail.org
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.8 (/)

--Sig_/JzE4jY9/oHVAAJ9BIwZcyyg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri,  2 May 2025 06:47:44 +0000 (UTC)
Greg Maxwell <gmaxwell@gmail.com> wrote:

>=20
> On Thursday, April 17, 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot wro=
te:
>=20
>=20
> 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.=20
>=20
>=20
> 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.
>=20
> When relay policy is more restrictive than what is actually being
> mined there are at least two serious negative effects.
>=20
> 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.
>=20
> 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).
>=20
> 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).=20
>=20
> So on this basis I suggest a principle for these sorts of policy:
> Relay rules should admit all transactions which are reliably being
> mined.
>=20
> I think node software should adopt this principal as a general rule.
>=20
> 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.
>=20
> By general rule I mean that should something like a miner begin
> mining e.g. quadratic hashing bloat legacy txn, or using unused=20
> opcode/successcode/version number or whatever by mistake or technical=20
> 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.
>=20
> 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.=20
>=20
> 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.=20
>=20
> [*] 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.
>=20
>=20
>=20

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.

--=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/=
20250507012038.3EAE07C10F1%40smtp.postman.i2p.

--Sig_/JzE4jY9/oHVAAJ9BIwZcyyg
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRRMC5x24QeIt/G0ToEIsEasH71tAUCaBq1ZAAKCRAEIsEasH71
tP6aAP9yPE3iIjGd08DMjHf3fmbTy1mWvtIqltray+JsW8JBJQEAjRXIeU5midwh
Fgsh0gETE041UDX30wNIuTQLiTRrbgY=
=mLPY
-----END PGP SIGNATURE-----

--Sig_/JzE4jY9/oHVAAJ9BIwZcyyg--