Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-27 📝 Original message: On Fri, Nov 27, 2015 at ...
📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 07:14:54AM +0100, Mats Jerratsch wrote:
> Another way to deal with it is to add two HTLCs to the commit, basically
> 'I pay you 1.00000001 BTC and you pay me 1 BTC, so effectively I paid
> you 1 satoshi'.
True! Doubles the cost of the HTLC if it gets published to the
blockchain though...
> One issue with this is that it increases the fees by a lot, as the
> locked up capital increases by quite a lot. It might also not
> translate that well over many hops, when fees are different in each
> direction.
I don't think number of hops matters; it only affects each channel
directly (so hop1 pays a+b one way, and b the other way; hop2 pays
a-f+c one way, c the other way; etc), a as the transaction amount,
f as b's fee, b and c arbitrary channel parameters for a/b and b/c
channels respectively.
You only have to lock up a little more than the dust amount, so call that
1c per HTLC, assume a locktime of 20 days, and a time cost of bitcoin
of 20% pa, then that's an extra cost of 0.01 of a cent per transaction.
If you're aiming for a 1% per-hop fee, you can still handle transactions
worth about a cent with that approach. If you've got a time cost of
bitcoin at about 5% pa and a lock time of 10 days, you can do a 2c
transaction with a per-hop fee of about 0.1%.
> We might want to have some special protocol for these
> payments?
I don't think that helps?
> By the way, as far as I know the dust value got increased to 5430? So
> even more of a problem for us now... (wow, that's already 2ct, don't
> think we can just disallow these, given that we promised the holy
> grail of micro payments ;) )
I don't think so? minrelayfee got increased to .05 mBTC, but that's for
1000 bytes while the dust threshold is for 546 bytes, so that's 2730
satoshi (a little under 1c at $351 USD/BTC).
According to Visa, anything less than $20 is a micropayment though, so
there's still plenty of leeway ;)
http://www.techworld.com.au/article/351015/visa_payclick_takes_paypal_micropayments/
> I also don't think just adding these to the change amount is
> sustainable. That's a thing I realized some time ago, as soon as there
> is some loop hole somewhere, there will be one guy who will move
> heaven and earth to make a profit off of it.
Yeah, and with onion routing and so on, I could be that guy!!
If you anonymously setup two channels with another node, and route a whole
bunch of dust payments to yourself, ie me1 -> them -> me2, then:
- if the HTLCs are in both txns, you can't do anything
- if the second channel's commitment unconditionally pays you for a
bunch of transactions, close the channel, and never reveal any of
the secrets. you eventually get all your money back in me1, and made
a profit in me2.
- if the first channel's commitment doesn't debit you for a bunch
of transactions, reveal the corresponding secrets in the second
channel, updating its commitment, but refuse to follow protocol to
update the transactions in the first channel, closing it, but keeping
your money.
- if txns in the second channel are credited to fees, but have HTLCs
in the first channel; close the second channel, and the txns timeout,
refunding your money, but costing the other node the sum of those
HTLCs.
Yay, more problems!
Maybe you could tweak the dual HTLC approach to make attacks unattractive:
42 satoshi from A -> B
10042 satoshi for (B && R || A && 20days CLTV)
10000 satoshi for (A && R && 15 days CLTV || B && 20days CLTV)
If it resolves on channel, fine; but if it hits the blockchain, A has to
wait 15 days even if R gets revealed to get her 3.5c back.
Not actually sure if that does any real good though...
Cheers,
aj
> 2015-11-27 4:58 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> > Anthony Towns <aj at erisian.com.au> writes:
> >> Hey,
> >>
> >> Suppose you have a lightning channel, with balances of exactly 2 BTC
> >> on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
> >> micropayment of 42 satoshi across the channel, resulting in an updated
> >> commitment that looks like:
> >>
> >> in:
> >> anchor (3.001 BTC): [yoursig theirsig redeemscript]
> >>
> >> out:
> >> 1 BTC: [pay2pubkey(theirs)]
> >> 1.99999958 BTC: [pay2pubkey(yours)]
> >> 0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
> >> timeout)]
> >>
> >> But the third output will hit the IsDust() test (less than 546 satoshi
> >> for a min relay fee of 0.01 mBTC) and the entire transaction will be
> >> rejected, so the channel can't be closed at all!
> >>
> >> This is a similar problem to sub 1-satoshi payments, but it's different
> >> in that while you can't represent them as an HTLC output, you can
> >> represent them as soon as they complete -- ie:
> >>
> >> out:
> >> 1.00000042 BTC: [pay2pubkey(theirs)]
> >> 1.99999958 BTC: [pay2pubkey(yours)]
> >>
> >> is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
> >> wouldn't be).
> >>
> >> I assume treating them much the same way is the only real option --
> >> account for them exactly in the lightning state, but just approximate the
> >> results in the actual commitments. So long as you're closing channels
> >> infrequently, losing a few hundred satoshi here and there won't matter
> >> much.
> >
> > Yes, unfortunately we'll have to have a rule to avoid producing those
> > outputs.
> >
> > I've opened https://github.com/ElementsProject/lightning/issues/14
> > so we make sure we track this.
> >
> >> Another option might be to weaken the dust protection in the network --
> >> eg if you made the dust output be
> >>
> >> 0.00000042 BTC: [(them && (R || revoke))
> >> || (you && d CSV && t CLTV)
> >> || (3 months CSV)]
> >>
> >> then anyone could clear the dust after 3 months if it weren't otherwise
> >> claimed; maybe having some dust for a finite time is okay. But it'd also
> >> mean paying to an actual (non-standard) script, rather than a scripthash,
> >> which would be annoying in its own way... And, really, adding that output
> >> to the txn would probably cost more in additional fees that it's going
> >> to pay you in any case.
> >
> > Agreed, we'll just cull those outputs and let them go to fees.
📝 Original message:
On Fri, Nov 27, 2015 at 07:14:54AM +0100, Mats Jerratsch wrote:
> Another way to deal with it is to add two HTLCs to the commit, basically
> 'I pay you 1.00000001 BTC and you pay me 1 BTC, so effectively I paid
> you 1 satoshi'.
True! Doubles the cost of the HTLC if it gets published to the
blockchain though...
> One issue with this is that it increases the fees by a lot, as the
> locked up capital increases by quite a lot. It might also not
> translate that well over many hops, when fees are different in each
> direction.
I don't think number of hops matters; it only affects each channel
directly (so hop1 pays a+b one way, and b the other way; hop2 pays
a-f+c one way, c the other way; etc), a as the transaction amount,
f as b's fee, b and c arbitrary channel parameters for a/b and b/c
channels respectively.
You only have to lock up a little more than the dust amount, so call that
1c per HTLC, assume a locktime of 20 days, and a time cost of bitcoin
of 20% pa, then that's an extra cost of 0.01 of a cent per transaction.
If you're aiming for a 1% per-hop fee, you can still handle transactions
worth about a cent with that approach. If you've got a time cost of
bitcoin at about 5% pa and a lock time of 10 days, you can do a 2c
transaction with a per-hop fee of about 0.1%.
> We might want to have some special protocol for these
> payments?
I don't think that helps?
> By the way, as far as I know the dust value got increased to 5430? So
> even more of a problem for us now... (wow, that's already 2ct, don't
> think we can just disallow these, given that we promised the holy
> grail of micro payments ;) )
I don't think so? minrelayfee got increased to .05 mBTC, but that's for
1000 bytes while the dust threshold is for 546 bytes, so that's 2730
satoshi (a little under 1c at $351 USD/BTC).
According to Visa, anything less than $20 is a micropayment though, so
there's still plenty of leeway ;)
http://www.techworld.com.au/article/351015/visa_payclick_takes_paypal_micropayments/
> I also don't think just adding these to the change amount is
> sustainable. That's a thing I realized some time ago, as soon as there
> is some loop hole somewhere, there will be one guy who will move
> heaven and earth to make a profit off of it.
Yeah, and with onion routing and so on, I could be that guy!!
If you anonymously setup two channels with another node, and route a whole
bunch of dust payments to yourself, ie me1 -> them -> me2, then:
- if the HTLCs are in both txns, you can't do anything
- if the second channel's commitment unconditionally pays you for a
bunch of transactions, close the channel, and never reveal any of
the secrets. you eventually get all your money back in me1, and made
a profit in me2.
- if the first channel's commitment doesn't debit you for a bunch
of transactions, reveal the corresponding secrets in the second
channel, updating its commitment, but refuse to follow protocol to
update the transactions in the first channel, closing it, but keeping
your money.
- if txns in the second channel are credited to fees, but have HTLCs
in the first channel; close the second channel, and the txns timeout,
refunding your money, but costing the other node the sum of those
HTLCs.
Yay, more problems!
Maybe you could tweak the dual HTLC approach to make attacks unattractive:
42 satoshi from A -> B
10042 satoshi for (B && R || A && 20days CLTV)
10000 satoshi for (A && R && 15 days CLTV || B && 20days CLTV)
If it resolves on channel, fine; but if it hits the blockchain, A has to
wait 15 days even if R gets revealed to get her 3.5c back.
Not actually sure if that does any real good though...
Cheers,
aj
> 2015-11-27 4:58 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> > Anthony Towns <aj at erisian.com.au> writes:
> >> Hey,
> >>
> >> Suppose you have a lightning channel, with balances of exactly 2 BTC
> >> on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
> >> micropayment of 42 satoshi across the channel, resulting in an updated
> >> commitment that looks like:
> >>
> >> in:
> >> anchor (3.001 BTC): [yoursig theirsig redeemscript]
> >>
> >> out:
> >> 1 BTC: [pay2pubkey(theirs)]
> >> 1.99999958 BTC: [pay2pubkey(yours)]
> >> 0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
> >> timeout)]
> >>
> >> But the third output will hit the IsDust() test (less than 546 satoshi
> >> for a min relay fee of 0.01 mBTC) and the entire transaction will be
> >> rejected, so the channel can't be closed at all!
> >>
> >> This is a similar problem to sub 1-satoshi payments, but it's different
> >> in that while you can't represent them as an HTLC output, you can
> >> represent them as soon as they complete -- ie:
> >>
> >> out:
> >> 1.00000042 BTC: [pay2pubkey(theirs)]
> >> 1.99999958 BTC: [pay2pubkey(yours)]
> >>
> >> is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
> >> wouldn't be).
> >>
> >> I assume treating them much the same way is the only real option --
> >> account for them exactly in the lightning state, but just approximate the
> >> results in the actual commitments. So long as you're closing channels
> >> infrequently, losing a few hundred satoshi here and there won't matter
> >> much.
> >
> > Yes, unfortunately we'll have to have a rule to avoid producing those
> > outputs.
> >
> > I've opened https://github.com/ElementsProject/lightning/issues/14
> > so we make sure we track this.
> >
> >> Another option might be to weaken the dust protection in the network --
> >> eg if you made the dust output be
> >>
> >> 0.00000042 BTC: [(them && (R || revoke))
> >> || (you && d CSV && t CLTV)
> >> || (3 months CSV)]
> >>
> >> then anyone could clear the dust after 3 months if it weren't otherwise
> >> claimed; maybe having some dust for a finite time is okay. But it'd also
> >> mean paying to an actual (non-standard) script, rather than a scripthash,
> >> which would be annoying in its own way... And, really, adding that output
> >> to the txn would probably cost more in additional fees that it's going
> >> to pay you in any case.
> >
> > Agreed, we'll just cull those outputs and let them go to fees.