Blockstream Satellite API: Pay with BTC via Lightning to Broadcast Data Globally

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.

If civilization collapsed I think people would have more pressing issues than whether or not they can spend their Bitcoin.

> 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...

Number stations come to mind.

> 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.