Blockstream has announced a new version of their satellite bitcoin blockchain stream:
https://blockstream.com/2020/05/04/en-announcing-blockstream-satellite-2/It now supports getting the entire blockchain history over the satellite!
I've been beta testing this the last few weeks. The software is still pretty new but it's great.
One of the exciting new technical features in it is that it has an alternative serialization of Bitcoin transactions which is more bandwidth efficient. Any bitcoin transaction can be losslessly converted, one transaction at a time, into this alternative serialization and applied across the whole Bitcoin history it reduces transaction sizes by about 25%.
It saves a little more on older blocks, in part because their transactions have a lot more uncompressed pubkeys and compressing pubkeys is one of the things it does to shrink transactions. Newer blocks are more like 20% smaller using this serialization.
Similar, but somewhat less reduction in size can be achieved by using standard compression tools like xz or zstd on groups of blocks. But because the new serialization in blocksat works a single transaction at a time it's compatible with both transaction relay and fibre's-mempool-powered-reconstruction. (if you do want to work whole-block-at-a-time it can also be combined with traditional compression to get a little more savings).
If a Bitcoin nodes were to use this generally, they could drop their on-disk storage requirement for the full block data by about 25%, they could also negotiate using it with supporting peers and lower their bandwidth used for initial sync and transaction relay. Post erlay, this would give a 15% reduction in the total ongoing bandwidth usage of a node (pre-erlay the bandwidth used by INVs would diminish the gains a lot for anything except history sync).
The cool thing about it is that it's not a consensus change: How you store a block locally, or how two consenting peers share transactions data is no one else's business. This is why blocksat 2.0 can use the new format without anything changing in the rest of the Bitcoin network. Right now the blocksat software only uses this new serialization over the satellite-- where space savings is also critical--, but using it on disk or with other peers wouldn't be a huge addition.
The downsides of the new serialization is that it's more computationally expensive to decode than the traditional one, and of course the implementation has a bit of complexity. I've been pushing for this [sort of idea since 2016](
https://people.xiph.org/~greg/compacted_txn.txt) (note: the design I described in that link is only morally similar, their bitstream is different-- I'd link to docs on it but I don't think there are any yet), so I'm super excited to see it actually implemented!
The history download is pretty neat: Every block is broken into ~1152 byte packets and redundantly coded with 5% + 60 extra packets. A rolling window of about ~6500 blocks is transmitted in interleave, resulting in about one packet from each block in the window per minute. With this setup, which can be adjusted on the sending side, you can take an hour long outage per day or so plus 5% packet loss and not suffer any additional delays in initial sync. If it does lose sync it saves the blocks it completely received--even if it doesn't have their ancestors yet-- and will continue once the history loops back around again. If you have internet access (potentially expensive or unreliable; or maybe even sneaker net!), you could also connect temporarily and just get the chunk of blocks you missed instead of waiting for it to loop around again.
The software was also rebased on 0.19-- their prior stuff had been falling behind a bit.
The satellite signal is doing some neat stuff: They time division multiple two different bitrate streams (one about 100kbit/sec like the original blocksat stream, and one about 1mbit/sec) on the same frequency. The low rate stream can be reliably received with a smaller dish and under worse weather, and only carries new blocks, and transactions. The high rate stream also carries new blocks and transactions (when they show up), but in addition carries the block history. When new blocks come in the data from both streams contribute to how fast you receive the block.
I believe they're recommending an 80cm dish now, mine are 76cm and the signal on both streams is very strong and robust against poor weather. YMMV based on location and weather conditions. The low rate stream should be reliable on pretty small dishes.
This new high rate stream also significantly reduces the latency for transmitting blocks, making it more realistic to mine using blocksat as your primary block feed (and then using $$$ two-way sat to upload blocks when you find one). Right now 4 second latencies are typical though there is some opportunity for software running that should get it consistently closer to 1 second. The updated stream also handles multiple sat feeds more seamlessly-- in some regions you can see two different blocksat feeds, such as in California where I live, and if you have two receivers it'll half the latency to receive blocks (and obviously increase the robustness).
The new setup makes it easier to separate the modem from the bitcoin node. You can have a modem left closer to the dish(es) connected to ethernet (directly w/ their ethernet attached modems, or w/ a usb modem and a rpi) have it send udp multicast across a network to feed one more receiving bitcoin nodes. This can help eliminate long annoying coax runs.
Finally, they also preserved the ability to get the stream with a pure SDR receiver *and* added the ability to use an off the shelf USB DVB-S2 modem, and the DVB modems are more flexible in what LNBs you use... so if you're in a location where getting more blocksat specific hardware is inconvenient or might erode your privacy-- they've got you covered.
All in all, I think this is pretty exciting.
