<oembed><type>rich</type><version>1.0</version><author_name>npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_name><author_url>https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2019-12-17&#xA;📝 Original message:&#xA;Good morning t-bast,&#xA;&#xA;Further, we can enforce that RBF is signalled for every spend of the output by:&#xA;&#xA;    &lt;0&gt; OP_CHECKSEQUENCEVERIFY OP_DROP &lt;R&gt; OP_SWAP OP_CAT &lt;ACINQ&gt; OP_CHECKSIG&#xA;&#xA;Requiring that RBF is signalled gives a little more assurance.&#xA;Suppose ACINQ becomes evil and double-spends the output.&#xA;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.&#xA;Then anyone who notices the double-spend can RBF the double-spending transaction to themselves rather than ACINQ.&#xA;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.&#xA;&#xA;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.&#xA;Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing such powerful constructions.&#xA;&#xA;Regards,&#xA;ZmnSCPxj&#xA;&#xA;&#xA;&gt; Thanks a lot David for the suggestion and pointers, that&#39;s a really interesting solution.&#xA;&gt; I will dive into that in-depth, it could be very useful for many layer-2 constructions.&#xA;&gt;&#xA;&gt; Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` construction,&#xA;&gt; a lot of cool tricks coming up once (if?) we have such tools in the future ;)&#xA;&gt;&#xA;&gt; Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj &lt;ZmnSCPxj at protonmail.com&gt; a écrit :&#xA;&gt;&#xA;&gt; &gt; Good morning David, t-bast, and all,&#xA;&gt; &gt;&#xA;&gt; &gt; &gt; I&#39;m not aware of any way to currently force single-show signatures in&#xA;&gt; &gt; &gt; Bitcoin, so this is pretty theoretical. Also, single-show signatures&#xA;&gt; &gt; &gt; add a lot of fragility to any setup and make useful features like RBF&#xA;&gt; &gt; &gt; fee bumping unavailable.&#xA;&gt; &gt;&#xA;&gt; &gt; With `OP_CAT`, we can enforce that a particular `R` is used, which allows to implement single-show signatures.&#xA;&gt; &gt;&#xA;&gt; &gt;     # Assuming signatures are the concatenation of (R,s)&#xA;&gt; &gt;     &lt;R&gt; OP_SWAP OP_CAT &lt;ACINQ&gt; OP_CHECKSIG&#xA;&gt; &gt;&#xA;&gt; &gt; The above would then feed `s` only on the witness stack.&#xA;&gt; &gt;&#xA;&gt; &gt; Regards,&#xA;&gt; &gt; ZmnSCPxj</html></oembed>