[Lightning-dev] Pay-to-Open and UX improvements

Wed Dec 18 10:14:38 UTC 2019

Good morning list,

Thanks again for all the good suggestions, this is awesome.
David and ZmnSCPxj's proposals got me thinking (and I still need to dive
into
Antoine's suggestion as well), and I may have found a very interesting
construction. It's either great or completely dumb. I hope you can help me
figure out which of the two it's going to be.

The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the
signature as a single 64-bytes stack argument, let's add a small change to
read
the signature as two 32-bytes stack arguments: `R` first then `s`.
Since Taproot already makes changes to this opcode, adding this small change
seems to be quite simple and harmless (and this is the right time to propose
such a change as we're still in the Taproot review process).

This effectively lets us leverage nonce reuse as a feature to prevent double
spending once a signature has been shared off-chain.

Let's set the scene for this usecase. We have a service provider Patrick
that
wants to offer layer 2 services. Patrick prepares some of his UTXOs to have
the
following spending condition:

* A provably unspendable key-path spend
* A script-path spend with the following script (and only that script):
OP_SWAP OP_DUP <R> OP_EQUALVERIFY OP_SWAP <P> OP_CHECKSIG
* Notes:
* The script could be more fancy (maybe we want to use hash(R) instead of R
directly) but you get the idea
* The OP_SWAP are needed because the spending stack will be <P> <R> <s>
* P is of course different for every UTXO

This means that Patrick is committing to the nonce he'll be using to spend
that
output.

Now comes our friend Alice. Patrick wants to open a channel to Alice and
wants
to start using this channel without waiting for on-chain confirmation.
Alice and Patrick build the funding transaction as usual; once Alice sees
the
transaction in the mempool, she can verify that the inputs have the right
format.
Now Alice can be sure that Patrick will not double-spend the funding
transaction's inputs: if he does, he will be signing a different message
with
the same nonce. That would allow Alice to extract the private key for `P`
and
spend the UTXO to herself. She has nothing to lose there because it's
Patrick's
UTXO so she has an incentive to use much higher fees than Patrick.

It seems to me that this construction can be generalized for many off-chain
protocols that don't want to wait for confirmation. I may be overly
optimistic,
but I think this could enable a whole lot of new use-cases and remove many
pain points in Lightning.

This is only a first draft, and there are things that can be improved. Let's
list what comes to mind (you will probably identify other issues):

* Patrick can't use RBF on transactions that spend this kind of UTXO
because it
would reveal his private key: that's probably ok in practice (we can add an
output for CPFP instead like we're doing for anchor outputs [1])
* These UTXOs are easy to recognize on-chain once spent, which may indicate
that this is spent for an off-chain protocol
* It would be great to have a way to allow key-path spend, but revoke this
capability once the script has been revealed (off-chain): that would allow
Patrick to encumber all his UTXOs with such a script and only use it when
needed for an off-chain scenario (and use normal key-path spend otherwise)

Please let me know if this is completely broken, completely dumb or worth
sharing to the bitcoin-dev mailing list to consider including this
`OP_CHECKSIG`
change in the Taproot soft-fork.

Cheers,
Bastien

[1] https://github.com/lightningnetwork/lightning-rfc/pull/688

Le mer. 18 déc. 2019 à 05:49, Antoine Riard <antoine.riard at gmail.com> a
écrit :
>
> Hi Bastien,
>
> The use case you're describing strikes me as similar to a slashing
protocol for a LN node and a watchtower, i.e punishing
> a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
> unlock some funds for B".
>
> Here a rough slashing protocol I've sketched out to someone else
off-list, it may work for you use case if you replace the penalty tx
> by the funding transaction as a way for the trusted channel funder to
clear his liability. Though you will need onchain interactivity
> before the fact but you may be able to reuse slashing outpoint for
multiple channel funding.
>
> Slashing Protocol
> ----------------------
>
> Alice and Bob lock fund in channel outpoint X. They issue commitment tx
N.  Will the accountable watchtower locks fund
> in a 2-of-2 slashing outpoint Y with Bob the client.
>
> When Alice and Bob update channels to N', Bob and Will use some output
from commitment N (like upcoming anchor output)
> to create an accountable tx M. M is paying to Bob after timelock+Bob sig
or is paying to transaction success_penalty P
> with Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M
and from J the justice tx than Bob has given
> to Will. J is spending Alice's revoked commitment N.
>
> So this slashing protocol should avoid Bob making false claim, because
you need a revoked broadcast to enable the claim
> and at same time we use a justice tx output as a proof than Will have
done its monitoring+punishment job. Will shouldn't
> learn commitment balance if there is no channel breach and Alice and Bob
wouldn't be able to collude against Will, if
> watchtower have a penalty tx on Alice non-revoked commitment tx, that's
her concern.
>
> So topology would be:
>
>                                                        to_Bob
>                                                      /
>           X  <---------- N   <--------- J
>                                 ^                   ^
>                                    \                   \
>             Y <---------------  M  <---------- P - to_Will
>                                        \
>                                         to_Bob
>
>
> Main idea of the protocol is to use transactions topology of a first
contract as proofs for a subsidiary contract.
>
> I'm quite sure it's insecure, just quick ideas, any thoughts ?
>
> (but would be really cool to have one accountable protocol to both
watchtower and pay-to-open use cases to save
> engineering costs)
>
> Cheers,
>
> Antoine
>
>
> Le mar. 17 déc. 2019 à 16:08, Ethan Heilman <eth3rs at gmail.com> a écrit :
>>
>> From where I'm sitting the fact that OP_CAT allows people to build
>> more powerful constructions in Bitcoin without introducing additional
>> complexity at the consensus layer is a positive not a negative. Using
>> OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful
>> protocol tool for enforcing fairness in layer two protocols.
>>
>> On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev
>> <lightning-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Good morning t-bast,
>> >
>> > Further, we can enforce that RBF is signalled for every spend of the
output by:
>> >
>> >     <0> OP_CHECKSEQUENCEVERIFY OP_DROP <R> OP_SWAP OP_CAT <ACINQ>
OP_CHECKSIG
>> >
>> > Requiring that RBF is signalled gives a little more assurance.
>> > Suppose ACINQ becomes evil and double-spends the output.
>> > The transaction that is posted in the mempool must be marked by RBF
due to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles
as RBF opt-in.
>> > Then anyone who notices the double-spend can RBF the double-spending
transaction to themselves rather than ACINQ.
>> > This also further publishes ACINQ private key, until the winning
transaction has an `OP_RETURN` output that pays the entire value as fees
and nobody can RBF it further.
>> >
>> > This is a minor increase in the assurability of the construction, by
making any output that is double-spent directly revocable in favor of the
miners.
>> > Again, it requires `OP_CAT`, which is a very dangerous opcode,
allowing such powerful constructions.
>> >
>> > Regards,
>> > ZmnSCPxj
>> >
>> >
>> > > Thanks a lot David for the suggestion and pointers, that's a really
interesting solution.
>> > > I will dive into that in-depth, it could be very useful for many
layer-2 constructions.
>> > >
>> > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT`
construction,
>> > > a lot of cool tricks coming up once (if?) we have such tools in the
future ;)
>> > >
>> > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a
écrit :
>> > >
>> > > > Good morning David, t-bast, and all,
>> > > >
>> > > > > I'm not aware of any way to currently force single-show
signatures in
>> > > > > Bitcoin, so this is pretty theoretical. Also, single-show
signatures
>> > > > > add a lot of fragility to any setup and make useful features
like RBF
>> > > > > fee bumping unavailable.
>> > > >
>> > > > With `OP_CAT`, we can enforce that a particular `R` is used, which
allows to implement single-show signatures.
>> > > >
>> > > >     # Assuming signatures are the concatenation of (R,s)
>> > > >     <R> OP_SWAP OP_CAT <ACINQ> OP_CHECKSIG
>> > > >
>> > > > The above would then feed `s` only on the witness stack.
>> > > >
>> > > > Regards,
>> > > > ZmnSCPxj
>> >
>> >
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191218/723025ac/attachment-0001.html>