📅 Original date posted:2019-12-17
📝 Original message:
>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 at 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 <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
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Ethan Heilman [ARCHIVE] /
npub1ga…gac47
2023-06-09 12:57:48
in reply to nevent1q…yahe
Author Public Key
npub1gaszwl7qd0tjmnwcaamgzzgsmzzjlvle6kz0td66pwa8z69vsxsqxgac47Published at
2023-06-09 12:57:48Event JSON
{
"id": "743e0ab484ba0a326ee30e4f1ab20933cddfa0af86c73eef642f9a94b3479abd",
"pubkey": "4760277fc06bd72dcdd8ef76810910d8852fb3f9d584f5b75a0bba7168ac81a0",
"created_at": 1686315468,
"kind": 1,
"tags": [
[
"e",
"e45c5a8385868cf007616f6909d9e9621b3b808a38fc0e859d163cf4d778a1c0",
"",
"root"
],
[
"e",
"f0a625318f92a147af0f55c255dda52b7a776ed873751e21556091361dd6c409",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-12-17\n📝 Original message:\n\u003eFrom where I'm sitting the fact that OP_CAT allows people to build\nmore powerful constructions in Bitcoin without introducing additional\ncomplexity at the consensus layer is a positive not a negative. Using\nOP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful\nprotocol tool for enforcing fairness in layer two protocols.\n\nOn Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Good morning t-bast,\n\u003e\n\u003e Further, we can enforce that RBF is signalled for every spend of the output by:\n\u003e\n\u003e \u003c0\u003e OP_CHECKSEQUENCEVERIFY OP_DROP \u003cR\u003e OP_SWAP OP_CAT \u003cACINQ\u003e OP_CHECKSIG\n\u003e\n\u003e Requiring that RBF is signalled gives a little more assurance.\n\u003e Suppose ACINQ becomes evil and double-spends the output.\n\u003e 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.\n\u003e Then anyone who notices the double-spend can RBF the double-spending transaction to themselves rather than ACINQ.\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing such powerful constructions.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e \u003e Thanks a lot David for the suggestion and pointers, that's a really interesting solution.\n\u003e \u003e I will dive into that in-depth, it could be very useful for many layer-2 constructions.\n\u003e \u003e\n\u003e \u003e Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` construction,\n\u003e \u003e a lot of cool tricks coming up once (if?) we have such tools in the future ;)\n\u003e \u003e\n\u003e \u003e Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\u003e \u003e\n\u003e \u003e \u003e Good morning David, t-bast, and all,\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e I'm not aware of any way to currently force single-show signatures in\n\u003e \u003e \u003e \u003e Bitcoin, so this is pretty theoretical. Also, single-show signatures\n\u003e \u003e \u003e \u003e add a lot of fragility to any setup and make useful features like RBF\n\u003e \u003e \u003e \u003e fee bumping unavailable.\n\u003e \u003e \u003e\n\u003e \u003e \u003e With `OP_CAT`, we can enforce that a particular `R` is used, which allows to implement single-show signatures.\n\u003e \u003e \u003e\n\u003e \u003e \u003e # Assuming signatures are the concatenation of (R,s)\n\u003e \u003e \u003e \u003cR\u003e OP_SWAP OP_CAT \u003cACINQ\u003e OP_CHECKSIG\n\u003e \u003e \u003e\n\u003e \u003e \u003e The above would then feed `s` only on the witness stack.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Regards,\n\u003e \u003e \u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "e995a1e9144cf132e5b3bb84ab8f9dfa377f3c714c8a34ecc8eb52bbdff6493014d69c76b7f1a346ad58d9124365a2130327784bf0cd1e1f74230be59aedb0ab"
}