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 <zmnsc...@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to