[Lightning-dev] PoDLEs revisited

ZmnSCPxj ZmnSCPxj at protonmail.com
Tue Jan 5 08:38:19 UTC 2021


Good morning LL, and happy new year as well,



> # Signaling Transactions
>
> Finally I present a simple but unintuitive protocol that achieves roughly the same properties as the PoDLE protocol but without lightning gossip messages.
>
> Whenever the initiator adds an input in the interactive tx building they provide signatures on a "signaling" transaction spending that input (and any inputs they have added so far).
> The signaling transactions will typically spend the funds back to the initiator's wallet.
> Before revealing any of their inputs, the peer checks that none of the inputs added by the initiator are in their mempool/chain.
> If the initiator aborts the protocol after learning one of the peer's inputs the peer broadcasts one of the signaling transactions.

I would suggest rather that each added input should add a one-input one-output signaling transaction, instead.

Consider the case of a malicious initiator who has two coins A and B.

* Mallory sends A with a signalling transaction spending A.
* Mallory sends B with a signalling transaction spending A and B.
* Victor the victim initiatee node sends its coins.
* Mallory spends A to itself, using a different transaction, with a feerate that is slightly higher than the feerate of the signaling transaction spending A and B.

Mallory only needs to spend A, and there is no way for Victor to impose a cost on the use of B --- the signaling transactions available to Victor spend A and cannot replace the non-signaling transaction that Mallory created.

So I think it is better if there is one signaling transaction per input provided by the initiator.

Alternately, we can consider that Mallory will rationally want to reduce its exposure to cost, and would prefer to just provide a single input on each initiation.
If Mallory is in possession of multiple coins, it is in the best interest of Mallory to use each coin on a different Victor to spread out its risk *and* retain its own privacy, anyway, and not give two or more inputs to each Victor.
Thus, we only really need one signalling transaction, that for the first input provided by the initiator, and the single signalling transaction is sufficient to impose costs on Mallory.

>
> Like the PoDLE proposal this doesn't achieve (3) since a malicious peer could broadcast the signaling transaction making the honest initiator pay a transaction fee before using the input in another session.
> To mitigate this a bit, the transactions could be RBF and have a 1 sat-per-byte feerate to give the initiator a decent amount of time to use their input productively before the tx confirms (and paying a low fee if it ever does confirm).
>
> The advantages of signaling transactions over PoDLE is that it doesn't involve any wonky crypto or new gossip messages.
> The advantage of the PoDLE proposal over this is that a malicious peer can only blacklist the UTXO (not necessarily force you to spend it).
>
> # Summary
>
> The preference of protocol depends on how you weigh the importance of a malicious non-initiating peer griefing the initiator.
> To protect fully, the extended version of Darosior's protocol does not allow griefing.
> There is always a lot to be said for ruling out a class of attack even if it costs you a few rounds of communication.
>
> Is griefing a real concern though? Layer-2 is full of opportunities to grief your counterparty and the ones presented here are hardly the worst.
> If you're opening channels with someone who wants to grief you, you are already in trouble.
> PoDLEs have very weak griefing in the form of unfairly adding your UTXO to the blacklist but comes at the cost of complexity and a few difficult to answer questions.
> I think the simplicity of signaling transactions may be worth the extra griefing capabilities it offers a malicious peer given they are hardly as bad as the griefing capabilities they will have if you open a channel to them!

Indeed.

With the network already "booted up", so to speak, in general, a node will prefer to initiate channels with existing nodes that have:

* High uptime.
* Good connectivity and capacity.
* Long-lived channels.

A node which acts as a passive malicious peer in this protocol *could* have gotten another channel to justify its high uptime and locked funds, and potentially earn more funds in the future, rather than pissing off the incoming initiator by this form of griefing.

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list