From niftynei at gmail.com Thu Feb 13 16:52:55 2020 From: niftynei at gmail.com (lisa neigut) Date: Thu, 13 Feb 2020 10:52:55 -0600 Subject: [Lightning-dev] DRAFT: interactive tx construction protocol In-Reply-To: <5Erhu88hURJRUS-JgLvrFeyj10cpg5mMYFv4VKyTW6IBaST6yQsMilcnFjpRi2YflR1y1TdzO4tAZl_bnawSZPM35cwg7cFpj12y3hFchFk=@protonmail.com> References: <87imkbnkcc.fsf@rustcorp.com.au> <5Erhu88hURJRUS-JgLvrFeyj10cpg5mMYFv4VKyTW6IBaST6yQsMilcnFjpRi2YflR1y1TdzO4tAZl_bnawSZPM35cwg7cFpj12y3hFchFk=@protonmail.com> Message-ID: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: