Mats Jerratsch [ARCHIVE] on Nostr: š Original date posted:2015-11-27 š Original message: Another way to deal with ...
š
Original date posted:2015-11-27
š Original message:
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'.
In reality we would of course use smaller 'transport-values'. Both of
these payments would pay to the same R value, so they would be atomic.
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. We might want to have some special protocol for these
payments?
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 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.
Cheers
Mats
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.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
š Original message:
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'.
In reality we would of course use smaller 'transport-values'. Both of
these payments would pay to the same R value, so they would be atomic.
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. We might want to have some special protocol for these
payments?
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 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.
Cheers
Mats
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.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev