Streaming the Dash Blockchain to the whole Planet from Geosynchronous Satellites

[Gilemon]

How about beaming the live blockchain around the World using satellite services that would provide free access to the DASH network?

Let me give you an example to illustrate how it could work:

Alice is a prominent mountain guide. She spends most of her time above the timberline with no connection to the rest of the world. She has no interest and very little time to spend in cities. Dealing with the hassle of online banking is the last of her concerns.
Bob is a business owner in a small village in the valley. The village has roads but very expensive and intermittent access to internet with aggressive data caps. His shop sells the food and equipment necessary for organising mountaineering expeditions. Bob also sells Wi-Fi access to traveler and he is a good friend of Alice. He proposes her services online.
Carol lives in a world-class city. Her 23rd floor apartment is connected to internet by gigabit fibre. She is organising her upcoming challenge to the mountains. She wants to climb with Alice. Bob sends Alice’s DASH address to Carol. Carol transfer the agreed amount within the next block. The block is broadcasted by satellite to Bob’s full node. Bob can tell Alice that the transaction has been confirmed and she can book Carol into her schedule.
Alice has her funds secured within the DASH blockchain. She can use them as she wishes, for instance spending them at Bob’s shop next time she goes back to the village.​

The project would be very similar to Outernet (local news, weather, crop prices) or Blockstream (Bitcoin) as it does not require to launch new dedicated satellites into space, but rather rents frequency from existing providers.
It would target applications for the billions of people who still have zero or very limited access to internet due to many factors. These can be due to financial or political reasons or even due to intermittent natural or atmospheric conditions. Living in such a forsaken place half of the year myself, I do realise the importance of filling this gap and of enabling the infinite possibilities that the wild wide world has to offer.

Pros:

1. DASH leading R&D in blockchain broadcasting
2. Serving potential DASH users all over the world in places beyond the reach of the usual internet
3. Increasing decentralisation and optimising distribution
4. Enable off-grid DASH applications (outdoor events, remote festivals, mining)
5. Easier to develop air-gap applications and networks
   
6. Increasing network resiliency in case of localised catastrophic events (disaster, war)
7. Countering political intervention and censorship
8. Countless future application that yet to be discovered

Cons:

1. Cost of satellite capacity leasing per month
2. Some applications can already be addressed with SPV clients (Electrum-DASH)

I would be most interested to hear the thoughts, considerations, or technical challenges the DASH community may have on this proposal.

My company nThinking and I, do have extensive experience dealing with large engineering corporations. We currently work in railway, logistics and telecom industries and we’d be very interested in working on such project. I already have some figures about market price for leasing a test link and I think that is within DASH monthly budget bracket. I also have more technical information references and project scheduling to share as I have already put quite a lot of thought into this. If you’re interested, this will be posted here very soon.

 

[tungfa]

Gilemon is a very good old friend of mine, one of the few who actually understood me when i was constantly babbling about Darkcoin back then

interesting read , i wonder what the community thinks

 

[Name3]

Depending on your fully fleshed out plan this is definitely something that I think would be worth funding! Looking forward to learning about your company, and how you would go about accomplishing this.

 

[stan.distortion]

Hell yes! Another use is simple vending machine type situations when all the machine needs to know is a payment has been made. There was a Bitcoin project for doing something like that with digital radio in Sweden (iirc) a few years back, not sure if it ever gained any ground but something like that with global coverage would open up a lot of options. Dash In Space!!

Fwiw, I met Gilemon at the Dash conference and have no doubts whatsoever that he can make this happen.

 

[Beru]

Can we have a little idea how much it cost to rent what we need to have the dash blockchain supported on satellites.

 

[Gilemon]

Can we have a little idea how much it cost to rent what we need to have the dash blockchain supported on satellites.

Yes this is coming very soon. I'll post this during the week with more technical information.

 

[stan.distortion]

Something keeps niggling at me with this. Ages ago there was a lot of discussion on a distributed courier service using bitcoin, kind of like Uber for post. GPS data as part of multisig was one possible method of handling payments and I'm certain GPS data coupled with satellite broadcasting of transactions opens up some possibility but I can't think what it is :/

 

[Gilemon]

Something keeps niggling at me with this. Ages ago there was a lot of discussion on a distributed courier service using bitcoin, kind of like Uber for post. GPS data as part of multisig was one possible method of handling payments and I'm certain GPS data coupled with satellite broadcasting of transactions opens up some possibility but I can't think what it is :/

Thanks for putting some thoughts into the possible use cases. I'm excited to look at all the doors that this new information pipeline can open for MN applications and the rest of the network.

As I have mentioned, I am working on finalizing a detailed estimate of the proposal I have posted. I am still engaged in discussions in order to establish the most appropriate geographical coverage to price ratio for an initial testing phase. 

The two best candidates so far are Africa on L-Band or Asia on C-Band. The discussions happening at this stage will be very valuable in order to choose the best telecommunication partners for moving to the production phase that intend to cover the rest of the world.

 

[codablock]

Did you check the available bandwidth options? I know that Blockstream Satelite for example is currently limited to 64kbits/s. Their solution uses forward error correction codes to mitigate some of the errors that might happen in transmission. This however reduces the available bandwidth as it adds redundant data to the stream. They are currently able to send just about 1mb per 10 minutes with this. With Dash however, we currently have a maximum of 1mb per 2.5 minutes and at the same time plan to go to much larger blocks. We will easily hit the technical limits here and require a bandwidth that will probably be much too expensive.

The Bitcoin P2P network has some nice block propagation optimizations (compact blocks in Bitcoin Core and XTHIN blocks in Bitcoin Unlimited) which are based on reusing data from local mempools. This reduces very huge blocks to just a few kb if the mempool is warmed up enough. A one-way transmission solution won't be able to use such optimizations. (We plan to add either compact blocks or XTHIN to Dash as well).

Also, there are 2 additional problems with one-way transmission which I currently see as unsolved.
1. How are you going to do the initial block download? If it requires a normal internet connection, you lose most of the benefits. Ok, you can ignore this if you're just interested in new blocks to check for incoming payments, but then you can't do full validation and fully trust the incoming data. People suggested to "simply" buy a DVD or hard drive with pre-loaded blocks and then use a backup internet connection to catch up to the tip of the chain, so that the satellite stream can be used afterwards. TBH, this sounds horrible.
2. What if you loose too much data so that forward error correction does not work? For example, when your node crashes or has to be restarted. Or if you're unlucky and it's too cloudy. You loose blocks in this case and won't be able to extend the nodes chain anymore unless you have a normal internet connection as backup.

There are also a few more problems in combination with Dash specific features. For example, instant send won't be usable because it can't be verified without knowledge about all the running masternodes. This would require additional data to be included into the stream, which would have the same problems as in 1. and 2. from above.

IMHO, streaming blockchain data through satellites is not worth it as long as bandwidth is so low. Also, if there is no way to make this work without a second internet connection...why not use a SPV node then and just connect to 1 or 2 nodes? You'll receive 80 bytes (+ some small overhead) every few minutes and a few kb per incoming transaction.

 

[Gilemon]

That's great you're starting this discussion as your are raising very important questions about the bandwidth requirement. It's truly much appreciated that you're stepping in the nuts and bolts of this complexe undertaking.

Did you check the available bandwidth options?

Yes and indeed we are currently looking into 64kbits/s for C-Band and slightly less for L-Band. L-Band being more expensive as their is less bandwidth available but super cheap to work with on the ground. So it's very adapted for small budget terminals that can withstand harsh weather conditions.

I know that Blockstream Satelite for example is currently limited to 64kbits/s. Their solution uses forward error correction codes to mitigate some of the errors that might happen in transmission. This however reduces the available bandwidth as it adds redundant data to the stream. They are currently able to send just about 1mb per 10 minutes with this. With Dash however, we currently have a maximum of 1mb per 2.5 minutes and at the same time plan to go to much larger blocks. We will easily hit the technical limits here and require a bandwidth that will probably be much too expensive.

We are considering to use 1/3 forward error correction and at 64kbits/s this will still translate to over 200 mb per day. To my understanding it's plenty enough to keep the blockchain synchronised but I'd be very interested to learn more about the maximum of 1mb per 2.5 minutes requirement.

Also we are also currently testing both Blockstream (Ku-Band) and Outernet (L-band) in order to assess the performance of these solutions.

The Bitcoin P2P network has some nice block propagation optimizations (compact blocks in Bitcoin Core and XTHIN blocks in Bitcoin Unlimited) which are based on reusing data from local mempools. This reduces very huge blocks to just a few kb if the mempool is warmed up enough. A one-way transmission solution won't be able to use such optimizations. (We plan to add either compact blocks or XTHIN to Dash as well).

Yes you're right not doable with one-way transmission. But once we have tackled the technical and integration challenges of the testing phase, these awesome features can be integrated in a future upgrade phase with bi-directional transmission on ku-Band. This will add some cost on the terminal hardware requirement (bigger dish, low noise LNB), but the endusers who are interested in these features will have an incentive to upgrade accordingly.

Also, there are 2 additional problems with one-way transmission which I currently see as unsolved.
1. How are you going to do the initial block download? If it requires a normal internet connection, you lose most of the benefits. Ok, you can ignore this if you're just interested in new blocks to check for incoming payments, but then you can't do full validation and fully trust the incoming data. People suggested to "simply" buy a DVD or hard drive with pre-loaded blocks and then use a backup internet connection to catch up to the tip of the chain, so that the satellite stream can be used afterwards. TBH, this sounds horrible.

2. What if you loose too much data so that forward error correction does not work? For example, when your node crashes or has to be restarted. Or if you're unlucky and it's too cloudy. You loose blocks in this case and won't be able to extend the nodes chain anymore unless you have a normal internet connection as backup.

We are planning to develop a scheduler that rebroadcast blocks when their is unused transmission slots. We need to plan it properly, but we're considering to rebroadcast the whole blockchain (4.5G?) every month or even week.

There are also a few more problems in combination with Dash specific features. For example, instant send won't be usable because it can't be verified without knowledge about all the running masternodes. This would require additional data to be included into the stream, which would have the same problems as in 1. and 2. from above.

Yes I agree that InstantSend does not look like a feature that can be easily achieved with geostationary satellite streaming. Especially considering the long ping (<2 seconds) introduced by the distance at which the satellites are.

IMHO, streaming blockchain data through satellites is not worth it as long as bandwidth is so low. Also, if there is no way to make this work without a second internet connection...why not use a SPV node then and just connect to 1 or 2 nodes? You'll receive 80 bytes (+ some small overhead) every few minutes and a few kb per incoming transaction.

We have considered SPV node communication to become an interesting feature that we will add to the broadcasting when we go bidirectional.

Satellites bandwidth is not necessary low if we choose the right frequency and the right satellite. I personally do use bidirectional satellite Internet and I'm quite aware of its performance and limitation. But as someone from Outernet quoted, its is not necessarily straightforward for someone born with a limousine to consider the opportunities that a bicycle can offer to someone who has been on foot all his life.
I do not have disclosed price yet as we still need some time to present it but as I said on my first post I'm quite confident that you'll be nicely surprised. If we can agree that the bandwidths mentioned above are not enough, doubling them is still very affordable. Actually the most expensive part of such project is the effort in integration, development and testing. But when this parts will be done this would become a really interesting framework for the DASH eco systems that can be reused by other means of transmission (other wireless technologies or a land fibre).

As I said above all your points are not just valid concerns but important technical challenges that we need to first consider and then solve. We'll definitely need some help from the developers to do so. I'm actually also trying to help with DASH development myself. So you're more than welcome to continue the discussion here or to contact me if you have time so that we can go over the application requirements and design.

 

[codablock]

We are considering to use 1/3 forward error correction and at 64kbits/s this will still translate to over 200 mb per day. To my understanding it's plenty enough to keep the blockchain synchronised but I'd be very interested to learn more about the maximum of 1mb per 2.5 minutes requirement.

With Dashs avg. block time of 2.5 minutes, we are at 576 blocks per day. With 200mb per day, we'd limit our self to an avg. block size of 0.35mb. Even if we double the bandwidth, we still won't be able to transmit full blocks already. This will immediately be a problem when adoption starts to rise. Yes, currently this won't be a problem, but we definitely want to scale to blocks > 1mb, multiple dozens of mb, even up to max 200mb blocks. We'd easily end up requiring DSL level bandwidth for the satellite stream.

We are planning to develop a scheduler that rebroadcast blocks when their is unused transmission slots. We need to plan it properly, but we're considering to rebroadcast the whole blockchain (4.5G?) every month or even week.

With current block size limits we may have the chain increase by >500mb per day. That'd be >180gb per year. We'll never be able to rebroadcast the full blockchain this way.

We have considered SPV node communication to become an interesting feature that we will add to the broadcasting when we go bidirectional.

If you go bidirectional, then what's the point of a Dash specific broadcasting network? People would have to pay for the uplink in that case. So a normal paid satellite internet connection would do well enough in combination with SPV.

Please don't forget: Blockstream does not want to scale on-chain at any price. They will stick with 1mb as long as possible. Even if Segwit2X succeeds, it's still just 2mb (actually max 4mb, depending on how you calculate it). So whatever works for them, will never work for Dash.

 

[demo]

I strongly support this satellite idea.
I have already consulted the Dash community towards it, one month ago.

If you care mainly for the downstream, then satellite internet access is also an option.

You should search local gateways in the town of your interest that offer this service.

 

[demo]

Did you check the available bandwidth options? I know that Blockstream Satelite for example is currently limited to 64kbits/s. Their solution uses forward error correction codes to mitigate some of the errors that might happen in transmission. This however reduces the available bandwidth as it adds redundant data to the stream. They are currently able to send just about 1mb per 10 minutes with this. .

IMHO, streaming blockchain data through satellites is not worth it as long as bandwidth is so low.

Half knowledge is worse than ignorance. You are simply uniformed. You are simply wrong.

64kbits/s is the average upstream.
The downstream is a lot lot more.

https://en.wikipedia.org/wiki/Satellite_Internet_access
Satellite Internet Characteristics
Maximum downlink rate 1000 Gbit/s
Maximum uplink rate 1000 Mbit/s
Average downlink rate 1 Mbit/s
Average uplink rate 256 Kbit/s

P.S. Thanks for the dumb rate, @stan.distortion. It reveals to the knowledgeable, how dumb you are. It makes them understand the reason why I have so many negative ratings, from stupid like you. If you lie down with dogs, you will get up with fleas..

 

[codablock]

You are ignorant.
64kbits/s is the upload.
The download is a lot more.

We are not talking about consumer level internet broadband connections here. We are talking about global broadcasting with bandwidth leased from satellite networks. The limits and pricing here is not comparable with the type of satellite internet you are talking about. That's why I asked @Gilemon about the available options. That's why I compared it to existing solutions.

If you're suggesting a consumer level internet broadband connection with a satellite (is this even available for consumers?) or modem uplink, then what's the point of broadcasting the blockchain? Just use SPV.

 

[demo]

If you're suggesting a consumer level internet broadband connection with a satellite (is this even available for consumers?) or modem uplink, then what's the point of broadcasting the blockchain? Just use SPV.

For what reason to broadcast the blockchain? China, of course!

Go try your SPV in china, if you dare!

 

[demo]

We are not talking about consumer level internet broadband connections here. We are talking about global broadcasting with bandwidth leased from satellite networks. The limits and pricing here is not comparable with the type of satellite internet you are talking about. That's why I asked @Gilemon about the available options. That's why I compared it to existing solutions.

Please try to understand that satellite internet is UDP (not TCP).
Please, if you dont really understand something, dont talk about it.

 

[codablock]

For what reason to broadcast the blockchain? China, of course!

Go try your SPV in china, if you dare!

I'm speechless by the level of trolling and hijacking you're currently doing. I really don't know what to say. Also, there is so much wrong with your reasoning that I don't even know where to start...and I know it won't help to even start.

Pleaste try to understand that satellite internet is UDP (not tcp)

And again...wtf? Now explain to me please how your http connection magically turn into UDP based connections when you use satellite internet. Actually, please don't explain it. Really, stop hijacking this thread please. You seem to believe that you understand what you're talking about, but you clearly don't. You're mixing up stuff, using info you somehow gathered in completely wrong context. You're not helping this discussion.

 

[demo]

And again...wtf? Now explain to me please how your http connection magically turn into UDP based connections when you use satellite internet..

What are you talking, you ignorant? Do we necessarily need to download the blockchain using only http (unicast)? We have better broadcast it, multicast it, anycast it and geocast it, in case the transmission medium allows it !

 

[Gilemon]

To my understanding when adoption starts to rise, the budget will also increase and we can scale the bandwidth accordingly. When this happens, DASH will already have the infrastructure in place. This will be an optimum return on investment as the price of bandwidth decrease with time (LEO projects deployment for 2020) and volume.

I'm confident bidirectional communication can be achieved for no cost to the end user. The hard part here is to get regulatory approval from the regulatory authority in the country where the ground stations are.

About SPV, I don't think it is necessary to oppose the two. I love light clients, but they have their weakness as well (privacy, security).
For people who don't know what we are talking about here, I invite you to watch this video:

or read the slides here https://breaking-bitcoin.com/slides/SPVSecurity.pdf

I apologize if I have triggered some kind of confrontation even I think it is healthy and necessary.
We need to approach this step by step and avoid putting all the problems and larger arguments at the same time.
The main argument at this stage is the cost of leasing the required bandwidth. As I said before, we do already have these figure, but we still need some time to assess draft feasibility on our side (nThinking) with integration, teleport services and modem procurement. It's realistic to assume that I will be able to share this information here before the end of next week.

To avoid unnecessary heat over the cost discussion, I can tell you already that the cost for covering one satellite footprint (like Asia) for the current requirement of the blockchain are not so far from a professional level internet satellite broadband connection (where I live in Europe for 20mb/s downlink, 10mb/s uplink).

 

[codablock]

I'm confident bidirectional communication can be achieved for no cost to the end user. The hard part here is to get regulatory approval from the regulatory authority in the country where the ground stations are.

Do I understand you correctly that this would require base stations where users would have to connect to so they can send transactions?

For people who don't know what we are talking about here, I invite you to watch this video:

Unfortunately the forum removes the t= parameter from youtube links. Can you tell me at which time it's about SPV security?

To avoid unnecessary heat over the cost discussion, I can tell you already that the cost for covering one satellite footprint (like Asia) for the current requirement of the blockchain are not so far from a professional level internet satellite broadband connection (where I live in Europe for 20mb/s downlink, 10mb/s uplink).

Really looking forward to the numbers.