Bitcoin Forum
December 05, 2016, 02:34:47 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Feature proposal: bitcoind tx-forwarding  (Read 684 times)
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


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!)
1480948487
Hero Member
*
Offline Offline

Posts: 1480948487

View Profile Personal Message (Offline)

Ignore
1480948487
Reply with quote  #2

1480948487
Report to moderator
1480948487
Hero Member
*
Offline Offline

Posts: 1480948487

View Profile Personal Message (Offline)

Ignore
1480948487
Reply with quote  #2

1480948487
Report to moderator
1480948487
Hero Member
*
Offline Offline

Posts: 1480948487

View Profile Personal Message (Offline)

Ignore
1480948487
Reply with quote  #2

1480948487
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480948487
Hero Member
*
Offline Offline

Posts: 1480948487

View Profile Personal Message (Offline)

Ignore
1480948487
Reply with quote  #2

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

Activity: 261



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


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
Legendary
*
expert
Offline Offline

Activity: 1428


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:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!