1 2017-12-05 00:10:10 <deego> can you/how do you rescan without having to restart the client?
  2 2017-12-05 00:10:33 <deego> (I don't see a rescan option in bitcoin-cli help)
  3 2017-12-05 00:12:00 <gevs> oh my god i think i found the keys
  4 2017-12-05 00:12:55 <gevs> for each cosigner mnemonic => bip39 seed => bip32 hd key => derive m/44'/0'/0'/0/2 and now i have the 3 public keys that you meant earlier
  5 2017-12-05 00:20:10 <gevs> arubi: gevs, that is the exact redeemscript : 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae
  6 2017-12-05 00:20:10 <gevs> <arubi> it's a 2-of-3 with pubkeys 02109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2 0318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8 0350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f303
  7 2017-12-05 00:20:54 <gevs> never mind my bad
  8 2017-12-05 00:24:54 <gevs> aoutch - i was exactly where i have to be ^^ except that the bitcoin-php wrapper that i use may not accept non-standard transaction im creating lol
  9 2017-12-05 00:26:00 <gevs> i just found out, when i try to *sign only* the raw transaction payload provided by shmali in the btt thread - i come back to an error i have had before, the library cant sign my OP_RETURN output and it says "scriptPubKey not supported"
 10 2017-12-05 01:10:53 <tyranny> what c++ toolkit to use for implementing thin wallet (lightweight)  for my pet project? libbitcoin is for full node, as far as  understood
 11 2017-12-05 01:17:05 <cncr04s> we don't need a pet app running over bitcoin, already have enough transactions
 12 2017-12-05 01:27:45 <mlz> lol
 13 2017-12-05 01:28:34 <tyranny> cncr04s: it will use test net, that's why it's toy educational project
 14 2017-12-05 01:29:26 <mlz> he thinks you're going to run many dumb kitties over bitcoin :D
 15 2017-12-05 01:31:49 <tyranny> mlz: not answered the question though /sigh
 16 2017-12-05 01:32:18 <mlz> i have no clue, wait for the geeks to wake up
 17 2017-12-05 01:33:01 <tyranny> mlz: i mean the other dude, not you ;)
 18 2017-12-05 01:33:19 <mlz> oh sorry lol
 19 2017-12-05 01:33:59 <gevs> OH
 20 2017-12-05 01:34:02 <gevs> MY GOODNESS
 21 2017-12-05 01:34:49 <gevs> 0 => 'OP_HASH160 666e5e7041cd7a9df7075d2f3fc79b6d53df7963 OP_EQUAL',
 22 2017-12-05 01:35:30 <gevs> i reproduced the hell of a hash  :D noiicceee awesome help here arubi !! thank you very much
 23 2017-12-05 01:39:52 <gevs> elligius wont broadcast my transaction and smartbit pushtx tells me "Missing inputs"
 24 2017-12-05 01:40:09 <gevs> but my signing part is definitely right now. so very much thanks :+1:
 25 2017-12-05 01:56:43 <gevs> uho ok i may have done wrong sending some money of this account earlier haha - my input contains 200000 satoshis but i have spent some, so im going to add a new input (i think im geting this right, lets hope im back here with a big smile in an hour or so :P)
 26 2017-12-05 02:29:09 <gevs> ok that input has a different hash though
 27 2017-12-05 02:29:33 <gevs> (im forced to use a different input than the one we have been trying to use... because earlier i sent money out of that address ^^)
 28 2017-12-05 02:30:04 <gevs> GET
 29 2017-12-05 02:30:04 <gevs> so - now the hash im trying to reproduce is vout=1 in : https://api.smartbit.com.au/v1/blockchain/tx/517a0ad4bf4cc423ce578f043a13e98d405902c08b1bfcac92b199ba3fd2cc39
 30 2017-12-05 03:58:11 <gevs> i figured my inputs are fine now since i reproduce the 666 hash in there. working out how my signed transaction must be exactly still.
 31 2017-12-05 04:39:31 <jb55> has anyone made any blockchain parsers that compile and are actively maintained? I want to do some basic analysis on blocks/txs and RPC is pretty slow for that
 32 2017-12-05 05:08:21 <eck> for the rpc messages or what?
 33 2017-12-05 05:26:02 <jb55> just the whole round trip between http -> blocks -> json, would rather access them directly.
 34 2017-12-05 05:26:41 <jb55> to do stuff like output every single distinct script in the blockchain, etc. very quickly.
 35 2017-12-05 05:44:36 <fishtop> jb55: have you given a go at writing your own? it's a pretty quick process tog et one up and running
 36 2017-12-05 05:45:28 <jb55> fishtop: I will if there isn't one readily available
 37 2017-12-05 05:47:34 <fishtop> have you looked at john ratcliff's?
 38 2017-12-05 05:47:49 <jb55> fishtop: yeah but it looks windows specific
 39 2017-12-05 05:48:10 <jb55> I guess I could try fixing it. maybe it's worth writing my own for learning purposes 🤔
 40 2017-12-05 05:48:36 <fishtop> it's a good exercise to write your own. he has a great post about parsing the blockchain here http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html
 41 2017-12-05 05:49:16 <jb55> ohh I remember there was a site that visualized the block format...
 42 2017-12-05 05:59:53 <jb55> fishtop: this works too, thx!
 43 2017-12-05 06:00:30 <jb55> but has the format changed since then...
 44 2017-12-05 06:00:46 <jb55> looks simple enough
 45 2017-12-05 10:09:24 <MrBar> why best hash always exists? it mathematically proven?
 46 2017-12-05 10:09:43 <MrBar> what if at some point it just not exist?
 47 2017-12-05 11:12:46 <Sentineo> MrBar: there is no such thing as best hash
 48 2017-12-05 11:13:05 <Sentineo> MrBar: there is a hash that is valid according to consensus
 49 2017-12-05 11:13:23 <Sentineo> and there is way to tell which one has more "work" in case you need to compare them
 50 2017-12-05 11:13:41 <Sentineo> by more work you simply look at the odds of finding that hash, the smaller the odd the better the hash in comparison
 51 2017-12-05 11:14:14 <MrBar> but more zeros more good hash?
 52 2017-12-05 11:15:46 <Sentineo> if you compare 2 blocks one has 64 leading zeros in the hash, the other 66 the 64 wins in that comparison
 53 2017-12-05 11:16:10 <Sentineo> but that is not the way a fork is handled, the next block will tell and the cumulative work of the whole chain mined upon
 54 2017-12-05 11:21:33 <MrBar> someone who find better hash is win?
 55 2017-12-05 11:22:19 <Sentineo> lets bring this to #bitcoin, this is more a dev channel
 56 2017-12-05 11:24:33 <AndyS2> the cumulative work is calculated in a way that having many zeroes despite only needing a few does not increase the cumulative work above what was required, right?
 57 2017-12-05 11:25:51 <AndyS2> would be kind of bad if someone finds a nearly all zero hash and that'd be considered the longest chain now despite another chain being 2-3 blocks longer
 58 2017-12-05 11:30:41 <MrBar> there maybe some time to block ack
 59 2017-12-05 11:31:20 <MrBar> consensus time window?
 60 2017-12-05 11:32:20 <MrBar> at #bitcoin only stupid miners
 61 2017-12-05 11:43:35 <Sentineo> AndyS2: the work in a block is iirc 2^256/Target, and log2 of it. Now it is computed for every block and the node keeps that info so it can do the cumulative part
 62 2017-12-05 15:09:22 <AndyS2> Sentineo: thank you :)
 63 2017-12-05 15:44:32 <dansmith_btc> hi, i thought i saw somewhere there is an bitcoind option which allows to not verify the chain up to a certain block height. This is to speed up the initial download. Am I mistaken? is there any other option to achieve the same goal? I dont want to spend CPU cycles unnecessarily.
 64 2017-12-05 15:55:11 <instagibbs> dansmith_btc, "assumevalid" forgoes any signature checks until that blockhash, but still has to build the utxo set
 65 2017-12-05 15:55:30 <instagibbs> fastest possible is just importing blocks/chainstate from another machine, although that's completely trusted solution naturally
 66 2017-12-05 16:37:57 <MrBar> only two days needed to download and verify blockchain
 67 2017-12-05 17:12:41 <gevs> arubi, :( i changed input... and the newer input i use also specifies a new hash :( "665ea557807d7114aeee2f049d2a54b79e59a9e4", its not the 666 anymore, does it mean i have to reproduce that one instead of the 666 hash? because the 666 was maybe linked to that other input?
 68 2017-12-05 17:13:13 <gevs> because now i get error: RuntimeException : Redeem script fails to solve pay-to-script-hash      - which comes from the bitcoin php wrapper and seems to be clear about im failing to provide the right solution
 69 2017-12-05 17:13:56 <gevs> so, since now i am referring to input "VOut 1" in: https://api.smartbit.com.au/v1/blockchain/tx/517a0ad4bf4cc423ce578f043a13e98d405902c08b1bfcac92b199ba3fd2cc39
 70 2017-12-05 17:14:28 <gevs> im thinking now i need the 665 hash, please im so near to getting it all wrapped haha :) thanks for your great help up to here already :v
 71 2017-12-05 17:18:18 <gevs> this redeem script error happens when i try to sign the transaction now
 72 2017-12-05 17:21:21 <gevs> hold on i was passing the sign() method the outputscript of the P2sh. my bad.
 73 2017-12-05 17:27:23 <arubi> doesn't seem like there's a tether op_return in that transaction gevs ?
 74 2017-12-05 17:28:48 <arubi> I mean sure, you need to redeem a script with the hash160 of 665EA557807D7114AEEE2F049D2A54B79E59A9E4 now, but that's just a normal transaction since the tether aren't in the input at all right?
 75 2017-12-05 17:36:39 <gevs> yes
 76 2017-12-05 17:36:45 <gevs> the tether is *not* in there
 77 2017-12-05 17:36:56 <gevs> but thats what some other guy explained on the forum - doesnt need to be in the inputs
 78 2017-12-05 17:37:07 <gevs> because Omni doesnt work with inputs/outputs - its a state machine instead
 79 2017-12-05 17:37:24 <gevs> destination is:   the last output in the transaction which is not the sender
 80 2017-12-05 17:37:28 <gevs> oh
 81 2017-12-05 17:37:46 <gevs> >>>> sender is:   the first input in the transaction
 82 2017-12-05 17:37:56 <gevs> now the first input doesnt contain the tether - is that what you mean ?
 83 2017-12-05 17:38:02 <arubi> yep
 84 2017-12-05 17:38:31 <arubi> well, the input you're redeeming doesn't have a transaction with a tether output sent to it
 85 2017-12-05 17:38:42 <arubi> so not sure how omni tracks it
 86 2017-12-05 17:39:24 <gevs> ha you must be right though
 87 2017-12-05 17:40:00 <gevs> because that other guy from the forum was using another input, which has the address who owns tether
 88 2017-12-05 17:40:32 <gevs> adding the input with the tether back would solve this no?
 89 2017-12-05 17:40:37 <gevs> because i got signing right, i think it wouldnt hurt
 90 2017-12-05 17:47:53 <arubi> what was the path that you used for the keys eventually?
 91 2017-12-05 19:32:08 <gevs> arubi, m/44'/0'/0'/0/2
 92 2017-12-05 19:32:49 <gevs> sorry for the delay, i need a little sport in between hexadecimal numbers lol
 93 2017-12-05 19:32:57 <arubi> no worries at all
 94 2017-12-05 19:32:57 <gevs> *needed
 95 2017-12-05 19:33:02 <arubi> so that was the root for the rest of the signers?
 96 2017-12-05 19:33:05 <arubi> or just one of them?
 97 2017-12-05 19:33:36 <gevs> no, for each cosigner i have to derive the bip39 seed with m/44'/0'/0'/0/2 to have the right keys
 98 2017-12-05 19:33:40 <gevs> makes sense?
 99 2017-12-05 19:33:52 <arubi> ah, so three different seeds
100 2017-12-05 19:33:59 <gevs> yes 3 different mnemonics i input
101 2017-12-05 19:34:06 <arubi> cool, gtk
102 2017-12-05 19:34:59 <gevs> the forum post says: mandatory-script-verify-flag-failed    comes from missing signatures though and i have also seen that this error is replace by "64: scriptpubkey" whenever i add a OP_EQUAL to the OP_RETURN output..
103 2017-12-05 19:35:10 <gevs> that thing with the OP_EQUAL might be a false guess of mine though
104 2017-12-05 19:35:18 <arubi> that's wrong
105 2017-12-05 19:36:19 <arubi> "64: scriptpubkey" -- probably entered it wrong, maybe invalid character, odd length
106 2017-12-05 19:36:53 <arubi> gevs, forget about the op return stuff for now
107 2017-12-05 19:36:53 <gevs> oh ok yeah then thats just because adding the OP_EQUAL, it fails validation of that output
108 2017-12-05 19:37:00 <gevs> exactly yep forgetting
109 2017-12-05 19:37:07 <arubi> it makes 0 difference for the validity of your signature
110 2017-12-05 19:37:45 <arubi> not sure why you're trying to shove the hash160 of the same redeemscript that you're spending with back into the op return, isn't that like sending to yourself?
111 2017-12-05 19:38:57 <arubi> which software validates your transaction that's returning these errors?
112 2017-12-05 19:39:00 <arubi> is it bitcoin core?
113 2017-12-05 19:39:25 <gevs> those errors actually happen on broadcast
114 2017-12-05 19:39:26 <gevs> https://www.smartbit.com.au/api
115 2017-12-05 19:39:31 <gevs> using the PUSHTX from that url ^
116 2017-12-05 19:39:47 <gevs> i integrated it in my script so that it automatically tries to broadcast when i tell it to
117 2017-12-05 19:40:23 <gevs> so they probably are relayed through a bitcoin core yes - but im a little unsure - i found smartbit API just because it has lots of APIs integrated.
118 2017-12-05 19:41:16 <gevs> > not sure why you're trying to shove the hash160 of the same redeemscript that you're spending with back into the op return, isn't that like sending to yourself?
119 2017-12-05 19:41:33 <gevs> not trying to do that - the redeemscript is meant only to sign the inputs if i am not mistaken
120 2017-12-05 19:42:40 <gevs> why do you think im doing this? maybe i missed some part :$
121 2017-12-05 19:42:49 <arubi> what's currently the transaction that you're trying to spend?
122 2017-12-05 19:42:54 <arubi> use pastebin pls :)
123 2017-12-05 19:44:19 <arubi> I'm wondering because you said "whenever i add a OP_EQUAL to the OP_RETURN output."
124 2017-12-05 19:44:41 <arubi> to me that makes absolutely no sense :)
125 2017-12-05 19:45:00 <achow101> why are you adding an OP_EQUAL to an OP_RETURN script?
126 2017-12-05 19:45:10 <achow101> such a script will be a non standard output script and be rejected
127 2017-12-05 19:45:11 <arubi> that's not what's happening.  I'm almost positive
128 2017-12-05 19:45:51 <gevs> you mean the payload ?
129 2017-12-05 19:46:17 <arubi> well, just the op return stuff will at least assure us that you're not trying crazy stuff :)
130 2017-12-05 19:46:27 <achow101> gevs: what output are you spending and what does the spending transaction look like?
131 2017-12-05 19:46:51 <gevs> oh wait
132 2017-12-05 19:46:54 <arubi> it's tether achow101, the log is long
133 2017-12-05 19:46:59 <gevs> adding op_equal to op_return was just a debug test xD
134 2017-12-05 19:47:04 <arubi> pfft
135 2017-12-05 19:47:14 <gevs> sending you guys a pastebin with the payload
136 2017-12-05 19:47:37 <arubi> whatever you pass to the "here sign this" function is the best
137 2017-12-05 19:47:39 <achow101> arubi: oh, I didn't see the scrollback went back super far
138 2017-12-05 19:48:16 <arubi> yea I'm pretty curious about how this plays out.  never interacted with tether
139 2017-12-05 19:48:32 <arubi> or copay, or that other .io that was mentioned :)
140 2017-12-05 19:48:38 <gevs> https://pastebin.com/KdE55H2i
141 2017-12-05 19:48:44 <gevs> so there is a payload in there
142 2017-12-05 19:48:51 <gevs> and the decoded version of it in JSON just underneath :)
143 2017-12-05 19:50:38 <arubi> lol
144 2017-12-05 19:50:53 <arubi> you're the same "wrong" again :)
145 2017-12-05 19:50:53 <gevs> so now im trying to spend input  517a0...  but it doesnt contain the address with tether
146 2017-12-05 19:50:58 <gevs> so i will add back the tether
147 2017-12-05 19:51:01 <arubi> using the wrong redeemscript
148 2017-12-05 19:51:05 <gevs> yes sorry didnt add the tether thingy input yet
149 2017-12-05 19:51:06 <gevs> oh
150 2017-12-05 19:51:26 <gevs> ah yes, you mean the one that doesnt specify having tether? or someting else?
151 2017-12-05 19:52:18 <arubi> you've set your tx to redeem an input sent to 3B2JEDkAB9nSnvAj7ehPRCY1s13APLKnnd, which has hash160 665EA557807D7114AEEE2F049D2A54B79E59A9E4, with the redeemscript for 3B2d4gAe51A6yEPG9qAxRfKxdVA1Zfpq9R which hash hash160 666E5E7041CD7A9DF7075D2F3FC79B6D53DF7963
152 2017-12-05 19:52:28 <gevs> ok
153 2017-12-05 19:52:32 <gevs> yes :) thats what i understood
154 2017-12-05 19:52:33 <arubi> 3B2d4gAe51A6yEPG9qAxRfKxdVA1Zfpq9R has thwe the tether, 3B2JEDkAB9nSnvAj7ehPRCY1s13APLKnnd, does not
155 2017-12-05 19:52:35 <gevs> cool im following now :D
156 2017-12-05 19:53:15 <arubi> what's in the op_return data?
157 2017-12-05 19:53:47 <arubi> tether you want to send to 1Ajqkh2foqMGLRAe9YkS7mwMgsAEiAx3aM ?
158 2017-12-05 19:54:33 <gevs> yes exactly
159 2017-12-05 19:54:57 <gevs> and the other output with 25000 is to make sure i control the fee (and have the rest sent to that address)
160 2017-12-05 19:55:12 <arubi> alright, can you add an input to your transaction?  specifically it's 9141346500a45fb588e2ee2908583d9d2b0484b1941dcb0e50fbf9bf1e4e5b51:1 , and it should be before the one that's already there
161 2017-12-05 19:55:31 <arubi> also, you need to move the redeemscript from the input it is at now to this one that you're adding
162 2017-12-05 19:55:38 <gevs> adding it
163 2017-12-05 19:55:44 <gevs> ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
164 2017-12-05 19:55:48 <gevs> THATS WHAT I DIDNT GET
165 2017-12-05 19:55:50 <gevs> gimme 2 min
166 2017-12-05 19:55:58 <arubi> gl :)
167 2017-12-05 19:56:57 <gevs> $transaction->spendOutpoint($secondInput, $outputScript);
168 2017-12-05 19:57:08 <gevs> secondInput being the NOT TETHER input
169 2017-12-05 19:57:20 <gevs> what outputscript should i use there then since it seems it shouldnt be the same?
170 2017-12-05 19:58:03 <gevs> never mind wait im leaving it blank for the first.
171 2017-12-05 20:00:25 <arubi> also gevs, don't use 4294967295 as the sequence number.  use 4294967293
172 2017-12-05 20:02:56 <arubi> the amounts in the outputs are also wrong.  you're losing a bunch of change.  is 143f5QPkc5mJurEr2kGPPoecJqkhvaQ2u2 your address ?
173 2017-12-05 20:13:02 <gevs> yes
174 2017-12-05 20:13:12 <gevs> well "my"... bittrex btc wallet
175 2017-12-05 20:13:19 <gevs> and the other bittrex tether wallet
176 2017-12-05 20:13:36 <gevs> out of disk storage on my laptop :'(( i cant use the omniwallet because i dont have enough space ..
177 2017-12-05 20:13:52 <gevs> <arubi> also gevs, don't use 4294967295 as the sequence number.  use 4294967293
178 2017-12-05 20:14:07 <gevs> i dont do this- must be the lib itself, where should i look in the inputs somewhere?
179 2017-12-05 20:14:39 <arubi> don't bother if it's not exposed to you.  it's just setting RBF, not a requirement
180 2017-12-05 20:15:27 <arubi> you'll have to send change from the second input to somewhere.  currently it all goes to fees which is bad
181 2017-12-05 20:15:52 <gevs> first input has 2700 Sat and second input 134382 Sat
182 2017-12-05 20:16:01 <gevs> i spend 27500 Sat
183 2017-12-05 20:16:18 <gevs> hui thats a happy miner isnt it
184 2017-12-05 20:16:48 <gevs> (this is not the *real* scenario, thats why i have been careless about those amounts. looking into those more precisely too)
185 2017-12-05 20:17:15 <gevs> no matter how bad that sounds - it was actually wanted xD
186 2017-12-05 20:17:32 <gevs> copay tells me "high fees needed" ... so i thought high fees needed. :)
187 2017-12-05 20:17:45 <arubi> hehe ok :)  weird
188 2017-12-05 20:18:17 <arubi> I mean, that copay message
189 2017-12-05 20:18:23 <gevs> ok back to it - im going to add the input correctly and give you a new payload when im done
190 2017-12-05 20:18:28 <arubi> cool
191 2017-12-05 20:18:32 <gevs> oh yeah the copay message is probably because they detect something weird
192 2017-12-05 20:19:34 <gevs> one thing arubi, the 2 inputs i will be producing will be different OP_HASH160 xxx values each right ?
193 2017-12-05 20:19:54 <gevs> because earlier when i simply added the input with my --input2="" argument (which i coded..) - it created a new input, with this exact same 666 hash.
194 2017-12-05 20:20:07 <gevs> but if i got you right, i must produce one input with 666 and one with 665
195 2017-12-05 20:20:27 <arubi> the input at 9141346500a45fb588e2ee2908583d9d2b0484b1941dcb0e50fbf9bf1e4e5b51:1 needs the 666.., the one currently encoded needs the 665..
196 2017-12-05 20:20:29 <gevs> respectively first input 666 - second input 665
197 2017-12-05 20:20:34 <arubi> yep :)
198 2017-12-05 20:21:12 <gevs> yep, bad i havent seen that 665 reproduced since im working on it :P might be a key i havent discovered yet haha probably something like 0/3 or so because it the next address, ill come back amazing answers thank you lots :)
199 2017-12-05 20:21:42 <arubi> oh, that's probably it
200 2017-12-05 20:22:54 <gevs> yeah but go tell that my script xD
201 2017-12-05 20:22:57 <gevs> didnt foresee this one
202 2017-12-05 20:23:19 <gevs> haha now my setupKeys() is all for the dump :P no im exagerating, but yes i think this might be it i will check it out :)
203 2017-12-05 20:23:39 <gevs> makes perfect sense now
204 2017-12-05 20:26:45 <arubi> you know bitcoin core can pretty much beat any tool at raw transaction stuff?  you can use the bitcoin-tx utility to easily set up everything.  just feed it the private keys you can already derive
205 2017-12-05 20:27:04 <arubi> or, if you can feed a raw transaction to copay, you don't even need the keys.  just set it all up from there
206 2017-12-05 20:27:11 <waxwing> arubi, any tool except `bc`
207 2017-12-05 20:27:31 <arubi> man my scripts would've been done with this by now :)
208 2017-12-05 20:31:26 <gevs> haha yeah, been learning so much at once that i found its best to keep the most in such command line i wrote myself
209 2017-12-05 20:31:36 <gevs> because at least i have some understanding of all this :)
210 2017-12-05 20:31:56 <gevs> i also waited about a good week before i posted a payload on the net :P trying to determine whether someone would hack my trransaction
211 2017-12-05 20:31:57 <gevs> haha
212 2017-12-05 20:32:09 <gevs> gotta feel respectful for all this knowledge :)
213 2017-12-05 20:35:55 <arubi> fwiw the txids are published on multiple boards by now (btctalk, se), now a publicly logged channel.  our debugging will live on forever :)
214 2017-12-05 22:03:50 <gevs> arubi,
215 2017-12-05 22:04:10 <arubi> ya
216 2017-12-05 22:04:19 <gevs> is it possible for you to do your magic trick to find out which pub keys are needed for the 665 hash? i didnt quite get how you found out the right thing to pass to your magic command line pipes :P
217 2017-12-05 22:04:34 <gevs> i have extended my code a little to allow multiple signing derivation paths
218 2017-12-05 22:04:47 <gevs> would like to see if im on the right way with the 0/3 thought now :)
219 2017-12-05 22:05:03 <gevs> echo -n 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae | xxd -r -p | sha256sum -b | xxd -r -p | openssl rmd160 -r
220 2017-12-05 22:05:06 <gevs> this magic trick
221 2017-12-05 22:05:12 <gevs> but for 665 if its somehow possible :?
222 2017-12-05 22:05:39 <arubi> I just got the redeemscript from the input at https://www.smartbit.com.au/tx/517a0ad4bf4cc423ce578f043a13e98d405902c08b1bfcac92b199ba3fd2cc39
223 2017-12-05 22:06:16 <arubi> you used one of the two inputs that were sent to 3B2d4gAe51A6yEPG9qAxRfKxdVA1Zfpq9R.  you can see that hex in the input
224 2017-12-05 22:06:50 <arubi> you did that spend using the copay wallet.  I just did `bitcoin-cli decodescript 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae`
225 2017-12-05 22:07:55 <arubi> if you were running bitcoin core, you could do `bitcoin-cli decodescript <that hex>` and see the pubkeys in prettyprint :)
226 2017-12-05 22:10:26 <arubi> they're right there encoded in hex.  522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae`
227 2017-12-05 22:11:09 <gevs> ah ok :) great
228 2017-12-05 22:12:12 <gevs> yeah
229 2017-12-05 22:12:53 <gevs> so looking at that: https://api.smartbit.com.au/v1/blockchain/tx/9141346500a45fb588e2ee2908583d9d2b0484b1941dcb0e50fbf9bf1e4e5b51
230 2017-12-05 22:13:05 <gevs> input n 1
231 2017-12-05 22:13:30 <gevs> and my second input is: https://api.smartbit.com.au/v1/blockchain/tx/517a0ad4bf4cc423ce578f043a13e98d405902c08b1bfcac92b199ba3fd2cc39
232 2017-12-05 22:20:17 <gevs> yep so that input from 517 is the one with the 665 hash
233 2017-12-05 22:20:21 <gevs> n 1
234 2017-12-05 22:21:00 <gevs> is the output 1 maybe another part of that asm?
235 2017-12-05 22:21:38 <gevs> ah wait :) we got this redeemscript because i created this transaction
236 2017-12-05 23:28:15 <eck> when calculating the new difficulty, is the new difficulty calculated on the last block of the previous period, or the first block in the new period?