Topic: The Lightning Network FAQ - page 47. (Read 33287 times)

That's why I stopped using Bitpay My favourite nowadays is Coinpayments.net, which gives a bunch of options including LN and doesn't add an additional fee. But most services use something else.
If, however, a service offers LN payment, I prefer that service over anything else

I would not overly pay a fee for a feel good feeling.
If I believe a service is overcharging me for a transaction fee, I use another service.

Now imagine you buy the same $2 product using on-chain Bitcoin. You'll pay $12 in fees, and the payment service will charge you 0.0002 BTC (or more) because of their own consolidation costs. That's $24 in fees for a $2 product, and the transaction takes much longer.

I'll gladly pay whatever fees LN charges me. It's negligible compared to on-chain transactions.

and so the hop model fails and the hub-spoke banker model prevails

imagine the average product bought via LN was $2.
if someone has 4 channels with say $1650 per channel ($6600 total(average node/channel cap:1ml)
thats only 825 transactions possible per session per channel

with closing/reopening channels being ~$2x2. thats a $4 cost to run a channel.
to break even LN payment fees need to be $0.0049

but for emphasis. the reality is the hop ideal of utopian freedom wont flourish. the hub/spoke banker model will

using a abacus idea..
the issue is

before: A|ooo-----| D |ooo-----| B
after:   A|-----ooo| D |-----ooo| B

although D has 'ooo'.. somewhere
D cant then spend his own funds to B direct anymore..
so other people have now locked him out of D->B
and if he wanted to pay B he has to go back through A and hope A has another path around to reach B
A-Z-Y-X-W-V-U-T-S-R-Q-P-O-N-M-L-K-J-I-H-G-F-E-C-B

well if A had to go through D then chances are A hasnt got another path. or if they do its obviously going to cost more, else A woulda used it in the first place

so now D has to close channels and re-aggregate the 2 channels back in his favour of the path D prefers.

so its not the fantasy promotion that 'it dont matter' or 'there shouldnt be any net loss' because it will actually now cost D more to do anything either round-routing backwards or re-aggregating channels onchain

i know i know some fangirls will sat D just has to man up and reroute backwards at the higher fee(IF A had alternative route) and send 'ooo' to B and then get B to send 'ooo' back to D via that reroute.. saying doing that will still be cheaper than onchain re-aggregating..

but thats the hope method. not the guarantee method. you hope A has a back way round to B

so again. might be best you dont allow big players route through you too much.
and yea think about your own investment. and not the wishes of other players hoping they can abuse your path
or it will cost you in the long run.

many fangirls dont care about your own situation they just want people to put in high liquidity so that THEY can take advantage.

so other people have now locked him out of D->B
and if he wanted to pay B he has to go back through A and hope A has another path around to reach B

but thats the hope method. not the guarantee method. you hope A has a back way round to B

many fangirls

before: A|ooo-----| D |ooo-----| B
after:   A|-----ooo| D |-----ooo| B

Not complaining just trying to understand why people are doing some things and if what I am doing to facilitate them doing it is the proper way.

-Dave

Not complaining just trying to understand why people are doing some things and if what I am doing to facilitate them doing it is the proper way.

-Dave

maybe he should up his fees.. to take advantage of his predicament.. or sway them away from using him as a middleman

if what I am doing to facilitate them doing it is the proper way.

and there was the LN naive community thinking that middlemen were not suppose to know the sender/receiver of long routes. or of any route (promotion:private untracable untrackable network)
strange because he seems to be able to see and log all payments not meant for him personally(he not intended final destination)

im guessing DaveF has a direct channel with coingate and a direct channel with walletsofsatoshi. and thus he is their direct route to each other.
im guessing DaveF didnt turn off his autopilot or didnt turn off his 'routing' to not allow them to abuse him

im guessing this tactic means DaveF has to close his channels and reaggregate his funds into new channels quite often if they are pushing payments via him so often. (well more often than he likes as he seems to be complaining that he is being used as a middleman)

maybe he should up his fees.. to take advantage of his predicament.. or sway them away from using him as a middleman

I keep getting a "bandwidth exhausted" notice every time I try to open a channel via Zap to this node:


It's a fresh install of the latest Zap (and my bandwidth is OK) so there shouldn't be any issues.



(I'm trying to open a channel for BTC 0.0026 plus tx fees)

...
For instance, Alice pre-generates one million keys, each key being a child of the previous key. Alice allocates which keys to use according to some deterministic manner. For example, she starts with the child deepest in the tree to generate many sub-keys for day 1. This key is used as a master key for all keys generated on day 1. She gives Bob the address she wishes to use for the next transaction, and discloses the private key to Bob when it becomes invalidated. When Alice discloses to Bob all private keys derived from the day 1 master key and does not wish to continue using that master key, she can disclose the day 1 master key to Bob. At this point, Bob does not need to store all the keys derived from the day 1 master key. Bob does the same for Alice and gives her his day 1 key.
When all Day 2 private keys have been exchanged, for example by day 5, Alice discloses her Day 2 key...

With all of that being said, it might not be you but the ACINQ channel itself. I have had several issues with them in the past, and actually stopped connecting to them. Fold, WalletofSatoshi, OpenNode, Coingate. No issues at all. ACINQ was....not fine.

Has anyone here experimented with the Lightning Lab's Loop? It worked fine for a node with only a couple of channels, but it failed for my channel with ACINQ which is significantly better connected to the rest of the network. I recall having some routing problems in the past when my channel to them was the only one I had. I am about to open a few more channels since the transaction fees have decreased significantly. I will report back once I try "loop out" on them tomorrow.