From rusty at rustcorp.com.au  Mon Oct 17 03:15:17 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 17 Oct 2016 13:45:17 +1030
Subject: [Lightning-dev] Block chain fee proposal worked out in more
	detail
In-Reply-To: <1476132805.2158.26.camel@ultimatestunts.nl>
References: <1476132805.2158.26.camel@ultimatestunts.nl>
Message-ID: <8760orbr96.fsf@rustcorp.com.au>

CJP <cjp at ultimatestunts.nl> writes:
> I can think more clearly when no one is talking, so I took advantage of
> the evening to work out my fee proposal in more detail. :-)

You effectively extract the bitcoin fee from the HTLC creator on
establishment, but extract from the HTLC recipient on HTLC success (by
requiring them to on-pay more than the HTLC amount).

That's a novel twist, but I don't think it's less exploitable than a
naive system.  Fees only matter if someone drops onchain; I can make you
push a pile of HTLCs to me, then drop.

It does increase channel capacity slightly, since fees come out of
HTLCs.  But is it worth the complexity?

(FWIW: Note that the Summit decided fees for now would be
initiator-pays, initiator-sets, for simplicity, so this discussion would
be aimed at v1.1 or whatever we call it).

Thanks!
Rusty.

> A deposits into channel, as a way of paying B.
> Amount to be paid to B:         1.000 BTC
> Extra amount stored in channel: 1.997 BTC
> Fee required for commit tx:     0.003 BTC
>
> Anchor tx output size:          3.000 BTC
> Commit tx outputs:
>   to A:                         1.997 BTC
>   to B:                         1.000 BTC
>   fee:                          0.003 BTC
>
>
> Next, A makes microtx to B:
> Amount to be paid to B:         0.500 BTC
> Extra fee required for HTLC:    0.001 BTC
>
> Commit tx outputs while tx is locked:
>   to A:                         1.497 BTC
>   HTLC:                         0.499 BTC
>   to B:                         1.000 BTC
>   fee:                          0.004 BTC
> Commit tx outputs when tx is released to B:
>   to A:                         1.497 BTC
>   to B:                         1.500 BTC
>   fee:                          0.003 BTC
> Commit tx outputs if tx were returned to A:
>   (just like before tx was locked)
>
>
> Next, B makes microtx to A:
> Amount to be paid to A:         1.000 BTC
> Extra fee required for HTLC:    0.001 BTC
>
> Commit tx outputs (while tx is locked):
>   to A:                         1.497 BTC
>   HTLC:                         0.999 BTC
>   to B:                         0.500 BTC
>   fee:                          0.004 BTC
> Commit tx outputs (if tx is released to A):
>   to A:                         2.497 BTC
>   to B:                         0.500 BTC
>   fee:                          0.003 BTC
> Commit tx outputs (if tx is returned to A):
>   (just like before tx was locked)
>
> So, summarizing the algorithm:
> * Initially, the channel creator pays the fee (presumably, he has an
> interest in creating the channel, and this is consistent with regular
> BTC payments).
> * Generally speaking, while using the channel, you're just shifting
> around the non-fee part, without touching the fee itself.
> * For as far as adding an HTLC requires extra fees (since it makes the
> tx larger), that fee is deducted from the HTLC itself. Dust-sized txes
> would create negative-size HTLCs; of course you'd just not create the
> HTLC at even larger tx sizes (the fees of follow-up txes would not make
> the HTLC worth the effort).
>
> Not yet covered: how to change the fee size when on-blockchain fee
> market conditions change.
>
> Comments?
>
> CJP
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev