
Blockstream Satellite API: Pay with BTC via Lightning to Broadcast Data Globally - grubles
https://blockstream.com/2019/01/16/satellite_api_beta_live/
======
g45y45
If bitcoin is to be the global currency, it needs more channels to propagate
than just public internet. Public Internet is too censorship receptive for
system like Bitcoin. Broadcasting the block and tx data to the world via
satellite gets us one step closer. Great work Blockstream!

~~~
bufferoverflow
Bitcoin, Bitcoin Cash and Ethereum (and probably other coins) all work over
SMS. They are actually substrate-agnostic. You can technically deliver your
transaction to a node with a pigeon, as long as the node accepts pigeons.

~~~
xorcist
You need to process incoming transactions as well. It's inconvenient to
receive the blockchain over carrier pigeons.

~~~
VMG
Circumventing censorship is always inconvenient. That is the point of
censorship.

------
adam3us
There is a setup guide by grubles [https://hackernoon.com/building-your-own-
bitcoin-satellite-n...](https://hackernoon.com/building-your-own-bitcoin-
satellite-node-6061d3c93e7) for linux capable people.

------
DavidShares
Quote from Jeff Garzik about the Blockstream satellite:

> It’s cheap to write a check to another satellite provider to do a broadcast
> for you. It’s a centralized data service, with a centralized [satellite]
> provider, and carries plenty of shutdown and censorship risk.

> It’s also a great way to centralize everybody on Blockstream’s version of
> the blockchain, as it appears that Blockstream are the only ones
> transmitting (uplinking) to the satellite.

Why is Blockstream being disingenuous about their satellite service promoting
it as a path to decentralization when in reality it’s a centralized
chokepoint?

Also, why is Blockstream actively destroying BTC’s value proposition by
turning BTC into a settlement layer for the Lightning Network?

~~~
xorcist
Wasn't it Garzik who came up with the first proposal to broadcast the Bitcoin
blockchain over satellite?

As I remember it he went to far as to solicit donations for the project. There
was a lot of articles written about it at the time (Bitcoin! In space!) but
nothing ever came of it.

~~~
cedivad
You are confusing leasing bandwidth on a satellite with having a bitcoin
satellite.

------
nonamenoslogan
Hey look, another interesting idea for blockchain based propagation that will
be niche and forgotten in a few months. Cool tech, but ultimately fucking
useless.

~~~
ENGNR
It's still cool though

If civilisation collapsed, as the power grid shut off, sys admins became
farmers and ISPs collapsed, satellite ground stations go dark, interstate
trade might still be possible through something like this. If it was able to
receive messages and payment from unauthorised satellite dishes on the ground
rather than through a REST API

Being able to slow the collapse of civilisation, the idea is cool even if not
quite this specific implementation

~~~
duskwuff
No, I think you've severely misunderstood what is going on here.

First and foremost: Bitcoin is completely dependent on the availability of
lots of power (for proof-of-work calculations) and network connectivity (to
distribute unmined transactions). Without both of these, it cannot operate.
Adding satellite transmissions to the picture doesn't change this. In any sort
of apocalyptic scenario like what you're imagining, cryptocurrency will be one
of the first technologies to become unusable.

Additionally, all that's going on here is that a company is using several
commercial satellites to transmit the blockchain, as well as some user-
specified data. These satellites do not belong to Blockstream, and are not
controlled directly by Blockstream's clients.

~~~
lowracle
It strikes me how uneducated people on hacker news still are about bitcoin. In
10 years, people didn't even take the time to inform themselves before posting
wrong facts.

>Bitcoin is completely dependent on the availability of lots of power Wrong.
Bitcoin can work even if only one nuclear power station remains. The
difficulty will adjust to the new hash rate, and as long as no single actor
can control more of the nuclear power station than the sum of the miners,
double spending isn't a problem.

As for network connectivity in apocalyptic scenario, miners would only have to
find a way to propagate data to the satellite, and users would only have to
find a way to propagate data to miners. That is a lot less than what the
current financial system would demand to function.

~~~
lawlessone
>the new hash rate

would be 0

~~~
lowracle
Given that a 1 square meter solar panel produces 200W, and the energy
efficiency of an Ebit E10 ASIC miner is 11100 * 10^6 hash per J, you can
compute 200 * 11100 * 10^6 hash per second so no, in an apocalyptic event, the
hash rate will hardly be 0.

------
SiempreViernes
The broadcast is global, the ability to recieve the broadscasts is... uh....
an implementation detail left to the user! (NB: involves satellite dishes)

~~~
RL_Quine
Buy data transmission for an obscure currency, use obscure lightning software
to use the obscure currency to pay a company to transmit data to something you
need to buy dedicated hardware for. Hapless optimism aside it’s hard to see
what benign purpose this could possibly be used for.

It’s sort of strange to bother with anything custom. Bitcoin signatures have a
free, encrypted data channel within ECDSA signatures. You can just broadcast
those through the normal bitcoin network without paying Blockstream.

~~~
r32a_
This is to be used for areas that don't have access to reliable internet

~~~
RL_Quine
For what, exactly. People keep saying this and having nothing backing up why
it could possibly be useful to have a mechanism for receiving broadcast files
with a lot of dedicated hardware required.

~~~
jacobush
Number stations come to mind.

------
sygma
For those wondering about how much the lightning network is actually used,
have a look at the stats [0]. Adoption is growing steadily.

[0]: [https://1ml.com/statistics](https://1ml.com/statistics)

~~~
runeks
One of the problems with LN is that, in order to actually receive BTC (on the
Bitcoin blockchain) that you can sell, you almost certainly need to go through
multiple LN nodes. Due to this, the node in this path with the _smallest_
capacity will determine the maximum amount you can transfer (before needing to
touch the blockchain). From the stats we can see that " _Average Channel
Capacity_ " is 0.025 BTC/$91.77, and that 50% of channels have a capacity of
0.005 BTC/$18.35, which means the minimum, for any given path, is likely close
to $20.

So, in other words, you can expect to transfer, roughly, $20 until you need to
touch the blockchain again (in order to fund a channel), which means that
sending ~$20 over LN is as expensive as doing it in a normal Bitcoin
transaction.

LN doesn't scale because of this. People keep pretending that adding new nodes
is a sign of success, when in fact adding new nodes to LN decreases
performance -- because the smallest-capacity channel on a path determines how
much can be sent through that path until you have to touch the blockchain. If
two or more channels in a path need to be refilled, you've spent _more_ on a
LN transfer than you would have on a regular Bitcoin transaction (on-
blockchain).

~~~
sparkie
The channel capacities in Lightning are currently restricted by an arbitrary
limit of 2^24 satoshis which was put there by the developers to prevent people
from putting too much into what is effectively a beta test network currently.
The limit is already scheduled to be removed in the 1.1 BOLT spec.

There are usually many possible paths for a payment, so the payment limit
isn't the minimum of any possible node along the route, but the _set_ of all
possible routes from one node to another. However, even this is scheduled to
be removed, because LN will get Atomic Multi-Path Payments, which will enable
a payment to traverse multiple routes and only succeed if all of the routes
are successful.

"Refilling" of Lightning channels does not require new on-chain payments - it
can be done directly on the Lightning network by routing payments through
paths which require balances moving in one direction or another. You can route
payments to yourself to reduce your balance in one path and fill it in another
path.

Putting aside large payments for a moment, you're completely ignoring the
potential use-cases for small payments. Currently you can make _thousands_ of
transactions on the Lightning Network, with fees averaging _hundredths of a
cent_. This was possible on Bitcoin in the early days, but clearly cannot
scale because it costs money to store and propagate information on a broadcast
network. Lightning doesn't broadcast any transactions, and doesn't need to
store old transactions. The use cases are left up to your imagination.

If you wish to learn more I recommend reading the BOLT specifications and
subscribing to the lightning-dev mailing list.

~~~
runeks
> There are usually many possible paths for a payment, so the payment limit
> isn't the minimum of any possible node along the route, but the set of all
> possible routes from one node to another.

My main gripe with LN is this: why would I want to route a payment through a
bunch of arbitrary nodes (which may or may not process my transaction), rather
than just establish a connection with a single node, who I pay to guarantee
uptime?

> "Refilling" of Lightning channels does not require new on-chain payments -
> it can be done directly on the Lightning network by routing payments through
> paths which require balances moving in one direction or another.

If we assume the products purchased via LN need to be paid for in national
currency, then on-chain payment _is_ needed in order to refill a channel,
since the merchant (payment receiver) will need to withdraw BTC from LN and
convert to a national currency in order to pay a supplier. If BTC is withdrawn
from LN, then it needs to be deposited again.

If LN isn't supposed to be used for this, then I agree that on-chain
transactions aren't needed, but then LN isn't really a competitor to
traditional payment networks (since you can't buy e.g. a cup of coffee with
it).

> Putting aside large payments for a moment, you're completely ignoring the
> potential use-cases for small payments.

I don't think I am. In order for small payments to be of value, it must be
possible to receive a lot of them, and LN only supports up to ~20M users per
month[1] (while using up the entire capacity of the Bitcoin blockchain).

LN payments have value because they can be redeemed into BTC (on the
blockchain). In order for a payment network to be successful, it must be
fairly cheap to move value through the economic circle composed of 1)
consumer, 2) retailer (merchant), 3) supplier, 4) producer (and then back to
the consumer, in the form of wage paid by a producer). The bottleneck of this
movement is still the Bitcoin blockchain, and LN doesn't do much to help it,
unfortunately.

[1] [https://runeksvendsen.github.io/blog/posts/2017-10-08-no-
bit...](https://runeksvendsen.github.io/blog/posts/2017-10-08-no-bitcoin-
based-protocol-can-handle-more-than-20m-users-per-month.html)

~~~
sparkie
> why would I want to route a payment through a bunch of arbitrary nodes,
> rather than just establish a connection with a single node, who I pay to
> guarantee uptime?

There are already countless systems to do the latter. You can use PayPal,
MasterCard, Stripe, etc, etc. The point of Bitcoin is to eliminate trusted
third-parties. Nobody can guarantee uptime, only give you an empty promise.
Bitcoin can guarantee uptime isn't tied to any one or few parties.

Bitcoin requires anonymous third-parties to propagate your payments to miners.
You aren't an island. The anonymous trustless third-parties who route payments
in LN are just regular users, have no access to information about the payment
they're routing, and are negatively incentivized to be dishonest, because they
have to pay bitcoin transaction fees themselves for any of their own channels
they unilaterally close.

> If we assume the products purchased via LN need to be paid for in national
> currency, then on-chain payment is needed in order to refill a channel,
> since the merchant (payment receiver) will need to withdraw BTC from LN and
> convert to a national currency in order to pay a supplier. If BTC is
> withdrawn from LN, then it needs to be deposited again.

Again, this is nonsense. Exchanges between fiat and bitcoin can operate
directly on the Lightning Network. There's no need to constantly open and
close channels. You would send a direct lightning payment to your exchange to
deposit money, or you would issue a lightning invoice to your exchange to
withdraw money.

> LN payments have value because they can be redeemed into BTC (on the
> blockchain). In order for a payment network to be successful, it must be
> fairly cheap to move value through the economic circle composed of 1)
> consumer, 2) retailer (merchant), 3) supplier, 4) producer (and then back to
> the consumer, in the form of wage paid by a producer). The bottleneck of
> this movement is still the Bitcoin blockchain, and LN doesn't do much to
> help it, unfortunately.

As above, the bottleneck is removed by the consumer, retailer, supplier and
producer all being on the Lightning Network.

In situations where a supplier offers a merchant credit, this is an ideal case
for plain old payment channels. Instead of offering individual Bitcoin
transactions, they can open a payment channel and issue RSMCs when a business
invoice is created or paid. Using a plain payment channel is a missed
opportunity though - because it can only be used by the supplier and merchant.
By connecting that very same payment channel to the LN, opportunities are
opened up for both the merchant and supplier. The merchant can make use of the
suppliers payment channel network to transact with a wider audience, and vice-
versa. They can all save on transaction costs for channel opening and closing
by pooling resources which would otherwise be underutilized.

The Lightning Network is fundamentally an abstract protocol for creating and
connecting different kinds of payment channels, providing encrypted and
authenticated transport, and an onion routed transport for payments.
Currently, theres only one type of payment channel it supports, but this is
simply down to there being few developers with different priorities.

~~~
runeks
> Again, this is nonsense. Exchanges between fiat and bitcoin can operate
> directly on the Lightning Network. There's no need to constantly open and
> close channels. You would send a direct lightning payment to your exchange
> to deposit money, or you would issue a lightning invoice to your exchange to
> withdraw money.

In this world where no LN-transaction touches the Bitcoin blockchain, what's
the reason for having a blockchain in the first place?

~~~
sparkie
The blockchain provides the security, ensuring that nobody can take funds
unilaterally out of a channel. At all times, each party has bitcoin
transactions for the correct channel state, partially signed by the channel's
counter party, which either party can sign at any time to _settle_ the channel
balance on the chain (the settlement can be made to pay automatically into new
lightning channels, although this is not implemented yet.)

It is like a credit line that can be closed by either party at any time, with
the balance settled automatically by an impartial judge - the blockchain.
Without the chain, we'd just have the existing system where you need human
arbitration to settle balances if any party disagrees about their balance.

Bitcoin takes individual humans out of decision making about who owns what
money. That's its fundamental purpose. We can build potentially any number of
transaction systems on top of it, but it is not worth sacrificing the
impartiality of the chain just to get a marginal increase in capacity of on-
chain transactions. The chain's impartiality depends on the network being so
finely distributed that no group can orchestrate control over it. This also
requires that participants can be anonymous.

------
martindale
Congratulations, Blockstream! Great to see this come online. Will Liquid
customers pay extra for this, or is it included?

------
abstrct
Was satellite communication the goal of blockstream all along or did a random
thought/opportunity come around at some point over the last couple years and
it appeared like a good pivot?

~~~
RustyRussell
Not even a pivot, IMHO (Blockstream employee here). Just cool infrastructure
which may even end up paying for itself...

------
adam3us
btw you can see the sent queue and send messages here
[https://blockstream.com/satellite-queue/](https://blockstream.com/satellite-
queue/)

~~~
clayrab
Yeah, but does it support tabs?

~~~
lawn
For context this is Adam Back who said that instead of raising the block size
to avoid the ridiculous fees we should instead use tabs.

[https://www.youtube.com/watch?v=BGfPEZRkn6o](https://www.youtube.com/watch?v=BGfPEZRkn6o)

> So I mean for today, You could have, some bitcoin business have a tab, so
> you pay them and you work your tab there and presumably you can cash your
> tab out if you don't use it. If you have repeat custom... or maybe the shops
> in the local area could make a shared tab or something in anticipation of...
> you know somebody in the local area ... technology expert could make a local
> bitcoin tab that's interoperable between the shops and some sort of app to
> do it.

------
unrealchild
for some reason this strikes me as spectacularly unnecessary

------
NVRM
So this seems useless for payment, but here is the real hidden interest:

You can send a file up to 10Kb, and pay for byte sent.

It's cheap, coast looks to be $0.0035 for a 5Kb file.

The receiver can get the file, encrypted, without internet, using only a SDR
tv card, amplifier and antenna, worldwide, in 10 minutes.

I see there large possible applications!!!

[https://blockstream.com/satellite-queue/](https://blockstream.com/satellite-
queue/)

[https://github.com/Blockstream/satellite#hardware-
requiremen...](https://github.com/Blockstream/satellite#hardware-requirements)

[https://blockstream.com/satellite-api-
documentation/](https://blockstream.com/satellite-api-documentation/)

~~~
RL_Quine
Name even one application.

~~~
NVRM
You are not much into electronics as I can see.

~~~
RL_Quine
You still haven’t managed to explain an application, with all your
imagination.

------
wmf
I wonder why they're using SDR instead of a standard like DVB-S2.

~~~
adam3us
We tried to keep the equipment cost down, to support emerging market. Reusing
existing 45cm/60cm TV satellite dishes is part of it. The usb SDRs cost $10-15
on ebay.

~~~
skoold2003
Was this the motivation for keeping blocks small then? Also, don't you need
duplex links to run a node?

~~~
sparkie
It's one of many reasons to keep blocks small. Ability to send over many kinds
of restricted bandwidth mediums, including the Tor network is part of it.
Other concerns are bandwidth caps/monthly limits, storage costs, validation
times (which affect negatively affect miners).

Some other hardforks of Bitcoin which promoted themselves for having bigger
blocks, have had examples where block validation times have exceeded the
average block mining time of 10 minutes. Obviously not suitable for running on
a Raspberry Pi.

Bitcoin depends on its network being widespread and diverse. Any increase in
the requirements to run node will create centralization pressure which does
not help. The goals of big blockers are to have just one or a few big data
centres hosting bitcoin and everyone else connecting to them. We already have
PayPal for that.

~~~
lawn
> Some other hardforks of Bitcoin which promoted themselves for having bigger
> blocks, have had examples where block validation times have exceeded the
> average block mining time of 10 minutes.

Such a ridiculous counter argument.

The only fork that had a long propagation time was when BSV produced > 100 MB
blocks. Note that I say propagation time and not validation time caused by
them not propagating transactions before including them in the block. Which
__everyone __told them was a bad idea as the software wasn 't optimized for it
yet.

But using it as a counter argument against moderately larger blocks than 1 MB,
like 2 or 8 MB, just stupid. Instead we should just accept insanely large fees
and wait for LN which may never be a suitable replacement.

> The goals of big blockers are to have just one or a few big data centres
> hosting bitcoin and everyone else connecting to them.

No. The goal of big blockers is to scale on-chain and to allow people to run
full nodes if they want to. Not to have it work on the crappiest hardware you
can and kill adoption. It's a realization that most people won't run full
nodes as they want to use their phones as wallets.

SPV wallets provide enough security for mobile phones with only having to
trust that the POW system works. In reality only exchanges and other
businesses have a need to run full nodes.

I could for example easily run a full node with full 32 MB blocks today with
my current hardware. I would just have to upgrade my storage occasionally for
a minor cost. It would amount to 1.7 TB per year which costs less than $60.

> We already have PayPal for that.

 __Even if __only two data centers hosts full nodes it would still be better
than PayPal. Better update your anti big block propaganda to use actual facts.

