lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-13 📝 Original message: > With PoDLE this would ...
📅 Original date posted:2020-02-13
📝 Original message:
> 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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/b925f71c/attachment.html>;
📝 Original message:
> 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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/b925f71c/attachment.html>;