0

I currently have a bitcoind version:80500 running on a VPS. I am interested in using it to only verify transactions for me much the same way blockchain.info does.

Is it possible to run bitcoind to do this? I guess the best analogy to this would be acting as a leecher. Or does it always act as an active node passing transactions etc?

Improve this question
  • This might not be quite what you want. but what about checking out electrum? – Joe White Dec 9 '13 at 5:55
  • There's no way of configuring a node not to relay transactions, as it would be detrimental to the network. You would need to heavily modify bitcoind to manage this, and there's not a huge reason for you to ever want to. What do you think you will achieve by not relaying anthing? It's not what you or the network wants. – Anonymous Dec 9 '13 at 7:52
  • The reason being, to save on bandwidth and cpu cycles – robbywashere Dec 9 '13 at 8:48
  • How much CPU and bandwidth is it using right now, then? – us2012 Dec 9 '13 at 10:26
  • Relaying transactions takes no effort at all really, and if you're not listening then nobody will sync from you and take up large amounts of bandwidth. The CPU impact of bitcoind once synchronised is negligible. – Anonymous Dec 9 '13 at 10:35
1

What you are asking for is not possible with an unmodified version of bitcoind. So I will interpret your question as why not and how to achieve something similar.

Having bitcoin nodes that do not relay transactions is a danger to bitcoin: If nodes start behaving that way, not only do we move a tiny step further towards risking that transactions are stuck because someone sending a transaction does not get them forwarded at all, but more importantly, mining exploits like the one described in the preprint Majority is not enough: Bitcoin Mining is Vulnerable move from the rather theoretical to the practical. In fact, someone trying to implement this exploit might ask pretty much the same question as you do!

So what stops you from just doing it anyways, with a modified version of bitcoind? Nothing, really, except that it seems a bit self-defeating. Consider that as soon as others start perceiving it as a sufficient nuissance (and they should, for reasons of fairness and security!), we'll come up with some modification that will require you to forward at least some transactions or not get transactions forwarded yourself. Or get stuck with only similarly selfish nodes to connect to. That'll be the exact opposite of what you want to achieve for verifying transactions. Just consider that eventually you may only see those transactions more likely to not get propagated all the way to the mining pools!

So what options do you have to limit bandwidth (I doubt you can save much CPU time, anyways)? Here are your options:

  1. You already know the most radical answer: Not running your own copy of bitcoind, and instead use the public APIs of blockchain.info and blockexplorer.com (or some commercial solution). I presume you are not happy with relying on free external services, but considering that there is redundancy (to either deal with individual downtime or to get more than one confirmation). So this super-low bandwidth approach (at least for few transactions to actively monitor) may not be quite as bad as it must sound at first.

  2. Limit the number of nodes your bitcoind connects to. This, unfortunately, is a double-edged sword. It simultaneously limits the data you will send out (fewer peers!) and the data you receive. Hence you have a greater chance of being late to see a transaction, if for whatever reason it did not reach the very few (one?) other node you connected to, or because few peers mean you are at an elevated risk of simultaneously lose connection to all of them, being cut off from the bitcoin network briefly.

  3. Modify your client in a sensible way. Maybe you can live with relaying new transactions, but throttling bulk downloads of the entire blockchain? This could potentially have a huge impact on your outgoing (and total) bandwidth, whilst offering the potential for very sensible overall behavior. Consider that it could even make sense for the mainline bitcoind if alternative means of bulk download of the blockchain could be implemented---and as long as we find mirrors for them, this should be doable. In fact, by putting a "blockchain mirror" part of your site behind a free cloudflare account to serve static content at zero cost, you could do it!

May I suggest that option 3 could be the way to go? If the necessary modifications to bitcoind are a problem for you, I could help (or even do it all), although I am sorry to say I probably couldn't do it for free.

Improve this answer
  • The protocol doesn't support any sort of signalling that they don't want to respond to an inventory request for blocks. At the current point in time, a client's only response is to crash. If you throttle your outgoing connection you tarpit clients trying to sync from you, which is extremely harmful. – Anonymous Dec 9 '13 at 11:08
  • Yes, just starting to become slower in sending old transactions is not enough. You would have to limit (throttle) in a different way. Thanks for pointing out this problem. I was under the impression that e.g. satisfying only a limited number of requests for very old blocks, then refusing (e.g. by disconnecting from that particular client) should not cause any serious disturbance other than slowing its synchronization, as similar disconnects are natural in the Bitcoin network with some not-permanently-on nodes. I'd double check the source code, obviously, before starting this. – pyramids Dec 9 '13 at 11:15
  • My goal would be to have a node which stored the up-to-date blockchain only Who knows, I may also be running some relay nodes out there too! But please, stack-exchange is a Technical Q & A, not an ethical one. Regardless, thanks for some clarification. – robbywashere Dec 9 '13 at 11:30
  • @robbywashere If you are going to be negatively impacting other nodes, I will bring it up. It's as simple as that. It's a technical issue as much it is an ethical one. Just because you're running other nodes doesn't mean that the clients you've connected to your gimped might take months to get the blocks they need. – Anonymous Dec 9 '13 at 11:50
  • @pyramids If you do that you're going to be churning through peers constantly. None of my peers are synchronising but I still get at least a block request every 10 minutes. Just honestly, pay $5 a month for a dedicated bitcoind node and save yourself the bother. At least then you won't be such a bad network citizen. – Anonymous Dec 9 '13 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.