Lightning Network Skepticism
chrispacia.wordpress.com
chrispacia.wordpress.com
As the co-author of the Lightning Network, this is not true, there has been no pivot. The design has always designed around wallet-wallet topologies from the beginning (try doing a Find for the word "hub" in the paper). Will there be nodes more connected than others? Of course. But with LN, they are designed to be interchangeable and formless. It may look like other P2P topologies of ever-shifting "supernodes", but never irreplaceable "hubs" like Visa or Fedex's single primary Memphis, TN hub -- in fact you'd be challenged to find a P2P network with a topology of only a handful of static hubs (this makes sense because establishing connectivity is cheap in a virtual system, opposed to physical infrastructure like wires or an airport).
I'm not particularly happy that "small-block skeptics" are using LN as some kind of punching bag against their pet ideas of who the enemies are (the arguments have become highly politicized in the bitcoin community). The LN paper itself presumes bigger blocks, and have never argued that LN is the sole solution, merely that a large component of scalability needs to occur via moving transactions off-chain. The alternatives are a failure of mining incentives (whether it be low-value transactions get crowded off bitcoin and moves to a bitcoin-backed centralized ledger, or the fee-market breaks down and miners reduce fees far too low due to commons externalities).
There is a clear obvious misunderstanding of core principles in computer science, wishful thinking does not solve real problems. It is is akin to assuming that systems are easily capable of a broadcast topology -- that everyone in the world can be on the same wifi access point. Bigger block capacity is desirable, but it's also desirable to be able to instantly transact a payment of $0.0001 without everyone in the world processing that payment.
(I'm going to be intermittent with computer access today due to the holidays but I will reply to email or respond tomorrow :P)
This is very clearly not true, and you don't do yourself any favours by saying such things. The paper discusses hubs that need to provide various guarantees, like being continuously online and routing payments for arbitrary third parties. This is not at all the same thing as a wallet and Chris is right to point out the distinction.
With respect to your point about becoming a punching bag, I'm afraid I am not particularly sympathetic. When Blockstream started floating LN as an alternative to raising the block size (which is what they have consistently done) you should have condemned that and them right away, loudly and clearly, as it was obviously an absurd suggestion and not going to happen anywhere near in time.
LN is a highly theoretical system that doesn't have any implementation that ordinary people could actually use. There is no practical experience with running such a network. It doesn't even have answers to basic design questions, like how routing and addressing would work. The chance of project failure is therefore quite high, as is always the case for research projects.
Thus to imply LN is some sort of dead-cert thing is hubris. Academics have been producing e-cash white papers for decades. Almost none of them actually turned into real-world systems. Nobody will know if LN actually works better than Bitcoin does (or did) until it's built and has competitive usability, which is a very long time away.
> There is a clear obvious misunderstanding of core principles in computer science, wishful thinking does not solve real problems
That's not very charitable is it?
I can assure you, the CS understanding of the people who disagree with you (like Chris, Gavin, myself and Satoshi) is just fine, but I have to question your understanding of engineering. The calculations were done years ago that showed for typical payment network loads that global broadcast could work just fine. Computer science doesn't mean "some algorithms never work and some always work". It just gives us the tools to analyse costs. By simply ignoring complexity and engineering costs of LN, as well as some rather tricky algorithmic costs around pathfinding in global non-suspended networks, you can obviously make any actually existing system look bad in favour of a theoretical proposal.
I've never argued that it is a dead certainty, certainly less so than you have argued that arbitrarily large blocksizes are the only solution.
Quite frankly, I don't understand why you're so butthurt with my comment, I've stated that I think multiple solutions are best, and have explicitly avoided the politicization with this community.
> I can assure you, the CS understanding of the people who disagree with you (like Chris, Gavin, myself and Satoshi) is just fine
I'm pretty sure your comments don't accurately represents Gavin's view (AFAIK, he also thinks we need to explore many technical approaches), nor do you speak for Satoshi (current understanding of bitcoin's risks is significantly different than 2011).
Engineering costs are one thing, technical impossibilities are another. It's not credibly possible for bitcoin to exist in its current form while also being able to make a $0.0001 payment. I agree there are some aspects to consider, esp with maximizing the social value of the network and testing it out, though. Certainly, for all we know there may be unaccounted issues, but that's the case for bitcoin as well (51% risks are still unknown).
For those who are not paying attention to the bitcoin discussions, I have always stated many transactions will still be on-chain (e.g. large directional flows, but paying $0.001 has not been feasible for a very long time in Bitcoin, LN enables those payments to exist using Bitcoin again).
Yet in person the opposite is true. I've heard Tadje refer to large hubs plenty of times.
As for your comment about CS understanding, curious to know, what are your credentials? What's your background in algorithms, networks and software engineering? There is no biographical data on the Lightning network website.
Of course it is. I've made such payments many times over the years. The only reason it's not currently possible is because the Bitcoin Core developers have deliberately forced the network to run out of capacity instead of doing what the community wanted and raising the block size limit. So now the fees are huge, payments are flaky and users are rightly complaining that the system they rather liked appears to be losing any advantages it had over the competition.
Saying "it isn't feasible" or "not credibly possible" when it was repeatedly done right up until very recently is ... not great.
The proposed Lightning Network has received some very strong technical criticism, such as Chris Pacia's article. I wrote a similar one months ago that touched on different issues. I have not seen much in the way of answers to these criticisms.
The Bitcoin developers suspect that there is nearly unlimited demand for $0.000000000000000000001 bitcoin transactions (micropayments). "Unlimited demand" is another way of saying "denial-of-service vulnerability".
I think that "forced the network" is tiresome allegation-making. The developers did not force the network to have an asymmetric bandwidth graph, but they definitely have an interest in countering centralization pressure (such as the increase in resource requirements derived from increasing transaction rate directly through the block size parameter). ....
I know you have long-standing disagreements with Bitcoin Core developers, but this does not seem like good reason to gloss over their reasoning.
> Saying "it isn't feasible" or "not credibly possible" when it was repeatedly done right up until very recently is ... not great.
"What they call a 'centralization pressure' was working fine right up until some limitations on that 'centralization pressure' were implemented!"
> instead of doing what the community wanted and raising the block size limit
Btw "what the community wants" is irrelevant when trying to determine feasibility; sum of community-desire-weight does not make community-desired options more/less feasible.
Can you quote the paper on that?
Speaking for Satoshi is a bit presumptuous, yes? It does make me question who else you're supposedly representing.
Now go read the Lightning white paper. They also use Visa as an example and state that Bitcoin cannot scale. They directly contradict Satoshi on literally the first Bitcoin topic ever discussed.
So I am not speaking for Satoshi in my post above: I am pointing out that he strongly disagreed with Poon & Dryja's reasoning right from day one.
As you can see above, Joseph uses the same language some of the other Bitcoin Core folks use ... they like to say "our understanding is much better now". They do not like to explain exactly what this "better understanding" actually is, given that computers haven't got any slower. They just assert that it could never work. That's unfortunate.
Scalability isn't only about going fast/slow. Scalability is about growth in performance, reliability, guarantees, etc. What counts as better (or worse)? And what are the tradeoffs? And which tradeoffs can we reliably make without breaking the system's guarantees, if indeed it makes any guarantees at all? It's easy to see how Satoshi may not have been omnipotent. Indeed many programmers don't always know all performance characteristics of all the software they write; too, we see programmers taking up opinions on system performance even when their opinion is wrong (some are even known to recognize when they are wrong and update their opinions based on new better knowledge).
I think there is a feeling (rightly or wrongly) in the community that LN is being sold as the future of bitcoin, and that this is not just about sending $.0001, but sending pretty much any amount. And there is concern, fear, etc that LN is one not ready yet, might have some issues we haven't uncovered, may be preventing us scaling in other ways, and may lead us to a bitcoin world we didn't sign up for.
>are using LN as some kind of punching bag
So yes, those concerns about the direction of bitcoin will lead people to beat up on LN, but mostly because there are strong champions of LN stoking those fears/concerns in some ways.
Probably if it was perceived in the community that the future state of bitcoin, was a really good combination of LN plus what we have today (on chain txs unrelated to LN settlements) then there would be less concern and divisiveness. Then it would be clear we have to grow/scale both parts. LN would be a nice solution to some use cases, and on chain bitcoin would need to scale to meet those other use cases (as well as support LN).
What's the business model for the company you are forming around LN?
The design has been a true peer-to-peer payments network without hubs for quite a while[1].
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/20...
From a user perspective, the benefits of GreenAddress were similar (instant confirmation), and the hurdles to adoption were actually lower.
GreenAddress and Lightning each require both sides -- sender and receiver -- to use something different, and more complex, than a regular bitcoin transaction.
They both have to restart with 0 network effect.
GreenAddress never got anywhere with users. Why will Lightning be any different? Because bitcoin itself won't work very well anymore?
As I understand the situation: Bitcoin has a hardcoded limit for the number of transactions that can be processed every 10 minutes. Having such a limit is a good thing, because nobody can stress the network with an unlimited number of transactions. But the limit should be close to the normal usage of the network. So the hardcoded limit should rather be a setting that gets updated from time to time.
So there are the Bitcoin Unlimited guys who propose a client that has a setting for the limit.
And there are the LN guys, who propose a whole new layer on top of Bitcoin. Why?
Such a system enables transactions to occur between a limited set of participants without the requirement that the entire world know about them.
Avoiding telling the entire world reduces the cost of transaction processing by many orders of magnitude (something on the order of 1,000,000 times cheaper).
reduces the cost of transaction processing
Unfortunately Bitcoin has often been oversold as being "free"; but if transactions are free, and there's a fixed number of coins to mine, who pays for this whole network in 30 years?
The motivation behind the design of LN is to minimize the number of transactions which need to be globally verified (which has a cost) while still adhering to the general model of Bitcoin (decentralized, pseudonymous, etc).
You're right though that with tx fees being on the order of ~0.05 USD, you don't really need LN yet. I've long assumed that fees would become significant, pushing out some use cases. That's already happened with e.g satoshidice.
So you say LN is to solve future problems. Because transactions are free and in 30 years nobody will do the mining for free. Well, thats why bitcoin has fees. And a mechanism to let the market decide on those fees. This has been planned from the beginning.
From what I can see, all is fine with bitcoin. And there is no need for the complexity LN brings.
Basically any sort of payment you would want to do at the machine level. If I'm uploading a file to you, I would want you to pay per MB because I'm not sure if you're going to leave after you have 50% of the file.
Why pays to seed torrents? Who pays to run NTP servers? Who pays for running game servers? Its is wrong to assume that something has to be profitable in order for it to exist.
Altruism certainly exists, but assuming that altruistic actors (rather than self-interested actors) will expend more resources than attackers is a very different security model than what Bitcoin is designed upon.
This is causing nodes to go offline. There are about 500 to 1000 rasberry pies operating as full nodes on the network and their 1 GB of ram is not enough to hold the backlog of tx.
Blockstream is proposing to raise the limit to 2MB 2 years from now. That would be a disaster for the network.
There are many problems which arise from unbounded transaction rates in Bitcoin. The most fundamental is that long term the coinbase reward is zero, and transaction fees are the only reason to create new blocks. Without artificial scarcity of block space (artificial in the sense of beyond what hardware can support) transaction fees would tend to zero, and mining would no longer generate revenue.
LN is proposed to allow many users and many transactions (when nodes cooperate) while keeping the security properties of Bitcoin (when nodes don't).
My own estimation is between $400k per day (hard lower bound) and $800k per day depending on assumptions about hardware efficiency, although around $100k / day was added in the last week in a trend that is continuing, so $1MM/day will very quickly be accurate.
Mining only costs a lot because coin value is high and the block reward is high. This means miners are willing to spend more to win the reward.
As the block reward lowers then mining becomes funded entirely by equilibrium-priced fees.
If you knew anything about Bitcoin Unlimited I am sure you would have come across its most fundamental aspect - moving the blocksize limited from the hardcoded centralised protocol layer to the transport or messaging layer thus allowing each node operator to choose the limit in a decentralised fashion so creating an emergent consensus.
In regards to your speculative economics, as I am sure you are aware, storage/bandwith/processing/validation and mining has costs. No one would therefore mine a transaction for free in 20 years because if they do so they would soon go bankrupt.
Bitcoin's design has an inbuilt long term solution. Reward miners early on - grow adoption - increase transactions to a "very large number" - charge pennies out of millions of transactions - profit.
Finally, LN may be secure for microtransactions. It is in no way secure for decent transactions. There are millions of ways it can be hacked even now that it only exists in speculative heads. Once it becomes hardcode implemented I am sure attack vectors will only increase much further.
If you knew anything about Bitcoin, you'd know that this is a sure-fire way to get forked off the network and ripped off by double-spends. The nature of Nakamoto consensus is such that consensus parameters are not up to vote.
"The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote." - Nakamoto
> ISM is used for soft-fork upgrades, which do not change existing consensus rules.
"Soft-forks" do change existing consensus rules. Will a miner's v1 blocks be accepted by the majority of the network today?
> Block size is not a parameter you can force on upgraded nodes by soft-fork.
Isn't this what the Segregated Witness proposal[1] effectively does? The new limit proposed would be 4MB with an expected confirmed transaction throughput increase on the order of 2x.
To quote Pieter:
"Another way of looking at it, is that we raise the block size to 4 MB for the witness part, but the non-witness has same size."
[1] http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/s...
And if they are not?
Yes this is one of the things that Satoshi got wrong. "1 CPU = 1 vote" is wrong. Turns out that Proof-of-Work is unrelated to the physical quantity of CPUs, rather it's more about computation and hashrate. Also it's a stretch to call Proof-of-Work a vote ..... it's not an election, it's more like a random lottery or something.
> it's not an election, it's more like a random lottery or something.
A random lottery where your odds of winning directly correlate with your CPU power / hashrate. The more you win the more influence you have over the state of the network. Comparing it to a vote is a reasonable analogy.
One of two things must therefore be true:
1. If consensus parameters cannot be voted on then Bitcoin is a failure, and Core's huge war against upstarts like XT and BU are totally misplaced (since as you say they cannot be changed by vote) or
2. You're dead wrong
If consensus parameters are not up to vote then obviously XT simply cannot be "voted in", so why fight it?
If consensus parameters are not up for a vote then Bitcoin loses permissionlessness and censorship resistance: a hostile actor merely needs to infiltrate the governance structure of one ragtag dev team and he can block certain transactions or indeed greatly harm the network by inserting consensus code to keep undesirable txns out or by making the rules unworkable. Since nobody can vote the bad rules out, the network just has to accept the bad rules and implode.
If consensus rules cannot be voted on then permissionless innovation of the system is thwarted or impossible. If I have a great idea for a consensus rule innovation, I have to get permission from the keepers of the consensus rules to add my rule change.
If consensus rules are not up for vote then if a supermajority of users including miners attempt to change the rules by running different rules, nothing will happen, because the rules "weren't up to vote." But it is objectively the case that if this were to happen, then the rules would be changed because a majority of voters agreed with the change. This is the defacto behavior of Bitcoin.
Methinks that #2 is the case. Consensus rules, as a simple matter of fact, are amenable to change by a simple supermajority of CPU votes from a majority of miners and nodes.
Are you refuting my points or agreeing with them? If you have an actual rebuttal to any of them, I'm interested in hearing it.
Eagerly awaiting a substantive response to this by maaku.
However I disagree with the BU proposition that unrestrained "voting" on max blocksize is a good idea. It doesn't stand up to attacks by a small amount of hash power.
> Eagerly awaiting a substantive response to this by maaku.
I am very much not maaku, but first it's obvious that Proof-of-Work has not been used to decide consensus protocol parameters (it's used for transaction ordering and establishing the consensus history). Second, Bitcoin success or failure is entirely unrelated to how the protocol wasn't designed to vote on consensus protocol parameters.
Every "soft-fork" to date has used PoW to activate new consensus rules by requiring block version super-majority.
Consensus rule parameters are things like "max block size". However, there have been some proposals for extension blocks to increase block size without requiring a hard-fork (e.g. using a soft-fork mechanism).
As long as the changes are non controversial then miners and nodes simply act at a rubber stamp. But it's unrealistic to think no important issues will be controversial.
If consensus changes arent up for CPU vote, then you tell me what happens if a supermajority of miners and nodes decide to run software with different consensus rule from Core? Sounds like a CPU vote too me.
Or natural scarcity, which already exists.
That should be essentially everybody with even a pretty loosely connected graph.
On chain A blocks bigger then 1mb will be valid
On chain B blocks bigger then 1mb will be invalid
Unless the transaction has coins in one of its inputs that already went through a block bigger then 1mb. Then the transaction is only valid in chain A. This way you can double the value of a coins that are spendable on both chains. Because now you can sell them once on chain A and once on chain B.
Anyway, I think this is extremely unlikely to happen, because:
1) It requires 50% of miners to cooperate to even create a >1MB chain
2) Anyone using the old chain would be insecure, due to lack of mining power making it susceptible to a 51% attack.
3) If that many miners were on board, it's unlikely that existing core developers would opt to continue working on an insure fork rather than admit defeat.
4) If that many miners were on board, it's unlikely that exchanges would opt to confuse users by letting them separately trade two different types of Bitcoin, rather than just switching to the more secure, more popular chain.
It's odd considering the struggle to keep the blocksize near 1MB for the purpose of keeping bitcoin decentralized. LN could centralize by making private transactions very expensive.