Lightning protocol addresses that. You can make millions of transactions per second [1]. Quite a lot of crypto sites are already supporting it and wallet support is increasing too [2].
It's sound engineering. Like in other systems by composing layers you can achieve the advantages of each component while addressing their costs, without creating insurmountable complexity... "have your cake and eat it too".
Particularly, the central Bitcoin system is a global broadcast medium-- necessarily for its security. Global broadcast is inherently somewhat limited in its scalability (though less than some assume). Other layers effectively add "transaction switching" to Bitcoin, radically improving scalablity and performance with their own costs which are good trade-offs for their applications.
As far as the status quo of traditional finance... If you're happy with the status quo! Use it!
(I'm going to assume you don't mean the status quo of Bitcoin--because 28kb/sec isn't something only large entities can keep up with, it adds up over time-- but even cumulatively its managable)
You could recreate the status quo of centralized finance with Bitcoin, but it wouldn't be obviously better: at least systems like visa and paypal are purpose build to do what they do. Bitcoin takes on a lot of costs and tradeoffs to achieve decenteralization.
Bitcoin was created to be money that existed above and outside of the vulgarities of immediate human politics, just like how strong encryption made it effectively impossible for some sysadmin to just read your files based on some excuse.
I think having that option in the world is extraordinarily valuable.
It's laughably bad engineering to try to solve the scaling issue of the base layer by adding another layer on top. It's like you'd try to solve a throughput problem of IP by layering TCP or HTTP on top.
But this is the logic of one of the main devs who championed the "fee market" idea of Bitcoin[0], that high fees are required for Bitcoin to function. And who in 2017 celebrated when fees were around $50.[1]
2nd layer avoids bloating the ledger. Once limits of 2nd layer are being explored, you can make adjustments to 1st layer with information about how that'll improve 2nd layer throughput. This is like arguing that we shouldn't have in-memory caches, we should just have faster disks
Once limits of 1st layer are explored (the Bitcoin developers have never even bothered to research where the limits are) you can augment it with 2nd layer solutions. Both should of course be done simultaneously, and never focus on one to the exclusion of the other.
Even the Lightning Network whitepaper states it needs much larger blocks, and for it to work well you need to be able to settle quickly and cheaply on-chain, which is not the case with full blocks.
Let me get this clear: You want to WAIT until it's evident that we can't scale anymore, and then add 2nd layers?
And this, you want to do after significant adoption?
So, you are basically going to tell the Starbuckses and other large corporations that have built a large infrastructure around onchain transactions that they need to stop that, wait a few years until 2nd layers are adopted, and then start using that?
The article you're linking is an extremely dishonest anonymous hit piece that distorts history to manipulate the audience.
The design of Bitcoin where security is supported by fees to get into blocks is established in the Bitcoin whitepaper and has been in the software since day one.
Contrary to the claims of the article the term "fee market" was introduced and promoted by Jeff Garzik-- rather than people opposing him as the article claims. (Fee market is kind of a bad term, the correct term would be blockspace market, but it actually made sense in the original usage which was about wallets paying 'fees at market rates').
> The answer is lies in the free market. Move transaction fees away from hardcoded limits, and towards something more dynamic, with economic feedback between merchants, users and miners. ... Also introduced is an anti-spam rule that avoids relaying transactions whose value is below that of the transaction fee required to send it. This rule self-adjusts over time, as the "tx fee required to send" changes over time. In a dynamic fee market, it might change a lot.
> 2010-11-19 20:55:42 <jgarzik> eventually we'll all be paying TX fees, sooner or later. and competition to get -some- fee (at lower prices) versus no fee kicks in.
> 2011-02-28 04:13:57 <jgarzik> amiller: it's inevitable that fees will be required. nobody should be assuming bitcoin transactions are / will always be free.
> 2011-03-01 20:32:21 <jgarzik> fees are inevitable
> 2011-03-10 22:14:34 <jgarzik> I think TX fees are a great feedback
system; a healthy attribute of bitcoin.
> 2011-11-07 22:43:12 <gavinandresen> Lolcust: yes, but I worry because transaction fees are broken right now-- clients and miners really need more flexibility to let fees go where the market decides, instead of us guessing what the right fees are.
> 2012-10-11 17:01:27 <jgarzik> gmaxwell: I think storage and network
will be cheap enough that any non-zero fees will be interesting to
miners
> 2013-03-16 00:47:40 <gavinandresen> So: I have no idea what the right answer for fees is. We need to create a market between miners and users, and let the fees go where they belong.
> 2013-03-17 21:12:04 <jgarzik> TD: Satoshi obviously wanted fees to
support the system long term. If there is no scarcity, there are no
fees.
And people being willing to pay substantive fees to use Bitcoin is absolutely something to celebrate, Bitcoin's long term security is completely dependent on fee income. Getting a non-trivial part of the rewards from fees is a basic validation of the concept.
> 2013-03-17 21:12:44 <jgarzik> TD: The current situation, where block
subsidy dominates other incentives, clouds thinking on block size
> 2013-08-12 17:59:33 <jgarzik> auctions make me want replace-by-fee :)
> 2014-05-12 15:13:22 <gavinandresen> hearn: fee cap, meaning what? Fees need to be a market, and rise or fall based on supply and demand for block space
> 2014-08-15 12:37:53 <jgarzik> Merge this useful change, and next will come the call to remove block size limit altogether, which will throw a nuclear bomb onto any nascent fee market.
> 2014-08-15 12:38:37 <jgarzik> All the VCs and execs want an infinite
block size limit. It's a sad fixation.
> The article you're linking is an extremely dishonest anonymous hit piece that distorts history to manipulate the audience.
That's rich coming from you. It's easy for anyone reading this to search for what nullc has said and done.
> The design of Bitcoin where security is supported by fees to get into blocks is established in the Bitcoin whitepaper and has been in the software since day one.
Many transactions paying low fees can support security just as well as few transactions paying high fees. I'd say even better as people will stop using Bitcoin or move to other cryptocurrencies when fees grow.
Saying that the "fee market" (or "blockspace market" if you want) is supported by the white paper extremely dishonest. The blocksize limit was only meant as a temporary spam protection, not to enforce higher fees. Zero fee transactions were on the other hand accepted from day one.
> That's rich coming from you. It's easy for anyone reading this to search for what nullc has said and done.
How so? I'm fairly proud of my actions, and I'd be happy to discuss any of them with you.
> The blocksize limit was only meant as a temporary spam protection, not to enforce higher fees.
There is nothing that actually supports that the claim that it was spam protection, thats just blind unsubstantiated assertions.
The system has anti-spam mechanisms in it all along that worked independently of the blocksize.
I think it's fairly likely that Satoshi didn't give these details a lot of thought... It's a champagne problem, and for as many things as he clearly thought through there were many others that were a little rough (e.g. like the broken original longest chain rule).
> Many transactions paying low fees can support security just as well as few transactions paying high fees.
This is being slowly disproved in practice. Bitcoin currently pulls in $3m per month in fees. The most popular fork with no blocksize limit pools in a couple thousand dollar at most, with a substantially lower amount of fees per transaction. Even if their block was 95% full at their current rate, it wouldn't be more than a few percent of its funding from inflation (while bitcoin fees currently are as much as 25% of that altcoin's inflation).
Assuming it isn't inhibited by node resource usage, propagation centralization pressures, or other considerations it could always be increased in the future... going the other day with an ecosystem that depens on effectively zero fees would be much harder. I don't think it's an accident that analysis supporting unlimited block sizes assumes perpetual inflation instead of limited supply.
TCP wasn't build on IP because it wasn't scalable. It was build on it because it was.
But that aside, calling Lightning on BTC a second-layer is a bit misleading: Lightning data is not encapsulated in BTC data, more like the other way around; so Lightning is more like layer 0 and BTC layer 1 in that model. (That's also not entirely correct either but much closer)
> At the start, TCP handled both datagram transmission and routing, but as the protocol expanded, other researchers started to recommend that these two functions be split into layers.
> One of these researchers, Jonathan Postel of the University of California’s Information Sciences Institute and an editor for the Request of[sic] Comments (RFCs) which is a document series capturing the development of the Internet.
> Postel has stated:
> “We are screwing up in our design of Internet protocols by violating the principle of layering”
> Basically, the monolithic design of TCP would soon become inflexible and unable to scale efficiently. Therefore TCP was split into two protocols, TCP & the Internet Protocol (IP).
I'm not all too familiar with the history of IP and TCP but my point still stands. Protocols aren't build because the underlying protocol doesn't scale in term of throughput, it's for the opposite reason that they scale very well. I could also have used HTTP and TCP.
Bitcoin has very strong properties for _security_ which is the inherent property that makes it possible to build other automated trustless systems on top of it.
The comparison with TCP and IP is limit in that TCP data all goes inside IP packets. With second layer transaction systems the relationship is different: the security and stability comes from the underlying blockchain. The higher part adds capacity.
Bitcoin forms a trustworthy robotic court system upon which the wheels of automated commerce can ride.
Amusingly enough ... The rates there are, in fact, significantly slower than what plain old Bitcoin developers. Bitcoin dev's probably should make the syncing status print the number of inputs per second being processed.
But being able to barely keep up means that if you fall behind for even a moment (say, if your connection drops... or if miners get lucky and mine a bunch of extra blocks) then you will _never_ catch up. Operating anywhere near the limit of your processing rate is non-viable for that reason.
You need to be able to process many times the network's capacity so that you can catch up in a reasonable amount of time.
It’s not sound engineering whatsoever, it actually is horrible engineering especially when the base layer is congested - Engineers and developers who are far more proficient than you have already chimed in on this, including Vitalik the creator of Ethereum, who also firmly supports the path to scale Bitcoin Cash is taking:
That’s not the status quo at all. You can buy a raspberry pi 4, a 1TB SSD, and have a perfectly functional bitcoin node, and lightning node and BTCPAY server all in one for close to $200.
Secondly, Lightning isn’t “additional complexity” fir bitcoin— it’s taking complexity and putting it where it belongs— at the platform layer.
TCP/IP doesn’t get faster by making packets bigger. Same with bitcoin. And the application layer should be kept separate from the transport layer.
On-chain scaling does not prevent that. In fact, it reduces complexity by removing the Lighting requirement.
Tangent: I would not recommend running lightning on such hardware. State is local to the node, unlike with on-chain scaling. That implies you need server-grade (read: redundant) hardware.
> TCP/IP doesn’t get faster by making packets bigger.
Technically larger MTUs can increase performance somewhat by reducing per-packet overheads... but the effect marginal and not that enormous with good nics and drivers.
Right, because no nic vendor was ever retarded enough to purposely cripple their product by restricting throughput to thousandths of actual potential theoretical physical capacity at the driver level like you and your toxic coterie did. In fact nobody has ever been this stupid in the entire industry period that I can think of except that coterie.
Good thing for you it's in the interests of extremely rich and powerful people to see that your sabotage is well supported, and good thing for the rest of the world you have a containment chain where your stupidity is restricted from bleeding over to the rest of them, and every single other chain appears to be completely mercifully free of your idiotic philosophy.
> I don't get your argument. Block size is limited so fees can go up to pay the miners so they have incentive to mine.
Probably because that point has nothing to do with anything, as basically every single blockchain in existence has fees that go to miners. BTC isn't the slightest bit unique in that.
> Aim of bitcoin is not to be the fastest cryptocurrency but the most mined one (thus safest?).
Which once again has nothing to do with the artificial useless block limit. The cryptocurrency that is most mined is the one in which mining is most profitable, the US federal reserve could launch a competitor tomorrow with a goal directly opposed to every other cryptocurrency in existence and if they paid more per SHA256 hash rate unit they would become the most mined cryptocurrency.
I can answer part of that question. You can't make it much more frequent because the amount of time for the difficulty has to be balanced against propagation time for blocks or else you will have lots of forks. Probably you can make it work, but there are a fair number of assumptions in the Bitcoin protocol about this and it would probably be better to start a new coin if you want to do that. The 10 minute update was chosen specifically to avoid common network partition events.
As for block size, it's been ages since I looked into this stuff at all (and I've only ever watched out of the corner of my eye), but my impression is that the block size is currently limited for relatively arbitrary reasons. I don't think there is actually a lot of resistance to increasing the size sometime. It's just that the developers want to limit the size now to guide development in certain ways.
And really, as far as I'm concerned that's totally fair. If you don't like it, fork the coin. Or start a new one. Or stick with Bitcash. The developers are in control because that's the whole point -- to guide development in the way that they think will work best. Not everybody is going to agree. So what?
I think the only reason people get upset is because of the ludicrous amount of potential money on the line. And again: if you are controlling that ludicrous amount of potential money, you are able to vote with your feet -- to the extent that you can convince other people with ludicrous amounts of potential money to follow suit. If all that insane speculation and fraud were to vacate Bitcoin, the developers could happily code away and there would be nobody left to complain.
Let's face it. If we believe that there are billions of dollars tied up in BTC, the owners of that coin could easily afford to hire programmers to fork the protocol. They don't do it because the politics of doing so is essentially impossible. Most people want to stick with the dev group. Again, I'm left with saying, so what?
> You can't make it much more frequent because the amount of time for the difficulty has to be balanced against propagation time for blocks or else you will have lots of forks.
The same problem also limits block size, since large blocks take longer to propagate.
But that's why Ethereum went with GHOST, which was originally proposed for Bitcoin. Instead of choosing the block with the most hashpower behind it, you choose the block with the most hashpower in the entire tree after it, so that forks contribute to a block's security. The original paper calculated that this allowed both faster blocks and higher throughput, and it's the reason Ethereum has 15-second blocks.
> non-conflicting transactions of blocks outside the main chain are included in the ledger
I am pretty sure that isn't true. I'm looking at the code, and the only thing I see included for 'uncles' is the header. This has the beneficial property that higher orphan rates increase difficulty which should lower orphan rates.
OTOH, it doesn't appear that including other people's orphans is incentive compatible without the rest of ghost (because it lowers your own future income).
"a version of" -- there is no close in cryptography. :) Security analysis usually do not apply well to approximations.
Indeed; the market has clearly chosen to prefer optimizing for low cost of full system validation (running a full node) over lost cost of transacting (cheap block space.)
Lightning also requires funds recipients to monitor their channels continuously, to make sure they're not closed early with obsolete balances. At least you can pay someone to do that for you.
Hardly, because building LN on the 1MB base layer is like building a pyramid upside down, it's unstable and creates more problems than it was meant to solve.
Lightning was supposed to make tx fees low right? Well it technically has, but it also introduced the following problems that Bitcoin never had:
- LN requires that both sender and receiver be online at the same time to transact. This never existed on Bitcoin.
- If you're an LN merchant accepting payments, you must periodically topoff your side of the channel...just so you can keep accepting money. This problem never existed on Bitcoin. I can have an empty address on Bitcoin and receive any amount of money without any limits.
- In Lightning when making a transactions you must always reserve the current Bitcoin onchain miner fee, so that if either channel party wants to close the channel it'll get accepted and mined by a Bitcoin miner. Well when Bitcoin fees hit $3 a few months ago, 60% of the Lightning network capacity was locked up in miner fees lol... defeating the purpose of microtransactions and the LN network
- In Bitcoin my coins can only be stolen if I leak my private key. Well for LN your money can be stolen simply by not being online to monitor your money. In addition to stealing your LN private keys, a bad user can attempt to steal your funds when you're offline. Which is why LN requires a 3rd party service called Watchtowers to watch over your funds. Way more complicated than Bitcoin
- The unsolvable routing problem. A good chunk of LN transactions will fail simply because the routing is weighted and chanes constantly. Compare that to Bitcoin's gossip network which doesn't require any weighted routing. FYI weighted routing is currently a mathematically unsolved problem.
- LN is centralizing around LNbig.com At one point LNBig.com had over 70% of the entire LN network capacity. LN will continue to centralize around these big hubs, because they can offer cheap connections and low fees than a regular peer can. Welcome to Bank of America LN Hub TM.
- With Bitcoin I can keep my money in a cold wallet. With LN it's either a hot wallet or cold wallet and I must close all my channels and pay the Bitcoin onchain fee just to close it. You're literally choosing betwen low fees OR security with Lightning, where as with Bitcoin you have both.
- Both creators of Lightning Drya and Poon have publically stated LN was never meant to be a scaling solution for Bitcoin and show many problems that will simply never be solved. Like the race condition when a big hub closes and hundreds of users all attempt to race to transmit their transaction to miners.
- In the Lightning whitepaper, LN requires AT LEAST 133MB+ blocks for global adoption for LN to work without congestion... And Blockstream blocked a minor 2MB increase. So good luck.
So congrats to Lightning, for "solving" 1 problem and creating 12 new ones.
There's many more, but these are the ones easily digestable by users without going into the deeper technical problems with LN. There's a reason Lightning is always 18 months away from completion....for 5.5 years now. While Bitcoin Cash just works.
> - Both creators of Lightning Drya and Poon have publically stated LN was never meant to be a scaling solution for Bitcoin
[citation needed]
The initial presentation of the paper was titled "SF Bitcoin Devs Seminar: Scaling Bitcoin to Billions of Transactions Per Day". If we didn't mean it to help scaling, what was it meant to be?
[note: am one of the authors]
> LN requires that both sender and receiver be online at the same time to transact. This never existed on Bitcoin.
Correct, but this is clearly stated in its whitepaper and is one of the tradeoffs to get massively more txs and privacy.
> If you're an LN merchant accepting payments, you must periodically topoff your side of the channel...just so you can keep accepting money. This problem never existed on Bitcoin. I can have an empty address on Bitcoin and receive any amount of money without any limits.
Correct, but you can also move those funds to other channels you have already opened. Also, loop-in and loop-out are coming. Also, receiving multiple bitcoin transactions on a single UTXO is a privacy hit for all involved.
> In Lightning when making a transactions you must always reserve the current Bitcoin onchain miner fee, so that if either channel party wants to close the channel it'll get accepted and mined by a Bitcoin miner. (...)
You need to if you don't plan to aggregate your settlement and opening txs, or aggregate those transactions with others. All if that tech is still coming.
> In Bitcoin my coins can only be stolen if I leak my private key. Well for LN your money can be stolen simply by not being online to monitor your money. (...)
This is your first statement rewritten. I will not address it again.
> The unsolvable routing problem. (...)
And yet, the vast majority of transactions on the LN proceed without a problem, and further improvements like AMP will further reduce the number of failed fees. Another option is to make an on-chain transaction.
> LN is centralizing around LNbig.com (...)
Like bitcoin was centralizing around Satoshi's mining farm in the first year of Bitcoin? LN is at infancy stage, and has a hard cap on what amount of BTC you can open a channel with.
> With Bitcoin I can keep my money in a cold wallet. With LN it's either a hot wallet or cold wallet and I must close all my channels and pay the Bitcoin onchain fee just to close it. You're literally choosing betwen low fees OR security with Lightning, where as with Bitcoin you have both.
Besides the fact that bitcoin will still be there, all of these points are explained as part of the network. I don't understand why you are harping about these sorts of issues when the whitepaper or easily found literature about LN clearly state these issues. Also; don't forget that LN doesn't have to be the only second layer on Bitcoin. I can imagine banks building a second layer walled garden with the feature of settling onchain. Heck, this could be made in less than a year, and would basically give every user in the world the option to buy bitcoin. They would however need to have the right volume of BTC available, so it would be utterly devastating to those vested in fiat (which is why they aren't doing it yet).
> Both creators of Lightning Drya and Poon have publicly stated LN was never meant to be a scaling solution for Bitcoin and show many problems that will simply never be solved.
Drya is, to my knowledge still very positive on LN, don't know about Poon though.
> In the Lightning whitepaper, LN requires AT LEAST 133MB+ blocks for global adoption for LN to work without congestion (...)
With the then current code, and the then current block size. Block size has increased with Segwit. Taproot will further increase capacity. Channel factories are a thing thought of after publishing the white paper, etc.
> While Bitcoin Cash just works.
Bitcoin Cash works. I agree. It's miners will keep raising the block size and spammers will keep filling those blocks to make the ghost towm seem inhabited. Then, users will slowly stop their BCH full nodes because it becomes a bother to keep them online. After that, it will centralize to a small set of players that will be able to change the consensus rules to their wish. Is that the decentralized peer-to-peer money you wanted? This attack vector is a considerably more important threat than reduced adoption will ever be.
> And yet, the vast majority of transactions on the LN proceed without a problem, and further improvements like AMP will further reduce the number of failed fees. Another option is to make an on-chain transaction.
Oh that's funny. While you're right that payments failing for not finding a route is a big problem, it's not even the real problem with routing.
The problem is for LN to function at scale, it have to centralize around a few big hubs. Because otherwise routing is impossible, and transactions will fail.
Decentralized routing is an intractable problem, and LN have to choose between centralization and scaling.
Because LN is seeing barely any usage at all. The routing problem will bite as soon as it tries to scale.
Definitely not true.
As I previously mentioned in this thread, lightning has over $6 billion USD in liquidity, nearly 11,000 nodes and tens of thousands of transactions every day: https://news.ycombinator.com/item?id=21980404
Those stats are either false, or are actually evidence that the network is tiny. Tens of thousands of transactions per day means it's not even doing a single transaction per second, which is miniscule.
According to a recent study, the privacy properties of the lighting Network are weak.
The problem with lightning privacy is that to get good privacy you need more than about 2 hops. The problem is that every hop locks up money equal to the amount transferred: increasing the cost of the transaction.
The study also finds that the LN is currently subsidized, and based on the capital costs alone, fees should be comparable to on-chain (BTC) transactions. BCH transactions are currently subsidized as well, but not to the same extent (I estimate 3cents/kB would pay for processing and storage).
> Then, users will slowly stop their BCH full nodes because it becomes a bother to keep them online.
Why do you assume BTC/LN will improve scalability properties but not BCH? On-chain capacity can be optimized over time without increasing the average cost for running a node.
Ha! Another empty prediction that we'll happily call you out on once it expires. Remember when you predicted that Bitcoin would completely cease to exist by the end of 2019? https://twitter.com/lopp/status/1211707215620530176
The argument that "only large entities will be able to keep up with that" doesn't really hold - thats the status quo already.