Bitcoin Forum
March 19, 2024, 03:16:02 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Feature proposal: bitcoind tx-forwarding  (Read 898 times)
etotheipi (OP)
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
October 23, 2011, 06:01:43 PM
 #1

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. 

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
1710818162
Hero Member
*
Offline Offline

Posts: 1710818162

View Profile Personal Message (Offline)

Ignore
1710818162
Reply with quote  #2

1710818162
Report to moderator
1710818162
Hero Member
*
Offline Offline

Posts: 1710818162

View Profile Personal Message (Offline)

Ignore
1710818162
Reply with quote  #2

1710818162
Report to moderator
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710818162
Hero Member
*
Offline Offline

Posts: 1710818162

View Profile Personal Message (Offline)

Ignore
1710818162
Reply with quote  #2

1710818162
Report to moderator
1710818162
Hero Member
*
Offline Offline

Posts: 1710818162

View Profile Personal Message (Offline)

Ignore
1710818162
Reply with quote  #2

1710818162
Report to moderator
1710818162
Hero Member
*
Offline Offline

Posts: 1710818162

View Profile Personal Message (Offline)

Ignore
1710818162
Reply with quote  #2

1710818162
Report to moderator
dogisland
Sr. Member
****
Offline Offline

Activity: 262
Merit: 250



View Profile
October 24, 2011, 08:02:44 AM
 #2

I totally agree with this.

If you want to use Bitcoin to send and receive payments and you don't want to use the built in wallet then this functionality is essential.
mndrix
Michael Hendricks
VIP
Sr. Member
*
Offline Offline

Activity: 447
Merit: 258


View Profile
October 24, 2011, 02:03:43 PM
 #3

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.
etotheipi (OP)
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
October 24, 2011, 10:50:57 PM
 #4

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. 


Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!