Lloyd Fournier <lloyd.fo...@gmail.com> writes:
> This achieves all properties except for (4 - distinguishable on-chain)
> which is why it was dismissed.
It also seems to require 2 txs per channel open? (Interestingly I
missed that post previously, thanks for the pointer!)
> I think it is possible to extend the idea to achieve (4) and therefore
> obtain all desired properties.
> Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups
> in case of abort. Here's how it could work in my mind:
>
> 1. Initiator requests dual-funding and provides a TX_temp spending their
> input set to a main output and a change output (does not sign it yet). They
> also provide a sighash SIGNLE|ANYONECANPAY signature on the main output
> spending into TX_backup-fund and a signature on the first commitment
> transaction spending from TX_backup-fund (exactly as in [6]).
> 2. Peer responds with commitment TX signature for TX_backup-fund.
> 3. Initiator responds with the signatures for TX_temp.
> *Peer now has a fully functional transaction chain with which to open the
> channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.
> 4. Peer (if possible) checks there are no existing transactions in the
> chain or mempool spending from the taker's inputs. If not it responds with
> its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.
> 5. Initiator responds with commitment TX signature and TX_fund input
> signatures.
> 6. Peer broadcasts TX_fund.
> *If at any point after step 3 Initiator does not respond for ~2 seconds
> they broadcast TX_temp and TX_backup-funding*
2 seconds is not sufficient; as an Australian (or Tor user) you should
know this :)
But otherwise, it's kinda nice (bar breaking the interactive construction).
> We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain
> in case of abort (i.e. TX_backup-funding makes it on-chain).
> It appears to be pretty close to the ideal solution in terms of privacy and
> security.
> If the malicious initiator learns an output they will always have to spend
> one of their inputs otherwise they will quickly get hit by the TX_temp +
> TX_backup-funding.
> Note that it is possible the node is just slow in which case even if step
> TX_backup-funding makes it in both parties should just carry on with the
> channel.
>
> The downsides are that it involves six rounds of communication and cannot
> use the "interactive tx building" protocol developed for the original
> proposal
>
> # 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.
>
> 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).
We only need a single UTXO for this, which is even better.
So the initiator sends a "good faith" signed tx, which spends one of its
UTXOs, to the accepter. 1sat-per-byte is probably a too low, but the
accepter can provide a feerate for it[1]. Opener aborts if that
"good-faith" feerate is too high. It's implied that this is the first
added input, too.
If the accepter screws the opener by broadcasting it, the opener can
still open a channel with someone else before it's confirmed: they just
can't use *that* utxo if they want another node to DF. Or simply take
the loss, since the feerate is presumably minimal, and use CPFP.
Cheers,
Rusty.
[1] The latest c-lightning implementation of the spec[2] already has the
accepter indicating min, max and preferred feerates (and then the
opener selects within that range). This would simply add another
feerate field, suggest implementing as ceiling(min / 2, 1).
[2] Which Lisa promises she'll publish RSN, so we can add your derived
points proposal to it.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
