{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-12-18\n📝 Original message:\nHi Bastien,\n\nThe use case you're describing strikes me as similar to a slashing protocol\nfor a LN node and a watchtower, i.e punishing\na lazy watchtower for not broadcasting a penalty tx on remote revoked\nstate. In both case you want \"if A don't do X\nunlock some funds for B\".\n\nHere a rough slashing protocol I've sketched out to someone else off-list,\nit may work for you use case if you replace the penalty tx\nby the funding transaction as a way for the trusted channel funder to clear\nhis liability. Though you will need onchain interactivity\nbefore the fact but you may be able to reuse slashing outpoint for multiple\nchannel funding.\n\nSlashing Protocol\n----------------------\n\nAlice and Bob lock fund in channel outpoint X. They issue commitment tx N.\nWill the accountable watchtower locks fund\nin a 2-of-2 slashing outpoint Y with Bob the client.\n\nWhen Alice and Bob update channels to N', Bob and Will use some output from\ncommitment N (like upcoming anchor output)\nto create an accountable tx M. M is paying to Bob after timelock+Bob sig or\nis paying to transaction success_penalty P\nwith Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M\nand from J the justice tx than Bob has given\nto Will. J is spending Alice's revoked commitment N.\n\nSo this slashing protocol should avoid Bob making false claim, because you\nneed a revoked broadcast to enable the claim\nand at same time we use a justice tx output as a proof than Will have done\nits monitoring+punishment job. Will shouldn't\nlearn commitment balance if there is no channel breach and Alice and Bob\nwouldn't be able to collude against Will, if\nwatchtower have a penalty tx on Alice non-revoked commitment tx, that's her\nconcern.\n\nSo topology would be:\n\n                                                       to_Bob\n                                                     /\n          X  \u003c---------- N   \u003c--------- J\n                                ^                   ^\n                                   \\                   \\\n            Y \u003c---------------  M  \u003c---------- P - to_Will\n                                       \\\n                                        to_Bob\n\n\nMain idea of the protocol is to use transactions topology of a first\ncontract as proofs for a subsidiary contract.\n\nI'm quite sure it's insecure, just quick ideas, any thoughts ?\n\n(but would be really cool to have one accountable protocol to both\nwatchtower and pay-to-open use cases to save\nengineering costs)\n\nCheers,\n\nAntoine\n\n\nLe mar. 17 déc. 2019 à 16:08, Ethan Heilman \u003ceth3rs at gmail.com\u003e a écrit :\n\n\u003e From where I'm sitting the fact that OP_CAT allows people to build\n\u003e more powerful constructions in Bitcoin without introducing additional\n\u003e complexity at the consensus layer is a positive not a negative. Using\n\u003e OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful\n\u003e protocol tool for enforcing fairness in layer two protocols.\n\u003e\n\u003e On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev\n\u003e \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Good morning t-bast,\n\u003e \u003e\n\u003e \u003e Further, we can enforce that RBF is signalled for every spend of the\n\u003e output by:\n\u003e \u003e\n\u003e \u003e     \u003c0\u003e OP_CHECKSEQUENCEVERIFY OP_DROP \u003cR\u003e OP_SWAP OP_CAT \u003cACINQ\u003e\n\u003e OP_CHECKSIG\n\u003e \u003e\n\u003e \u003e Requiring that RBF is signalled gives a little more assurance.\n\u003e \u003e Suppose ACINQ becomes evil and double-spends the output.\n\u003e \u003e The transaction that is posted in the mempool must be marked by RBF due\n\u003e to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as\n\u003e RBF opt-in.\n\u003e \u003e Then anyone who notices the double-spend can RBF the double-spending\n\u003e transaction to themselves rather than ACINQ.\n\u003e \u003e This also further publishes ACINQ private key, until the winning\n\u003e transaction has an `OP_RETURN` output that pays the entire value as fees\n\u003e and nobody can RBF it further.\n\u003e \u003e\n\u003e \u003e This is a minor increase in the assurability of the construction, by\n\u003e making any output that is double-spent directly revocable in favor of the\n\u003e miners.\n\u003e \u003e Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing\n\u003e such powerful constructions.\n\u003e \u003e\n\u003e \u003e Regards,\n\u003e \u003e ZmnSCPxj\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e \u003e Thanks a lot David for the suggestion and pointers, that's a really\n\u003e interesting solution.\n\u003e \u003e \u003e I will dive into that in-depth, it could be very useful for many\n\u003e layer-2 constructions.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT`\n\u003e construction,\n\u003e \u003e \u003e a lot of cool tricks coming up once (if?) we have such tools in the\n\u003e future ;)\n\u003e \u003e \u003e\n\u003e \u003e \u003e Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a\n\u003e écrit :\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Good morning David, t-bast, and all,\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e I'm not aware of any way to currently force single-show signatures\n\u003e in\n\u003e \u003e \u003e \u003e \u003e Bitcoin, so this is pretty theoretical. Also, single-show\n\u003e signatures\n\u003e \u003e \u003e \u003e \u003e add a lot of fragility to any setup and make useful features like\n\u003e RBF\n\u003e \u003e \u003e \u003e \u003e fee bumping unavailable.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e With `OP_CAT`, we can enforce that a particular `R` is used, which\n\u003e allows to implement single-show signatures.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e     # Assuming signatures are the concatenation of (R,s)\n\u003e \u003e \u003e \u003e     \u003cR\u003e OP_SWAP OP_CAT \u003cACINQ\u003e OP_CHECKSIG\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The above would then feed `s` only on the witness stack.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Regards,\n\u003e \u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/52ad7f11/attachment.html\u003e"}