Anthony Towns [ARCHIVE] on Nostr: đź“… Original date posted:2015-08-29 đź“ť Original message: On 30 August 2015 at ...
đź“… Original date posted:2015-08-29
đź“ť Original message:
On 30 August 2015 at 03:50, CJP <cjp at ultimatestunts.nl> wrote:
> Maybe I'm overlooking something, but wouldn't it be enough to add a
> fine, to be paid from payee-side of a single link to the payer-side of
> the link, if the R value is delayed?
It wouldn't even be necessary to
> cryptographically enforce such a fine: if the fine isn't paid, the other
> node can simply close the channel, isolating the misbehaving node.
>
​I think that gives the following choices for the payee:
a) acts quickly, everyone's happy!
b) reveal R later, get less money due to having to pay a fine
c) fail the payment /and/ pay a fine for taking so long
d) pay the fine and close the channel cooperatively
e) close the channel unilaterally
I think (b) or (c) is better than (d) always.
If the fine is small (relative to bitcoin blockchain fees), then (d) should
always be better than (e).
Between (b) and (c), I think the fine is just a sunk cost, so (b) is
probably always better than (c), assuming you know R.
I'm not sure the fine is necessarily small relative to the blockchain fees,
though (especially if the blockchain fee is zero...)? A long chain might
get fees into the 1% range, and for a moderate sized payment ($5 coffee, 20
mBTC) that would be .2 mBTC, exceeding a 1kB txn fee of .1 mBTC...
> Well-behaving nodes will always pay the fine, thereby keeping their link
> intact and keeping a healthy network of well-behaving nodes.
>
​The thing that I can't get to work out here is when you have a misbehaving
node at the end of a chain, who doesn't pay their fine, but well-behaved
nodes making up the rest of the chain.
> A - b - c - D - e - F - g - H
H pays 0.003 mBTC to F (explicit source routing fee; H selected F for
> onion-routing towards D, without A's knowledge)
>
You mean "D selected F for onion-routing towards H" here, surely?
> A pays 0.002 mBTC to b (non-source routing fee)
> b pays 0.001 mBTC to c (non-source routing fee)
> D pays 0.001 mBTC to c (non-source routing fee)
> D pays 0.001 mBTC to e (non-source routing fee)
> F pays 0.001 mBTC to e (non-source routing fee)
> F pays 0.001 mBTC to g (non-source routing fee)
> H pays 0.001 mBTC to g (non-source routing fee)
>
These fees still don't vary with time​, so a 30s result versus a 4 day
result still has a factor of 10k difference in cost vs revenue. I think
over 4 days, a 0.20% fee is about reasonable matching the 0.002 fees that
c, e and g end up with above (0.20%/4 days works out to a 20% ROI per annum
if all your channels are constantly at 100% use), so linearising to an hour
that's a 0.002% fee, which works out to 2 satoshi per mBTC per hour.
Hmm, you /could/ actually lock those fees in cryptographically just by
updating the channel once an hour with the fees applied to the balances --
at the above rate, accepting the update would be cheaper than paying a
0.1mBTC blockchain txn fee, as long as you had less than 10 BTC worth of
active transactions that you're paying fines on.
​Cheers,
aj​
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150830/3a200b75/attachment-0001.html>;
đź“ť Original message:
On 30 August 2015 at 03:50, CJP <cjp at ultimatestunts.nl> wrote:
> Maybe I'm overlooking something, but wouldn't it be enough to add a
> fine, to be paid from payee-side of a single link to the payer-side of
> the link, if the R value is delayed?
It wouldn't even be necessary to
> cryptographically enforce such a fine: if the fine isn't paid, the other
> node can simply close the channel, isolating the misbehaving node.
>
​I think that gives the following choices for the payee:
a) acts quickly, everyone's happy!
b) reveal R later, get less money due to having to pay a fine
c) fail the payment /and/ pay a fine for taking so long
d) pay the fine and close the channel cooperatively
e) close the channel unilaterally
I think (b) or (c) is better than (d) always.
If the fine is small (relative to bitcoin blockchain fees), then (d) should
always be better than (e).
Between (b) and (c), I think the fine is just a sunk cost, so (b) is
probably always better than (c), assuming you know R.
I'm not sure the fine is necessarily small relative to the blockchain fees,
though (especially if the blockchain fee is zero...)? A long chain might
get fees into the 1% range, and for a moderate sized payment ($5 coffee, 20
mBTC) that would be .2 mBTC, exceeding a 1kB txn fee of .1 mBTC...
> Well-behaving nodes will always pay the fine, thereby keeping their link
> intact and keeping a healthy network of well-behaving nodes.
>
​The thing that I can't get to work out here is when you have a misbehaving
node at the end of a chain, who doesn't pay their fine, but well-behaved
nodes making up the rest of the chain.
> A - b - c - D - e - F - g - H
H pays 0.003 mBTC to F (explicit source routing fee; H selected F for
> onion-routing towards D, without A's knowledge)
>
You mean "D selected F for onion-routing towards H" here, surely?
> A pays 0.002 mBTC to b (non-source routing fee)
> b pays 0.001 mBTC to c (non-source routing fee)
> D pays 0.001 mBTC to c (non-source routing fee)
> D pays 0.001 mBTC to e (non-source routing fee)
> F pays 0.001 mBTC to e (non-source routing fee)
> F pays 0.001 mBTC to g (non-source routing fee)
> H pays 0.001 mBTC to g (non-source routing fee)
>
These fees still don't vary with time​, so a 30s result versus a 4 day
result still has a factor of 10k difference in cost vs revenue. I think
over 4 days, a 0.20% fee is about reasonable matching the 0.002 fees that
c, e and g end up with above (0.20%/4 days works out to a 20% ROI per annum
if all your channels are constantly at 100% use), so linearising to an hour
that's a 0.002% fee, which works out to 2 satoshi per mBTC per hour.
Hmm, you /could/ actually lock those fees in cryptographically just by
updating the channel once an hour with the fees applied to the balances --
at the above rate, accepting the update would be cheaper than paying a
0.1mBTC blockchain txn fee, as long as you had less than 10 BTC worth of
active transactions that you're paying fines on.
​Cheers,
aj​
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150830/3a200b75/attachment-0001.html>;