public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail.com>
To: James Prestwich <james@prestwi.ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] IsStandard
Date: Fri, 3 May 2019 11:51:25 +0200	[thread overview]
Message-ID: <37e3f1ee-a3c6-2670-f0e0-4b939bf8e396@gmail.com> (raw)
In-Reply-To: <CAOP2CbwfwnDCRTpsoDyAHemRYu617QeOWinwM8j95m5e7ceRKA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6876 bytes --]

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<hash160 of pubkey>, and scriptPubKey OP_HASH160 <hash160 of
0014<hash160 of pubkey> OP_EQUAL, then scriptSig executes pushing
nothing and <hash160 of pubkey> into the stack, then scriptSig is pushed
again and executed with scriptPubKey, at the end we get nothing +
<hash160 of pubkey> + 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
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> 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://github.com/Ayms/torrent-livenode-Tor> :
>     https://www.github.com/Ayms/node-Tor
>     GitHub : https://www.github.com/Ayms
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto: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


[-- Attachment #2: Type: text/html, Size: 11577 bytes --]

  reply	other threads:[~2019-05-03  9:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-27 10:37 [bitcoin-dev] IsStandard Aymeric Vitte
2019-04-29  1:46 ` ZmnSCPxj
2019-04-29  3:01 ` Luke Dashjr
2019-04-29  9:30   ` Aymeric Vitte
2019-04-30  4:29     ` ZmnSCPxj
2019-04-30  9:43       ` Aymeric Vitte
2019-05-02  0:10         ` ZmnSCPxj
2019-05-02 10:01           ` Aymeric Vitte
2019-05-02 23:33             ` James Prestwich
2019-05-03  9:51               ` Aymeric Vitte [this message]
2019-05-02 23:35             ` Pieter Wuille
2019-04-29 17:27 ` Marco Falke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37e3f1ee-a3c6-2670-f0e0-4b939bf8e396@gmail.com \
    --to=vitteaymeric@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=james@prestwi.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox