C1 Specifications

[snyde...@gmail.com]

While we are at it, we should probably figure out the specifications for the Next Generation.

  1) How much computational power is really necessary ?
  2) Constant Connectivity to the internet at what speed ?

-Gar.

[Jeff Garzik]

Here is a sketch of a current bitcoin node's needs, then extended 6-12 months into the future, somewhat conservatively:

- Temporary storage (RAM): 4 GB
- Persistent storage (SSD): 100 GB
- Average Internet usage: 3.2GB/day incoming and 5.0GB/day outgoing

- CPU usage is within reach of a current ARM CPU. The main tasks are ECDSA signature checking and SHA256 hashing.

It is important that bitcoin data be inexpensive to validate.  Excluding power- and CPU-hungry mining, computational power is not a large factor.

--
You received this message because you are subscribed to the Google Groups "BitSat project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitsat-projec...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[snyde...@gmail.com]

So,,,

It occurs to me that radiation bit hits in the memory and storage may be a significant issue.
ECC memory and Raid storage is probably required, Which is not seen in Cubesats yet.
How vulnerable is the bitcoin blocks to single bit flips ? This will probably be needed in the
B series satellites also.


5GB/day is about 63kbps throughput, which sounds like it will need a geostationary
position or a TDRSS-type system (geostationary relay sat), or at least a high orbit complete
with full time orbital communications.

[Alek Lidtke]

Bit flips can be corrected for using, say, Reed Solomon or Hamming codes (so called memory scrapping where you keep scanning the entire memory, detect bit flips and then replace the corrupt data with the same data that had been stored on a different physical device). There actually is a lot of source code that is freely provided by the European Space Agency: http://www.esa.int/TEC/Microelectronics/SEMK5Z8L6VE_0.html I'm not a S/W engineer so can't tell you how to implement those, but I'm probably going to use some of that in another cubesat project.

Geostationary position is not feasible with a cubesat if you want to communicate with it at 63 kbps. Neither is achieving 100% time coverage - this'd require an extensive ground station network all over the globe. TDRS may be an option, but it'd impose very strict constraints on the transponder that the cubesat would need to carry (it'd presumably cause the cubesat to be much larger than a cubesat = more expensive to build and launch). If you're looking at reducing cost as much as possible the cubesat will have to tag along as a secondary payload, in which case you don't get to choose the orbit too much, just use what other people are fine with sharing with you.

Does every cubesat really need to have 100% up-to-date data on-board an any time instance? This seems to be the main system driver to me i.e. it'll very strongly affect the constellation shape, size, ground station (GS) number and locations as well as the spacecraft (S/C) design itself. So it's important to set this requirement consciously not to make the system too oversized if it need not be. I'm sorry I don't know much about bitcoins.

[Phillip Keane]

There are space hardened Arduino and FPGA flight systems available for CubeSats.  In terms of memory, the older systems are less susceptible to radiation induced bitflips.