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