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