Right, LN nodes will eventually become big speciallized hubs, with great BTC capacity to attend as many channels as possible. Each channel is a source of revenue for the LN node, so LN nodes will try to become as big as possible (both technically and BTC-wise) to cope with greater audience.
Think that in a LN-node the profit will be proportional to capacity of open channels, so its very probable that we will see very-big-BTC-LN-nodes appear to serve demand
The reputation of LN-nodes will play a very important to the users (as it already happens with BTC exchanges - do you use a unknown-fishy-exchange or do you use a big-known-stable-exchange ?), and so that will incentivize LN-nodes to avoid/solve problems with channels to avoid teardown-to-the-blockchain (which as you mentioned, is abnoxious to the user for its fee and lock-time)
Let’s imagine an LN network with 1,000 payers all connecting to one, single LN hub, which routes all payments to a single payee (merchant).
How will the on-blockchain settlement transaction look like? It needs to redeem all 1,000 outputs provided by the payers, because each payer creates a new output when it funds a channel, which creates a huge settlement transaction (1,000 inputs) with a correspondingly huge fee.
A channel is committed to using one unspent transaction output (UTXO), settling it consumes only that UTXO and all of the other channels a given party might have are completely unrelated.
What is the use of the hub? You can just connect the merchant directly, even if you are just an occasional customer. You don't need the entire blockchain to use LN, so more users will be running Lightning nodes than Bitcoin nodes.
If you have an intermediary node (you call it a hub), there is no requirement for it to close its channel with the merchant, once you close your channel with that intermediary node.
> If you have an intermediary node (you call it a hub), there is no requirement for it to close its channel with the merchant, once you close your channel with that intermediary node.
As far as I can see, merchants receiving payments over payment channels is unrealistic, because it requires:
1) the merchant to predict what its revenue will be this week/month
2) the merchant (or someone else) to lock up this entire amount for the revenue period (week/month)
So, if a merchant wants to receive payments over a payment channel, the effective supply of BTC is halved, because 1 BTC needs to be deposited in the merchant’s payment channel for every 1 BTC a customer sends.
Most merchants simply don’t have that kind of capital and, even if they did, they wouldn’t be able to compete on price with other merchants who don’t demand trustless payments (merchants receiving payments over payment channels need to adjust their prices to account for the fact that they need to borrow a week/month’s worth of revenue, and have it sit idle in a payment channel). It’s very poor use of a scarce resource (bitcoins).
Who says the merchant needs to do that work? Specialized companies run like exchanges (or payment networks) could run the nodes on behalf of the merchants, much like bitpay does today. Of course, then you're just back where you started, with a banking institution controlling payments. But perhaps it would be more decentralized than four big payment companies, and that could be a step in the right direction.
It’s not about work. Borrowing money isn’t time-consuming. It’s about the cost of capital, and the inefficiency of requiring a scarce resource to be locked up with no other purpose than lowering the risk of losing a week’s revenue from 0.1% to zero.
Why do you think the merchant needs to lock up funds? If his exchange supports Lightning, the merchant would never need to worry about the fact that transactions won't hit the blockchain (if nobody is cheating or losing connectivity).
The freeplane community is craaaving for better documentation that can shed light to the multiple features of the program. The current docs/wiki are outdated/desorganized, and this has multiple times been recognized in the freeplane community as the #1 to priority to make freeplane easy for new users - new users just have a hard time going onboard because there are no good docs explaining the simplest things!
And the program is not hard, it's just missing good documentation!
The docs are sometimes called the "missing killer feature" of freeplane. So, If anyone with experience feels like joining in, it will be a joy for everyone :)
Side issue - I've become very reluctant to even click on sourceforge links. I never know if that's the real, current site, or just an example of sourceforge's sometimes practice of keeping a project for ... how do they make money off that scheme? Or is it just not wanting to let go of relevance?
I've used txt files/folders, then excell/word, then markdown (easy to write & read), and wiki.
Then I found freeplane, started to play with it and never got out, its incredible: use plain text or html (to format your notes), insert images, links to external files/folders, the visual mind-map representation gives a great overview of your notes and lets you organize in a foldable tree (branches, parents, childs) your notes (like in deeper layers of detail).
After the initial text/html nodes, branches and folds, I started to use "styles" to add icons and automatically format certain nodes with a background color (ex: TODO=yellow backgrnd, DONE=green backgrnd, PROBLEM=red backgrnd, ...)
Never really got into other freeplane features such as "notes" view or node-attributes. But it all went up to another level when I discovered that its possible to create http://www.freeplane.org/wiki/index.php/Scripting:_Other_lan... freeplane-scripts (in groovy or java or javascript, or any other JSR 223 language like Ruby). And using freeplane-script I started to make my own scripts, to automate repetitive tasks and improve its behaviour for my needs.
Why is freeplane better than the others methods I tried before? It organizes knowledge in a foldable tree, that gets bigger and bigger over time, and after a few years, its just easy to "find" in the notes. It also performs quite well (my maps are huge, huge, years old huge)
