[Lightning-dev] Directionality of the transaction fees

[Edward Marynarz]

On Tue, Dec 12, 2017 at 2:25 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:


> > It's good, though not as good as if both sender and recipient could set
> > their own fees.  I know it would have made everything more complicated
> but
> > receiving is actually more costly than sending. If you have less balance
> > than the initial opening of the channel, it is risk-free.
>
> But forwarding nodes do both, so they can charge appropriate fees.


If there is only one path, then yes. But with many paths, you cannot
restrict the path you do not want to receive with.


>
> > Another trivial question: can the fee be negative? It might help with
> some
> > channel rebalancing.
>
> In my original implementation, they could be.  However, that turns out
> to be a very strange idea, and complicates routing.
>
> Interesting.

  > important than the LN fees. I worry about a scenario that I create a

> > channel (paying fees), send some funds through the channel to have the
> > channel available also for receiving and the other side of the channel,
> > simply cashes out the balance, and I'm without the channel  opening fees
> > and with no receiving channel.
>
> The channel initiator pays all onchain fees, at the moment.  This is
> simple, but potentially gamable.  However, current alternatives are
> complex and potentially gamable, so we went with simple.
>
>
So the only thing that protect a small-scale user from a hub that closes
the channels with some balance fee-free is a)  market pressure by avoiding
the hubs that do it b) that Bitcoin is actually more expensive to receive
than to send since inputs are larger than outputs?

It should indeed work now but with Schnorr signatures, b) i no longer the
case  and we would only rely on a). And market pressure may be a too weak
incentive because it requires knowledge that hubs behave in a certain way.
And this information may be difficult to obtain,

Regards,

Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171222/73eb8e90/attachment.html>