Live data from Hacker News

Bitcoin has a huge scaling problem–Lightning could be the solution

arstechnica.com

61–70 of 141 posts

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#61
post #30

Earlier quoted context omitted.

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.

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#62

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…

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.

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#63

Earlier quoted context omitted.

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 bala…

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…

Tor has a centralised list of exit nodes.

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#64
post #44
post #27

Earlier quoted context omitted.

>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.

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#65

Earlier quoted context omitted.

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.

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?

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#66
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"?

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#67
post #51
post #12

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 transactions are confirming for less than 5 Sat/b since the spamming stopped. http://core.jochen-hoenicke.de/queue/#24h

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".

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#69
post #60

Earlier quoted context omitted.

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 chai…

OK. So 0-conf are not secure because you read it somewhere, good argument.

Re: Bitcoin has a huge scaling problem–Lightning could be the solution

#70
post #55

Earlier quoted context omitted.

>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…

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 t…

>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).

Post reply on HN