Negative fees also come up in the context of peer to peer credit using self
issued IOUs (over colored coins or whatever) that are atomically swapped via a
lightning HTLC. In this case negative fees may be the norm as there is
incentive to rebalance from higher to lower interest IOUs.
> On Jan 1
Hi Jonathan,
This is definitely a problem! I have a mainnet channel I force closed 2 weeks
ago that is still not mined :(
With current spec I guess it is not much that can be done other than crossing
fingers. For future specs maybe someone could come up with some SIGHASH flag
magic to either (1)
Hi Rusty,
This is something I’ve been thinking a bit about, as I’ve stumbled into some of
the edge cases you mention. Just to get on the same page: does the other side
(non-funder) pay any fees in the current implementation? [1] suggests that the
funder pays everything atm (on both sides’ commit
I agree. Negative shadow prices are incredibly important for optimality of
constrained network markets where flows in opposite directions cancel (as is
the case with lightning). See for example FTRs. It’s unclear to me how well
the analogy holds, but it’s worth considering.
—Will
On Tue, Jan
Thanks. It sounds like it was dropped due to difficulty in the routing
protocol. Is that difficulty documented somewhere I can review? If so, I
might take a crack at a solution to it. But regardless I suggest the
protocol should support negative fees, even if an individual routing
implementation pr
Benjamin Mord writes:
> [..]
> why not allow negative fees to incent unwinding, in scenarios where nodes
> consider that cheaper than on-chain rebalancing?
This was brought up before here [1]:
Rusty Russell writes:
>> Edward Marynarz writes:
>> Another trivial question: can the fee be negative
It isn't obvious to me from the BOLTs if fees can be negative, and I'm
finding uint in the go source code - which suggests not. In scenarios where
the funding of a payment channel has been fully committed in one direction,
why not allow negative fees to incent unwinding, in scenarios where nodes
co
With all due respect to Bradner, RFC 2119 (written in 1997) is harmful to
lightning and to cryptocurrency protocols more broadly. As was the
prevailing mindset at the time, RFC 2119 is for a world of good guys and
(if we're feeling diligent) bad guys, where good guys try to communicate
despite pres
