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).
Or natural scarcity, which already exists.
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.
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.
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.
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.
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.
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.
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).
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.
"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
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.
> 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?
That should be essentially everybody with even a pretty loosely connected graph.
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?