[Lightning-dev] DRAFT: interactive tx construction protocol

Rusty Russell rusty at rustcorp.com.au
Thu Feb 20 09:50:32 UTC 2020


lisa neigut <niftynei at gmail.com> 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.


More information about the Lightning-dev mailing list