Bitcoin has a huge scaling problem–Lightning could be the solution
arstechnica.comLightning appears to add more problems than solutions. It has a whole bunch of critical issues. Here is a short list.
1. You need to have a computer constantly online or your counter party can easily steal all your money. This leaves you vulnerable to all sorts of attacks.
2. The lightning network works by routing payments through a network to your destination. The issue here is that the routing for the lightning network is extremely complicated and is currently an unsolved (and probably unsolvable) problem. The core issue is that you have to route money though a network where channel capacities are changing with each and every transaction. Imagine trying to route internet packets if the size of the links changed thousands of times per second.
3. It's relatively expensive to create and destroy channels at about two transactions per channel. Lightning proponents claim that this will be rare, but that can only be the case if there is minimal net flow of money. This is trivially not the case because users will be sending bitcoin more than they recieve and the reverse for retailers.
4. Lightning has huge capital costs. You need to lock up large amounts of bitcoin in these channels for significant amounts of time. There is a real cost for this in terms of the lost interest. Channels are certainly not anywhere close to free.
>1. You need to have a computer constantly online or your counter party can easily steal all your money. This leaves you vulnerable to all sorts of attacks.
This isn't not the case. You can outsource channel monitoring to other peers in the network such that if anyone attempts to cheat you, they can punish the cheater and claim a reward. Bitcoin makes various security assumptions such as 51% of the mining power is honest, users have access to perfect information about the blockchain, etc... The LN, if the software is designed correctly, is likely to more realistic security assumptions than Bitcoin itself.
>3. It's relatively expensive to create and destroy channels at about two transactions per channel. Lightning proponents claim that this will be rare, but that can only be the case if there is minimal net flow of money. This is trivially not the case because users will be sending bitcoin more than they recieve and the reverse for retailers.
Channel factories[0] address this problem such that you can move channels between participants without touching the blockchain. There are also ways to do this whereby you switch n channels for a single transaction that spends log n outputs.
[0]: Scalable Funding of Bitcoin Micropayment Channel Networks https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7c...
Don't channel factories only allow you to move channels between users who were a part of the original multiparty transaction?
It's a fantastic idea, but I feel it more has usecases between popular hubs and less for actual users.
Although they also have the side effect of making the initial transaction on the blockchain up to 90% cheaper, so they are useful there too!
>It's a fantastic idea, but I feel it more has usecases between popular hubs and less for actual users.
Won't actual users be connected to popular hubs? For instance Alice's connects to Hub1, Hub2, and Hub3 via a channel factory.
That is true! The biggest downside with channel factories is that noncompliance from one party forces the whole factory to close and reopen without them, which gets much more likely with every added participant. But if there is only one participant which is "untrustworthy" (on some level, in the sense that they aren't trusted to stay online as much as well known nodes are), then the system could work fine.
That's really interesting, and opens up a lot of ideas. Still, I think we should avoid trying to bring up channel factories for now. They are still a few steps away as they add more complexity to an already complex system. Focus on getting LN up and working, then add in nice-to-haves like channel factories slowly once vendors are on-board.
I agree there is enough to do with getting the LN up and running. However the future of layer two protocols is extremely bright and the current limitations of the system are clearly surmountable. Add op code support for channel factories and you can change key sets on an arbitrary number of factories with one 200 byte on-chain transaction.
Given all the money flying around ICOs, it is pretty amazing that there isn't more money flowing into layer two. Hopefully that will change in 2018-2019.
2 isn't true at all, routing isn't nearly that complicated and I don't know why everyone thinks it is. Most routes are expected to be under a few hops. But regardless we will find out soon as the number of nodes on the live system is very rapidly growing.
3 doesn't really apply, as channels can be used as middle hops to rebalance.
If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin from coinbase, coinbase can route that BTC to me through you to rebalance our channel so it is all on my side.
4 isn't true, as "locking the BTC up" is basically making it available. Would you consider depositing cash into a checking account "locking it up"? Because that's the equivalent here. But also locktimes are normally a few days.
2. Where is the evidence of this? Sure, routing can be easy and short if it's centralized and the number of hops is small. But, if it's centralized, then what's the point of using Bitcoin? Where is this mystical routing algorithm that will work in the presence of constant capacity changes over a decentralized network?
3. The issue here is that the flow for all channels across the entire network needs to be about balanced for things to work out properly. Once someone starts either net accumulating bitcoin or net dispersing bitcoin, then there will be problems somewhere on some link.
4. I can take money out of my checking account at any time at no expense.
About 2, like I said we should know soon if it will work. I just don't think that most channels will be updating as quickly as you think, and even if they are, a channel will know of someone is trying to route through it, so it can avoid trying to route another tx for the duration of the first.
3. Fees can and will help balance things out. If a channel is really unbalanced, negative fees can strongly incentivize rebalancing in many cases. If it starts to get unbalanced again, fees can increase to help reduce the speed that it unbalances.
4. You can also take money out of LN at any time (assuming your counterparty I cooperative). Only in the case of non-cooperation do you need to wait for locks to expire, and in that case you get ALL money from both sides of the channel, and need to wait for the lock to expire.
Id love it if my bank could give me 2x my money if it takes more than 3 days for me to get my money...
> You can also take money out of LN at any time (assuming your counterparty I cooperative)
This isn’t what people mean when they imply liquidity. Needing consent and being able to unilaterally demand cash are different domains. The former is e.g. a holding in a fund or coins in a LN, the latter is a consumer checking account.
> Id love it if my bank could give me 2x my money if it takes more than 3 days for me to get my money
Or lost 90%. We had this in the era of free banking, i.e. pre Federal Reserve. We then split the speculation and transfer functions of our financial system and ended up better for it.
>This isn’t what people mean when they imply liquidity. Needing consent and being able to demand cash are different domains.
I don't understand what you are trying to say here. You don't need "consent" if you want to wait the 3 days, but if you get "consent" from your counterparty you can get it instantly. 3-days is about as fast as ACH. But if you want, you can feel free to open channels with shorter locktimes if needed.
>Or lost 90%. We had this in the era of free banking, i.e. pre Federal Reserve. That history is one Bitcoin is presently replaying.
But you can't lose money if LN is working correctly. The whole idea is that you sign the transactions saying "if this is broadcast under these conditions, you get all of my money" when you open the channel. It's literally not possible to fractionally lend on LN, because all money MUST be there, and signed, for you to use it.
I've had conversations with you before, and I'm fairly sure you don't understand the basics of Bitcoin as you keep repeating these things as fact, so I'm going to stop replying here. Please make an effort to understand it before you start denouncing it. Or at least explain why you think these apply to the conversation in ways that someone like myself who isn't well-versed in traditional banking systems but understands Bitcoin technically will understand.
> if you get "consent" from your counterparty you can get it instantly. 3-days is about as fast as ACH
You said, like a checking account, one “can also take money out of LN at any time.” I clarified that when people say “take money out at any time,” they mean unilateral liquidity. You can unilaterally demand cash or an instantaneous Fedwire transfer, the latter which costs 3 to 69 cents [1] (though some banks heftily upcharge this service), against your checking account balance. It takes a good deal longer to settle a LN balance (theoretically).
TL; DR The Lightning Network has some neat features, but pitching its liquidity as analogous to a checking account’s is disingenuous.
> you can't lose money if LN is working correctly
This applies to anything. In finance, things never work correctly because someone, somewhere, can be trusted to be an arsehole.
> It's literally not possible to fractionally lend on LN
The number of Americans who have lost a single U.S. dollar to this threat since the FDIC was formed is basically zero. The number of Americans who have nuked substantial fractions of their net worths speculating on Bitcoin is significantly greater.
[1] https://www.federalreserve.gov/paymentsystems/fedfunds_corep...
> This isn’t what people mean when they imply liquidity. Needing consent and being able to unilaterally demand cash are different domains. The former is e.g. a holding in a fund or coins in a LN, the latter is a consumer checking account.
Is it really true that you can get easily the money out of your checking account if your bank declines to give it to you? In a traditional bank account, it is possible to place a hold on an account for various reasons, mostly when compelled by the government.
> In a traditional bank account, it is possible to place a hold on an account for various reasons, mostly when compelled by the government
The traditional hierarchy of liquidity goes first cash, then Treasuries then checking accounts. Checking account balances (i.e. senior, registered claims on a bank) are junior to the first two (i.e. senior, registered claims on the U.S. Treasury and senior, unregistered claims on the Federal Reserve, respectively) for the reason you specified. I still contend a checking account will more reliably produce immediately-available funds quicker than a LN "deposit," even if one is a criminal.
This sidelines into why I believe illegal markets are the only place blockchains have a shot at being a currency. Shadow economies are substantial, between $1 and 3 trillion in the U.S. alone [1]. It's a different pitch from "replace the U.S. dollar," but it's more realistic. (I am not advocating anyone do anything illegal.)
Stepping back, it's pertinent to look at the Two Generals' Problem [2] which Satoshi's paper solved. It's a problem of exchanging information, not value per se. Blockchains are here to stay, but not--in my opinion--as currencies. Libor on a blockchain or legal documents "Docusigned" on a blockchain are far more compelling than "we'll make our light-speed payments system less reversible and better for illegal activity". They're also use cases which become difficult to justify if the "tokens" underlying them rise in value.
[1] http://www.imf.org/en/Publications/WP/Issues/2018/01/25/Shad... Table 4, page 11
Lightning uses the same routing algorithm as tor — it’s an onion router. It has the added benefit of no one in the network knowing where transactions are from or whom they’re to.
With regards to channel capacity — fees in lightning are proportional to the amount of the transaction. If you are sending a transaction which consumes a large amount of capacity, you pay a high fee. Note how this is a fundamental difference from onchain transactions where fees are proportional to the amount of block space used.
Lightning is more akin to an atm. You pay a fee to take out cash, but you can then transact instantly all day with nearly no fees.
Tor has a centralised list of exit nodes.
which doesn't apply to tor hidden services, which work fine without an exit node.
Sounds like you're familiar with the tech, maybe you could answer a couple of questions:
> If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin from coinbase, coinbase can route that BTC to me through you to rebalance our channel so it is all on my side.
Could you point me to details about how cross-channel rebalancing happens?
Since lightning network channels are purely 1:1 (per the whitepaper); say you drained your channel to me, how does your channel with Coinbase allow you to route BTC to our channel without reopening a channel (requiring on-chain transactions)?
The whitepaper mentions hops, but I can't find any details on how they actually work.
> But also locktimes are normally a few days.
Does that imply that every channel needs to make an on-chain transaction every few days to reopen/keep the channel open?
>Could you point me to details about how cross-channel rebalancing happens?
Lightning transactions are less like TCP packets, and more like water in a pipe. If I put 1 ml of water in a pipe full of water, 1 ml comes out the other end, but it's not the same water.
It works like this:
I can give you 1 apple, but I contractually obligate you to give 1 apple to my friend Bob, and if you don't you get penalized. You won't actually give Bob the apple I gave you, you'll give him another apple that you have, and if you don't know exactly where bob is, you could give an apple to someone else, telling them to eventually give an apple to bob "or else". (in LN, the "or else" is actually cryptographically secure pre-created transactions)
Because of this, each 1:1 channel is actually a network of 1:1 channels that can move in both ways.
In my first example, there was an unwritten implication that you would have a connection to coinbase somehow through another channel. So if I paid you 1 BTC for something, and you have a connection with coinbase (either directly, or through another channel), then if I buy from coinbase they can send that money "through" you to recharge our channel, without you really "spending" any money. And you are more than happy that happened, because now I can buy more from you directly through our channel, so you might incentivize that kind of routing by setting an extremely low, or even zero, or even NEGATIVE! fee.
>Does that imply that every channel needs to make an on-chain transaction every few days to reopen/keep the channel open?
No, locktimes only come into play in the case of non-compliance. If we have a channel with a 3-day locktime, on day 2 we can agree to re-up our lock for another 3 days (really at any time we can), we can also agree to close it right now if we want, all off the blockchain. Only when you either try to cheat, or become non-responsive do locktimes come into play.
Sorry, I didn't mean in layman metaphors but the actual mechanics. (I am technical and fairly familiar with Bitcoin, I'm just having a hard time convincing myself from reading the Lightning whitepaper and I'm hoping to find some alternative explanations that are clearer.)
Like what kind of transactions/operations need to happen between nodes for two channels to get rebalanced?
> No, locktimes only come into play in the case of non-compliance. If we have a channel with a 3-day locktime, on day 2 we can agree to re-up our lock for another 3 days (really at any time we can), we can also agree to close it right now if we want. Only when you either try to cheat, or become non-responsive do locktimes come into play.
Right, I understand that it's for non-compliance, that's why I was assuming that this part has to happen on-chain.
Aren't timelocks enforced on chain? How can we agree to extend our timelock without committing that agreement to the blockchain?
I understand that the premise of timelocks is that if there's a conflict, the channel collapses and the timelock buffer period allows the victim a period to claim restitution (hence needing to stay online or have a service do it on their behalf).
>Like what kind of transactions/operations need to happen between nodes for two channels to get rebalanced?
So "rebalancing" is kind of a word for a side-effect of normal routing.
It's all based on fees. So if you have a channel with "the network" (either through 1 or more channels to a big hub, or some other way), and I have a single channel with you, then another channel with "the network".
Our channel started off with .5 BTC from each of us. Then I paid you .4 BTC so the channels are:
You: .9 BTC, Me: .1 BTC.
Nodes broadcast fees, so you would broadcast that for me to send money from me to you (either directly, or through a "hop"), it will cost 20 satoshis. But you can also broadcast that for someone to send money the opposite direction (from you to me), it's free right now. Someone that wanted to pay a 3rd party unrelated to us would try to find a route that went from you to me then to the rest of the network.
So really "rebalancing" is just incentivizing someone else to rebalance your channel by exploiting their selfishness and want of low transaction fees and to include you as part of a hop. Fees can even go negative, which would make it super beneficial for someone else to include your channel in their transaction (even if it's out of the way, or doesn't serve any real purpose) to get a bit of money from it!
Who actually broadcasts the fees can be found by looking through popular node software (each node only broadcasts one direction of the channel, and I don't remember which it is right now), as well as the broadcast system (which I genuinely don't know off the top of my head).
>Aren't timelocks enforced on chain? How can we agree to extend our timelock without committing that agreement to the blockchain?
Yes and no. They are "enforced" on chain in the sense that they can't be accepted into a block until a specific block number. But they aren't ever broadcast to anyone else until you are ready to use them. In essence all LN transactions are created, but kept secret until ready to be used. The whole concept of LN relies on the fact that if we make a transaction but never broadcast it, did it really happen? If you and me agree to make a new transaction saying "this expires in 3 days from right now", technically the original transaction is now valid once 3 days pass from it, but if you try to broadcast the tx that forces all the money to you, I can broadcast the transaction that proves that we did something else after that (our second "update the locktime"), and then gives all the money to me.
Every time we do something to transact, we also create a set of transactions that serve as proof that the old transactions are in fact "old" and shouldn't be accepted, and if anyone tries to broadcast them, we can invalidate them (and enforce a "penalty" to dissuade anyone from trying to cheat).
That's fine, but if #1 is true, Lightning is far from workable.
#1 isn't strictly true, you don't need to be "always online", only online at some point within the locktime (normally 3 days right now).
You can also hand your "revocable delivery" transactions to a 3rd party (or multiple 3rd parties) who can monitor and broadcast them in the case of cheating, but can't actually spend any of your money themselves.
So you could have a group of people watching the blockchain always online that can punish non-compliance, but you yourself are only online when you want to transact.
Of course, someone could pay off that third party to stop watching your channel.
And you could have multiple "watching" services that can prevent any one "watching" service from betraying you.
Obviously controlling your own "watching" system is most secure, but the vast majority of people aren't going to want to do it themselves.
And again, if the biggest worry is that someone will pay off multiple "watchers" then publish a previous version of a channel to steal money from you and hope that your proper node isn't online at any point during the locktime (or DoS your node to prevent you from seeing the bad transaction) to punish the thief and "steal" all the money back. I think we are doing a pretty good job!
According to you own words, the answer to poor transaction times is to make transactions less reliable and to introduce centralization.
I have to ask the million dollar question. Has this been threat modeled?
I don't know where you got all that from!
Transactions in LN are just as "reliable", and don't introduce centralization in any meaningful way.
As for the "modeling", I'm not sure what you want. The threats have been outlined in the whitepaper, and successfully tested in some capacity on testnet. And now they are being tested as lightning network is being rolled out on mainnet. There might be some formal "threat modeling", but i'm not familiar with what that would even look like or mean.
No better way to "threat model" than to try it out in a hostile environment where bad actors that have some kind of "exploit" can already use it to gain BTC.
> As for the "modeling", I'm not sure what you want. The threats have been outlined in the whitepaper, and successfully tested in some capacity on testnet.
> No better way to "threat model" than to try it out in a hostile environment
You just answered my question, sorry to say.
Don't take my not knowing what you mean as a confirmation that nobody in this space knows what you are talking about.
I know the technical side somewhat well, and apparently have a thing for explaining the basics in layman's terms. I have a feeling I don't know what you mean by "threat modeling", but that doesn't mean nobody does. And your choosing to make sly comments instead of explaining yourself doesn't fill me with confidence that you are being completely impartial here...
> Don't take my not knowing what you mean as a confirmation that nobody in this space knows what you are talking about.
I don't take that. I'd go on a limb to say the majority of readers here are familiar with the concept of threat modeling. Since you don't want to look-up the term, instead slighting me for using it: What is called a threat model is in reality a vulnerability model created by a formal process. In software development, there may not have been a single threat model created by security people that didn't expose vulnerabilities overlooked or not paid attention to by developers of the particular app in question. This is done from an attacker's perspective by people familiar with that perspective, instead of from a developer's perspective which usually doesn't notice vulnerabilities in their own design. This isn't a slight on the developers but that the attacker's mindset and the specialized knowledge of security people are not normally conjoint with general purpose devs.
> instead of explaining yourself doesn't fill me with confidence that you are being completely impartial here...
Impartial? That sounds silly to me, but I know there are tons of people who promulgate their cryptocurrencies and network addons without regard to reality. I'm not one of them. I no longer have any position in any coins, having sold my coins fully in the latest run-up, and am not a creator or anything of any of them.
By the way, you come across as pushing for lightening partially not impartially, since you have danced around the two points I made in my first post. You seem to be an apologist for the tech, not someone who wants to get the right tech implemented. I don't know why you accused me of being partial, when all I did was point out two issues with your statement and asked a question. In reality, you don't seem impartial and should disclose your stake in this tech.
I am not familiar with the term "threat model" to mean anything specific, which is why I asked (in other words, it's like asking for the "architecture model", it's ambiguous enough that it could mean any number of things).
But in that case, yes, there is a section of the whitepaper dedicated to risks and threats to the system, and throughout the entire whitepaper an attacker's perspective is taken when explaining most aspects of the system, as well as some "formal" dives into specific risks referenced.
>By the way, you come across as pushing for lightening partially not impartially
I am absolutely not impartial, I very much believe in this technology and want to help explain it. However I don't think that I have at any point mislead or misrepresented the technology.
That being said, i don't actually hold any BTC currently due to personal events in my life, however I most likely will in the relatively near future. (as a side note, I always laugh at comments like this. There is no way to prove if I own or don't own BTC, and I don't personally think it's very relevant to some comments on a forum. You may feel differently, but in my experience most "bias" isn't in the form of possible monetary gain, but from the need to be "right")
>you have danced around the two points I made in my first post
If you mean that the #1 makes LN "far from workable", I feel I spoke to that directly already in the direct reply.
As for the comment of:
> According to you own words, the answer to poor transaction times is to make transactions less reliable and to introduce centralization.
I didn't say that, and if I implied it, it was a mistake. i don't think I ever brought up blockchain times at all. Bitcoin transaction times (assuming you mean blocktimes) aren't "poor", they are long enough to reduce orphan blocks and short enough to allow transactions to complete in a reasonable amount of time. I never thought bitcoin (without LN) could ever replace money, but was instead a separate type of "money" that can be used in specific cases. LN expands the possibilities here, but as for what it will do or the impacts it will have, I don't know, and i don't pretend to know.
And I feel I spoke to the "reliability" and "centralization" directly as well, but didn't' explain myself.
LN transactions are just as reliable as blockchain transactions, more so in fact. A run-up of activity can cause blockchain transactions to be caught in the mempool out-bid by others for blockchain space unless RBF or CPFP are used, which are both cumbersome and in some cases impossible. LN has no such issues. You will know before you make your transaction if it will "complete", and you will know the max amount of time that you will need to wait for funds in the case of noncompliance, as well as how much you will get as a "bonus" in that case.
And the centralization aspect is also false, as the "network" part of LN makes it so that it's easy to route around a "centralized" hub if you need to for any reason, and the routing protocol increases privacy by making it impossible for the hub to know the source or destination of the transaction unless it is one of them. Fees are the incentive that make this whole network work, and for more information you can read some of my other comments in this post.
The questions you posed were based on false information that I didn't say, and were wrong in my opinion, which is why I didn't expand on my very direct answer of "Transactions in LN are just as "reliable", and don't introduce centralization in any meaningful way."
Anyway I feel this conversation is getting a bit more agressive than I'd like, so this will most likely be my last reply. You can read into that however you want.
(1) is false. If you're not online, counterparties might decide to close open channels. But that just means you get your share of the funds in that channel refunded to you. You would need to pay a transaction fee to the bitcoin network for the on-chain transaction, but the other party doesn't get any of your money.
See section 9.5 of the lightning whitepaper:
> 9.5 Forgetting to Broadcast the Transaction in Time
> If one does not broadcast a transaction at the correct time, the counterparty may steal funds.
You need to be online all the time (or at least frequently enough) so that you can publish a penalty transaction if your counter party tries to steal coins from you.
This can be easily be solved by pre-signing that transaction and having a third party service broadcast that transaction if you're not online.
if you have to trust third parties, whats the point?
you don't. you're not handing over the private keys. you sign the transaction locally, and give them to the third party to broadcast in case you're not online. it can even be multiple third parties so you're not trusting a single one. this provides better reliability than broadcasting it yourself on your home/vps/colo connection.
You are trusting those third parties to react accordingly. They could be paid off or attacked in other ways.
If you're dealing with amounts so large that you can't trust [large number] of independent third parties, you can always fall back to on-chain. but you've got to be pretty paranoid to think that starbucks is going to collude with [large number] of independent third parties to steal your $100 coffee deposit.
I see what you mean. Three thoughts on this:
* The time lock on commitment transactions is typically set to be a few days, so you don't need to be online "constantly." At most you need to check in about once a day.
* As the white paper says, you can delegate this function to a third party, without giving the third party the ability to steal your funds.
* If the other party tries to steal your funds and you catch him, you get to steal all of his funds. So in practice I don't expect this to be a common situation. If the other guy believes there's at least a 90 percent chance that you'll check the blockchain on any given day, then the expected value of broadcasting a revoked transaction is going to be heavily negative.
One interesting comment about the third point is that once a channel gets sufficiently depleted (say down to 10% of the balance on one side), then there is an increased incentive to cheat (because the potential losses are lower). So you will usually have to keep channels at above a certain balance for security reasons.
Sure, but there’s services you can outsource that to. Furthermore, if you only use lightning for sending payments (the majority of us) then publishing an earlier version of the channel benefits you!
Are those services called banks?
You could call them that if you want, but they are significantly different than traditional banks.
These services won't actually hold your money, just a transaction that sends all the money to you if someone tries to cheat. It's more of an escrow service than a bank, but the escrow service again doesn't actually hold anything valuable.
Not exactly banks, but there's a huge chance they will be big corps with a money transmitter license, KYC, AML. What if they refuse your channel or transaction?
I think we are talking about different things. This thread is about services that will watch the blockchain for "cheaters" and will punish them on your behalf so you don't need to be always online.
You are talking about LN nodes, which work a bit differently than you seem to think it does.
For starters, anyone can "refuse" to open a channel with you, but they can't "refuse" to pass along a transaction (well they can, but because of the routing system used, you don't know where a transaction came from, or where it's going to, so they have no reason to refuse it). So if coinbase refuses to open a channel with me, I can still send money using coinbase as a middle "hop", and they would never know.
And KYC/AML laws aren't really applicable at this level in the stack. KYC laws apply regardless of what i'm buying/selling (in most cases). If I'm buying from best buy, they need to know who I am. That has nothing to do with how I'm paying, and the "middle hops" are like routers more than banks. Even if an internet router is sending a financial transaction, that doesn't mean they need to follow KYC laws. It's the same with LN, if your node is acting as a "hop" for a transaction, you don't know who or where the tx is coming from, or who or where it's going to, and it's counterparty risk free. It's more like an internet router than any kind of financial institution, so KYC laws don't apply.
> You would need to pay a transaction fee to the bitcoin network
So a micro-transaction is a 10 cent payment that can turn into a 20 dollar fee plus 10 cent payment?
> Lightning has huge capital costs. You need to lock up large amounts of bitcoin in these channels for significant amounts of time.
Isn't that kind of the point?
You conduct your day to day transactions outside the bitcoin network and (presumably) only need to hit the blockchain on rare occasions. Or so I assume not having read the whitepaper.
Having studied the history of money and banking in a previous lifetime I'd say it's more akin to gold backed deposit certificates with guarantees against double-spending and fractional reserves.
"You need to lock up large amounts of bitcoin in these channels for significant amounts of time."
That's actually false. The protocol actually limits channels to a fraction of a bitcoin currently (something like 0.1 or maybe even 0.01 BTC).
I think they mean across all channels implying some "velocity of money" fallacy harming the bitcoin network.
Wow, I guess it's dead then /s
It's an evolving software still in pre-alpha state. But the core idea is solid and if you follow the development you'll see the strides of progress that is being done on all fronts.
To your points.
1. Depending on the options you set to your channels, you could have a window of days (or anything the two parties agree to), to act in case the other party tries to broadcast outdated TXs i.e. steal funds. Also you don't need to have a computer constantly online, you can offload the task to Watchtowers, software dedicated to do that for multiple users concurrently. (You also can have multiple Watchtowers as backups). Also, I imagine it could even be a mobile app. So this is a non-issue.
2. Routing will keep being improved but it's already pretty good and the way you present it screams FUD.
3. Currently crazy low fees aside, LN basically enables the multiplication of on-chain TXs population. I think your assumption is that the retailer will close and reopen a channel for every LN payment they receive which it makes no sense whatsoever from any point of view.
4. If by huge you mean $100 of which the fee is $0.5, sure. You can add any amount you want on an LN channel. Basically it's like a hot-wallet, e.x you can add $1500 for $0.5 fee, and casually spend it for coffees and other small expenses with lower TX fees than a satoshi (since LN supports fees at the millisatoshi = 1/1000 satoshi level).
P.S: This FUD-wave is pretty pitiful, at least get some real arguments. I hope even more people start to recognize that a lot of people have incentives to attack new tech in order to push their narratives for their altcoins or w/e.
> It's an evolving software still in pre-alpha state
Now imagine a start-up in this state was hocking shares to college students and grandmas at a $140 billion valuation.
I was talking about Lightning Network nodes, not Bitcoin. Bitcoin at one point was at this stage but through iterations and continuous improvement it evolved to being able to secure all those funds.
The point is that it's disingenuous to deem a new tech dead, while the engineers working on it sill say that it's not yet fully-ready for production.
The implementation and the protocol still evolves, but the core idea behind it is rock solid and the most promising way forward to help with scaling AND enable use-cases that would be otherwise impossible (see microtransactions & realtime millisecond scale monetary transactions etc.)
> I was talking about Lightning Network nodes, not Bitcoin
The latter being useless as a currency, per the article, without the former.
I fail to see how this moves the discussion forward, we're talking about how effective LN could be regarding helping with scaling.
Also, note the core idea of LN (updatable non-broadcasted Bitcoin TXs with incentive-based security and eventual broadcast to the blockchain network) is a powerful idea and as we explore this scheme and more engineers get accustomed I am sure we will see even more exciting things.
Do you happen to know where I can find the code or white paper for the current, working, routing algorithm?
Sure.
- Onion Routing Protocol: https://github.com/lightningnetwork/lightning-rfc/blob/maste...
- P2P Node and Channel Discovery https://github.com/lightningnetwork/lightning-rfc/blob/maste...
This repo contains specs for a lot of parts of the LN, although probably there may be changes I imagine.
As for code, one of the implementations, LND (Go): https://github.com/lightningnetwork/lnd/tree/master/routing but there are at least 3 other implementations in the works.
https://github.com/ElementsProject/lightning (clang) https://github.com/ACINQ/eclair (Scala) https://github.com/mit-dci/lit (Go)
5. With channel networking, you have to be online to receive funds. Unlike (1) you can't really outsource this, unless you're willing to trust someone else to hold your funds for you.
Wow. I didn't know about #1. That is absolutely, categorically fatal. If that's true then lightning is DOA.
Nothing to see here.
As long as you solve transaction malleability (segwit), #1 is a non-issue.
At that point haven't you just reinvented fiat currency?
I'm not sure how you can come to that conclusion.
Literally none of these are true except for #4. It’s remarkable to have this many incorrect assertions stated so confidently in a single post.
As for #4, I view it like a checking account. You need to have a bit of money set aside in liquid form in case you want to buy something.
Here's a shorter explanation of Lightning, with Solidity code: http://www.blunderingcode.com/a-lightning-network-in-two-pag...
Nice article, thanks!
Or perhaps replacing bitcoin with something that doesn't have fundamental flaws in its design.
Hence why a lot of us think it has no inherent value into the future. Of course, those in on the ponzi scheme will disagree with this sentiment.
Nano previously called Raiblocks is an amazing candidate for fee-less, instant transactions. The block-lattice approach is a fundamental breakthrough that overcomes the limitations of blockchain in terms of cost and speed.
Stellar is also a worthy contender although it wasn't designed with the purpose of payments, but decentralised currency/crypto exchanges.
The Lightning Network daemon codebase on Github is a beautiful well commented piece of Golang code though.
>The block-lattice approach is a fundamental breakthrough that overcomes the limitations of blockchain in terms of cost and speed.
Not really. DAG/lattice based cryptocurrencies offer different security guarantees compared to blockchain based ones.
They also have different scaling tradeoffs as they scale really well (the graph can be arbitrarily wide as tx's can run in parallel) when most transactions are causally unrelated but hit bottlenecks with every "killer app" that gains traction (graph narrows as more and more transactions become causally related).
I'm not sure what domains see this problem crop up but I've seen it in quant finance strategy execution. Say you have 1k strats that you want to run in parallel but risk needs to bound the bank's per-equity positions globally. When the strats work on different subsets, DAG approaches aren't a problem, but when most of the strats trade APPL/IBM your once very wide (parallel execution) graph narrows significantly (becomes more sequential) as the strats need to check with risk w.r.t. AAPL/IBM sequentially.
NB: for this reason, causal approaches are pretty rare to see today (though it depends on the domain as high latency contexts don't really care).
I know that there might be spam problems if one manages to precompute the local PoW hashes (solved by pruning the chain), but I would love if you explained more this security problems. Are they consensus-related as some people in reddit suggested? If this is the case, it might be good for Nano to get someone like @aphyr to audit the code.
My understanding is that Stellar is both a payment solution and a platform for facilitating decentralized exchanges. The two go hand in hand.
Nano is also interesting, but limited. In terms of moving value around, I think Stellar is more compelling.
It’s funny to say ‘replacing’ bitcoin to me because we talk like it had a strong value and use in the past but really this has all just been speculation since the start. We all seem in agreement that blockchain as a technology is legitimate but none of these currency implementations float my boat yet because of how highly speculative the whole market is right now.
Aside: last week up I looked it up and sure enough there’s a ‘PonziCoin’ out there
I don't think the blockchain is a good technology. Traditional databases or something like Git solve the same problems better. I have an ideological desire to see more trustless and peer-to-peer systems and I think they'll take hold eventually, but at the moment blockchains are worthless.
It's a good technology if you agree with the goals of libertarians today which is that we should be able to do everything without trust. Having trust is such a huge shortcut of energy and enables you not to have to completely do everything yourself. It pretty much enabled civilization to begin with, but many people now have given up on trusting anything and don't think they have the agency to improve any sort of trusted authority.
There’s a lot more I could know about the practicality of blockchain but the value of the technology is still more real than the currencies that live on it. It seems to me, in my perhaps naive opinion, that in the long run blockchain might just be a way to make digital certificates of authenticity for digital goods that need a guaranteed uniqueness feature.
As I previously posted here in HN, this author suggests PGP for immutable database where Bitcoin is projected as serious use case http://rajeshanbiah.blogspot.co.uk/2018/01/technology-predic...
The lightning network can also be used for atomic swaps to exchange cryptocurrencies with each other. If a vendor accepts lightning payments in theory you could pay with any cryptocurrency you want. In a future like that it's likely that bitcoin could become insignificant.
I think that the end game of Lightning is very bad. Imagine that Bitcoin remains relevant and continues to have huge market cap for several years and that Lightning takes off to the point that most transactions use Lightning and the cost of an actual on-chain transaction drops to a few tens of cents. The reward for mining a block will drop significantly (as originally planned in the Bitcoin design), and the transaction fees per block will also drop significantly.
On the flip side, with Lightning, it's possible to steal quite a lot of money if you have the ability to prevent transactions from being mined (i.e. if you can mount a 51% attack). In particular, you can prevent any penalty transactions against yourself from ever showing up on the blockchain.
In other words, Lightning will drive the profit available from 51% attacks up and will drive the profit available from honest mining down. What happens when they cross over?
> the cost of an actual on-chain transaction drops to a few tens of cents
"In 2014, the volume-based transaction fees [for Fedwires] range from 2.8 cents to 69 cents per transfer" [1]. They charge an extra 15¢ if the quantity is over $10 million and another 36¢ if over $100 million. These transactions settle instantly and almost every bank gives consumers access to them (albeit with varying surcharges).
[1] https://www.federalreserve.gov/paymentsystems/fedfunds_corep...
Bitcoin Cash seems to be doing just fine with on-chain scaling. There are concerns about centralization on miners with it, but in my understanding the incentives planned in the original Bitcoin paper account for that.
Bitcoin Cash can’t even scrape together enough transactions to form 100kb blocks. It’s rather disengenuous to say it’s scaling better when it has a fraction of the users. Furthermore, larger block size is directly related to centralization. The bcash crowd hopes people forget decentralization is important.
It's a common misconception that block size is somehow related to decentralization. In fact you don't need a whole blockchain to verify transactions securely, you only need a few last blocks at max. Also full nodes add nothing to the network, they have no vote, only miners and actual users do.
Did you forget http://www.uasf.co/ ?
If only Coinbase and large exchanges can afford to run full nodes, how many programmers will be able to afford to program your programmable money?
>Bitcoin Cash seems to be doing just fine with on-chain scaling
Has it though? AFAIK it still has lower transaction volume than bitcoin.
There were some episodes in the latest months of very intense traffic (either an “attack” or someone stress testing) and Bitcoin Cash has endured it just fine.
Let’s see how it works out when adoption grows. If it doesn’t scale, then the timing for off-chain scaling will be more appropriate.
I don't think anyone seriously thought that 8MB blocks would crash the network. The actual concern was in the increased cost of running a full node.
Bitcoin transactions are confirming for less than 5 Sat/b since the spamming stopped.
Spam? You mean "spam" generated by Steam and Stripe since they stopped accepting Bitcoin? People have stopped using Bitcoin because the fees were too high. That's not "spam".
Bitcoin may have made a PR mistake by not allowing for interim scaling solutions like BCH did with doubling the block size, but block size increases are a dead end. They cannot possibly scale the network enough if demand really takes off. I think lightening is a very interesting solution. You may disagree, but you can’t just plan to increase the block size forever.
The moment I used Bitcoin Cash myself, I was completely stunned why people keep supporting it.
To give something to back me up, just look at the charts of BCH and it's main competitors: Litecoin and Dogecoin.
total # transactions: https://bitinfocharts.com/comparison/transactions-bch-ltc-do...
-> Litecoin does more than 2x the traffic of Bitcoin Cash and Dogecoin. Remark that Dogecoin sometimes handles more traffic than Bitcoin Cash.
Transaction fee: https://bitinfocharts.com/comparison/transactionfees-bch-ltc...
-> Dogecoin clear winner, Bitcoin Cash about the same as Litecoin (but remark that Litecoin handles double the amount of transactions)
So to be honest, I think Bitcoin Cash is just trying to ride the "Bitcoin" name, because for applicability, it doesn't seem to have any advantage over its direct competitors.
Lightning involves an always-on, networked, machine holding your private key. Your bitcoin is a bounty for 0-day exploits. Brilliant!
Opening a Lightning payment channel doesn't require your master private key. You'd create an initial transaction using your primary wallet (which would presumably be in cold storage) to open the Lightning channel and fund it. There's no relation between the two, _at all_. A funding transaction is no different from any other transaction.
By design, the Lightning hot wallet can only hold small amounts of BTC (0.042 BTC currently), and yes, this would be essentially a hot wallet. The funds are held in a trustless, multi-sig, timelocked payment channel between you and your channel peer (which does not have to be the intended recipient). A channel can stay open indefinitely, and it will be possible to replenish it as needed. The idea is to have it function like a checking account. I fail to see how this is any different from a regular BTC wallet on your phone, or even your bank/investment app (except safer).If you're really paranoid about the funds in your hot wallet, you're free to create an m-of-n multi-sig wallet with somebody else you'd trust, which renders that attack vector useless.
Also, your LN wallet needs to remain online _only_ when it needs to transact. It can go offline the rest of the time with no problem. When it needs to make a LN transaction, it'll need to remain online for the duration of the transaction (a few seconds), or else the fund recovery mechanisms will kick into place.
> doesn't require your master private key
So it does require the private key to your hot-wallet to be on an always on, networked machine, right?
And the hotwallet and lightning channel can only transmit, across all channels, as much as is in this hot-wallet, and each channel has a potentially higher and rising transaction cost to open as lightning network will generate more transactions to the blockchain, not less. So you can keep your cake safe, or eat it, but not both.
I'll take the bitcoin cash approach, please. Worse is better.
> So it does require the private key to your hot-wallet to be on an always on, networked machine, right?
No. You can have the private key in an offline hardware wallet like Ledger, with the lightning app on your machine waiting for the device to sign it.
> And the hotwallet and lightning channel can only transmit, across all channels, as much as is in this hot-wallet, and each channel has a potentially higher and rising transaction cost to open as lightning network will generate more transactions to the blockchain, not less. So you can keep your cake safe, or eat it, but not both.
Let's break this down:
>lightning channel can only transmit, across all channels, as much as is in this hot-wallet
No. Each channel has its own limits, and there's no limits to the number of channels you can open.
> each channel has a potentially higher and rising transaction cost to open as lightning network will generate more transactions to the blockchain, not less If you want to open a lot of channels, yes, each one will incur a blockchain transaction. Keep in mind though that you don't need a channel per payment/per payment provider. Payments are _routed_ to your recipient via the network, in up to 20 hops, so you don't need to have a channel open to your recipient directly.
Also, in theory this should lead to _lower_ transaction fees on the network, not higher. Lightning transactions need to be segwit by design, so there's a 75% discount to each transaction. Since each channel can have an unlimited number of transactions on it, this should lead to a massive number of transactions moving out of the main blockchain into LN channels. Additionally, the channels can be opened whenever you want, so you don't have to wait till you're paying for your coffee to open the channel. If you don't mind waiting for a few blocks, you can open the channel for cents.
We don't know how this plays out in practice, of course, so we'll have to wait and see.
Edit: formatting
Not necessarily. Easy to build a lightning wallet that uses a hardware wallet for signing.
I thought it relies on a multisig transaction.
And if you go offline for a few hours, your peers can steal your balance (unless you entrust somebody else to monitor it for you, which has its own tradeoffs)
So basically, it turns into a ridiculously complicated bank. That requires 42tWh of power waste (and growing) to function.
I'm sorry, but I'm not impressed. Let's build a solution that scales better on-chain and uses a more power efficient mining algorithm.
> uses a more power efficient mining algorithm
Thats axiomatically impossible. Its the amount of energy required, not nhashes/etc, that disincentivize an attacker from rewriting history.
Well, it's the financial cost required, which in PoW is a combination of energy and capital cost.
I think a combination of both is required for optimal results. Lightning is good enough for micropayments. On chain transactions are good for large payments. The only problem with on-chain scaling is that keeping a payment history for the entire planet is not really feasable. You have to somehow prune old data from the blockchain.
What are the trade offs to having say 100,000 other parties monitor your channel for you?
For a moment I thought this was an article about how mining groups could try to power their ASICs by waiting for lightning to strike and storing the energy in giant capacitors or something.
(Not because this is a good idea, but because I didn't know anything about the Lightning network.)
I honestly dislike how the author abuses terms like "lots" and "a handful".
For example: « That means you can use a single payment channel to make lots of payments to many different people—all while generating just a handful of transactions on the underlying blockchain.»
I am no bitcoin expert, but AFAIK the bitcoin network can currently process in the order of tens of transactions per second, and that is a low number compared to the 50-100k transactions per second that VISA et similia are currently capable of processing.
So, many are "lots"? How many are "a handful"?
No, the processing capacity is about 7 transactions per second. See https://en.wikipedia.org/wiki/Bitcoin_scalability_problem
I was wondering recently, why Bitcoin is even needed for a Lightning-like network? Just settle the channels in cash (or even bank transfers), it won't be any more traceable than Bitcoin. Moreover, there is a successful precedent of such network: https://en.wikipedia.org/wiki/Hawala
Seems like a large enough "overlay network" over cache reserves and bank accounts can be made barely traceable and pretty efficient.
Lightning's core innovation is the use of the Bitcoin blockchain as a cryptographic backstop for payment channels. If the other party in a payment channel stops cooperating, you can broadcast the current commitment transaction to the blockchain, which effectively refunds the current balance back to each party. There's a similar mechanism for enforcing the hashed time lock contracts that make Lightning payment chains possible. I don't know how you could do anything similar with conventional bank transfers.
Well, it can be solved the way current banks deal with fraud and chargebacks: rely on a very small number of parties misbehaving and set off a small percentage of money in the system to offset fraud. Another (complementary) way is a reputation system for "nodes" (as is the case in hawala). Both imply some sort of centralization, but so do Lightning incentives (see the discussion around "payment hubs"), so not much difference there.
Bitcoin is both a currency and a payment method. Everybody knew right from the beginning that it's not a great payment method. The 10 minutes delay is a long time if you want to prevent double-spending.
For fast payments nothing beats a server with credit accounts. Naysayers will say that it defeats the purpose of bitcoin, but nobody thought bitcoin would entirely make banks and their fractional reserves system disappear. If anything, people will still want to borrow money.
Banks could function on top of cryptocurrencies, the difference would be that their clients would be able to withdraw their funds out of the banking system alltogether at any time, that is not just turning one credit into an other.
If it's not a decent payment method, it's not a currency. Sure, there are plenty of non-currency assets which are deficient as payment methods highly valued to investors, but they tend to have some use value or return.
Why would banks function on top of something which has no use value, generates no returns and whose sole claim to be a useful asset rests on its fungibility, which is now inferior to that of currency except in cases of regulation evasion? If people are concerned credit instruments are too risky because debtors sometimes fail to repay, it makes no sense to swap it out of their portfolio for something with no more intrinsic value than a credit instrument but also no repayment obligations.
> If it's not a decent payment method, it's not a currency.
Before bitcoin, was there any currency that was also a payment method?
I would also add that though it's not great a payment method, it's not to a degree worse than payments in euros for instance. Bank wire transfers take up to three days in Europe. I don't hear anyone stating that this undermines the value of euro as a currency.
> was there any currency that was also a payment method?
Every currency has, by definition, native payment methods. (If it doesn't, it's a settlement system, not a currency.) Most simply: physical cash.
Electronic payment systems are more complicated. In some countries, consumers can directly access them. In others, e.g. the United States, consumers indirectly access the settling-in-seconds and costing-pennies Fedwire system through banks.
> Bank wire transfers take up to three days in Europe
Maximum settlement time for SEPA transfers has been 1 business day since 2012.
[1] https://www.ecb.europa.eu/pub/pdf/other/sepa_brochure_2009en... footnote on page 20
> Maximum settlement time for SEPA transfers has been 1 business day since 2012.
I had not noticed. It's still much longer than 10 minutes, isn't it?
> It's still much longer than 10 minutes, isn't it?
Wrong tool for the task. Ironically, every transaction I’ve done in Europe used U.S. dollars and Fedwires, which close immediately and cost basically nothing. When people go off about petrodollars or whatever, the simple fact of American international payment superiority is often missed.
(The ECB has been taking about an always-on instantaneous system for a while [1]. I haven’t kept track of its progress.)
[1] https://www.ecb.europa.eu/paym/retpaym/instant/html/index.en...
People have only been paying with coins for six or so millenia now...
(And of course the reason bank credit has more recently become treated as currency and accepted as electronic payment is because it's exchangeable on demand, at parity to and often instantaneously for legal tender)
When you exchange coins physically, the payment method is ... your hands.
> bank credit has more recently become treated as currency
A bank credit is not a currency. The thing it is denominated into (EUR, USD, BTC...) is.
> And of course the reason bank credit has more recently become treated as currency (sic) and accepted as electronic payment
I think the real reason is that people had little to no choice in that regard.
> For fast payments nothing beats a server with credit accounts.
For scalability and robustness, one server won't cut it. You need a whole infrastructure to handle lots of payments securely.
I see various exchanges having trouble with scaling to support all their (new) customers, and basically they are doing the "single server" that you are talking about. Only at deposit/redraw they need to go over the requested blockchain.
So in that sense, what is your view on the latest generation of cryptocurrencies which have instant transactions and 0 fees (such as Nano)? Since I consider them the BitTorrent of currencies, I don't see how any institution could beat that.
0-confirmation transactions were working excellent before Bitcoin Core added SegWit and other useless stuff. You don't need to wait for a new block if your signed transaction is in the mempool, and it's secure enough for small payments.
0 conf transactions are incredibly insecure. If you accept one you are putting a great deal of trust in the person paying you. Bitcoin transactions are suppose to be trustless.
They are. Some context might help: when it originally launched, Bitcoin Cash was slower and more unusable than Bitcoin if you needed even a single confirmation, because the forker fucked up the difficulty adjustment algorithm so badly that blocks were every hour or so most of the time. So the Bitcoin Cash community pushed the idea that zero-confirmation transactions were safe there, unlike on the evil SegwitCoin chain, so they could claim it was still faster than Bitcoin since this was the whole selling point. There was no actual foundation for this claim, but it became vital to marketing the coin.
OK. So 0-conf are not secure because you read it somewhere, good argument.
No, they are secure, you just have to trust miners a bit more so they don't throw your transaction out of mempool. I would even argue that all the complications involved in setting up and using Lightning network make it less secure than 0-conf.
You could argue it, but you'd be wrong. 0-conf requires trust, LN is trust-less.
> You don't need to wait for a new block if your signed transaction is in the mempool
Still, many companies have always required a few confirmation blocks before accepting a transaction, regardless of the amount. Like currency exchange companies, for instance.
Savjee has a great 5 min video breaking down bitcoins proposed lightning network
What is your oppinion about that: https://youtu.be/UYHFrf5ci_g
It's a mistake of course though to think some technical change is going to suddenly make bitcoin go up again.
Thinking of an analog system — maybe this is like short term vs long term memory systems. BTC being the later.
Lightning will become centralized into services like banks and Paypal since it's too difficult to use for an average person, which completely defeats the idea of Bitcoin as P2P cryptocurrency.
1. Banks/exchanges/Paypal have KYC regulations - fulfilling these are impossible due to Onion routing provided by the nodes.
2. My mom does not know how HTTP works and she uses the Internet just fine. It's naive to think that users are going to be explicitly opening and closing channels, finding best path, etc. These can be built into wallets and abstracted out. Besides, Bitcoin of today is already too complicated for the "average" person.
Lightning is the solution and it's going to be great for making micro transactions w/ bitcoin again.
Lightning network is actual innovation and the next evolution in making Bitcoin easier to use for the masses. One step at a time.