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?
Lightning (which is shorthand for Hash Locked Bi-Directional Payment Channels) is a trust-less net settlement system built by leveraging the smart contracting capabilities of bitcoin.
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).
Check out /r/Bitcoin sometime for users complaining about transactions fees :)
(Actually more the threat that some day there will be significant fees)
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.
Downloading a webpage, for example. Sending an email, giving someone an upvote, making use of a caching service.
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.
If both transaction fees and the coinbase are zero or negligible, there is potential revenue in mining: to reverse transactions and rip people off.
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.
Running the Bitcoin mining network costs millions of dollars per day in electricity costs alone. Who's going to to pay that when the subsidy goes away?
The block reward only halves, it doesn't "go away". Unless you are talking about when it can't halve anymore because of the 8 decimals limit, which we could just remove, just like Satoshi wanted (same situation as with block size limit).
You are wrong about mining costs. Miners are estimated to consume 100-200 megawatt. Most of them pay below worldwide average electricity prices, being located in Iceland (KnC), WA state (BitFury), etc; maybe around $0.05/kWh. So the miners' daily costs would be $120 000 to $240 000.
For the past month there has been a backlog of 6000 to 10,000 transactions in the mempool.
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.
"Bitcoin Unlimited" has no maximum block size, hence the name.
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).
Mining does not need to be profitable. People always make the mistake in thinking that if mining ceases to be profitable that mining would suddenly stop. That is simply not how it works. It is more economical to buy tomatoes at the grocery store, but that doesn't stop people from growing tomatoes in their backyard.
Mining costs millions of dollars per day in electricity costs. I guess we can just expect a few people to burn a hole in their pocket for the good of the network?
I'm a physicist so naturally I do all back-of-the-envelope calculations to one-significant figure with rounding at each step. :)
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.
Oh I understand mining economics quite well. The comment I was responding to however claims that some people will continue to mine at a loss after the subsidy is negligible. However that assumes that people would be willing lose hundreds of millions of dollars per year on power costs just to meet current security levels, let alone whatever level of higher security might be required in a moonshot scenario.
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 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.
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 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
Um, I'm not sure why you are pointing to that? ISM is used for soft-fork upgrades, which do not revert existing consensus rules. You can have a ISM vote over a new block size, but old clients will still reject the bigger blocks.
The upgrades are triggered by a super-majority of blocks of a certain version. This version maps to a possible new consensus rule. Block creation is a product of computational work. Therefore there is a precedent for CPUs/ASICs voting on the consensus rules of the system.
> 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?
You made the claim that under "Nakamoto consensus" the consensus parameters are not up for a vote. A correction seemed warranted.
> 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."
> "Proof-of-work is essentially one-CPU-one-vote." - Nakamoto
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.
He stated PoW was _essentially_ one-CPU-one-vote. It's clear that the intent is to mean hashrate, or CPU power as he phrases it multiple times in the same paper.
> 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.
> The nature of Nakamoto consensus is such that consensus parameters are not up to vote.
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.
> 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)
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.
> > 1. If consensus parameters cannot be voted on then Bitcoin is a failure
> 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
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).
Of course proof of work has always been used to decide consensus parameters. It's just tuat no controversial changes / failures to change have ever been put to the vote.
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.
Roughly: LN allows you to transact instantly, but with a limited group of people (it takes one normal bitcoin transaction to setup your group, but then transactions are instant). Whereas bitcoin allows you to transact slowly (block confirmation time, i.e. ~10mins) with anyone.
In case the blockchain forks, it will get really interesting. And how I understand it, some people will get stinking rich. Because you can then effectively double every old coin by mixing it with new coins. After that, it is valid and independently spendable on both forks. So people in the know will probably buy old coins like mad, mix them with new coins and immediately sell them on both chains. Then use the money to buy old coins again.
Not how it works. If there was a fork, then coins on each side would become independent (you could not mix them together). Since the current price represents the total demand, the market cap must equal the sum of the parts, so coins on each side would become less valuable. I would expect the aggregate would actually go down, due to lack of faith in Bitcoin developers being able to get shit done (and possibility for other coins to pick up the slack).
On chain A blocks bigger then 1mb will be valid
On chain B blocks bigger then 1mb will be invalid
Now when you sign a transaction and broadcast it, it will get executed on both chains.
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.
Right. But economically speaking, if exchanges started allowing you to trade both coins against each other, then supply has doubled while total Bitcoin demand remained constant. So the price would tank to at least 50% of its previous level on each side of the fork to reflect the new equilibrium.
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.
I'm presuming 3dfan is assuming some kind of split in merchant/exchange acceptance, I agree this is less likely, though. However, in a hardfork, you can be sure there will be some kind of forkA/forkB exchange site that will emerge (not at a 1-to-1 exchange rate, of course).
> It seems I wasn’t the only one with this concern as there’s been a fairly recent pivot away from the hub-and-spoke network topology to a more organic, wallet-to-wallet routing. The network is now envisioned as a more pure p2p payment layer without those large scale payment hubs.
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)
The design has always designed around wallet-wallet topologies from the beginning (try doing a Find for the word "hub" in the paper).
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.
The paper never refers to hubs, the necessity of a handful of entities routing payments a-la Visa has never been part of the design. There are certainly more connected nodes, but that's true in any P2P system (as well as nodes with higher uptime). Additionally the paper refers to larger blocks, LN doesn't resolve underlying block capacity issues alone, it could help mitigate its problems significantly -- much like how a switched network helps resolve bandwidth (but you still might want faster connections).
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).
> The paper never refers to hubs, the necessity of a handful of entities routing payments a-la Visa has never been part of the design.
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.
> It's not credibly possible for bitcoin to exist in its current form while also being able to make a $0.0001 payment.
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 only reason it's not currently possible is because the Bitcoin Core developers have deliberately forced the network to run out of capacity
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.
Lightning is a very interesting long term scaling solution. It may allow us to keep fees close to zero on the main chain while at the same time keeping space requirements efficient, and supporting all the transactions the world needs.
I feel it is though, very much at the research prototype stage of a project. How a transient network of piecewise connected nodes can efficiently route messages between disparate endpoints is certainly possible (as it is how the internet works) but certainly with the extra meta data required, and the connection based nature of the protocol, it is more like TCP and it is not trivial. So I agree it is something which needs a lot of work before we can realize its effectiveness.
I don't however see any need to throw around accusations of pivoting or deceptive intent. This is a new field and it is necessary and healthy for ideas and goals to morph and change as required to serve the market need.
Go read Satoshi's first announcement of Bitcoin on the crypography list. The very first question ever is about scalability and he states quite clearly that he thought about it extensively and it would never be an issue in practice. He uses Visa as an example to illustrate his point.
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.
> They do not like to explain exactly what this "better understanding" actually is, given that computers haven't got any slower.
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).
>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 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).
I agree wholeheartedly, all aspects of scalability needs to be (are being) looked at, with an eye for practicality. Hopefully, LN will reduce the load on-chain for people currently using bitcoin for instant low-value transactions as well by using LN and freeing up some blockspace.
I'd be a lot more excited about Lighting Mightwork if there were one, 1, ONE merchant accepting GreenAddress.
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?
Lightning networks can be huge, it just depends on the implementation.
For example if you check Ethereum's and compare it to Bitcoin's, you see that both can be pretty helpful I their own ways: http://www.arcturnus.com/ethereum-lightning-network-and-beyo...
My concern is that LN puts a premium on unpredictable transaction behavior, and private transactions are unpredictable by nature. Thus, LN trades privacy for efficiency.
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.
87 comments
[ 7.1 ms ] story [ 1966 ms ] threadAs 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).
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.
https://www.reddit.com/r/btc
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.
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.
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...
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?
I feel it is though, very much at the research prototype stage of a project. How a transient network of piecewise connected nodes can efficiently route messages between disparate endpoints is certainly possible (as it is how the internet works) but certainly with the extra meta data required, and the connection based nature of the protocol, it is more like TCP and it is not trivial. So I agree it is something which needs a lot of work before we can realize its effectiveness.
I don't however see any need to throw around accusations of pivoting or deceptive intent. This is a new field and it is necessary and healthy for ideas and goals to morph and change as required to serve the market need.
We should not discourage new ideas.
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?
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?
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.