From rusty at rustcorp.com.au Thu Feb 20 09:50:32 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 20 Feb 2020 20:20:32 +1030 Subject: [Lightning-dev] DRAFT: interactive tx construction protocol In-Reply-To: References: <87imkbnkcc.fsf@rustcorp.com.au> <5Erhu88hURJRUS-JgLvrFeyj10cpg5mMYFv4VKyTW6IBaST6yQsMilcnFjpRi2YflR1y1TdzO4tAZl_bnawSZPM35cwg7cFpj12y3hFchFk=@protonmail.com> Message-ID: <8736b5mvtj.fsf@rustcorp.com.au> lisa neigut writes: >> 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. Yes, you need to PoDLE your own contribution I think, which means you need one UTXO per contributor in the N-way-open who you want to contribute a UTXO. Consider Alice trying to create a single-tx to open a channel with both Bob and Carol, and wants *both* of them to also contribute. Alice sends her own UTXO1 with proof to Bob, he shares his UTXO back. Alice sends her own UTXO2 with proof to Carol, she shares a UTXO back. Alice sets the lower bit on the serial_id from Bob and sends to Carol, and sets the lower on the serial_id from Carol and sends to Bob. She similarly reflects everything from Carol to Bob and vice-versa, and sends both of them the two "channel opening" outputs. Now all parties have the same tx; unless Bob and Carol chose the same serial_ids (spec says random, but Bob and Carol don't get along). But this is trivially identifiable, and you give up on mutual opening. Cheers, Rusty.