Good morning t-bast, > Good points, these are good optimisations if we propose such a new opcode! > I'm still pondering whether this will be useful enough or if finney attacks > completely ruin all use-cases...
It does indeed seem to ruin all use-cases, and even my suggestion to enforce RBF will not help against the Finney attack specifically, as the second signature broadcasted is the one that is already in a block. Further, if the amount in the single-show-signature UTXO being double-spent is greater than the expected block reward, then it may encourage competing miners to instead mine an alternate block at that blockheight instead of building on the block made by the Finney attacker. This is because they already know the privkey for that UTXO and can instead immediately redirect it to an address they control, and earn more from that block that replaces the Finney attacker block rather than builds on top of it. All miners will then compete on that block and the Finney attack is promoted from an attack on a single target to an attack on the entire Bitcoin ecosystem, for much justice and laughter. Thus, `OP_CAT` is too powerful and must not be enabled!!! Oh no. Regards, ZmnSCPxj > > Le jeu. 19 déc. 2019 à 07:24, ZmnSCPxj <zmnsc...@protonmail.com> a écrit : > > > Good morning t-bast, > > > > > > - A script-path spend with the following script (and only that > > > > script): > > > > OP_SWAP OP_DUP <R> OP_EQUALVERIFY OP_SWAP <P> OP_CHECKSIG > > > > > > > > > > Why not this: > > > > > > <R> OP_SWAP OP_CHECKSPLITSIG > > > > > > ? > > > > > > Since `R` is constrained to be fixed anyway, why repeat `R` twice, once > > > in the script and once in the witness stack? > > > > For that matter, since we are far more likely to have a constant `R` than a > > constant `s` maybe you should instead propose that `OP_CHECKSPLITSIG` be > > given `<s> <R> <P> OP_CHECKSPLITSIG`, so that a fixed-`R` single-show > > signature is just `<R> <P> OP_CHECKSPLITSIG`. > > > > Regards, > > ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
