📅 Original date posted:2015-07-29
📝 Original message:
On Tue, Jul 28, 2015 at 11:08:05AM +0930, Rusty Russell wrote:
> For HTLCs, this means:
> 1) Timeout returns for HTLCs A initiates must be OP_CSV delayed.
> 2) Payments for HTLCs A receives must be delayed.
>
> I just noticed the scripts in the 0.1 draft are a bit messed up; in
> particular they're missing a delay. Here's the (fixed!) A offers HTLC
> to B case:
Ah ok, cool!
> [scripts]
After thinking about this for a bit, there's two implications for this
script:
1. De-facto requires constantly watching the blockchain for a very low
interval. If Alice and Bob establish a channel, make a couple payments,
and now the balance of the channel is now 0 to Alice and 1 BTC to Bob,
if Bob doesn't constantly watch the chain, he can lose money. If the
HTLC-TIMEOUT is defined as 1 day, Alice can broadcast an old Commitment
and then hope Bob isn't paying attention and steal some money. In
effect, the maximum time between watching the chain will be the minimum
HTLC-TIMEOUT throughout the life of the channel when the channel balance
is currently tiled heavily in one direction.
2. Probably at the minimum doubles the HTLC timelock on LN payments. If
there is a minimum amount of time to wait to redeem funds (or receive a
refund), then the HTLC timeout must give you sufficient amount of time
to redeem as well. I suspect the amount of time necessary is about the
same since they're both dependent upon the estimated amount of time to
enter into the blockchain. If that's the case, doubling the HTLC
timeouts has some implications since it'll result in higher fees as a
downside, but might bias towards less graph centralization as well.
Fundamentally, the cause is derived from the fact that the HTLC timeout
and the OP_CSV revocation are inextricably linked.
Number 1 is more relevant to me (IMO), which is why I brought up the
reserve thing. I'm not so into the reserve balance concept, simply
because it severely limits the amount of transactional flow available at
once (it also limits the number of retries/multiplexing sends), which
matters more for liquidity providers (that model can reduce available
liquidity by 4x in best-case scenarios).
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:43:47
in reply to nevent1q…kmx8
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:43:47Event JSON
{
"id": "2bb3b337770242d3a0e87a6ef0f3986b2c19579f6932a9467af3dc03fe2fce6c",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314627,
"kind": 1,
"tags": [
[
"e",
"136120fa9d254826614cb6c81e857559ae6ab498d602841cc63c63ab6debd5a9",
"",
"root"
],
[
"e",
"1d1f65a71c96d6770e14503deec8b873bb57dbf22f1830878f12cdce6419ab4d",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-07-29\n📝 Original message:\nOn Tue, Jul 28, 2015 at 11:08:05AM +0930, Rusty Russell wrote:\n\u003e For HTLCs, this means:\n\u003e 1) Timeout returns for HTLCs A initiates must be OP_CSV delayed.\n\u003e 2) Payments for HTLCs A receives must be delayed.\n\u003e \n\u003e I just noticed the scripts in the 0.1 draft are a bit messed up; in\n\u003e particular they're missing a delay. Here's the (fixed!) A offers HTLC\n\u003e to B case:\n\nAh ok, cool!\n\n\u003e [scripts]\n\nAfter thinking about this for a bit, there's two implications for this\nscript:\n\n1. De-facto requires constantly watching the blockchain for a very low\ninterval. If Alice and Bob establish a channel, make a couple payments,\nand now the balance of the channel is now 0 to Alice and 1 BTC to Bob,\nif Bob doesn't constantly watch the chain, he can lose money. If the\nHTLC-TIMEOUT is defined as 1 day, Alice can broadcast an old Commitment\nand then hope Bob isn't paying attention and steal some money. In\neffect, the maximum time between watching the chain will be the minimum\nHTLC-TIMEOUT throughout the life of the channel when the channel balance\nis currently tiled heavily in one direction.\n\n2. Probably at the minimum doubles the HTLC timelock on LN payments. If\nthere is a minimum amount of time to wait to redeem funds (or receive a\nrefund), then the HTLC timeout must give you sufficient amount of time\nto redeem as well. I suspect the amount of time necessary is about the\nsame since they're both dependent upon the estimated amount of time to\nenter into the blockchain. If that's the case, doubling the HTLC\ntimeouts has some implications since it'll result in higher fees as a\ndownside, but might bias towards less graph centralization as well.\n\nFundamentally, the cause is derived from the fact that the HTLC timeout\nand the OP_CSV revocation are inextricably linked.\n\nNumber 1 is more relevant to me (IMO), which is why I brought up the\nreserve thing. I'm not so into the reserve balance concept, simply\nbecause it severely limits the amount of transactional flow available at\nonce (it also limits the number of retries/multiplexing sends), which\nmatters more for liquidity providers (that model can reduce available\nliquidity by 4x in best-case scenarios).\n\n-- \nJoseph Poon",
"sig": "0286494fbb07fa31f52df4b4139335ca5366e39a44ac690ff24b35aa81c1c0e4f9fb66f359c5f43e484f708e715de8c468cebf645dbe4085002b8d0f6103ae70"
}