What I still don't understand is, if there's supposed to be a fee market to support miners once the block reward ends, this means there must be high on chain fees right? That means that it will be expensive opening channels?
So the BitcoinNewsAndUpdates twitter account (a bcash shill) tweeted an article from "Bitcoin Enquirer" that claimed LN will never be a working solution. It was in Jan. I tweeted back at them with the current status and mainnet beta launch news... They blocked me. We are doing all the right things people.
what do you mean by "apps"? I bought some steam credit using LN through bitrefill. It took about 5 seconds to send payment, and claim code to have the funds in my steam wallet.
It was actually faster than using VISA.
yeah its not "happening", if you need to compile code or run nodes, and copy paste transaction codes to use LN... and I dont have a user friendly AppStore LN app.
SORRY delusional pumpers can downvote me all they want but it will happen when it happens
Weird. I don't copy paste.
You don't have it on the app store because Apple and iOS sucks. Devleipers don't use it anyway.
I can e-mail you the APK and you can just tap and install it. You know how windows let's you download an EXE? Well Android let's you too even off the play store.
Also, I don't copy paste. I scan.
When I pull up to Alberto's, they have the total on the screen and a QR code. I scan it and tap "send" and it sends the correct amount.
Easy enough for me :)
Maybe it's too complex for you, but then again, most people are computer illiterate.
[Set up](http://dev.lightning.community/guides/installation/) a testnet node and buy some fake [ice cream](http://www.blockandjerrys.fun/) (down right now) and [coffee](https://starblocks.acinq.co/#/)!
The [Eclair](https://play.google.com/store/apps/details?id=fr.acinq.eclair.wallet&hl=en) wallet works great on mobile as well, but be forewarned: all of this stuff is still beta! Expect to have to wipe everything down and start fresh!
We set a the test item yesterday in our store, so far c-lightning to lightning was smooth, not so much with an LND if you want to test here's a [dummy item](https://bitcoinshirt.co/shop/uncategorized/ln-test/) In theory you can use it for any other item, but please don't since we're still testing the implementation and all of our other items are over 10$. If you do try it out let me know if you experienced any problems as feedback is crucial here.
All these explorers are not 100% reliable, they mostly depict the network from the point of view of one, single node, which not always sees everything.
Imagine you are in a room full of people. From your perspective, there will be people hidden behind others, so you won't have the "bird's eye" view on the whole room.
Wow, that's a lot of explorers. It would be incredible if there was a way to collate the data and find hidden corners from individual points of view, as you describe. Surely with about a dozen explorers, 95%\+ of all the nodes could be visible.
Is this the --private option?
Honest question: what's the reason to do this? IE: don't nodes WANT to be found, and thus expand the possible routes through the network?
Put differently: why run a hidden node?
I'd imagine "private" nodes would still be routing payments, granted they have open channels with other nodes. It's not like when a node attempts to make a payment, it attempts paths through every other node in the network. It only tries paths whose edges are payment channels between nodes. By definition, any node surely must know about any other node whom it has an open channel with, be that node "private" or not.
The only effect this "private" option having on routing that I can imagine is if a node is trying to find new nodes to connect to in order to successfully route a payment. In this case setting your node as "private" means that other nodes in the network cannot attempt to open up a new channel with said private node.
In other words, routing is generally expected to happen only through nodes that have open channels between them. If a node has an open channel with another node, it will already know it exists, even if the node is "private" - a "private" node is only hiding from nodes whom it doesn't have an open channel with, and thus wouldn't be able to route payments with anyway
Hopefully some of that made sense :) and notabene I'm not even sure if what I'm saying is correct
Nodes do not need to be direct peers in order to route transactions for one another. However, a sender must have knowledge - potentially indirect knowledge - of a given channel in order to include it in the route it builds. Private channels would require an alternate announcement mechanism, forming a shadow route to a private network. In order for the private channel to remain so, the alternative announcement would need to limited to a trusted network.
Hmm, are you saying that the sender must be able to explicitly see every node that the payment gets routed through?
It would make sense. My post was under the impression that say Charlie is a private node, Alice could send a payment to Dave through Bob and Charlie, without knowing that Charlie exists on the network. That is Alice would get the information from Bob that he can route forward through Charlie, but Alice wouldn't need to know that Charlie existed.
Now I'm grateful that I decided to add the "I'm not sure wtf I'm talking about" disclaimer at the end :)
Not necessarily every node. You're right that Charlie can give Alice the information necessary to get from Dave to him. But if we extend it one more hop, so Charlie gives Alice a route from Bob-to-Dave-to-Charlie, we run into a problem. If B-D is secret and D-C is secret, Charlie can't know how to create that route. If Dave tells Charlie about the (edit) B-D channel, he must trust Charlie to keep it secret. (edit) Dave would also be violating Bob's trust at that point.
> Three can keep a secret, if two of them are dead.
It's not about nodes being private, it's about channels.
You might want to do this if you had a large organization with lots of channels and wanted to mitigate routing fees. You'd have an internal private network that connected to a single (for instance) "border" node. All of your internal channels would be private and propagated through some other means. They would be able to find a route to the border node, which would have public channels with the rest of the public LN.
Good points. And thanks for the link.
But, I misunderstand your analogy about the room full of people. Don't the LN nodes need to know about all other nodes in order to be able to find the best route through the network?
I think the "room full of people" might be my analogy I posted the other day on the LND Slack so lets stretch it some!
Imagine you want to pay someone on the other side. Of course, you can talk to them but you can't move about (making channels, in Lightning terminology). What do you do?
**You**: "Who do you see?"
**Them**: "I see Bill, Jim, Jerry, Vanessa, Lance"
**You**: "Ah, stop there, I know Lance. I'm close enough to pass a message to Alice, who can pass it to Bob, who can reach Lance."
**Them**: "Great, then the rest of the path should be from Lance to Mark, then Craig, then me!"
That's _one_ (**but not the only**) way of figuring out routing through the network, and the method I believe is employed now. Every implementation can choose how they want to figure out routes, from trying to keep a whole picture of the network (unrealistic and difficult to scale) to the method I described (I believe it's called something like Beacon routing since in this case, Lance acted as a beacon for both parties to figure out a path).
That's not how routing works now and, while possible, is incompatible with the desire that transacting parties remain anonymous.
The way that routing works now is that nodes broadcast announcements of their channels and everyone builds their own map of the network. It's noisy and runs into scaling limitations because that map needs to be continuously updated as channel states and fees evolve.
[Here's a video of roasbeef talking about the future routing in Lightning](https://youtu.be/b_szGaaPPFk?t=2405). The routing tables are built on the sending side, and the payments are onion-layered so each path in the route only knows on what channel the payment to forward was received and on which channel to forward it.
per [the RFCs](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#overview):
>The route is constructed by the origin node, which knows the public keys of each intermediate node and of the final node. Knowing each node's public key allows the origin node to create a shared secret (using ECDH) for each intermediate node and for the final node. The shared secret is then used to generate a pseudo-random stream of bytes (which is used to obfuscate the packet) and a number of keys (which are used to encrypt the payload and compute the HMACs). The HMACs are then in turn used to ensure the integrity of the packet at each hop.
Further there are multiple ways of deciding how to route packets which are compatible with the spec.
Which is what I described. The origin node can construct a route because it maintains a graph of the network. It can build this map because everyone broadcasts their channel announcements.
The receiver _can_ provide the sender with a partial onion to get the transaction from a rendezvous node to its final destination, but that partial route can't include more than a single private hop - which must be the last hop - without introducing a trusted announcement mechanism.
> I think the "room full of people" might be my analogy I posted the other day on the LND Slack so lets stretch it some!
Yes! I liked it very much and it sticked in my mind. Hope you don't mind :)
>Don't the LN nodes need to know about all other nodes in order to be able to find the best route through the network?
When you open a channel, it's either public or private. The default is private, and it's only public if both participants agree (and provide their signature proving the existence of the channel).
I think what's confusing you is that the current routing algorithm wants to know about *as many channels as it can* so that it can find the most optimal route to its destination. That doesn't mean it has to know about *all* of them in order to function.
Well you only want one that's good enough. When things get going the fees are likely to be pretty constant across nodes (and very low of course), so all you'll likely need is to find one route with capacity I'd imagine.
I'm not an expert myself, so take it all with a grain of salt :)
I understand it so that the knowledge of one single node about the whole network is just not perfect in reality, because there are nodes coming on- and going off-line frequently, channels being opened and closed, channels being re-balanced and so on. Information like that has to spread over the network and if some things happen "on the other side" of the network, to which this particular node has no direct connection, it might be that the node is not entirely up-to-date. The information has yet to reach the node.
This is the coolest motherfucking thing I've ever seen. Is this motherfucking lightning network on motherfucking Bitcoin?!?! And we got a motherfucking 3d graphical view of it with motherfucking usernames of motherfucking people voluntarily taking part in a motherfucking second layer decentralized financial network on top of THE motherfucking decentralized financial network? Dooooooods.....
The main idea behind Bitcoin Cash on-chain/SPV style scaling model is that end users don't need to run nodes. [As Satoshi wrote](https://bitcointalk.org/index.php?topic=532.msg6269#msg6269):
> The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
This is different from LN where you actually need a node in order to transact.
And unlike a hard fork, Ln doesn't matter. Anyone who can run nodes will, anyone who can't won't, and will simply use the blockchain. Since people will be using it off chain, it will also be less congested. So what if it only works in 50% of use cases? Then 50% can be off chsin, and 50% is on chain solutions like you said! And, it didn't require a fork or making new currencies.
This is much different, since these "Nodes" are not using any resources at idle. It's not a node any more than Bitcoin client is. It does not transmit any data or use any computational power at idle. You could argue that most Bitcoin clients are nodes, since they transmit and receive data. Of course it's a different kind of node, but still is nonetheless. While if you go offline with your Bitcoin wallet, it's fine. Same with LN.
> It does not transmit any data or use any computational power at idle
Wrong. If you observe the lnd log output, you will see lots of channel updates and other announcements.
As the project scales so will the quantity of these announcements. A centralized routing service may prevent that, otherwise it's more likely that the system will DDoS itself.
Yes, on that implementation, it is helping to continuously update other nodes of which nodes it is connected to. It is also broadcasting information about itself to the network so that each knows receives information about every nodes that is online.
You don't have to broadcast though, the network is still fine without it. Kind of like how mining is essential for bitcoin, but mining isn't a requirement to run a node or to use it.
Nonsense. Fraud proofs are a red herring.
No mining majority is going to waste $250,000/confirmation to defraud an SPV using invalid blocks, as a 51% attacker can steal much easier using valid blocks withholding/releasing *without* wasting $250,000/confirmation.
You can disagree with Satoshi all you want, but at least be honest about the fact that you are doing so. The whitepaper talks explicitly about using fraud proofs and alerts for SPV security, and then goes on to say, "Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification." Or is the BCH approach supposed to be "Don't worry, no businesses will ever receive frequent payments"?
Furthermore, it's hard to pretend that an attack vector requiring a single entity to control >50% hashrate is dismissable because *Bitmain already has this*.
For anyone actually interested in learning more about SPV and its limitations, see [Lopp's excellent write-up](https://www.coindesk.com/spv-support-billion-bitcoin-users-sizing-scaling-claim/). The user I'm replying to is here to try to troll and subtly shill altcoins, so this link is intended for anyone else out there actually interested in learning more.
> You can disagree with Satoshi all you want, but at least be honest about the fact that you are doing so. The whitepaper talks explicitly about using fraud proofs and alerts for SPV security, and then goes on to say, "Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification."
He indeed hints at alerts which some assume to mean "fraud proofs" for SPV but they aren't relevant anymore.
Of course businesses that receive frequent payments will run their own node. End users don't need to run full nodes.
> Furthermore, it's hard to pretend that an attack vector requiring a single entity to control >50% hashrate is dismissable because Bitmain already has this.
I don't dismiss it. But an attack with valid blocks only is cheaper, easier, more destructive and no million full nodes can protect against it.
Relying on the economics of >51% is the very nature of PoW security.
>He indeed hints at alerts which some assume to mean "fraud proofs" for SPV but they aren't relevant anymore.
"What Satoshi said isn't relevant", but only when it suits you, huh?
>Of course businesses that receive frequent payments will run their own node.
Only if they can afford to do so. BCH espouses the philosophy that they don't need to be able to, hence this discussion.
>I don't dismiss it.
You have repeatedly demonstrated your misunderstanding of Bitcoin's security model. You proclaiming what the basis thereof is or isn't doesn't really count for much.
Can you please make a distinction between active nodes and nodes that are no longer signalling? It seems most explorers show every node that has ever been on the LN so the number of nodes can never decrease.
SLEEPYARK is the Blockstream store. But since names are self-chosen, anyone could also be SLEEPYARK.
I think it's interesting: lnd default names are just the key, older c-lightning nodes use NSA style names, modern ones append the version for dev builds (was sick of debugging without knowing that!) . But most people seem to customise their names anyway.
I like that they use the color (also customisable) but would prefer they use it for the names, though i know that's UX-hard.
My understanding is that the network graph is dependent on a node's view of the peer to peer network. It will be different depending on how long a node has been online, what peers it has connected to, and what channels/nodes it has seen in the past but are no longer active.