Re: [Lightning-dev] DRAFT: interactive tx construction protocol
> With PoDLE this would not be possible I think, as you would not be able to open the PoDLE commitment with the other node as the target (if we go with the modified PoDLE which also commits to which node an opening is for, to prevent the pouncing venus flytrap attack). Good question. It should be possible to do multi-channel open even with the PoDLE signature committing to a node_id. - An initiator can use the same utxo (h2) as their proof for multiple peers; the signatures passed to each peer will have to commit to that specific peer's node_id, however. - The revised PoDLE signature commitment requires every initiator to include at least one of their own inputs in the tx. Attempting to initiate an additional open etc using someone else's utxo's won't work (this is the pouncing venus flytrap attack which we're preventing). The initiator including at least one input is expected behavior, at least in the open case, since the opener has to cover the fees for the funding output. - Ideally, a node would remove the PoDLE TLV data from any 'forwarded' `tx_add_inputs` that isn't the input they're proving for, to prevent leaking information about which inputs belong to other parties. I say ideally here because even if you fail to do this, the peer can iterate through all the provided commitment proofs until one of them matches/verifies with the upfront provided PoDLE. On Thu, Feb 13, 2020 at 12:18 AM ZmnSCPxj wrote: > Good morning Rusty, niftynei, and list, > > > > > - 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". > > > > No, literally equal. i.e. you can only make this error by clashing with > > yourself. > > hmm, I thought the entire point of having the low bit was that you could > multifund in such a way that the initiator creates multiple channels > simultaneously with multiple nodes? > So you would have to take the UTXOs of one peer and give it to the other > peer claiming it as your own. > Or something. > > With PoDLE this would not be possible I think, as you would not be able to > open the PoDLE commitment with the other node as the target (if we go with > the modified PoDLE which also commits to which node an opening is for, to > prevent the pouncing venus flytrap attack). > > 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
Damn you're good. Le jeu. 13 févr. 2020 à 11:44, ZmnSCPxj a écrit : > Good morning t-bast, > > > > Propose we take the `z` to use as bolt11 letter, because even the > French > > > don't pronounce it in "rendez-vous"!) > > > > As long as Z-man didn't want to claim this bolt11 letter for himself or > his > > puppet army, that sounds good :). > > That would be too obvious. > What I *am* claiming is `8` for my own use and for my non-existent army of > city-marching robots, because it does not appear in my public alias at all, > thus actively misleading surveillors. > > 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
Good morning t-bast, > > Propose we take the `z` to use as bolt11 letter, because even the French > > don't pronounce it in "rendez-vous"!) > > As long as Z-man didn't want to claim this bolt11 letter for himself or his > puppet army, that sounds good :). That would be too obvious. What I *am* claiming is `8` for my own use and for my non-existent army of city-marching robots, because it does not appear in my public alias at all, thus actively misleading surveillors. 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
Hey Rusty and list, I was starting to think this whole thing was of marginal benefit: note > that solving "private channels need a temp scid" is far simpler[1]. That's true, the simpler solution does break the on-chain / off-chain link but I think we can take this opportunity to also improve payee privacy to make sure two invoices can't leak that they are from the same payee. Even better, this would be a replacement for current route hints Definitely, this is clearly a good opportunity to re-work route hints to something that can fix all the short-comings of current route hints, thanks for your suggestions on that. And if anyone on this list has other fields that may be useful in these new route hints, please do say it. Propose we take the `z` to use as bolt11 letter, because even the French > don't pronounce it in "rendez-vous"!) As long as Z-man didn't want to claim this bolt11 letter for himself or his puppet army, that sounds good :). I'll get started on an implementation, and will start working on a spec PR as well. I'm hoping to get more reviews from anyone experienced with both lightning and cryptography to verify that the scheme isn't broken. I'm still offering beers and cocktails to anyone who cracks it [1]! Thanks! Bastien [1] https://twitter.com/realtbast/status/1227233654503505925 Le jeu. 13 févr. 2020 à 05:49, Rusty Russell a écrit : > > Bastien TEINTURIER writes: > > Hi Rusty, > > > > Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;) > > ... Now -rc2. I actually had a RL use for lightning (OMG!), and sure > enough found a bug. > > > I've been thinking more about improving my scheme to not require any sender > > change, but I don't think that's possible at the moment. As with all > > Lightning > > tricks though, once we have Schnorr then it's really easy to do. > > Alice simply needs to use `s * d_a` as her "preimage" (and the payment point > > becomes the P_I Bob needs). That may depend on the exact multi-hop locks > > construction we end up using though, so I'm not 100% sure about that yet. > > I was starting to think this whole thing was of marginal benefit: note > that solving "private channels need a temp scid" is far simpler[1]. > > But since your scheme extends to rendevous, it's much more tempting! > > We would use this for normal private channels as well as private routes > aka new rendezvous. Even better, this would be a replacement for > current route hints (which lack ability to specify feature bits, which > we would add here, and is also grossly inefficient if you just want to > use it for Routeboost[2]). > > Propose we take the `z` to use as bolt11 letter, because even the French > don't pronounce it in "rendez-vous"!) > > Then use TLV inside:[3] > > * `z` (2): `data_length` variable. One or more entries containing extra > routing information; there may be more than one `z` field. Each entry > looks like: >* `tlv_len` (8 bits) >* `rendezvous_tlv` (tlv_len bytes) > > 1. tlvs: `rendezvous_tlv` > 2. types: >1. type: 1 (`pubkey`) >2. data: > * [`point`:`nodeid`] >1. type: 2 (`short_channel_id`) >2. data: > * [`short_channel_id`:`short_channel_id`] >1. type: 3 (`fee_base_msat`) >2. data: > * [`tu32`:`fee_base_msat`] >1. type: 4 (`fee_proportional_millionths`) >2. data: > * [`tu32`:`fee_proportional_millionths`] >1. type: 5 (`cltv_expiry_delta`) >2. data: > * [`tu16`:`cltv_expiry_delta`] >1. type: 6 (`features`) >2. data: > * [`...*byte`:`features`] > > That probably adds 6 bytes entry, but worth it I think. > > Cheers, > Rusty. > > [1] Add a new field to 'funding_locked': "private_scid". If both sides > support 'option_private_scid' (?) then the "real" scid is no longer > valid for routing, and we use the private scid. > > [2] It's enough to give the scid(s) in this case indicating where you > have incoming capacity. > > [3] I'm really starting to dislike my bolt11 format. We should probably > start afresh with a TLV-based one, where signature covers the hash > of each entry (so they can be easily externalized!), but that's a > big, unrelated task. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
