Broadcast a transaction to specific nodes

ghost commented at 2:47 pm on May 7, 2021: none

Is your feature request related to a problem? Please describe. There is no argument in sendrawtransaction to mention the peers

Describe the solution you’d like Add an argument in sendrawtransaction that accepts one or more addresses for nodes.

Describe alternatives you’ve considered

https://github.com/libbtc/libbtc#send-a-raw-transaction-to-specific-peers-on-mainnet-and-show-debug-infos-use-a-timeout-of-5s

Additional context

Note that the transaction will be sent unconditionally to all peers, so using this for manual rebroadcast may degrade privacy by leaking the transaction’s origin, as nodes will normally not rebroadcast non-wallet transactions already in their mempool.

https://bitcoincore.org/en/doc/0.21.0/rpc/rawtransactions/sendrawtransaction/

Rebroadcast thing mentioned above will be fixed in #21061 however this option will still be useful.

unknown added the label Feature on May 7, 2021

michaelfolkson commented at 4:09 pm on May 8, 2021: contributor

What would this feature be used for? Why would you want to broadcast a transaction to one specific peer and not other peers? Do you know what is used for in libbtc?

ghost commented at 10:45 am on May 9, 2021: none

What would this feature be used for? Why would you want to broadcast a transaction to one specific peer and not other peers?

Privacy: Ensure that your transactions cannot be linked to your IP address Freedom: Users will have more control over the peers selected for broadcasting a transaction.

There can be different setups a user or any open source wallet using Bitcoin Core in the backend might want to try for broadcasting transactions.

Two examples:

User checks outbound connections and randomly select 1-2 peers for each transaction while broadcasting. If the node has 8 outbound connections, 2 out of 8 are spy nodes, they wont know about each transaction broadcasted.
User wants to create a setup similar to Dandelion with short stem and guard node like Tor.

A: Node used by Alice regularly for broadcasting transactions B: Another node managed by Alice C: Random node in Bitcoin peer to peer network

Assume we also have two options in bitcoin.conf. One can be used to save addresses for nodes that will used for broadcasting transactions, so we don’t mention it for every transaction. Other option to randomly select one peer from outbound connections for broadcasting.

Setup 1: Node A broadcasts all transactions to only B. Node B randomly selects one peer from outbound connections to relay this transaction. Node C is using default options to it relays all transactions to all the peers.

Setup 2: Node A broadcasts most of the transactions to B. Node B works same as C in this case and relays all transactions to all peers.

Do you know what is used for in libbtc?

Not sure.

Other alternatives for privacy are Tor and i2p. Only 20% nodes use Tor according to Bitnodes and i2p support is recently merged. I don’t expect 100% usage of Tor/i2p ever and few ipv4/ipv6 nodes should exist for reasons mentioned in docs/tor.md. Not sure Dandelion will be implemented in Bitcoin so adding such option can only help in improving privacy for users or making things difficult for spy nodes.

Yihen-Liu commented at 10:27 am on August 18, 2021: none

+1

Yihen-Liu commented at 10:46 am on August 18, 2021: none

“sendrawtransaction to mention the peers”， I think you can make bitcoin-cli connect to special bitcoind daemon what is your mention peers.

ghost commented at 12:33 pm on August 18, 2021: none

Yes it can be a workaround.

0torify bitcoin-cli -rpcconnect=vazr3k6bgnfafmdpcmbegoe5ju5kqyz4tk7hhntgaqscam2qupdtk2yd.onion -rpcport=1309 -rpcuser=user3 -rpcpassword=password3 sendrawtransaction "02000000000101ea84d33abece87ba08d5cf7a31d70a9cfc74413d7cad741c52c5005a5ad8124d0000000000fdffffff0240420f0000000000160014a68d4fc082099435b4a47fc733ab6aebb2b16c662029f529010000001600144c2e7cf3b7f0256b84fb04dcb6050006e675c7990247304402205dfb7bb659b915238b3c4a0cefe5ad910189f0b82a29a4834653a4c7ba1d35d402205a65939bc344bf9fbac55126946be10ffcd963189b2cf5a6775722b5eccabf2d012102579da720a9a87cb33fc2ca4533909a95bc34b2f5229bc4315be0fec13e2a1abe00000000"

So this transaction will be broadcasted BY one of my bitcoin node but eventually it will follow the same process and relay it TO all its peers

The solution that I am looking for would allow us to do something like this:

0$ bitcoin-cli -named sendrawtransaction -hex "02000000000101ea84d33abece87ba08d5cf7a31d70a9cfc74413d7cad741c52c5005a5ad8124d0000000000fdffffff0240420f0000000000160014a68d4fc082099435b4a47fc733ab6aebb2b16c662029f529010000001600144c2e7cf3b7f0256b84fb04dcb6050006e675c7990247304402205dfb7bb659b915238b3c4a0cefe5ad910189f0b82a29a4834653a4c7ba1d35d402205a65939bc344bf9fbac55126946be10ffcd963189b2cf5a6775722b5eccabf2d012102579da720a9a87cb33fc2ca4533909a95bc34b2f5229bc4315be0fec13e2a1abe00000000" -peer [1,2]

So above command will only relay this transaction TO peer 1 and peer 2 ignoring others without affecting anything else.

Yihen-Liu commented at 5:01 am on August 19, 2021: none

Yes it can be a workaround.

0torify bitcoin-cli -rpcconnect=vazr3k6bgnfafmdpcmbegoe5ju5kqyz4tk7hhntgaqscam2qupdtk2yd.onion -rpcport=1309 -rpcuser=user3 -rpcpassword=password3 sendrawtransaction "02000000000101ea84d33abece87ba08d5cf7a31d70a9cfc74413d7cad741c52c5005a5ad8124d0000000000fdffffff0240420f0000000000160014a68d4fc082099435b4a47fc733ab6aebb2b16c662029f529010000001600144c2e7cf3b7f0256b84fb04dcb6050006e675c7990247304402205dfb7bb659b915238b3c4a0cefe5ad910189f0b82a29a4834653a4c7ba1d35d402205a65939bc344bf9fbac55126946be10ffcd963189b2cf5a6775722b5eccabf2d012102579da720a9a87cb33fc2ca4533909a95bc34b2f5229bc4315be0fec13e2a1abe00000000"

So this transaction will be broadcasted BY one of my bitcoin node but eventually it will follow the same process and relay it TO all its peers

The solution that I am looking for would allow us to do something like this:

0$ bitcoin-cli -named sendrawtransaction -hex "02000000000101ea84d33abece87ba08d5cf7a31d70a9cfc74413d7cad741c52c5005a5ad8124d0000000000fdffffff0240420f0000000000160014a68d4fc082099435b4a47fc733ab6aebb2b16c662029f529010000001600144c2e7cf3b7f0256b84fb04dcb6050006e675c7990247304402205dfb7bb659b915238b3c4a0cefe5ad910189f0b82a29a4834653a4c7ba1d35d402205a65939bc344bf9fbac55126946be10ffcd963189b2cf5a6775722b5eccabf2d012102579da720a9a87cb33fc2ca4533909a95bc34b2f5229bc4315be0fec13e2a1abe00000000" -peer [1,2]

So above command will only relay this transaction TO peer 1 and peer 2 ignoring others without affecting anything else.

suggestion: peer 1 can be formatted as “rpcconnect1:rpcport1:rpcuser1:password1”

Yihen-Liu commented at 5:14 am on August 19, 2021: none

to be honest, I don’t agree to add new feature for broadcasting to specific nodes; we can do this easily as for shell script:

0torify bitcoin-cli -rpcconnect=rpcconnect1.onion -rpcport=port1 -rpcuser=user1 -rpcpassword=password1 sendrawtransaction "raw transaction with hex"
1
2torify bitcoin-cli -rpcconnect=rpcconnect2.onion -rpcport=port2 -rpcuser=user2 -rpcpassword=password2 sendrawtransaction "raw transaction with hex"
3
4torify bitcoin-cli -rpcconnect=rpcconnect3.onion -rpcport=port3 -rpcuser=user3 -rpcpassword=password3 sendrawtransaction "raw transaction with hex"
5
6...

sipa commented at 12:38 pm on August 19, 2021: member

@NullBeings I assume @prayank23 means to have a feature broadcast to specific nodes through the P2P protocol, not RPC (as the latter is private and generally not exposed to the internet even). Still, there are existing tools for doing so.

Yihen-Liu commented at 2:42 am on August 20, 2021: none

Thanks for your mention @sipa; P2P protocol has implemented this feature, starting daemon with connect parameter:

0-connect=<ip>
1      Connect only to the specified node; -noconnect disables automatic
2      connections (the rules for this peer are the same as for
3      -addnode). This option can be specified multiple times to connect
4      to multiple nodes.

maflcko commented at 3:24 pm on August 11, 2022: member

See #https://github.com/bitcoin/bitcoin/issues/14692 and #https://github.com/bitcoin/bitcoin/issues/19042

maflcko closed this on Aug 11, 2022

ghost commented at 3:40 pm on August 11, 2022: none

See ##14692 and ##19042

Both issues are related to tor whereas this issue isn’t about broadcasting to tor nodes.

jonatack commented at 3:45 pm on August 11, 2022: contributor

So above command will only relay this transaction TO peer 1 and peer 2 ignoring others without affecting anything else.

As @Yihen-Liu mentioned above, my first thought would be to use -connect=<ip> to connect only to the specified node(s).

ghost commented at 3:48 pm on August 11, 2022: none

So above command will only relay this transaction TO peer 1 and peer 2 ignoring others without affecting anything else.

As @Yihen-Liu mentioned above, my first thought would be to use -connect=<ip> to connect only to the specified node(s).

Isn’t it different if my node connects to a node for broadcasting transaction vs my node randomly selects one node from list of peers?

bitcoin locked this on Mar 22, 2024

Broadcast a transaction to specific nodes #21876