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 --]
next prev parent 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