Transcript for #bitcoin-dev 2017/04/14

01:08 conman in a createnewblock() call am I right in assuming an ancestor transaction *must* precede any transactions that depend on it? It seems obvious that a txn would be invalid if its dependent txn hasn't been seen
01:09 conman so in a getblocktemplate call, the dependent transactions will always be serialised after their ancestors
01:09 conman CompareTxIterByAncestorCount() suggests so
08:33 `mist hey guys, a python/bitcoinrpc question. i've got the following code https://thepasteb.in/p/nZhlv4RlvWKfY. Is there any way of me to wrap the wallet = Wallet('BTC') in a try: except: so that i'm able to catch the exception and whatever message it has without having to import bitcoinrpc in the calling class?
08:36 `mist i'm thinking something like this but without having to import that JSONRPCException: https://thepasteb.in/p/76hElrBQnNOCV
09:08 wumpus `mist: I'm not entirely clear on what you're trying to do
09:08 wumpus you need to catch JSONRPCException *somewhere* to handle errors that come up, what is your difficulty with importing it?
09:09 `mist it's ok, i solved it =) wallet module raises the jsonrpcexception, then i import only the jsonrpcexception class in the module that calls the method
09:09 `mist and handle the raise there, and then reraise
09:09 wumpus ok, yes
09:10 `mist like this https://thepasteb.in/p/66hVzR4mqWNFW
16:55 ryan-c If I made a script that used OP_CHECKMULTISIG with 1-of-2 keys, and the second public key was obviously invalid, would the tx still be possible to redeem with the first key?
16:56 arubi ryan-c, invalid how? is it not a public key at all?
16:56 ryan-c arubi: not a public key at all, not even the right length
16:56 arubi one of two.. which of the keys is first, the valid one?
16:57 ryan-c yeah, the valid one is first
16:57 arubi I think that at least gives it more chance at being redeemable
16:58 ryan-c the specific script is
17:00 ryan-c OP_1 [33 byte compressed public key] [34 bytes arbitrary data] OP_2 OP_CHECKMULTISIG
17:01 arubi I think that makes the invalid key first
17:01 ryan-c i need the valid key first in the script
17:02 arubi at least that's how the stack will end up executing. still, a public key being neither compressed or uncompressed, it might still be valid but non-standard. I actually never tried
17:02 arubi well the key that ends up being pushed last is at the top of the stack
17:02 ryan-c I actually could do what i want with valid public key and a valid-looking one with no known private key
17:03 arubi sounds a lot cleaner and less "noisy" :)
17:03 ryan-c slightly less efficient
17:04 arubi how so?
17:04 ryan-c it's a vanity address generation method
17:04 ryan-c if you don't change the first 64 bytes of the script, you can partially hash it and reuse the midstate
17:05 ryan-c but with two compressed public keys you only have the last 3 bytes of the second key in the second hash block, so you have to generate a new first key every 16.7M iterations
17:05 arubi I see now :)
17:05 arubi well you could stick an OP_NOP in there
17:06 ryan-c wouldn't that cause redemption issues due to being nonstandard?
17:06 arubi that's also the case here for sure
17:06 ryan-c or is that not really an issue with p2sh
17:06 ryan-c well, with two compressed keys, you can't tell that the public key is arbitrary
17:06 ryan-c so it'd work
17:07 ryan-c if it were a compressed and an uncompressed, it could be detected that it's invalid
17:07 ryan-c but i don't know if that matters
17:07 arubi I think a regular op_nop (not with a number appended) should be okay
17:07 arubi but it's worth to check.. miners' policy is weird
17:07 ryan-c er, if the first "fixed" key is uncompressed there aren't issues
17:08 ryan-c but the script is longer and therefore slightly more expesnive to redeem
17:08 arubi right
17:10 ryan-c I suppose I could read the source for this
17:15 ryan-c clearly i should just try this on testnet
17:17 ryan-c ah, there is a CheckPubKeyEncoding step, which would abort script evaluation in valure
17:17 ryan-c failure
17:19 ryan-c but it doesn't look like public keys without signatures are validated
17:21 arubi right, but the checkmultisig doesn't know which one signature matches which of the two keys provided in the 1-of-2
17:22 arubi so it checks the first one on the stack first, and that should be the valid key
17:22 ryan-c the standard transaction thing only validates public keys as far as checking that they are between 33 and 65 bytes long inclusive
17:23 arubi oh is that between and not either or? huh.
17:24 arubi well SCRIPT_VERIFY_STRICTENC is checked too and bip66 is not in effect..
17:25 arubi er, s/not/now
17:25 ryan-c that's in standard.cpp
17:25 arubi might be related : https://github.com/bitcoin/bitcoin/issues/5939
17:26 arubi so, looks like it should still work.
17:26 ryan-c oh interesting
17:27 ryan-c but it looks like it'd be a lot safer just to do two compressed keys and update the first one when required
17:29 arubi yea, could be. I think a few dozen million keys/s is what current high end GPUs get with oclvanitygen
17:30 arubi I do think an op_nop between the two pubkeys should be ok though.. interesting.
17:31 arubi I guess that still wouldn't help though now re-thinking.. you do need arbitrary data