1 2017-04-14 01:08:49 <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
 2 2017-04-14 01:09:36 <conman> CompareTxIterByAncestorCount() suggests so
 3 2017-04-14 01:09:36 <conman> so in a getblocktemplate call, the dependent transactions will always be serialised after their ancestors
 4 2017-04-14 08:33:09 <`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?
 5 2017-04-14 08:36:15 <`mist> i'm thinking something like this but without having to import that JSONRPCException: https://thepasteb.in/p/76hElrBQnNOCV
 6 2017-04-14 09:08:12 <wumpus> `mist: I'm not entirely clear on what you're trying to do
 7 2017-04-14 09:08:49 <wumpus> you need to catch JSONRPCException *somewhere* to handle errors that come up, what is your difficulty with importing it?
 8 2017-04-14 09:09:26 <`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
 9 2017-04-14 09:09:32 <`mist> and handle the raise there, and then reraise
10 2017-04-14 09:09:45 <wumpus> ok, yes
11 2017-04-14 09:10:20 <`mist> like this  https://thepasteb.in/p/66hVzR4mqWNFW
12 2017-04-14 16:55:50 <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?
13 2017-04-14 16:56:09 <arubi> ryan-c, invalid how?  is it not a public key at all?
14 2017-04-14 16:56:23 <ryan-c> arubi: not a public key at all, not even the right length
15 2017-04-14 16:56:54 <arubi> one of two.. which of the keys is first, the valid one?
16 2017-04-14 16:57:04 <ryan-c> yeah, the valid one is first
17 2017-04-14 16:57:40 <arubi> I think that at least gives it more chance at being redeemable
18 2017-04-14 16:58:40 <ryan-c> the specific script is
19 2017-04-14 17:00:27 <ryan-c> OP_1 [33 byte compressed public key] [34 bytes arbitrary data] OP_2 OP_CHECKMULTISIG
20 2017-04-14 17:01:01 <arubi> I think that makes the invalid key first
21 2017-04-14 17:01:59 <ryan-c> i need the valid key first in the script
22 2017-04-14 17:02: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
23 2017-04-14 17:02:32 <arubi> well the key that ends up being pushed last is at the top of the stack
24 2017-04-14 17:02:51 <ryan-c> I actually could do what i want with valid public key and a valid-looking one with no known private key
25 2017-04-14 17:03:19 <arubi> sounds a lot cleaner and less "noisy" :)
26 2017-04-14 17:03:48 <ryan-c> slightly less efficient
27 2017-04-14 17:04:02 <arubi> how so?
28 2017-04-14 17:04:12 <ryan-c> it's a vanity address generation method
29 2017-04-14 17:04:58 <ryan-c> if you don't change the first 64 bytes of the script, you can partially hash it and reuse the midstate
30 2017-04-14 17:05:43 <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
31 2017-04-14 17:05:45 <arubi> I see now :)
32 2017-04-14 17:05:56 <arubi> well you could stick an OP_NOP in there
33 2017-04-14 17:06:17 <ryan-c> wouldn't that cause redemption issues due to being nonstandard?
34 2017-04-14 17:06:27 <arubi> that's also the case here for sure
35 2017-04-14 17:06:29 <ryan-c> or is that not really an issue with p2sh
36 2017-04-14 17:06:44 <ryan-c> well, with two compressed keys, you can't tell that the public key is arbitrary
37 2017-04-14 17:06:50 <ryan-c> so it'd work
38 2017-04-14 17:07:08 <ryan-c> if it were a compressed and an uncompressed, it could be detected that it's invalid
39 2017-04-14 17:07:26 <ryan-c> but i don't know if that matters
40 2017-04-14 17:07:35 <arubi> I think a regular op_nop (not with a number appended) should be okay
41 2017-04-14 17:07:50 <arubi> but it's worth to check..  miners' policy is weird
42 2017-04-14 17:07:59 <ryan-c> er, if the first "fixed" key is uncompressed there aren't issues
43 2017-04-14 17:08:11 <ryan-c> but the script is longer and therefore slightly more expesnive to redeem
44 2017-04-14 17:08:34 <arubi> right
45 2017-04-14 17:10:46 <ryan-c> I suppose I could read the source for this
46 2017-04-14 17:15:19 <ryan-c> clearly i should just try this on testnet
47 2017-04-14 17:17:37 <ryan-c> ah, there is a CheckPubKeyEncoding step, which would abort script evaluation in valure
48 2017-04-14 17:17:39 <ryan-c> failure
49 2017-04-14 17:19:00 <ryan-c> but it doesn't look like public keys without signatures are validated
50 2017-04-14 17:21:52 <arubi> right, but the checkmultisig doesn't know which one signature matches which of the two keys provided in the 1-of-2
51 2017-04-14 17:22:07 <arubi> so it checks the first one on the stack first, and that should be the valid key
52 2017-04-14 17:22:42 <ryan-c> the standard transaction thing only validates public keys as far as checking that they are between 33 and 65 bytes long inclusive
53 2017-04-14 17:23:27 <arubi> oh is that between and not either or?  huh.
54 2017-04-14 17:24:47 <arubi> well SCRIPT_VERIFY_STRICTENC is checked too and bip66 is not in effect..
55 2017-04-14 17:25:01 <arubi> er, s/not/now
56 2017-04-14 17:25:20 <ryan-c> that's in standard.cpp
57 2017-04-14 17:25:44 <arubi> might be related : https://github.com/bitcoin/bitcoin/issues/5939
58 2017-04-14 17:26:25 <arubi> so, looks like it should still work.
59 2017-04-14 17:26:25 <ryan-c> oh interesting
60 2017-04-14 17:27:11 <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
61 2017-04-14 17:29:21 <arubi> yea, could be.  I think a few dozen million keys/s is what current high end GPUs get with oclvanitygen
62 2017-04-14 17:30:41 <arubi> I do think an op_nop between the two pubkeys should be ok though.. interesting.
63 2017-04-14 17:31:26 <arubi> I guess that still wouldn't help though now re-thinking.. you do need arbitrary data