đź“… Original date posted:2019-12-17
đź“ť Original message:
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
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:57:48
in reply to nevent1q…5dty
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:57:48Event JSON
{
"id": "f0a625318f92a147af0f55c255dda52b7a776ed873751e21556091361dd6c409",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315468,
"kind": 1,
"tags": [
[
"e",
"e45c5a8385868cf007616f6909d9e9621b3b808a38fc0e859d163cf4d778a1c0",
"",
"root"
],
[
"e",
"13b8992ebb29706e5ac0a5f10dae7dfd4129b318359754647a5c489cb69c7e6b",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 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",
"sig": "f5caffb05080745487db367fcbf219219be9f3897548388bc789f78e03d51bcd72f26d60b3294816d9ac9260478e8be33beef8dc5f70ea769fb60de18f54c7db"
}