[runeks]

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

[chatmasta]

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.

[runeks]

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.

[iso-8859-1]

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