Cezary Dziemian [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-10 📝 Original message: Thanks a lot for ...
📅 Original date posted:2020-02-10
📝 Original message:
Thanks a lot for clarification René.
Sorry for that, next time I will not use dev list to ask such questions,
but in "keysend" there are some details would like to discuss.
Do we agree, that because payee doesn't know amount that payer wants to
send him, the last hub can just prepare own HTLC for one satoshi? If this
is true, I think this is not correct behavior. If payer wants to pay X,
payee shouldn't receive less.
Can't payer just send "preimage + amount" encrypted by payee pub key? That
way payee can check what amount payer wanted to send him, and should reject
if HTLC contains other value.
Best Regards,
CD
niedz., 9 lut 2020 o 10:51 René Pickhardt <r.pickhardt at googlemail.com>
napisał(a):
> Good Morning Cezary,
>
> you might want to direct questions about understanding the lightning
> network protocol like yours to https://bitcoin.stackexchanage.com as this
> mailinglist is more devoted towards driving the development of the
> protocol. Anyway here are the answers to your questions 2 and 3 and
> probably also to the first one though I am not entirely sure if I
> understand exactly what you are asking for. In case I misunderstood you
> suggest to put follow up questions on stackexchange.
>
> 1. Is this possible that by sending funds without invoice, the last hub
>> prepares the last HTLC with small amount to the payee? In other words - Can
>> payee detect, that the last HTLC amount is smaller that it should be?
>>
>
> But in general the payee will only release the preimage for an invoice if
> the payee is satisfied with the amount - which is usually specified in the
> invoice. If you talk about keysend then the payee does not expect an amount
> and will most likely release the preimage as the payee would consider this
> to be free money
>
>
>> 2. Are there additional data added to the end of onion encrypted list of
>> HTLCs in order to prevent last hub to guess, that it is the last hub in the
>> route?
>>
>
> yes the onions are always of constant size (20 * 65 Byte = 1300 Byte) This
> process of padding is well described in the Sphinx paper
> https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf and in BOLT 04
> https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md
>
> 3. When payment is during confirmation, are channels locked entirely, or
>> only for the in flight payment amount? In other words - can single channel
>> process more that single transaction at once?
>>
>
> HTLCs are additional outputs in the commitment transaction. The protocol
> allows for up to 483 htlcs concurrently in flight as specified in BOLT 04 ("
> max_accepted_htlcs is limited to 483 to ensure that, even if both sides
> send the maximum number of HTLCs, the commitment_signed message will
> still be under the maximum message size. It also ensures that a single
> penalty transaction can spend the entire commitment transaction, as
> calculated in BOLT #5
> <https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#penalty-transaction-weight-calculation>;
> .")
>
> However the the standard of implementations and recommendation is 30. This
> means that a single payment is not freezing the channel. It however "locks"
> the amount of that payment which for the time until settlement cannot be
> used by either party of the channel for other payments / activities.
>
> with kind regards Rene
>
>
>> I would like to kindly pleas to reply in simple words, as my English is
>> still far from being perfect.
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/24934f4c/attachment.html>;
📝 Original message:
Thanks a lot for clarification René.
Sorry for that, next time I will not use dev list to ask such questions,
but in "keysend" there are some details would like to discuss.
Do we agree, that because payee doesn't know amount that payer wants to
send him, the last hub can just prepare own HTLC for one satoshi? If this
is true, I think this is not correct behavior. If payer wants to pay X,
payee shouldn't receive less.
Can't payer just send "preimage + amount" encrypted by payee pub key? That
way payee can check what amount payer wanted to send him, and should reject
if HTLC contains other value.
Best Regards,
CD
niedz., 9 lut 2020 o 10:51 René Pickhardt <r.pickhardt at googlemail.com>
napisał(a):
> Good Morning Cezary,
>
> you might want to direct questions about understanding the lightning
> network protocol like yours to https://bitcoin.stackexchanage.com as this
> mailinglist is more devoted towards driving the development of the
> protocol. Anyway here are the answers to your questions 2 and 3 and
> probably also to the first one though I am not entirely sure if I
> understand exactly what you are asking for. In case I misunderstood you
> suggest to put follow up questions on stackexchange.
>
> 1. Is this possible that by sending funds without invoice, the last hub
>> prepares the last HTLC with small amount to the payee? In other words - Can
>> payee detect, that the last HTLC amount is smaller that it should be?
>>
>
> But in general the payee will only release the preimage for an invoice if
> the payee is satisfied with the amount - which is usually specified in the
> invoice. If you talk about keysend then the payee does not expect an amount
> and will most likely release the preimage as the payee would consider this
> to be free money
>
>
>> 2. Are there additional data added to the end of onion encrypted list of
>> HTLCs in order to prevent last hub to guess, that it is the last hub in the
>> route?
>>
>
> yes the onions are always of constant size (20 * 65 Byte = 1300 Byte) This
> process of padding is well described in the Sphinx paper
> https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf and in BOLT 04
> https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md
>
> 3. When payment is during confirmation, are channels locked entirely, or
>> only for the in flight payment amount? In other words - can single channel
>> process more that single transaction at once?
>>
>
> HTLCs are additional outputs in the commitment transaction. The protocol
> allows for up to 483 htlcs concurrently in flight as specified in BOLT 04 ("
> max_accepted_htlcs is limited to 483 to ensure that, even if both sides
> send the maximum number of HTLCs, the commitment_signed message will
> still be under the maximum message size. It also ensures that a single
> penalty transaction can spend the entire commitment transaction, as
> calculated in BOLT #5
> <https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#penalty-transaction-weight-calculation>;
> .")
>
> However the the standard of implementations and recommendation is 30. This
> means that a single payment is not freezing the channel. It however "locks"
> the amount of that payment which for the time until settlement cannot be
> used by either party of the channel for other payments / activities.
>
> with kind regards Rene
>
>
>> I would like to kindly pleas to reply in simple words, as my English is
>> still far from being perfect.
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/24934f4c/attachment.html>;