Re: [Lightning-dev] Decoy node_ids and short_channel_ids
Bastien TEINTURIER writes: >> But Mallory can do the same attack, I think. Just include the P_I from >> the wrong invoice for Bob. > > Good catch, that's true, thanks for keeping me honest there! In that case > my proposal > would need the same mitigation as yours, Bob will need to include the > `scid` he received > in `update_add_htlc` (this is in fact not that hard once we allow TLV > extensions on every > message). Yes, I've added this to the PR. Which gives a new validation path, I think: ## Figuring out what nodeid to use to decode onion 1. Look up scid from HTLC; if it didn't include one, use default. 2. Look up payment_hash; if no invoice is found, use default. 3. If invoice specified this scid, get nodeid and use that. 4. ... and refuse to forward the HTLC (it must terminate here). My plan is to add an argument to `invoice` which is an array of one or more scids: we get a temporary scids for each peer and use them in the routehints. We also assign a random temporary nodeid to that invoice. The above algo is designed to ensure we behave like any other node which has no idea about this nodeid if Mallory: 1. tries to use a temporary node id on a normal channel to us. 2. tries to pay another invoice using this temporary node id. 3. tries to probe our outgoing channels using this routing hint (I think we should probably ban forwarding to private channels, too, for similar reasons). --- Note that with any self-assigned SCID schemes, Alice has to respond to unknown scids in update_add_htlc with some BADONION code (which makes *Bob* give Carol an error response, since Alice can't without revealing her identity). With Bob-assigned SCIDs, Alice simply needs to make him unallocate it before forgetting the invoice, so she will simply never see old invoices. (All these schemes give limited privacy, of course: Bob knows who Alice is, and fingerprinting and liveness attacks are always possible). > I'm extremely nervous about custodial lightning services restricting >> what they will pay to. This is not theoretical: they will come under >> immense KYC pressure in the near future, which means they cannot pay >> arbitrary invoices. 1>> > > That's a very good point, thanks for raising this. However I believe that > there are (and will be) enough > non-custodial wallets to let motivated users pay whatever they want. Users > can even run their own > node to pay such invoices if needed. Not if ln_strike (no, the other one!) is the future. > If you are using a custodial wallet and KYC pressure kicks in, then > regardless of that feature law may > require users to completely reveal who they are paying, so even normal > payments wouldn't protect > them, don't you think? Regulation could for example disallow paying via > unannounced channels entirely > (or require you to show the funding tx associated to your unannounced > channel). Actually, as long as the same method is required for both normal private channels (which will all use non-tx-based short_channel_ids in the near future I hope!), I don't really mind. I expect such payments to become significant, and as long as paying to a temporary id and paying to a private channel looks identical, it's too draconian to ban. A business would probably meet any KYC requirements by simply asking the user (perhaps over a certain amount, etc). (I've put my implementation on hold for a moment while I'm supposed to be releasing 0.8.1-rc1 RSN!) Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Few questions
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
.")
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
[Lightning-dev] Few questions
Good morning, there are few things I'm not completely sure about, so would like to ask in order to prevent misunderstanding in Polish LN community. 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? 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? 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? 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
