new RPC: sendrawtransactiontopeer #28636

1. 
   MarnixCroes commented at 8:59 am on October 11, 2023: contributor

   Please describe the feature you’d like to see added.

   new RPC sendrawtransactiontopeer, which sends the raw transaction to a specified peer

   Is your feature related to a problem, if so please describe it.

   Using sendrawtransactiontopeer can be useful for the user when it has a peer it trusts (privacy wise) and wants to (re)broadcast a transaction (to that specific peer).

   Specifically for rebroadcasting, as sendrawtransaction doc contains a fair warning: using sendrawtransaction for manual rebroadcast may degrade privacy by leaking the transaction’s origin. So using a specific trusted peer to rebroadcast seems reasonable.

   Additionally, user might have a Transport v2 connection and it’s biggest worry is his ISP spying on him. In this case the user might want to use (one of) his v2 connected peers for (re)broadcasting the tx.

   Describe the solution you’d like

   new RPC sendrawtransactiontopeer, where the raw tx and peer are specified (somewhat similar to sendmsgtopeer)

   Describe any alternatives you’ve considered

   • have an argument in sendrawtransaction to specify a peer
   • use -connect= to connect only to the specified node(s). (for this, the user would need to restart and disconnect all other peers every time he wants to do it)

   Please leave any additional context

   #21876, similar request but suggesting to add an argument in sendrawtransaction to mention the peer #27509, useful but sendrawtransactiontopeer would still be a good addition imo

   Could this be used by malicious parties (who want to get a better view of the network etc)? Maybe, but they might already be doing that with a modified client.

   In contrary, sendrawtransactiontopeer might make transaction broadcast/relay analysis harder.

2. MarnixCroes added the label Feature on Oct 11, 2023
3. 
   Sjors commented at 9:13 am on October 11, 2023: member

   Adding a peer_id argument to sendrawtransaction (and to send) makes more sense to me, which is what #21876 suggested.
4. 
   maflcko commented at 9:22 am on October 11, 2023: member

   Adding a peer_id argument to sendrawtransaction makes more sense to me, which is what #21876 suggested.

   Not sure. sendrawtransaction requires the transaction to be added to the mempool, which is incompatible with hiding your knowledge about the transaction from other peers, see also #27509.

   I guess it would be easy to implement with the transaction being discarded afterward, and thus lost, if the peer does not relay it. However, that seems better as a new RPC, because the two RPC would be doing mostly different things?

   Additionally, user might have a Transport v2 connection and it’s biggest worry is his ISP spying on him.

   (Unrelated) To fix this longer term, I guess an v2-only option makes sense, once the network supports v2 largely by default.

5. maflcko added the label Brainstorming on Oct 11, 2023
6. maflcko added the label Privacy on Oct 11, 2023
7. maflcko added the label RPC/REST/ZMQ on Oct 11, 2023
8. maflcko added the label P2P on Oct 11, 2023
9. maflcko added the label Mempool on Oct 11, 2023
10. 
    Sjors commented at 9:29 am on October 11, 2023: member

    I guess it would be easy to implement with the transaction being discarded afterward, and thus lost, if the peer does not relay it.

    The send RPC already has an argument to return the hex encoded transaction instead of broadcasting. So here instead we’d want to send it to only one peer and then return the hex if the user wants to retry later (e.g. with sendrawtransaction or indeed a new RPC).

11. 
    ajtowns commented at 8:48 am on November 15, 2023: contributor

    In the meantime, you could presumably do bitcoin-cli sendmsgtopeer 0 "tx" "$txhex"
12. 
    1440000bytes commented at 7:18 pm on November 17, 2023: none

    In the meantime, you could presumably do bitcoin-cli sendmsgtopeer 0 “tx” “$txhex”

    Tried on regtest. Did not work because I could not see the transaction in peer 0’s mempool.

13. 
    vasild commented at 1:18 pm on February 10, 2024: contributor

    Notice that rebroadcast in this way wouldn’t achieve anything if the recipient has the same connections to the network. This is because upon the first receipt of the transaction the peer will announce it to all peers they are connected to and will remember that they have been told about the transaction. When the re-broadcast comes the peer will not announce the transaction a second time to the same peers.

    The broadcast can be done in such a way that you don’t have to trust the peer (privacy wise) if you don’t reveal any identity information to them. You may find #29415 interesting.

Contributors
MarnixCroes Sjors maflcko ajtowns 1440000bytes vasild

Labels
Feature Brainstorming RPC/REST/ZMQ P2P Mempool Privacy