Great doc, thanks, then my previous summarized conclusion was wrong, trying on my side to write a "demistifying (simply) once for all bitcoin scripting", not sure that "simply" can stay in the title at the end... So my multisig modification is non standard, now I am still puzzled by something, mainly the fact that we have op_pushdata inside op_pushdata, maybe I am misreading the specs, but in case of p2sh only the last op_pushdata (called {serialized script} (or redeem script) is executed, then if succesfull it comes back onto the stack and scriptpubkey is executed So, let's take again the BCH recovery example, scriptSig was OP_PUSHDATA 0014, and scriptPubKey OP_HASH160 OP_EQUAL, then scriptSig executes pushing nothing and into the stack, then scriptSig is pushed again and executed with scriptPubKey, at the end we get nothing + + 1 in the stack, then cleanstack (maybe among others, I have to read in more details your doc) says it is a correct transaction but non standard, is this correct? Le 03/05/2019 à 01:33, James Prestwich a écrit : > Hi Aymeric,  > > As Luke and ZmnSCPxj have pointed out, documenting standardness is > sisyphean, as it varies from version to version. I recently put > together a reference for default TX_NONSTANDARD policies in v0.18, > which can be found here: https://prestwi.ch/the-bitcoin-nonstandard/  > > It applies only to v0.18, and may already be outdated. > > Best, > James > > On Thu, May 2, 2019 at 4:29 PM Aymeric Vitte via bitcoin-dev > > wrote: > > Thanks for the answer, indeed for the redeem script and someone > attempting a 0/1 of 3, good example > > So to summarize everything is standard as long as it matches P2PKH, > P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in > op_return > > Still the case of bch is unclear (it's related since based on bitcoin > code unless they changed the policy), was the story that nodes > would not > propagate the fix or that people did not want to take the risk to > propagate it? And why a non segwit old bitcoin node would not > accept it > either? > > Le 02/05/2019 à 02:10, ZmnSCPxj a écrit : > > Good morning Aymeric, > > > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte > > wrote: > > > >> I must badly explain my point (or just wondering things that do not > >> exist finally), the question is indeed whether nodes will relay non > >> usual transactions or not and how to know what they will accept > or not: > >> > >> -   my modified multisig 2 of 3: I did put OP_2 out of the > usual redeem > >>     script, the redeem script still matches scriptpubkey and > scriptsig will > >>     execute succesfully, that's a normal legacy P2SH or segwit > P2WSH > >> > >> -   bch segwit recovery: it's a p2sh transaction without any > signature > >>     verification, as far as I remember there was a story that > it could not > >>     propagate in the network (even taking the risk to be > stolen) and that > >>     people had to contact a (honest) miner > >> > >> -   sha bounties: same as above, p2sh transactions without > signatures > >> > >>     etc > >> > >>     Will all of those transactions propagate normally? And then > the rule is > >>     just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH > templates > >>     whatever scripts you put inside? > > P2PKH and P2WPKH cannot have custom script. > > However, yes, any custom script can be wrapped in P2SH and P2WSH > and it will be propagated. > > The P2SH/P2WSH hides the details of your custom script so cannot > be filtered based on your custom script. > > Do realize that once a claim on your modified x-of-3 is > propagated your `redeemScript` is known and someone can attempt to > RBF (or coordinate with a miner) with a modified `witness` stack > or `scriptSig` to claim your UTXO. > > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at > least one of your signatories could make it a 1-of-3 and bribe a > miner to get it claimed) > > > > I cannot answer for BCH; arguably that is off-topic here. > > > > The old SHA bounty transactions were propagated in the days > before `isStandard` I think. > > Either that or they were put in by miners. > > An SHA bounty can still be propagated today if they are wrapped > in a P2SH or P2WSH, but you have to publish the `redeemScript` > yourself in some other method. > > Or bribe a miner if the transaction is not time-sensitive (for > an SHA bounty, unlikely to be time-sensitive). > > > > Regards, > > ZmnSCPxj > > -- > Move your coins by yourself (browser version): > https://peersm.com/wallet > Bitcoin transactions made simple: > https://github.com/Ayms/bitcoin-transactions > Zcash wallets made simple: https://github.com/Ayms/zcash-wallets > Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets > Get the torrent dynamic blocklist: http://peersm.com/getblocklist > Check the 10 M passwords list: http://peersm.com/findmyass > Anti-spies and private torrents, dynamic blocklist: > http://torrent-live.org > Peersm : http://www.peersm.com > torrent-live: https://github.com/Ayms/torrent-live > node-Tor : > https://www.github.com/Ayms/node-Tor > GitHub : https://www.github.com/Ayms > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms