Delivery-date: Fri, 06 Sep 2024 13:39:17 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) client-ip=2607:f8b0:4864:20::134;
MIME-Version: 1.0
References: <3c384b8e-fc91-4c30-95de-6856721e3318n@googlegroups.com> <ZtreUBJU21w1SYQx@petertodd.org>
In-Reply-To: <ZtreUBJU21w1SYQx@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 6 Sep 2024 20:52:14 +0100
Message-ID: <CALZpt+FgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR8mxwAQ@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal to upgrade the transaction relay protocol
 to a new version
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000004784a062178bfcb"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Hi Peter,

> Your BIP is really incomplete without a discussion of what clients make
use of
> unannounced tx messages, their goals for doing it, and how they are
expected to
> achieve those goals once all nodes discontinue unannounced tx messages.

The BIP is only applying effects for _upgraded_ peers and for now there is
no
code implementation to activate the halting of unannounced transactions
messages
towards non _upgraded_ peers, so non-upgraded clients are expected to do
nothing.

If you have a more wiseful transaction relay protocol upgrading deployment
in mind,
you can detail it. Personally, it might be wise in the future to always let
few inbound
slots to non-upgraded peers...?

One can have a look on what is done by bitcoinj, which is the oldest
library used
to build wallets in the bitcoin ecosystem, notably I think Bitcoin Wallet:
https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bit=
coinj/core/TransactionBroadcast.java#L182

> It seems to me that implementing wallets with good UX could become a lot
more
> difficult if this change results in it taking significantly longer for a
tx to
> be broadcast. I don't know if it will. But you need to address this issue=
.

No, this BIP should change nothing for non-upgraded wallets as their
unannounced
transaction messages should still be processed the same by upgraded peers.

Never heard that bitcoin non-documented transaction-relay set of messages
were
making any reliability guarantee on transaction delivery, like TCP is doing
so.

If someone wishes to introduce such a reliability mechanism, after
considering what
is the best approach between point-to-point or end-to-end, I'll note that
such
BIP proposal about a new node service bit should make it easier to do so.

Split the BIP in 2 proposals to dissociate the signaling mechanism from the
transaction
message processing mechanism, here following UNIX philosophy about
modularity:
- https://github.com/bitcoin/bips/pull/1663
- https://github.com/bitcoin/bips/pull/1664

Best,
Antoine
ots hash: 3ea684a09c2db91070296f082e78059946c5c1e987de2a590e2c9bd9fd139c02

Le ven. 6 sept. 2024 =C3=A0 11:49, Peter Todd <pete@petertodd.org> a =C3=A9=
crit :

> On Thu, Sep 05, 2024 at 03:49:55PM -0700, Antoine Riard wrote:
> > Hi list,
> >
> > Opened a BIP draft proposing to introduce an upgrade of the transaction
> > relay protocol by introducing a new node bit service:
> > https://github.com/bitcoin/bips/pull/1663
> >
> > For the movitations, see this old email thread from 2021:
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
391.html
>
> Your BIP is really incomplete without a discussion of what clients make
> use of
> unannounced tx messages, their goals for doing it, and how they are
> expected to
> achieve those goals once all nodes discontinue unannounced tx messages.
>
> It seems to me that implementing wallets with good UX could become a lot
> more
> difficult if this change results in it taking significantly longer for a
> tx to
> be broadcast. I don't know if it will. But you need to address this issue=
.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CALZpt%2BFgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR8mxwAQ%40mail.gma=
il.com.

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

<div dir=3D"ltr">Hi Peter,<br><br>&gt; Your BIP is really incomplete withou=
t a discussion of what clients make use of<br>&gt; unannounced tx messages,=
 their goals for doing it, and how they are expected to<br>&gt; achieve tho=
se goals once all nodes discontinue unannounced tx messages.<br><br>The BIP=
 is only applying effects for _upgraded_ peers and for now there is no<br>c=
ode implementation to activate the halting of unannounced transactions mess=
ages<br>towards non _upgraded_ peers, so non-upgraded clients are expected =
to do nothing.<br><br>If you have a more wiseful transaction relay protocol=
 upgrading deployment in mind,<br>you can detail it. Personally, it might b=
e wise in the future to always let few inbound<br>slots to non-upgraded pee=
rs...?<br><br>One can have a look on what is done by bitcoinj, which is the=
 oldest library used<br>to build wallets in the bitcoin ecosystem, notably =
I think Bitcoin Wallet:<br><a href=3D"https://github.com/bitcoinj/bitcoinj/=
blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#=
L182">https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/o=
rg/bitcoinj/core/TransactionBroadcast.java#L182</a><br><br>&gt; It seems to=
 me that implementing wallets with good UX could become a lot more<br>&gt; =
difficult if this change results in it taking significantly longer for a tx=
 to<br>&gt; be broadcast. I don&#39;t know if it will. But you need to addr=
ess this issue.<br><br>No, this BIP should change nothing for non-upgraded =
wallets as their unannounced<br>transaction messages should still be proces=
sed the same by upgraded peers.<br><br>Never heard that bitcoin non-documen=
ted transaction-relay set of messages were<br>making any reliability guaran=
tee on transaction delivery, like TCP is doing so.<br><br>If someone wishes=
 to introduce such a reliability mechanism, after considering what<br>is th=
e best approach between point-to-point or end-to-end, I&#39;ll note that su=
ch<br>BIP proposal about a new node service bit should make it easier to do=
 so.<br><br>Split the BIP in 2 proposals to dissociate the signaling mechan=
ism from the transaction<br>message processing mechanism, here following UN=
IX philosophy about modularity:<br>- <a href=3D"https://github.com/bitcoin/=
bips/pull/1663">https://github.com/bitcoin/bips/pull/1663</a><br>- <a href=
=3D"https://github.com/bitcoin/bips/pull/1664">https://github.com/bitcoin/b=
ips/pull/1664</a><br><br>Best,<br>Antoine<br>ots hash: 3ea684a09c2db9107029=
6f082e78059946c5c1e987de2a590e2c9bd9fd139c02<br></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 6 sept. 2024 =
=C3=A0=C2=A011:49, Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pet=
e@petertodd.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Th=
u, Sep 05, 2024 at 03:49:55PM -0700, Antoine Riard wrote:<br>
&gt; Hi list,<br>
&gt; <br>
&gt; Opened a BIP draft proposing to introduce an upgrade of the transactio=
n <br>
&gt; relay protocol by introducing a new node bit service:<br>
&gt; <a href=3D"https://github.com/bitcoin/bips/pull/1663" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/bitcoin/bips/pull/1663</a><br>
&gt; <br>
&gt; For the movitations, see this old email thread from 2021:<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
1-February/018391.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018391.html</a><br>
<br>
Your BIP is really incomplete without a discussion of what clients make use=
 of<br>
unannounced tx messages, their goals for doing it, and how they are expecte=
d to<br>
achieve those goals once all nodes discontinue unannounced tx messages.<br>
<br>
It seems to me that implementing wallets with good UX could become a lot mo=
re<br>
difficult if this change results in it taking significantly longer for a tx=
 to<br>
be broadcast. I don&#39;t know if it will. But you need to address this iss=
ue.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CALZpt%2BFgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR8mxwAQ=
%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.go=
ogle.com/d/msgid/bitcoindev/CALZpt%2BFgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR=
8mxwAQ%40mail.gmail.com</a>.<br />

--00000000000004784a062178bfcb--