As a BTC client developer who is not interested in modifying the networking behavior/protocol, I see three reasons I need to implement it anyway:

(1) Get new block data as it becomes available on the network

(2) Get transactions that have not yet made it into the blockchain

(3) Broadcast transactions after they have been signed

If I leave bitcoind running, I got (1) covered by watching blk0001.dat. I also have (2) covered by using the new JSON-RPC call "getMemoryPool." However, I do not see anything that covers (3).

Is there a known risk to adding a JSON-RPC call that allows one to hand bitcoind a pre-signed transaction, and have it verify&forward it as if it was received from a peer? If this functionality was available, I believe I (and many other developers) would have everything we need to shortcut the whole networking reimplementation, and instead implement a few JSON-RPC calls. This would be good for both new developers and the BTC network.

This feature might also help with anonymity. Open relay nodes could configure a JSONRPC proxy to allow only this one API. Those wishing to spend anonymously could make a single API call to one of these open relays. A single JSONRPC call is much faster than becoming a full peer in the network, so Bitcoin payments could be quickly spent when driving past an open wifi network.

This feature might also help with anonymity. Open relay nodes could configure a JSONRPC proxy to allow only this one API. Those wishing to spend anonymously could make a single API call to one of these open relays. A single JSONRPC call is much faster than becoming a full peer in the network, so Bitcoin payments could be quickly spent when driving past an open wifi network.

Couldn't this similarly be used for PoS transactions? For instance, you walk up to the cashier in a 7-11 to buy a candy bar. You pull out your phone, but you normally will have to wait 20 seconds for it to find peers and connect to them. Instead, the store's BTC-processor has a small wifi antenna with restricted network "BTC" -- you can instantly connect to it and send the tx to the 7-11 computer which will broadcast for you (assuming you have enough balance in your wallet already). Also, the 7-11 can be guaranteed to see the tx first, instead of having to wait for it to propagate around the world.

I guess all of this has to be considered in the context of: "is there a problem with accepting 'side-channel' tx-data?" I could see an attacker figuring out how to flood/DoS your client by throwing millions of tx's through the side-channel (if they can access it), but perhaps that side-channel can be treated just like another peer and cut-off if something suspicious is detected. I don't see any obvious reasons this would be a risky feature to add.

Alternatively (on the topic of non-instantaneous tx broadcasting)... what percentage of the "networking engine" would you need implemented in order to initiate a "light" connection to bitcoind through localhost? If tx-broadcasting is all I need, then I bet I could implement only a small subset of the networking protocol and still get bitcoind to accept my tx. It looks like I'd only have to implement a few messages for network version exchange, inv msg. I could skip bootstrapping/IRC, flood detection, peer DB building, etc.