The size of the blockchain...

[Peter R]

…is pretty small.  It fits on the tip of a finger with enough space (46 GB free, 18 GB used) to grow for another 1-3 years.  





This got me thinking: does anyone have bitcoind running on an ARM processor?  It seems it should be possible to create a "bitcoin node" based on an ARM processor, a microSD card, and a simple ethernet interface IC.   The entire node would be only slightly larger than the RJ-45 connector on the mating ethernet cable.


(Yes, I know about raspberry-pis, but this would be vastly smaller, cheaper.)  

[telepatheic]

does anyone have bitcoind running on an ARM processor?

People have got it running on raspberry pis. The amount of memory (RAM) you require is the main problem.

[skooter]

does anyone have bitcoind running on an ARM processor?

People have got it running on raspberry pis. The amount of memory (RAM) you require is the main problem.

Yeah, storing the data is no prob. You can't use it without a lot of RAM though.

[durrrr]

I don't understand what u mean here won't the memory stick always be the same size and shouldn't change?

[Peter R]

does anyone have bitcoind running on an ARM processor?

People have got it running on raspberry pis.

Thanks.  I do know about the raspberry pis, but I'm thinking even smaller: a tiny little custom board with only the bare minimum hardware required to run bitcoind.  Perhaps the ARM processor could still run linux, or perhaps in the future we could write a version of bitcoind that implemented its own simple OS (as is commonly done for DSP projects).  

The amount of memory (RAM) you require is the main problem.

I suppose you need enough RAM to pool the unconfirmed transactions, right?  A 64 MB chip could hold around 100,000 TXs.   Here's a 64 MB SDRAM chip that is only 6mm x 8mm in size and costs about $1.50: http://www.digikey.com/product-detail/en/AS4C4M16S-6BIN/1450-1077-ND/4531924

[skooter]

does anyone have bitcoind running on an ARM processor?

People have got it running on raspberry pis.

Thanks.  I do know about the raspberry pis, but I'm thinking even smaller: a tiny little custom board with only the bare minimum hardware required to run bitcoind.  Perhaps the ARM processor could still run linux, or perhaps in the future we could write a version of bitcoind that implemented its own simple OS (as is commonly done for DSP projects).  

The amount of memory (RAM) you require is the main problem.

I suppose you need enough RAM to pool the unconfirmed transactions, right?  A 64 MB chip could hold around 100,000 TXs.   Here's a 64 MB SDRAM chip that is only 6mm x 8mm in size and costs about $1.50: http://www.digikey.com/product-detail/en/AS4C4M16S-6BIN/1450-1077-ND/4531924

bitcoin QT can sometimes use upwards of 1 GB of RAM.

[Mobius7]

I don't understand what u mean here won't the memory stick always be the same size and shouldn't change?

What memory stick? OP was talking about ARM processor and microSD card.

[Peter R]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

Well there's your problem skooter up there in bold.  We are talking about a custom implementation of bitcoind to create a tiny and low-cost bitcoin node.  We don't even need a wallet implementation, and we definitely don't need the QT GUI (there's no display lol).

[telepatheic]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

With some custom settings to limit what gets held in memory, you could get this down to less than 10MB, but it would require a fair bit of work.

[cypherdoc]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

Well there's your problem skooter up there in bold.  We are talking about a custom implementation of bitcoind to create a tiny and low-cost bitcoin node.  We don't even need a wallet implementation, and we definitely don't need the QT GUI (there's no display lol).

bitcoind requires at least 1GB of RAM and usually more.

[Soros Shorts]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

With some custom settings to limit what gets held in memory, you could get this down to less than 10MB, but it would require a fair bit of work.

Whatever work is done must not slow down the speed at which the node works. You would be doing the network a disservice if your node took a long time to validate and relay messages and blocks because of your low memory footprint and under-powered CPU configuration.

[Peter R]

bitcoind requires at least 1GB of RAM and usually more.

Thanks Cypherdoc.  I am trying to make sense of this: is this because bitcoind is loading the unspent outputs into RAM for faster checking?  My intuition is still telling me that for a custom implementation I just need enough RAM to comfortably pool the unconfirmed transactions.

[Peter R]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

With some custom settings to limit what gets held in memory, you could get this down to less than 10MB, but it would require a fair bit of work.

Whatever work is done must not slow down the speed at which the node works. You would be doing the network a disservice if your node took a long time to validate and relay messages and blocks because of your low memory footprint and under-powered CPU configuration.

I think people underestimate how powerful low-cost DSPs have become.  For example, C. Gouvea was able to verify secp256k1 ECDSA signatures in 700 ms using an ultra-lower power 16-bit microcontroller running at a only 8 MHz (and available in a tiny 3 x 3 mm package size).  Even very cheap ARM-core processors ($2 - $4) will typically run at ~150 MHz (and with 32-bit registers).  So let's say signature verification for each received TX takes no more than 20 ms, at which point you can relay the transaction to your other peers.  This seems perfectly acceptable to me.  

The only other issue I can think of is RAM, but I don't see why you can't store the unspent outputs in the SD card itself (new SD cards permit reads in excess of 30 MB/s so I think the time it takes to cross check the outputs in a TX with the blockchain unspent outputs stored in flash will be short compared to the signature verification times [20 ms]).  It seems you just need sufficient RAM to pool the unconfirmed transactions (and some overhead to accept new blocks, etc), so upon first glance the 6x8mm 64 MB IC for $1.50 seems sufficient for this purpose.  

I think such a bitcoin node would be useful if it could be made only a few cm in dimensions, cost less than $10-$15 excluding the SD card, and be trivial to set-up.  

  

[Meuh6879]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

With some custom settings to limit what gets held in memory, you could get this down to less than 10MB, but it would require a fair bit of work.

yes ... and it's very simple : decrease "cache" setting from 100MB to 10MB for example.
i must do this on my dedicated P2P server (because many others tasks work with bitcoin-QT in mode setting).

[cypherdoc]

bitcoind requires at least 1GB of RAM and usually more.

Thanks Cypherdoc.  I am trying to make sense of this: is this because bitcoind is loading the unspent outputs into RAM for faster checking?  My intuition is still telling me that in a custom implementation I just need enough RAM to comfortably pool the unconfirmed transactions.

i'm not sure what's filling up the RAM altho UTXO sounds like a reasonable guess.

according to David Schwartz, bitcoind requires around 650MB.  sounds about right.  see here:

http://bitcoin.stackexchange.com/questions/8400/to-what-is-bitcoind-memory-usage-bound

and here:

https://bitcointalk.org/index.php?topic=313321.0

here's a top from one of my vps's:

[skooter]

bitcoin QT can sometimes use upwards of 1 GB of RAM.

With some custom settings to limit what gets held in memory, you could get this down to less than 10MB, but it would require a fair bit of work.

Whatever work is done must not slow down the speed at which the node works. You would be doing the network a disservice if your node took a long time to validate and relay messages and blocks because of your low memory footprint and under-powered CPU configuration.

I think people underestimate how powerful low-cost DSPs have become.  For example, C. Gouvea was able to verify secp256k1 ECDSA signatures in 700 ms using an ultra-lower power 16-bit microcontroller running at a only 8 MHz (and available as in a tiny 3 x 3 mm package size).  Even very cheap ARM-core processors ($2 - $4) will typically run at ~150 MHz (and with 32-bit registers).  So let's say signature verification for each received TX takes no more than 20 ms, at which point you can relay the transaction to your other peers.  This seems perfectly acceptable to me.  

The only other issue I can think of is RAM, but I don't see why you can't store the unspent outputs in the SD card itself (new SD cards permit reads in excess of 30 MB/s so I think the time it takes to cross check the outputs in a TX with the blockchain unspent outputs stored in flash will be short compared to the signature verification times [20 ms]).  It seems you just need sufficient RAM to pool the unconfirmed transactions (and some overhead to accept new blocks, etc), so upon first glance the 6x8mm 64 MB IC for $1.50 seems sufficient for this purpose.  

I think such a bitcoin node would be useful if it could be made only a few cm in dimensions, cost less than $10-$15 excluding the SD card, and be trivial to set-up.  

  

I think write endurance would be an issue if you're trying to use an SD card as RAM.

[Peter R]

I think write endurance would be an issue if you're trying to use an SD card as RAM.

We aren't talking about using a SD card for RAM.  The SD card would be used to store the blockchain, update the blockchain with new blocks, update the unspent outputs each block, and bootload code segments of the bitcoin binary.  Typically, flash memory is rated between 100,000 - 1,000,000 write/erase cycles (2 - 19 years if cycles happen every 10 min) and that's always writing the same segment over and over.  With intelligent disk management to avoid "hot spots," this could be greatly increased.  So I would expect even low-grade memory cards to last many years.

But skooter you don't really care about what we are talking about anyways, as can be verified by your post history as a troll and the glaring red warning in your profile (EDIT: suggesting you are also a scammer).  

[Lauda]

We aren't talking about using a SD card for RAM.  The SD card would be used to store the blockchain, update the blockchain with new blocks, update the unspent outputs each block, and bootload code segments of the bitcoin binary.  Typically, flash memory is rated between 100,000 - 1,000,000 write/erase cycles (2 - 19 years if cycles happen every 10 min) and that's always writing the same segment over and over.  With intelligent disk management to avoid "hot spots," this could be greatly increased.  So I would expect even low-grade memory cards to last many years.

But skooter you don't really care about what we are talking about anyways, as can be verified by your post history as a troll and the glaring red warning in your profile.

Trade with caution. User interested in generating double spends and willing to share profits with miners to defraud others.

This is why he was negative trust rating. That doesn't tell you if someone is a troll or not.
Also the blockchain has grown over the past years but it will be growing at an increasing rate.

[vpitcher07]

I'm not so concerned of the size of the blockchain once it's downloaded. What's more concerning is the bandwidth required to download it. Internet speed (for most) is not keeping pace with the increase in size of harddrives. I personally just got 1MB/s at home and I have cable. That's still a large amount of time to download a 17(?) gig file. Not to mention data caps.

[FeedbackLoop]

This got me thinking: does anyone have bitcoind running on an ARM processor?  It seems it should be possible to create a "bitcoin node" based on an ARM processor, a microSD card, and a simple ethernet interface IC.   The entire node would be only slightly larger than the RJ-45 connector on the mating ethernet cable.

Would be great if someone mounted and sold those for the lazy people who would like to run a full node at lost cost and low work like me .