* [Bitcoin-development] Opcode whitelist for P2SH?
@ 2013-07-28 19:39 John Dillon
2013-07-29 5:17 ` Luke-Jr
2013-07-29 8:13 ` Peter Todd
0 siblings, 2 replies; 5+ messages in thread
From: John Dillon @ 2013-07-28 19:39 UTC (permalink / raw)
To: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter Todd recently came up with two related, and IMO very good, uses for
non-standard transactions to implement both oracles and one-time-password
protection of wallet funds. While the wallet fund case could be implemented as
only a single standard type, at the cost of generality, the oracle case would
be most useful with more arbitrary rules. More generally it is also useful to
be able to have scriptPubKeys like the following:
n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR
and many other similar constructions.
What are your thoughts on creating a whitelist for specific opcodes that would
apply to scripts serialized using P2SH, retaining the existing standard
whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey
and pay-to-multisig due to their potential for dumping data in the UTXO set)
I'm thinking it should contain the following opcodes, picked for either being
already used, or having simple semantics:
0 to 75 byte pushdata
PUSHDATA1
1NEGATE
OP 1 to OP16 (numbers are allowed through pushdata anyway)
IF
NOTIF
ELSE
ENDIF
VERIFY
RETURN
TOALTSTACK
FROMALTSTACK (the alt-stack makes stack manipulation in complex ways possible)
DROP
DUP
SWAP
EQUAL
EQUALVERIFY
0NOTEQUAL
BOOLAND
BOOLOR
RIPEMD160
SHA1
SHA256
HASH160
HASH256
CHECKSIG
CHECKSIGVERIFY
CHECKMULTISIG
CHECKMULTISIGVERIFY
Note how this list allows for complex logic, but does not allow for arithmetic,
thus not exposing us to a source of problems in the past.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9XMQAAoJEEWCsU4mNhiPyXoIAMz2YZsq+/YUnq5G5AEVmJL/
D7qrLpuI++auMEDoXzt8CqmXbDqci/d70IsBYeHdZkxBp2dah99iDzwIoBhtO/xh
XR8m4P+FH+IF6xbuTUAQbBQxr9VuymUatUCmsFzP0YbtPwIzJvUAqJkVeYW1DUXj
6pc9EW3iYdhAvpKNU7A19F6FA96y9m9DyBvY3TCHwzf591Ld1S8ghb9dEuKKYMGl
8TuEMMU/bytZkdD590Ww+f6ukeSOMw9C9+IpAKotB2oq4F4Vkwyzw4rd8sNRAa6c
lEDov6UtDSp4ALMfUxw/nxMO8UB43iJhu31KihcjOZpiYvRVeQlM8XLEvAafZvA=
=Jph1
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Bitcoin-development] Opcode whitelist for P2SH? 2013-07-28 19:39 [Bitcoin-development] Opcode whitelist for P2SH? John Dillon @ 2013-07-29 5:17 ` Luke-Jr 2013-07-29 6:00 ` Jeff Garzik 2013-07-29 8:13 ` Peter Todd 1 sibling, 1 reply; 5+ messages in thread From: Luke-Jr @ 2013-07-29 5:17 UTC (permalink / raw) To: bitcoin-development On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: > What are your thoughts on creating a whitelist for specific opcodes that > would apply to scripts serialized using P2SH, retaining the existing > standard whitelist for scriptPubKeys? (I would still recommend dropping > pay-to-pubkey and pay-to-multisig due to their potential for dumping data > in the UTXO set) This would be reasonable for miners, but for interoperability between wallets, some specific standard forms would still be necessary without a much smarter solver (which would then expand the code required to implement a wallet, which is unfortunate if not entirely necessary). ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Opcode whitelist for P2SH? 2013-07-29 5:17 ` Luke-Jr @ 2013-07-29 6:00 ` Jeff Garzik 2013-07-29 7:41 ` Peter Todd 0 siblings, 1 reply; 5+ messages in thread From: Jeff Garzik @ 2013-07-29 6:00 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr <luke@dashjr•org> wrote: > On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: >> What are your thoughts on creating a whitelist for specific opcodes that >> would apply to scripts serialized using P2SH, retaining the existing >> standard whitelist for scriptPubKeys? (I would still recommend dropping >> pay-to-pubkey and pay-to-multisig due to their potential for dumping data >> in the UTXO set) > > This would be reasonable for miners, but for interoperability between wallets, > some specific standard forms would still be necessary without a much smarter > solver (which would then expand the code required to implement a wallet, which > is unfortunate if not entirely necessary). Indeed. Current designs are all based around pattern matching a script template. Satoshi even described lightweight clients as needing no script engine at all, only the ability to match patterns. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Opcode whitelist for P2SH? 2013-07-29 6:00 ` Jeff Garzik @ 2013-07-29 7:41 ` Peter Todd 0 siblings, 0 replies; 5+ messages in thread From: Peter Todd @ 2013-07-29 7:41 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1998 bytes --] On Mon, Jul 29, 2013 at 02:00:10AM -0400, Jeff Garzik wrote: > On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr <luke@dashjr•org> wrote: > > On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: > >> What are your thoughts on creating a whitelist for specific opcodes that > >> would apply to scripts serialized using P2SH, retaining the existing > >> standard whitelist for scriptPubKeys? (I would still recommend dropping > >> pay-to-pubkey and pay-to-multisig due to their potential for dumping data > >> in the UTXO set) > > > > This would be reasonable for miners, but for interoperability between wallets, > > some specific standard forms would still be necessary without a much smarter > > solver (which would then expand the code required to implement a wallet, which > > is unfortunate if not entirely necessary). > > Indeed. Current designs are all based around pattern matching a > script template. Satoshi even described lightweight clients as > needing no script engine at all, only the ability to match patterns. We're talking about two use-cases here: wallets protected by authorization tokens for multi-factor security, and allowing funds to be controlled by oracles that attest that events have happened allowing the funds to move. The latter application especially demands a specialized wallet, yet can only possibly work with non-standard script formats. IMO bringing the issue of wallet standardization into this discussion is kinda silly and premature; if you don't want to use those features, then you're wallet can ignore them. As for the people that are, they can come up with appropriate standards for their needs. After all John's suggesting only allowing the loosened IsStandard() rules within P2SH, so until the txout is spent all *any* wallet sees is a P2SH address with no information as to what scriptPubKey is needed to spend it. -- 'peter'[:-1]@petertodd.org 00000000000000220b76f98fc9414043f765ec48dba3fb556e096caffbaae8ec [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Opcode whitelist for P2SH? 2013-07-28 19:39 [Bitcoin-development] Opcode whitelist for P2SH? John Dillon 2013-07-29 5:17 ` Luke-Jr @ 2013-07-29 8:13 ` Peter Todd 1 sibling, 0 replies; 5+ messages in thread From: Peter Todd @ 2013-07-29 8:13 UTC (permalink / raw) To: John Dillon; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3697 bytes --] On Sun, Jul 28, 2013 at 07:39:08PM +0000, John Dillon wrote: > Peter Todd recently came up with two related, and IMO very good, uses for > non-standard transactions to implement both oracles and one-time-password > protection of wallet funds. While the wallet fund case could be implemented as > only a single standard type, at the cost of generality, the oracle case would > be most useful with more arbitrary rules. More generally it is also useful to > be able to have scriptPubKeys like the following: > > n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR > > and many other similar constructions. > > What are your thoughts on creating a whitelist for specific opcodes that would > apply to scripts serialized using P2SH, retaining the existing standard > whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey > and pay-to-multisig due to their potential for dumping data in the UTXO set) One subtlety of what you are proposing is that we should still retain the IsStandard() check, or to be exact the AreInputsStandard() check, if a P2SH serialized script follows a standard form. The reason is transaction mutability. Right now other than BIP11 CHECKMULTISIG only miners can mutate transactions because any change to the scriptSig will render the transaction non-standard. As you know this is a good thing because it means unconfirmed transaction chains don't get broken in flight. BIP11 is an interesting case because CHECKMULTISIG consumes one extra stack item, so when you spend a BIP11 n <pubkey>...<pubkey> m CHECKMULTISIG scriptPubKey you have to provide an additional item prior to the signatures; usually OP_0 is used. But we don't actually check that! You can put anything there provided it doesn't make the scriptSig go over the standard allowed scriptSig size of 500 bytes; for instance I (ab)used that feature just now to timestamp my Litecoin v0.8.3.6 audit report SHA256 hash: d0dfe270e8e8e4c0196f780d42e34d8a1121f2f8a249586aa1a2c5ebcada10b1 in transaction: 15bb08318335f94a8de154dc39b03db2cdebcc7a96ab6cec0379978676d00301 It's been suggested that we consider transactions non-standard, or just now allowed at all in a future soft-fork, if at the end of execution there is more than one stack item left; a opcode whitelist should probably do this. On the other hand I've come up with some soft-fork upgrade mechanisms that would leave extra items on the stack for non-upgraded nodes, suggesting a soft-fork imposing this is a bad idea. (though note how it suggests considering such tx's non-standard is reasonable in a few ways) CHECKMULTISIG isn't helped here because the value really is ignored - a soft-fork to force it to always be zero might not be a bad idea, though it's far from the only example of mutability. I'd be interested if you can come up with an example where imposing a one stack item at the end of execution rule causes problems. More generally, and getting a bit off topic, I think Bitcoin should have been designed so that CHECKSIG signed hashes of scriptPubKeys, rather than txid:vout outputs, so that malleability wouldn't affect the validity of a signature. Of course, this would mean that signatures could be reused if scriptPubKeys were reused, but address re-use is a bad thing anyway! Not that I'll fault Satoshi here, type 2 deterministic wallets were unknown back then. (though we should be careful that a future CHECKSIG design can go back to txid:vout references - ECC is unique in allowing for type 2 wallets) -- 'peter'[:-1]@petertodd.org 0000000000000053ef658095fb45c7a86955d70c76b44264c7abce79683a8a90 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-07-29 8:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-07-28 19:39 [Bitcoin-development] Opcode whitelist for P2SH? John Dillon 2013-07-29 5:17 ` Luke-Jr 2013-07-29 6:00 ` Jeff Garzik 2013-07-29 7:41 ` Peter Todd 2013-07-29 8:13 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox