<oembed><type>rich</type><version>1.0</version><title>lisa neigut [ARCHIVE] wrote</title><author_name>lisa neigut [ARCHIVE] (npub1sp…s64t2)</author_name><author_url>https://yabu.me/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2020-02-13&#xA;📝 Original message:&#xA;&gt; With PoDLE this would not be possible I think, as you would not be able&#xA;to open the PoDLE commitment with the other node as the target (if we go&#xA;with the modified PoDLE which also commits to which node an opening is for,&#xA;to prevent the pouncing venus flytrap attack).&#xA;&#xA;Good question. It should be possible to do multi-channel open even with the&#xA;PoDLE signature committing to a node_id.&#xA;&#xA;- An initiator can use the same utxo (h2) as their proof for multiple&#xA;peers; the signatures passed to each peer will have to commit to that&#xA;specific peer&#39;s node_id, however.&#xA;- The revised PoDLE signature commitment requires every initiator to&#xA;include at least one of their own inputs in the tx. Attempting to initiate&#xA;an additional open etc using someone else&#39;s utxo&#39;s won&#39;t work (this is the&#xA;pouncing venus flytrap attack which we&#39;re preventing). The initiator&#xA;including at least one input is expected behavior, at least in the open&#xA;case, since the opener has to cover the fees for the funding output.&#xA;- Ideally, a node would remove the PoDLE TLV data from any &#39;forwarded&#39;&#xA;`tx_add_inputs` that isn&#39;t the input they&#39;re proving for, to prevent&#xA;leaking information about which inputs belong to other parties. I say&#xA;ideally here because even if you fail to do this, the peer can iterate&#xA;through all the provided commitment proofs until one of them&#xA;matches/verifies with the upfront provided PoDLE.&#xA;&#xA;&#xA;&#xA;On Thu, Feb 13, 2020 at 12:18 AM ZmnSCPxj &lt;ZmnSCPxj at protonmail.com&gt; wrote:&#xA;&#xA;&gt; Good morning Rusty, niftynei, and list,&#xA;&gt;&#xA;&gt; &gt; &gt; &gt; -   Serial ids should be chosen at random&#xA;&gt; &gt; &gt; &gt;&#xA;&gt; &gt; &gt; &gt; -   For multiparty constructions, the initiator MUST flip the bottom&#xA;&gt; bit of any received inputs before relaying them to a peer.&#xA;&gt; &gt; &gt; &gt;&#xA;&gt; &gt; &gt; &gt; -   Collisions of serial ids between peers is a protocol error&#xA;&gt; &gt; &gt; &gt;&#xA;&gt; &gt; &gt;&#xA;&gt; &gt; &gt; I suppose we should define collision to mean &#34;equal in all bits except&#xA;&gt; the lowest bit&#34;.&#xA;&gt; &gt;&#xA;&gt; &gt; No, literally equal. i.e. you can only make this error by clashing with&#xA;&gt; &gt; yourself.&#xA;&gt;&#xA;&gt; hmm, I thought the entire point of having the low bit was that you could&#xA;&gt; multifund in such a way that the initiator creates multiple channels&#xA;&gt; simultaneously with multiple nodes?&#xA;&gt; So you would have to take the UTXOs of one peer and give it to the other&#xA;&gt; peer claiming it as your own.&#xA;&gt; Or something.&#xA;&gt;&#xA;&gt; With PoDLE this would not be possible I think, as you would not be able to&#xA;&gt; open the PoDLE commitment with the other node as the target (if we go with&#xA;&gt; the modified PoDLE which also commits to which node an opening is for, to&#xA;&gt; prevent the pouncing venus flytrap attack).&#xA;&gt;&#xA;&gt; Regards,&#xA;&gt; ZmnSCPxj&#xA;&gt;&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/b925f71c/attachment.html&gt;</html></oembed>