Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> partly because these off-chain networks would quickly form large central "hubs" which would obviate many of the benefits of Bitcoin

The Lightning Network is open-source and decentralized. It has no "hubs", but rather just peers that route payments to each-other using a payment routing algorithm. Lightning has no counterparty risk, as no one can ever steal your bitcoins and you're always in full control.

The best way to describe Lightning is as an write-cache layer. It improves the scalability properties of Bitcoin by many factors, makes micro- and nano- payments a reality, reduces fees to fractions of a cent, and even improves privacy (using a Tor-like onion routing for anonymized payments).

https://www.youtube.com/watch?v=MpfvhiqFw7A

https://bitcoinmagazine.com/articles/understanding-the-light...



What do you mean that Lightening has no counter party risk? It's my understanding that you have to constantly monitor the Bitcoin network as long as a payment channel is open to make sure your counter party doesn't try to cheat you.

I also don't buy that hubs won't tend to centralize since hubs with channels open with a lot of other peers will naturally be central points.


Yes, you have to watch for cheating attempts, but you get all your money back plus a bonus if you catch someone doing that. If you're doing that properly (and there's no reason you won't), then there's no counterparty risk.

Edit: also, you can outsource this task to someone else, who'll take a small fee out of your bonus if he catches the cheating for you (and only if he does).


That sounds horrible. All your counter party has to do is DDOS your node off line then they can steal your lightening network funds. Outsourcing the task to a centralized service also sounds bad. At that point you have to trust that service.

Anyone that looks at lightening can plainly see that it has a number of properties that aren't as nice as pure Bitcoin. With Bitcoin if I get knocked offline there is zero chance of my counter party stealing funds from me and you don't have to put your trust in any centralized monitoring service to prevent your counter party from stealing from you.


> Outsourcing the task to a centralized service also sounds bad. At that point you have to trust that service.

You don't have to trust that service. He can't steal your money, you don't lose any privacy if the other party doesn't cheat, you don't pay anything to the service if there's no cheating attempt, and the 3rd-party service is financially incentivized to help you prevent cheating.

So, no, you don't "trust" anyone in any more meaningful sense than saying that you're "trusting" the miners.


Yes, you absolutely have to trust the service.

If I have a channel open with Alice and she wants to cheat me but I've out sourced my monitoring to Bob Alice only needs to pay off Bob to go along with her cheating me. I have to trust Bob not to collude with Alice. In Bitcoin I don't have to trust anyone. Surely you can see that there is a difference in the two models.


You can have as many Bobs as you want, which can all function at a very low cost and compete for users with low fees and high service quality. I can easily imagine registering your transactions to tens of different service providers, making it quite impossible for Alice to pay them all of (or even know who they are).


How do you know bob didn't setup many nodes to perform a sybil attack on you? You don't.


How do you counter the description of the network in this article? It seems like de-facto hubs will form out of necessity to avoid creating a channel on the fly, which requires getting a transaction committed to the blockchain.

https://chrispacia.wordpress.com/2015/12/23/lightning-networ...


> Routing paths are much harder to find when values are considered.

Hard, yes, but definitely possible. There was some great work done on P2P routing for Lightning by the developers at BitFury.

http://bitfury.com/content/5-white-papers-research/whitepape...

> We could end up making more on-chain transactions ... Well, it will have to close one of its existing channels. So the process for making a transaction when your wallet can’t find a route is: 1) Make an on-chain transaction closing out an existing channel. 2) Make an on-chain transaction opening a new channel with the payee.

This is not true. You can close an existing channel and open a new one in a single transaction.

> The vast majority of users will be offline.

Some will, some won't. Some will set this up on a VPS, some will use hosted services, some will be professional liquidity providers (early adopters with lots of coins?) that have a machine dedicated to this.

He's making a prediction that he cannot really support in any way.

> Channels cannot be created on-the-fly.

RBF is opt-in, only if you mark your transaction as such. If you don't want RBF, don't use RBF. His assertion that RBF is somehow required is not true.

> Recipients have to be online.

Yes, they do. This is perfectly fine for some use-cases, and not good for others. For use-cases where the recipient is offline, people can always resort to on-chain transactions.

I'm not sure what this has to do with hubs, though.

Basically, he's making tons of assumptions and guesses (some of them based on incorrect/outdated technical information). You should go and read-up yourself on the technology and the improvements the developers are coming up with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: