Proposal to upgrade the transaction relay protocol to a new version

[Antoine Riard]

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

Cheers,
Antoine
ots hash: 2318085a857650b45583d58a76a966532e973b47800f6aa8927b81ac8b222c81

[Peter Todd]

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

[Antoine Riard]

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