Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: On Thu, Feb 20, 2020 at ...
📅 Original date posted:2020-02-20
📝 Original message:
On Thu, Feb 20, 2020 at 03:42:39AM +0000, ZmnSCPxj wrote:
> A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me?
>
> Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim it up until the timelock.
> If the peer does not claim it, I cannot claim it in my incoming as well.
> I also cannot safely fail my incoming, as the outgoing peer can still claim it until the timelock expires.
Suppose the channel state looks like:
Bob's balance: $150
Carol's balance: $500
Bob to Carol: $50, hash X, timelock +2016 blocks
The pre-signed close transaction will have already deducted maybe $1 in
fees, say 50c from each balance.
At 5% pa, that's $50*0.05*2/52, so about 10 cents worth of "holding"
fees, so that seems like it's worth just committing to up-front, ie:
Bob's balance: $149.60 (-.50+.10)
Carol's balance: $499.40 (-.50-.10)
Bob to Carol: $50, hash X, timelock +2016 blocks
Fees: $1
And that seems necessary anyway: if the channel does drop to the chain,
then the HTLC can't be cancelled, so if it never confirms, Bob will have
had to pay, say, 9.5c to Alice waiting for the timeout, and can then
immediately cancel the HTLC with Alice allowing it to finish unwinding.
So I think the idea would be not to accept a (rate, amount, timelock)
tuple for an incoming HTLC unless the rate*amount*timelock product
is substantially less than what you're putting towards the blockchain
fees anyway, as otherwise you've got bad incentives for the other guy to
drop to the chain.
Note the rate increases with number of hops, so if it's 1% pa per hop,
the 11th peer will be emitting 10% pa. I think that's probably okay,
because BTC's deflationary nature probably means you don't need to earn
much interest on it, and you can naturally choose the rate dynamically
based on how many HTLCs you currently have open and how much of your
channel funds are being used up by the HTLC?
Also, you'd presumably update your channel state every hundred blocks,
reducing the 10c by half a cent or so each time, so you could have your
risk reduce. Maybe there could be some way of bumping the timelock across
a HTLC path so that the risk is capped, but if the HTLC is still being
paid for it doesn't have to be cancelled?
Cheers,
aj
📝 Original message:
On Thu, Feb 20, 2020 at 03:42:39AM +0000, ZmnSCPxj wrote:
> A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me?
>
> Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim it up until the timelock.
> If the peer does not claim it, I cannot claim it in my incoming as well.
> I also cannot safely fail my incoming, as the outgoing peer can still claim it until the timelock expires.
Suppose the channel state looks like:
Bob's balance: $150
Carol's balance: $500
Bob to Carol: $50, hash X, timelock +2016 blocks
The pre-signed close transaction will have already deducted maybe $1 in
fees, say 50c from each balance.
At 5% pa, that's $50*0.05*2/52, so about 10 cents worth of "holding"
fees, so that seems like it's worth just committing to up-front, ie:
Bob's balance: $149.60 (-.50+.10)
Carol's balance: $499.40 (-.50-.10)
Bob to Carol: $50, hash X, timelock +2016 blocks
Fees: $1
And that seems necessary anyway: if the channel does drop to the chain,
then the HTLC can't be cancelled, so if it never confirms, Bob will have
had to pay, say, 9.5c to Alice waiting for the timeout, and can then
immediately cancel the HTLC with Alice allowing it to finish unwinding.
So I think the idea would be not to accept a (rate, amount, timelock)
tuple for an incoming HTLC unless the rate*amount*timelock product
is substantially less than what you're putting towards the blockchain
fees anyway, as otherwise you've got bad incentives for the other guy to
drop to the chain.
Note the rate increases with number of hops, so if it's 1% pa per hop,
the 11th peer will be emitting 10% pa. I think that's probably okay,
because BTC's deflationary nature probably means you don't need to earn
much interest on it, and you can naturally choose the rate dynamically
based on how many HTLCs you currently have open and how much of your
channel funds are being used up by the HTLC?
Also, you'd presumably update your channel state every hundred blocks,
reducing the 10c by half a cent or so each time, so you could have your
risk reduce. Maybe there could be some way of bumping the timelock across
a HTLC path so that the risk is capped, but if the HTLC is still being
paid for it doesn't have to be cancelled?
Cheers,
aj