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