Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 27 Sep 2022 12:21:35 -0700
Message-Id: <AA9BD913-E5BA-4D70-B3DB-9D83C1BBB62E@voskuil.org>
References: <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
In-Reply-To: <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
To: alicexbt <alicexbt@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Packaged Transaction Relay
Precedence: list

Thanks again for the feedback. Comments inline.

> On Sep 27, 2022, at 02:29, alicexbt <alicexbt@protonmail.com> wrote:
>=20
> =EF=BB=BFHi Eric,
>=20
>=20
>> If by "range" you mean a connected tx subgraph, I don't see why not. But n=
ote that nodes only operate over signed txs. PSBT is a wallet workflow.
>=20
> Matt Corallo mentioned that pre-signed transactions created with low fee r=
ate become an issue when they are broadcasted after a long time and there is=
 a high demand for block space at that moment.

Yes, I understood this. There are many ways that a fee may be created which i=
s too low for propagation.

> Example:=20
>=20
> Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte howe=
ver its taking hours/days to confirm the transaction with such low fee rate.=

>=20
> Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 sat/=
vbyte) for spending same inputs. She broadcasted PSBT3 which got confirmed i=
n a few minutes.=20
>=20
>=20
>> Always. Only signed transactions are accepted. But assuming you are refer=
ring to a transaction that has been produced by a pre-signing workflow, I'm n=
ot sure how this would be distinct from any other tx.
>=20
>=20
> `minfeefilter` for all peers of my node was 0.00001000 at the time of writ=
ing this email. I am assuming nobody creates pre-signed transaction with fee=
 rate below 1 sat/vbyte. How often does it happen that `minfeefilter` is abo=
ve this default value?

I don=E2=80=99t consider node configuration relevant, regardless of its appa=
rent consistency.

>> I'm not sure I follow this, maybe you could reword it. But it seems that y=
ou are saying that CPFP fee-bumping is a problem scenario and the complexity=
 of the proposed solutions are not justified by such scenarios.
>=20
>=20
> Sorry that sentence was confusing. Yes complexity isn't justified for CPFP=
 fee-bumping txs below minimum fee rate.
>=20
>=20
>> There are many node implementations used presently. And of course these a=
re protocol proposals, which presumes more than one implementation.
>=20
>=20
> Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) how=
ever they aren't used by lot of nodes. Based on this [chart][1] 98% nodes us=
e bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin c=
ore contributors and things could be different if even 30% nodes used other i=
mplementations.

I don=E2=80=99t consider such a measure relevant. This is a protocol conside=
ration. Also consider that many nodes are not visible, and aspects of nodes,=
 such as for p2p communication, are embedded into applications such as walle=
ts - which could easily exceed the number of visible nodes.

>> I don't consider this relevant to any protocol considerations. Miners sho=
uld always be expected to select the most optimal set of txs available in th=
e time available to do so.
>=20
>=20
> Agree, miners should be expected to select most optimal set of txs. Howeve=
r, according to one [comment][2] by Pieter Wuille, miners could affect the s=
ecurity of some bitcoin projects with MEV.

This would be a deficiency in such projects, by assuming economic irrational=
ity. The fact that fees will become a greater percentage of the block reward=
 is a surprise to no one.

>> Over time we are likely to see that the only policies that remain in wide=
spread application are those that are necessary for DOS protection (fee rate=
), as other restrictions are not economically rational and cannot be enforce=
d. We've seen recent debate regarding dust policy, and op_return policy. "no=
n-standard" txs are perfectly valid but get stuck very easily. I'll reiterat=
e, any policy beyond what is published via the protocol will cause the above=
 problems.
>=20
> I completely agree with this.
>=20
>=20
> [1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
> [2]: https://bitcoin.stackexchange.com/questions/107787/front-running-in-b=
itcoin#comment123441_107796
>=20
>=20
> /dev/fd0