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@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
