Cezary Dziemian [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-23 📝 Original message: For sure my questions are ...
📅 Original date posted:2018-11-23
📝 Original message:
For sure my questions are hard to understand because of my English skills.
Sorry for that and thanks for clarification.
Also I don't see no reason why I could not RBF the penalty transaction. The
main question is - is this implemented as default behavior in popular LN
implementations: clightning, eclair, lnd?
I'm thinking about this because LNBIG.com nodes opened 300BTC in channels
last week what is suspicious for me. I can imagine potential attack method
based on committing a lot of outdated commitment transactions and then spam
bitcoin mempool with transactions in order to increase fees. If RBF is not
implemented as default behavior for penalty transactions, then this can be
method to steal a lot of bitcoins. The risk for attacker seems not to be
very high, as penalty can be 10 times lower than funds that can be
potential stolen.
Cheers,
Cezary Dziemian
pt., 23 lis 2018 o 21:04 René Pickhardt <r.pickhardt at googlemail.com>
napisał(a):
> Hey Cezary,
>
> sorry I misread your initial question. I thought you where referring to
> the (probably bigger problem) of getting the commitment transaction to be
> mined because RBF does not work. But if we assume that your channel partner
> published an outdated commitment transaction which got mined then you can
> claim (both) outputs (your node should do this automatically) with this
> penalty transaction. This penalty transaction is spending the outputs of
> the commitment transaction and is signed with your nodes private key.
> Therefor as far as I know you should be able to RBF this penalty
> transaction. Also I believe you understand the process correctly.
>
> Actually since the timelock on the commitment transaction will at some
> point in time be over (in which case also your channel partner can spend
> their output) you have an economic incentive to quickly get the penalty
> transaction minded by using rather high fees or in case at this time really
> a lot of transactions come in to RBF. I currently see no reason why you
> could not RBF the penalty transaction. In case I oversee something I am
> sure someone here on the list will correct me.
>
> best regards Rene
>
> On Fri, Nov 23, 2018 at 8:34 PM Cezary Dziemian <cezary.dziemian at gmail.com>
> wrote:
>
>> Thanks for answer,
>>
>> My knowledge is mostly based on this article:
>>
>>
>> https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/
>>
>> Graph at the end shows that in order to claim former channel partner
>> funds I need to provide child transaction that contains my signature and
>> secret. This secret is evidence.that partner didn't commit the last
>> transaction.
>>
>> So the penalty transaction uses comitment transaction output as its input
>> and penalty transaction can be sign by one side only. Am I right, or I just
>> don't understand how it works? Or maybe this graph do not represents
>> correctly how commitment and penalty transactions are already developed?
>>
>> Best Regards,
>> Cezary Dziemian
>>
>>
>> pt., 23 lis 2018 o 19:07 René Pickhardt <r.pickhardt at googlemail.com>
>> napisał(a):
>>
>>> Dear Cezary,
>>>
>>> as far as I understand the problem in the case of a unilateral (force)
>>> close are:
>>>
>>> 1.) In order to RBF your commitment transaction you would have to have
>>> the signature of your former channel partner. since you initiated a force
>>> close it is unlikely that you get this signature to RBF because then you
>>> could have done a mutual close right away which is cheaper since less tx
>>> are invovled to claim all funds back.
>>> 2.) In order to CPFP you have to be able to spend your output which
>>> can't work because there is a timelock on it.
>>>
>>> I believe on the last lightning developer summit this issue was
>>> discussed and it was agreed that for BOLT1.1 we want have a third output in
>>> the commitment transactions which anyone can spend (OP_TRUE) and which is
>>> just above the dust level. This output is supposed to have no timelock so
>>> that anyone can CPFP it. In the general case miners of the block could
>>> collect the output as a fee. You can find a pointer to this on this
>>> wikipage in the lightning-rfc git repo:
>>> https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States
>>> (look in the section tx and fees)
>>>
>>> best Rene
>>>
>>> On Fri, Nov 23, 2018 at 6:30 PM Cezary Dziemian <
>>> cezary.dziemian at gmail.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> Sorry for my ignorance. I have two questions related with penalty txs.
>>>> I assume, that when someone commits obsolete commitment tx, my node
>>>> automatically commit penalty transaction.
>>>>
>>>> What if fees suddenly increases? Can my node use RBF to increase fee?
>>>>
>>>> Is there any approach common to major 3 implementations?
>>>>
>>>> How much time (how many blocks) do my node have to commit penalty tx?
>>>> Is there some value common for implementations?
>>>>
>>>> Best regards,
>>>> Cezary Dziemian
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
>>>
>>> --
>>> https://www.rene-pickhardt.de
>>>
>>> Skype: rene.pickhardt
>>>
>>> mobile: +49 (0)176 5762 3618
>>>
>>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181123/fbdf2e32/attachment.html>;
📝 Original message:
For sure my questions are hard to understand because of my English skills.
Sorry for that and thanks for clarification.
Also I don't see no reason why I could not RBF the penalty transaction. The
main question is - is this implemented as default behavior in popular LN
implementations: clightning, eclair, lnd?
I'm thinking about this because LNBIG.com nodes opened 300BTC in channels
last week what is suspicious for me. I can imagine potential attack method
based on committing a lot of outdated commitment transactions and then spam
bitcoin mempool with transactions in order to increase fees. If RBF is not
implemented as default behavior for penalty transactions, then this can be
method to steal a lot of bitcoins. The risk for attacker seems not to be
very high, as penalty can be 10 times lower than funds that can be
potential stolen.
Cheers,
Cezary Dziemian
pt., 23 lis 2018 o 21:04 René Pickhardt <r.pickhardt at googlemail.com>
napisał(a):
> Hey Cezary,
>
> sorry I misread your initial question. I thought you where referring to
> the (probably bigger problem) of getting the commitment transaction to be
> mined because RBF does not work. But if we assume that your channel partner
> published an outdated commitment transaction which got mined then you can
> claim (both) outputs (your node should do this automatically) with this
> penalty transaction. This penalty transaction is spending the outputs of
> the commitment transaction and is signed with your nodes private key.
> Therefor as far as I know you should be able to RBF this penalty
> transaction. Also I believe you understand the process correctly.
>
> Actually since the timelock on the commitment transaction will at some
> point in time be over (in which case also your channel partner can spend
> their output) you have an economic incentive to quickly get the penalty
> transaction minded by using rather high fees or in case at this time really
> a lot of transactions come in to RBF. I currently see no reason why you
> could not RBF the penalty transaction. In case I oversee something I am
> sure someone here on the list will correct me.
>
> best regards Rene
>
> On Fri, Nov 23, 2018 at 8:34 PM Cezary Dziemian <cezary.dziemian at gmail.com>
> wrote:
>
>> Thanks for answer,
>>
>> My knowledge is mostly based on this article:
>>
>>
>> https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/
>>
>> Graph at the end shows that in order to claim former channel partner
>> funds I need to provide child transaction that contains my signature and
>> secret. This secret is evidence.that partner didn't commit the last
>> transaction.
>>
>> So the penalty transaction uses comitment transaction output as its input
>> and penalty transaction can be sign by one side only. Am I right, or I just
>> don't understand how it works? Or maybe this graph do not represents
>> correctly how commitment and penalty transactions are already developed?
>>
>> Best Regards,
>> Cezary Dziemian
>>
>>
>> pt., 23 lis 2018 o 19:07 René Pickhardt <r.pickhardt at googlemail.com>
>> napisał(a):
>>
>>> Dear Cezary,
>>>
>>> as far as I understand the problem in the case of a unilateral (force)
>>> close are:
>>>
>>> 1.) In order to RBF your commitment transaction you would have to have
>>> the signature of your former channel partner. since you initiated a force
>>> close it is unlikely that you get this signature to RBF because then you
>>> could have done a mutual close right away which is cheaper since less tx
>>> are invovled to claim all funds back.
>>> 2.) In order to CPFP you have to be able to spend your output which
>>> can't work because there is a timelock on it.
>>>
>>> I believe on the last lightning developer summit this issue was
>>> discussed and it was agreed that for BOLT1.1 we want have a third output in
>>> the commitment transactions which anyone can spend (OP_TRUE) and which is
>>> just above the dust level. This output is supposed to have no timelock so
>>> that anyone can CPFP it. In the general case miners of the block could
>>> collect the output as a fee. You can find a pointer to this on this
>>> wikipage in the lightning-rfc git repo:
>>> https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States
>>> (look in the section tx and fees)
>>>
>>> best Rene
>>>
>>> On Fri, Nov 23, 2018 at 6:30 PM Cezary Dziemian <
>>> cezary.dziemian at gmail.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> Sorry for my ignorance. I have two questions related with penalty txs.
>>>> I assume, that when someone commits obsolete commitment tx, my node
>>>> automatically commit penalty transaction.
>>>>
>>>> What if fees suddenly increases? Can my node use RBF to increase fee?
>>>>
>>>> Is there any approach common to major 3 implementations?
>>>>
>>>> How much time (how many blocks) do my node have to commit penalty tx?
>>>> Is there some value common for implementations?
>>>>
>>>> Best regards,
>>>> Cezary Dziemian
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
>>>
>>> --
>>> https://www.rene-pickhardt.de
>>>
>>> Skype: rene.pickhardt
>>>
>>> mobile: +49 (0)176 5762 3618
>>>
>>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181123/fbdf2e32/attachment.html>;