Re: [Lightning-dev] Decoy node_ids and short_channel_ids
Good morning Rusty, > No, Bob can include the scid he used in the update_add_htlc message, so > Alice can check. > > 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. > > Thus my preference for a system which doesn't add any requirements on > the payer. This adds requirements on Bob, so the KYC pressure could transfer to them instead. This might be acceptable though, if the payer and Bob are on separate jurisdictions (i.e. Risk-Sharing), but then if the payer is on a custodial service as well, the custodial service can be pressured to inspect the routing hints of any invoice it is told to pay. Which I suppose is the entire point of t-bast email. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
Good morning niftynei, > Rusty had some suggestions about how to improve the protocol messages for > this, namely adding a serial_id to the inputs and outputs, which can then be > reused for deletions. > > The serial id can then also be used as the ordering heuristic for transaction > inputs during construction (replacing current usage of BIP69). Inputs can be > shared amongst peers by flipping the bottom bit of the serial_id before > relaying them to another peer (as your own). What happens if the initiator deliberately provides serial IDs 0x1, 0x3, while the acceptor naively provides serial IDs from `/dev/urandom`? Then the balance of probability is that the initiator inputs and outputs are sorted before the acceptor. Now, this is probably not an issue, since the initiator and acceptor both know which inputs and outputs are theirs and not theirs, so they could just reveal this information to anyone, so an actor providing such lousy serial IDs is just hurting its own privacy relative to blockchain analysts, so probably will not happen in practice. My initial reaction was to propose adding a secret-sharing round where the resulting key is XORed to each serial ID before sorting by the XORed serial ID, but this might be too overweight, and again the initiator is only hurting its own privacy, and the two participants already know whose money is whose anyway > > See below for details. > > > 1. type: 440 `tx_add_input` > > > > 2. data: > > > > * [`32*byte`:`channel_identifier`] > > * [`32*byte`:``serial_id`] > > Add a serial id. > > Each input addition must have a unique serial id. > > No addition may have a repeated id number. > > The initiator's serial id's must be odd. The non-initiator's serial id's must > be even. > > Serial ids are used as sorting heuristic for input ordering in final > transaction, replaces BIP69 > > > > * [`u64`:`sats`] > > > > * [`sha256`:`prevtx_txid`] > > > > * [`u32`:`prevtx_vout`] > > > > * [`u16`:`prevtx_scriptpubkey_len`] > > > > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`] > > > > * [`u16`:`max_witness_len`] > > > > * [`u16`:`scriptlen`] > > > > * [`scriptlen*byte`:`script`] > > Removes the signal_rbf; everything will be flagged as RBF eligible. (This > makes verifying RBF eligibility during a RBF round simpler.) Yes. Ish. RBF and privacy do not work well together unfortunately. This is still initiator-pays, right? > > 1. subtype: `witness_element` > > > > 2. data: > > > > * [`u16`:`len`] > > > > * [`len*byte`:`witness`] > > > > ## General Notes > > > > - All output scripts must be standard > > > > - nLocktime is always set to 0x > > - If a blockheight to be used as nLocktime is communicated in the initiation > step, is set to blockheight-6; otherwise set to zero- I am unsure what is the purpose of this minus 6. If you fear blockheight disagreements, this is probably a good time to introduce block headers. So for example if the acceptor thinks the initiator blockheight is too high, it could challenge the initiator to give block headers from its known blockheight to the initiator blockheight. If the acceptor thinks the initiator blockheight is too low, it could provide block headers itself as proof. This could be limited so that gross differences in blockheight are outright rejected by the acceptor (it could `error` the temporary channel ID rather than accept it). This is SPV, but neither side is actually making or accepting a payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV. Massive chain reorgs cannot reduce blockheight, only increase it (else the reorg attempt fails in the first place) so there must still exist at least one chain(split) with the highest known blockheight already given a proof-of-header-chain, and all you really need is some mining activity on top of *one* split that confirms your funding transaction. If it is not because of blockheight disagreements or massive chain reorgs, what is the purpose of `blockheight - 6`? > - Serial ids should be chosen at random > - For multiparty constructions, the initiator MUST flip the bottom bit of any > received inputs before relaying them to a peer. > > - Collisions of serial ids between peers is a protocol error I suppose we should define collision to mean "equal in all bits except the lowest bit". Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Decoy node_ids and short_channel_ids
> > 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). 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. > 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. 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). If we're taking into account such KYC pressure, then I believe none of the solutions we can provide will be useful. It will be up to the recipient to decide whether he thus wants to use a normal invoice and reveal his identity or pass on that payment. What do you think? Do you believe `option_scid_assign` can do a better job in such situations? Cheers, Bastien Le mer. 5 févr. 2020 à 02:44, Rusty Russell a écrit : > Bastien TEINTURIER writes: > > Hey again, > > > > Otherwise Mallory gets two invoices, and wants to know if they're > >> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has > >> nodeid N2, routehint Bob->C2. > > > > I think this attack is interesting. AFAICT my proposal defends against > this > > because of the way > > `payment_secret` and `decoy_key` are both used to derive the `decoy_scid` > > (but don't trust me, do > > verify that I'm not missing something). > > > > If Mallory doesn't use both the right `decoy_node_id` and > `payment_secret` > > to compute `P_I`, Bob > > will not decode that to a valid real `scid` and will return an > > `unknown_next_peer` which is good > > for privacy. > > But Mallory can do the same attack, I think. Just include the P_I from > the wrong invoice for Bob. > > > It seems to me that > > https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend > > against this attack. If both invoices are currently valid, Bob will > forward > > an HTLC that uses N1 > > with C2 (because Bob has no way of knowing N1 from the onion, for privacy > > reasons). > > The only way I'd see to avoid is would be that Alice needs to share her > > `decoy_node_id`s with > > Bob (and the mapping to a `decoy_scid`) which means more state to > > manage...but maybe I'm just > > missing a better mitigation? > > No, Bob can include the scid he used in the update_add_htlc message, so > Alice can check. > > 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. > > Thus my preference for a system which doesn't add any requirements on > the payer. > > Cheers, > Rusty. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
