public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] About hardware accelerators advantages for full-node (not mining)
@ 2015-07-13 12:55 Alex Barcelo
  2015-07-13 13:47 ` Tier Nolan
  0 siblings, 1 reply; 2+ messages in thread
From: Alex Barcelo @ 2015-07-13 12:55 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

I am searching for guidance and opinion in the subject's matter. I will begin with my use case, too see whether my ideas makes sense or not.

I have a Jetson TK1[1], which is a GPU (CUDA) powered development board. I thought that it may be a power-efficient device (in bitcoin environment), and thought about having it as a full-node. Either as a public full-node, if it makes sense, or a local full-node, to allow my PCs to perform relay onto the bitcoind in the Jetson. My idea is to run a bitcoind daemon on the Jetson as a node with high performance-per-watt (also cheap and repurposable). A pure-CPU implementation of bitcoind will clog the CPU

I assume that there are a bunch of heavy-compute highly-parallel functions which could be "outsourced" to a GPU. I may want to fork and/or contribute on that. However, maybe I am speaking nonsense. I have more background on parallel programming than my knowledge on bitcoin protocol. So, before coding a complete mess, I wanted to hear some opinions on the idea/configuration.

[1] https://developer.nvidia.com/jetson-tk1

[-- Attachment #2: Type: text/html, Size: 1320 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

• * Re: [bitcoin-dev] About hardware accelerators advantages for full-node (not mining)
    2015-07-13 12:55 [bitcoin-dev] About hardware accelerators advantages for full-node (not mining) Alex Barcelo
  @ 2015-07-13 13:47 ` Tier Nolan
    0 siblings, 0 replies; 2+ messages in thread
  From: Tier Nolan @ 2015-07-13 13:47 UTC (permalink / raw)
    Cc: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 795 bytes --]
  
  The main processor load is for signature verification.
  
  This requires a hash function call, some large number maths and an elliptic
  curve operation.  The elliptic curve stuff is the longest step.
  
  This takes around 1ms per signature on normal hardware, but optimized code
  is faster.
  
  The main task is to prove that
  
  R = u1 * G + u2 * Q
  
  G is a constant, and the rest are different per signature.
  
  Some of the core team have created a fast CPU implementation.
  
   https://github.com/bitcoin/secp256k1.git
  
  There was talk of batch verification of signatures.  The process might take
  16 signatures and compute them together.
  
  I think a lot of the benefit of the GPU would be lost due to communication
  bandwidth.  GPU miners benefit from needing very little information to be
  sent to the GPU routine.
  
  [-- Attachment #2: Type: text/html, Size: 1056 bytes --]
  
  ^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-07-13 13:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-13 12:55 [bitcoin-dev] About hardware accelerators advantages for full-node (not mining) Alex Barcelo
2015-07-13 13:47 ` Tier Nolan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox