* Re: [bitcoindev] Proposal to upgrade the transaction relay protocol to a new version
2024-09-06 10:49 ` Peter Todd
@ 2024-09-06 19:52 ` Antoine Riard
0 siblings, 0 replies; 3+ messages in thread
From: Antoine Riard @ 2024-09-06 19:52 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3643 bytes --]
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/bitcoinj/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 à 11:49, Peter Todd <pete@petertodd.org> a é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/018391.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
>
--
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BFgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR8mxwAQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4987 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread