You can also expect different channels of propagation to emerge if demand builds up.
> 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?
2) Blockstream is not the only developer working on LN, in fact, the main development team is called Lightning Labs, plus there are many open source developers working on LN. The bitcoin community has decided that it wants BTC mainchain to be settlement layer and the momentum behind LN proves this.
Garzik has something of a conflict of interest encouraging fudding this effort. After I originally proposed back in 2011/2012 doing a broadcast like the eventual blockstream effort, Garzik ran with it and raised money from the public ( https://bitcointalk.org/index.php?topic=334701.0 ) to do Bitcoin satellite broadcast. He creeped the scope to the point of proposing to launch a "cubesat" (why? Unclear, it would be a lot less useful due to their short life and the inability to use fixed antennas) and as a result ultimately failed to deliver anything at all.
Blockstream built something more practical and useful than a swarm of cubesats, and instead of just raising money and putting out hype then failing they put out a running system. In fact, Blockstream's system was up and running on the day the very first public announcement was made. I urged Garzik to do something like Blockstream's system as a MVP before sinking a fortune into trying to actually launch satellites...
And yes, absolutely anyone else can setup a similar system (though it isn't anywhere as simple as 'cut a check' unless you want to pay through the nose and don't want to support reception with $100 of deniable commodity hardware)... that isn't a minus, it's a plus and a direct counterpoint to your 'centralized chokepoint' claim if the fact that the next alternative to using the sat is the centralized chokepoint of your ISP wasn't enough.
This blockchain broadcast specific talk ignores the really cool "API" which they announced today: receiving a sat broadcast with commodity hardware is likely the most strongly anonymous communication method available... and this is something they've made available to everyone, paid for with Bitcoin micropayments.
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.
I admit this is confusing as 99.999999999999% of everything with "blockchain" in its name is a scam
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
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.
>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.
would be 0
No, it's not. If miners' hash power reduces, Bitcoin dynamically adjusts. At worst, there will be a slowdown in block production if mining power precipitously drops until the adjustment takes place.
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.
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).
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.
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 (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.
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.
In this world where no LN-transaction touches the Bitcoin blockchain, what's the reason for having a blockchain in the first place?
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.
> 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.
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!!!
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.
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.