1 2017-12-04 02:13:44 <eck> when doing the initial sync of block headers, am i supposed to query multiple peers for the same block hash to detect forks?
  2 2017-12-04 15:10:06 <denisx> 2017-12-04 13:27:08 connect() to [::84.251.161.205]:8333 failed: Network is unreachable (51)
  3 2017-12-04 15:10:13 <denisx> had this in my logfile, is this a bug?
  4 2017-12-04 15:10:25 <denisx> what is [::84.251.161.205]?
  5 2017-12-04 15:14:52 <mlz> denisx, it's an iP
  6 2017-12-04 15:15:15 <mlz> your node tried to connect to that IP and failed, nothing unusual and not a bug
  7 2017-12-04 15:15:24 <denisx> mlz: doesnt look like one, it is not ipv6 and it is not ipv4
  8 2017-12-04 15:16:11 <mlz> denisx, what do you think it is?
  9 2017-12-04 15:16:19 <denisx> a bug ;)
 10 2017-12-04 15:17:49 <denisx> ok, I looked it up, it is an ipv4 address mapped in ipv6
 11 2017-12-04 15:17:56 <denisx> not a bug ;)
 12 2017-12-04 15:19:13 <denisx> it is calld IPv6/IPv4 Address Embedding
 13 2017-12-04 15:19:21 <denisx> http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.htm
 14 2017-12-04 17:27:42 <BlueMatt> it'd be nice to move #11556 along....more than a month for a string change is...ugh
 15 2017-12-04 17:27:49 <BlueMatt> more review would help :)
 16 2017-12-04 17:49:44 <gevs> Hello people! I have been fighting to recover some USDT from a copay multisig and would like some insights from bitcoin network experts :) I am a total noob with Bitcoin, I have basic blockchain knowledge due to professional practice but am fighting with this topic because it includes: Bitcoin, OP_RETURN, Omni USDT & Copay multisig accounts. I have learned and read a lot about the subject, here is a link to the bitcoin stackexchange question I have
 17 2017-12-04 17:49:44 <gevs> posted which also links to more details on bitcointalk (quite a complicated topic to describe..). Any help is much appreciated, here is the link: https://bitcoin.stackexchange.com/questions/64105/bitcoin-protocol-op-return-omni-usdt-tether-copay-multisig-help  Thank you!
 18 2017-12-04 17:59:52 <arubi> so much links to follow, just show the unsigned transaction already :P
 19 2017-12-04 18:01:57 <arubi> "mandatory-script-verify-flag-failed" <- means that the script is not failing in the multisig part
 20 2017-12-04 18:02:11 <arubi> unless, what version of core are you running?
 21 2017-12-04 18:05:58 <gevs> oh hey :) that error i passed now :P but yes it was already giving me insurance about the mutlisig part
 22 2017-12-04 18:06:10 <gevs> now the error is "64: scriptpubkey"
 23 2017-12-04 18:06:23 <arubi> what's the signed tx hex then?
 24 2017-12-04 18:07:19 <gevs> 0100000002515b4e1ebff9fb500ecb1d94b184042b9d3d580829eee288b55fa4006534419101000000b500483045022100a4c41919ca7b9f5371f6dc90b8064defc03c89b6c938f04928cedcb60b1d6f4002207620c409448bfe88d78fb0ecb970c3986e01325b39b68460a94406c8f6b55797014c6951210247bcd2c9e1bf8bfc9e567c8f9c81ef5f2c5356e544ab7b9141b7ef93f272da9f2102771dbfd6b9e6183e893c07ea49cfc781d1836e42b6425ff2a59100cc2e9b11222102ab0456bde3a2a8f5066fa4827c8a00c9388e6da1fdc22f90c406d89112c8bacb53aeffffffffcb
 25 2017-12-04 18:07:19 <gevs> 0e9efba54a6acee3d8b09df2b9527ca05fb1c61b6f893ad5c8ee2cc4d6f54e00000000b500483045022100d7845a9e0e854d675451863027eefaa7b01d5ae87ee700c3b40012e2c94a30760220053e223dca51f234887226871cbbe94678913ab8b96c60edff8e454a2efc4876014c6951210247bcd2c9e1bf8bfc9e567c8f9c81ef5f2c5356e544ab7b9141b7ef93f272da9f2102771dbfd6b9e6183e893c07ea49cfc781d1836e42b6425ff2a59100cc2e9b11222102ab0456bde3a2a8f5066fa4827c8a00c9388e6da1fdc22f90c406d89112c8bacb53aeffffffff03000000000000
 26 2017-12-04 18:07:20 <gevs> 0000176a146f6d6e69000000000000001f000000002faf080087c4090000000000001976a914f40da014c137ad88006608834887556944e2dfeb88acf0490200000000001976a9142168fe52d8c1cbc656a544859c4193dd4b92e23788ac00000000
 27 2017-12-04 18:08:31 <arubi> alright let's see
 28 2017-12-04 18:08:38 <gevs> great thanks
 29 2017-12-04 18:08:50 <gevs> so let me explain real quick - if you import it through any API - you will see currently there is 3 outputs
 30 2017-12-04 18:09:24 <gevs> thats because i was unsure about how OMNI tells the "destination" - it seems "new protocol" uses the *first VIN* - while the old protocol used to *tell the largest input by sum* to know the destination
 31 2017-12-04 18:10:59 <gevs> the first output is the OP_RETURN with omni payload, the second output is the one im talking about 0.00002500 (dust BTC for omni destination) - the third output is a BTC output with which i make sure that at least 0.00050000 is used as the fee (because in the input linked, there is ~0.002)
 32 2017-12-04 18:11:43 <gevs> second output can be skipped, without it i also get a 64:scriptpubkey error :) greg over :P
 33 2017-12-04 18:16:18 <arubi> the redeemscript doesn't match the addresses
 34 2017-12-04 18:16:47 <arubi> so it fails at the p2sh stage, way before the multisig is even executed, so maybe hold off on setting up the outputs for now :)
 35 2017-12-04 18:17:24 <arubi> you got the redeemscript for hash D7FB889271798A9244F47320AEC28B926A2BB7A4, but you want one with hash 666E5E7041CD7A9DF7075D2F3FC79B6D53DF7963
 36 2017-12-04 18:17:47 <Sentineo> does not sound good :)
 37 2017-12-04 18:18:09 <arubi> maybe just wrong ordering of the pubkeys :)
 38 2017-12-04 18:18:54 <gevs> ha
 39 2017-12-04 18:19:03 <gevs> i was sure it was this 666 hash at the beginning
 40 2017-12-04 18:19:17 <gevs> but then my hd-from-xpubs tool gave me exactly that redeemScript and i thought i must be on the right way
 41 2017-12-04 18:19:50 <gevs> ordering of keys i tried a lot of different orders (lexicographically ordered as mentionen in the scriptPubKey preferred)
 42 2017-12-04 18:19:59 <gevs> also tried with 2 and 3 keys but cant come on that 666 hash
 43 2017-12-04 18:20:14 <gevs> when you say it fails at the p2sh stage - maybe im building my outpoint incorrectly?
 44 2017-12-04 18:20:23 <arubi> no, you have the wrong redeemscript
 45 2017-12-04 18:20:33 <arubi> the "HASH160 <scripthash> EQUAL" fails
 46 2017-12-04 18:20:55 <arubi> it's... not EQUAL :)  false is left on stack, and you script evaluates to false
 47 2017-12-04 18:21:55 <gevs> ok it fails because i have d7fb instead of 666 in my produced hash
 48 2017-12-04 18:23:13 <arubi> the condition to spend the input is to first provide a redeemscript that hashes to 666..., then when executed leaves a value "true" on the stack
 49 2017-12-04 18:24:51 <arubi> so if that's some copay multisig, you need to find the pubkeys that were used, then trying out some 1-of-n or 2-of-n is simple
 50 2017-12-04 18:26:21 <gevs> yes i have those keys
 51 2017-12-04 18:26:35 <gevs> with certainty because i  can also reproduce the right XPUB with the said derivation path
 52 2017-12-04 18:26:49 <gevs> (the XPUBs displayed for the 3 cosigners, in the copay app wallet information page)
 53 2017-12-04 18:27:16 <arubi> well, maybe the script also has some timelocks set in it
 54 2017-12-04 18:27:29 <arubi> like CLTV or CSV.  you need the complete redeemscript
 55 2017-12-04 18:27:56 <gevs> wouldnt that appear when you check the input of the transaction : 9141346500a45fb588e2ee2908583d9d2b0484b1941dcb0e50fbf9bf1e4e5b51
 56 2017-12-04 18:28:05 <arubi> no, it's in the redeemscript :)
 57 2017-12-04 18:28:12 <gevs> ah ok its in the 666
 58 2017-12-04 18:28:14 <gevs> got it
 59 2017-12-04 18:28:31 <arubi> that too, in some metaphysical sense
 60 2017-12-04 18:28:43 <arubi> it's encoded in the redeemscript.  the 666... part is its hash
 61 2017-12-04 18:28:52 <gevs> yep of course
 62 2017-12-04 18:29:38 <gevs> how can i know about that :')
 63 2017-12-04 18:29:46 <gevs> copay does not mention something like this
 64 2017-12-04 18:29:56 <Sentineo> well you need to know the redeemscript :)
 65 2017-12-04 18:30:06 <gevs> and from the code i have seen in their *minified* (brr) copay recovery tool, they just use the same derivation path as me
 66 2017-12-04 18:30:09 <gevs> m/44'/0
 67 2017-12-04 18:30:12 <Sentineo> to claim it, but not sure what you guys are doing, it is omni for me :D
 68 2017-12-04 18:30:22 <gevs> oups *m/44'/0'/0'/
 69 2017-12-04 18:32:14 <gevs> Sentineo, im trying to extract usdt from a copay multisig
 70 2017-12-04 18:32:30 <arubi> gevs, if you have access to the same wallet with these xpubs in it, you can try to send coins back to yourself and look at that redeemscriot
 71 2017-12-04 18:32:40 <Sentineo> yeah that I understood, but never played with that omni thing
 72 2017-12-04 18:32:41 <arubi> it'll show the structure at least, and you could just replace the pubkeys
 73 2017-12-04 18:32:43 <gevs> so it is omni yes - browsing some repositories i found how the omni payload is created (in several parts)
 74 2017-12-04 18:32:51 <gevs> ah ok :)
 75 2017-12-04 18:33:08 <Sentineo> wow arubi that is a really neat one!
 76 2017-12-04 18:33:27 <gevs> wait what - with what client?
 77 2017-12-04 18:33:53 <arubi> if only these services would offer testnet :)  gevs the one normally used to spend those copay funds?
 78 2017-12-04 18:33:57 <gevs> i have access to the 3 cosigners
 79 2017-12-04 18:34:11 <arubi> do you have examples of past transactions?
 80 2017-12-04 18:34:12 <arubi> (brb)
 81 2017-12-04 18:34:14 <Sentineo> what he is suggesting you do a similar tx as you are trying to craft
 82 2017-12-04 18:34:18 <gevs> ha, im guessing its something like an exchange ^^
 83 2017-12-04 18:34:42 <Sentineo> if you show him a similar tx (as this one) he can help you with the redeemscript format
 84 2017-12-04 18:34:46 <gevs> the Omniwallet probably wont let people send money on a copay wallet - yet unsure here too
 85 2017-12-04 18:35:43 <gevs> arubi, i dont have any other previous transaction - i did this 8 USDT transaction myself
 86 2017-12-04 18:35:53 <gevs> i reproduced what my customer asked me :)
 87 2017-12-04 18:36:23 <gevs> he sent tether on a copay multisig - then i reproduced this by sending 8 USDT myself - on a copay multisig with a little btc for the fee - which then locks those USDT in the copay multisig
 88 2017-12-04 18:38:13 <gevs> ok but i totally get the principle
 89 2017-12-04 18:39:15 <arubi> welp, it's either some timelock additions to the script, one of the keys is wrong, missing, or encoded differently (uncompressed?)
 90 2017-12-04 18:39:24 <gevs> the money was sent from changelly so sadly i dont have the client code here :/
 91 2017-12-04 18:39:45 <gevs> oh hell i was sure i would hurt on compressed/uncompressed after all the time i read about it haha
 92 2017-12-04 18:40:02 <gevs> will do some more testing about the keys as it seems its where the problem originates
 93 2017-12-04 18:40:40 <arubi> I can't imagine anybody uses uncompressed keys now.  it's probably that their service uses timelocks so in case they disappear, you can still redeem the funds
 94 2017-12-04 18:41:24 <arubi> gevs, did you see this?  https://github.com/bitpay/copay/issues/6329
 95 2017-12-04 18:41:24 <gevs> ok - i will need to read about timelocks too, havent had that one on my documents yet
 96 2017-12-04 18:41:35 <arubi> taking back my comment about not using uncompressed stuff :)
 97 2017-12-04 18:43:44 <gevs> thanks for the link checking this
 98 2017-12-04 18:47:38 <gevs> i havent seen this but i have learned it from the code :D
 99 2017-12-04 18:48:16 <gevs> in copay the bip32 XPUB is derived at m/44'/0'/0' and cosigners are then xpub/0/1 xpub/0/2 and xpub/0/3
100 2017-12-04 18:49:16 <gevs> but i didnt get the redeem scripts reading method, great checking out :)
101 2017-12-04 18:50:22 <arubi> <gevs> in copay the bip32 XPUB is derived at m/44'/0'/0'...
102 2017-12-04 18:50:32 <gevs> i see following ASM: 30450221008dad53ca84070e9328f7a1a33eecd490258958f10d1a1dccf5709af8cad1339002205d45b357727021f57075b4db9f309d266dd0ee90112b6df6e11a6a162a27efa001 04fcf07bb1222f7925f2b7cc15183a40443c578e62ea17100aa3b44ba66905c95d4980aec4cd2f6eb426d1b1ec45d76724f26901099416b9265b76ba67c8b0b73d
103 2017-12-04 18:50:34 <arubi> makes no sense.  this is a hardened derivation notation
104 2017-12-04 18:50:50 <arubi> or, they mean m/44'/0'/0'/... ?
105 2017-12-04 18:50:56 <gevs> ok enlighten me because i really thought im ok with key derivation now
106 2017-12-04 18:51:04 <gevs> yes
107 2017-12-04 18:51:13 <arubi> that's an uncompressed key, where is that from?
108 2017-12-04 18:51:24 <gevs> xpub/    is basically an alias for "m/44'/0'/0'"
109 2017-12-04 18:51:37 <arubi> the last "/" is important
110 2017-12-04 18:51:51 <arubi> (for the previous line)  I see what you mean now :)
111 2017-12-04 18:52:00 <arubi> where's the signature from?
112 2017-12-04 18:52:03 <gevs> this uncompressed ASM comes from the inputs of the transaction: https://api.smartbit.com.au/v1/blockchain/tx/9141346500a45fb588e2ee2908583d9d2b0484b1941dcb0e50fbf9bf1e4e5b51
113 2017-12-04 18:52:37 <gevs> this transaction's outputs is where the USDT to 3B2d4... are
114 2017-12-04 18:52:42 <arubi> but that's just some address paying.  that's the previous output being redeemed
115 2017-12-04 18:52:57 <gevs> and with omniwallet.com or .org im able to see those 8 USDT then on the address with all corresponding properties
116 2017-12-04 18:52:59 <arubi> it's unrelated to what you're trying to spend, unless you used that key in there
117 2017-12-04 18:53:14 <gevs> ah ok gotcha
118 2017-12-04 18:54:09 <gevs> i can send one transaction with copay now
119 2017-12-04 18:54:13 <gevs> just sending a few btc
120 2017-12-04 18:54:19 <gevs> this will help right?
121 2017-12-04 18:56:19 <arubi> yep
122 2017-12-04 18:59:31 <gevs> https://blockchain.info/tx/517a0ad4bf4cc423ce578f043a13e98d405902c08b1bfcac92b199ba3fd2cc39?show_adv=true
123 2017-12-04 19:00:59 <gevs> ok so what you are saying - now i should try to rebuild this transaction i just made ? because i kind of know the content?
124 2017-12-04 19:02:43 <arubi> gevs, that is the exact redeemscript : 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae
125 2017-12-04 19:03:15 <arubi> it's a 2-of-3 with pubkeys 02109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2 0318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8 0350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f303
126 2017-12-04 19:03:37 <arubi> all are different from what you had in mind :)
127 2017-12-04 19:05:56 <gevs> oh no dont worry i tried the 2 of 3 first :D
128 2017-12-04 19:06:03 <gevs> because thats what copay says on the app too :P
129 2017-12-04 19:06:55 <arubi> not what I mean.  your redeemscript uses 0247bcd2c9e1bf8bfc9e567c8f9c81ef5f2c5356e544ab7b9141b7ef93f272da9f 02771dbfd6b9e6183e893c07ea49cfc781d1836e42b6425ff2a59100cc2e9b1122 02ab0456bde3a2a8f5066fa4827c8a00c9388e6da1fdc22f90c406d89112c8bacb
130 2017-12-04 19:07:00 <arubi> which are three different keys
131 2017-12-04 19:11:14 <gevs> but yep exactly
132 2017-12-04 19:11:35 <arubi> so, you can derive them in your software?
133 2017-12-04 19:11:40 <gevs> yes :)
134 2017-12-04 19:11:45 <arubi> sweet :)
135 2017-12-04 19:11:48 <gevs> thats what gave me the first insurance about the multisig part
136 2017-12-04 19:12:21 <arubi> so what was the error?  what made it derive the wrong keys at first?
137 2017-12-04 19:12:41 <gevs> wait wait
138 2017-12-04 19:12:51 <gevs> that is the set of keys that i have been using since the beginning
139 2017-12-04 19:13:09 <gevs> i havent tried to reproduce that transaction with my code now.
140 2017-12-04 19:13:33 <gevs> my commands should derive exactly those keys, and order them lexicographically as its done in your message
141 2017-12-04 19:13:53 <arubi> are you not seeing that these are two different sets of keys?
142 2017-12-04 19:14:32 <arubi> the signed transaction that you provided uses the wrong set.  the set you need to use is the one from the 517a0ad.. tx
143 2017-12-04 19:22:01 <gevs> oh man im sorry
144 2017-12-04 19:22:20 <arubi> no worries :)
145 2017-12-04 19:22:32 <gevs> i didnt read the second message with "not what I meant" - and when i referred back to the keys, i saw those, which are the three im using for my cosigning
146 2017-12-04 19:22:43 <gevs> damn ok- great :)
147 2017-12-04 19:23:22 <gevs> will check a few details and come back if i have issues after finding those keys!
148 2017-12-04 19:24:31 <arubi> alright
149 2017-12-04 19:31:35 <gevs> thank you a lot i was somehow sure about the keys im using :/ because out of the xpubs from copay, it would show me that same list of public keys, for the redeem script i have been producing.
150 2017-12-04 19:32:33 <gevs> its hard to explain, lots of inputs with different paths, different xpub/xpriv to derive, etc.. hope it'll get me a little further, I do like the fact that it seems to be a key problem because i should be able to solve it.
151 2017-12-04 19:32:34 <arubi> I was guessing it's some kind of path issue
152 2017-12-04 19:33:39 <arubi> gevs, I'm guessing the exported pubkeys copay gives you are at the edge of the hardened path
153 2017-12-04 19:33:51 <arubi> so probably the last 0'
154 2017-12-04 19:34:12 <arubi> then you start deriving public keys from that point on.  is that what you're doing?
155 2017-12-04 19:35:39 <arubi> and then if the xpub is at 0', then 0'/0/1 is the first master xpub for signer 1, 0'/0/2 master xpub for signer 2, and so on
156 2017-12-04 19:36:02 <arubi> and you treat these master xpubs as the "new" root for whatever path for a specific set
157 2017-12-04 19:40:18 <gevs> 1) i do a bip39 seed derivation of the mnemonic  - based on the hexadecimal representation of this i create a bip32 HD key
158 2017-12-04 19:41:11 <gevs> 2) out of this hd key i derive the path m/44'/0'/0'    which is the XPUB path (keep in mind i do this for each cosigner, with each mnemonic)
159 2017-12-04 19:41:26 <gevs> ha
160 2017-12-04 19:42:01 <gevs> 3) is where its wrong i think :D im not deriving further xpub/0/0 for example which would make an absolute derivation path of m/44'/0'/0'/0/0
161 2017-12-04 19:42:13 <arubi> indeed :)
162 2017-12-04 19:42:16 <gevs> i see this just now so i might get back to the code thank you for the support here
163 2017-12-04 19:42:35 <arubi> cheers, let us know.  little docs with copay and this is valuable info
164 2017-12-04 19:45:23 <gevs> yep will do and the code is on github for people who are ok with laravel for CLI :P it was the fastest i could think of as i use it daily :)
165 2017-12-04 19:49:37 <arubi> gevs, you don't have to tell me.  I have these things written in gnu bc and bash
166 2017-12-04 19:50:34 <gevs> haha xD im glad i passed the paranoia step and kind of know which data im allowed to post in here and stuff :P
167 2017-12-04 19:51:26 <arubi> hehe, kinda tempted to open a mock copay wallet just to figure out the paths, but I need to have dinner first :)
168 2017-12-04 19:54:46 <gevs> im pretty sure about my paths haha - with the multiple commands i have written i am able to check starting from XPUB which address it will give, and also which redeemScript and scriptPubLKey - and then with the wallet:derive command i can get the private keys for the said paths
169 2017-12-04 19:55:29 <gevs> kind of made me learn *a whole bunch* haha because i come from a less cryptographic blockchain :P im not here to advertize easiness of integration or whatever, i knew what i was getting into and im overly glad to learn so much about the awesome script abilities :)
170 2017-12-04 19:58:36 <arubi> hopefully you'll defect.  bitcoin is so much more fun than op_return ;)
171 2017-12-04 20:25:04 <gevs> arubi, next time, dont ask for me to *defect* pff
172 2017-12-04 20:25:17 <gevs> ill *detect* the right keys, yes :P and come back haha
173 2017-12-04 20:25:38 <arubi> good luck :)
174 2017-12-04 20:34:31 <gevs> one little thing though- related to OP_RETURN
175 2017-12-04 20:34:56 <gevs> i am able to read integers out of it - but im guessing there must be some kind of charset to be encoded to too no?
176 2017-12-04 20:35:41 <eck> there's no specified encoding, it's binary
177 2017-12-04 20:35:53 <gevs> reading only integers, the only thing i could "read" out of it is that big endian signed + unsigned and little signed are all the same
178 2017-12-04 20:36:02 <gevs> but little endian unsigned is different from those 3
179 2017-12-04 20:36:20 <arubi> op_return is just an op code in a script.  generally, your script would be "op_return 0x<data size push> 0x<data>"
180 2017-12-04 20:36:31 <gevs> ah ok
181 2017-12-04 20:36:48 <gevs> yeah omni defines different parts of that <data size to push>
182 2017-12-04 20:37:02 <arubi> yea, I guess it's further encoded in the data part
183 2017-12-04 20:37:17 <arubi> not sure what tether does, I'm guessing it's a bunch of varints :)
184 2017-12-04 20:37:29 <gevs> 2 hexits Version, 2 hexits Type, 4 hexits property, 8 hexits value
185 2017-12-04 20:37:42 <arubi> ah, so nothing like that
186 2017-12-04 20:37:58 <arubi> seems simple enough to handle?
187 2017-12-04 20:38:11 <gevs> the value is *kind of* 8 000 000 00  which makes it possible to be the real value - but there its not exactly 800000000 so i dont think that integer converted value is exactly the transaction value.
188 2017-12-04 20:38:27 <arubi> what are you looking at?
189 2017-12-04 20:38:33 <gevs> yes - it got me to understand the principle - and understand that this payload does not store anything about destination xD
190 2017-12-04 20:40:11 <arubi> hexits, is that like "a 0-f character" ?
191 2017-12-04 20:40:38 <arubi> if it's just a bunch of data being pushed and it's small enough, then there are special push operations
192 2017-12-04 20:41:07 <arubi> [1,16] are [51,60]
193 2017-12-04 20:41:43 <arubi> it's weird, maybe they're not using standard script stuff at all.  I don't have an example to look at
194 2017-12-04 20:41:52 <arubi> anyway, dinner time :)
195 2017-12-04 20:45:41 <gevs> enjoy :)
196 2017-12-04 21:16:05 <laudiacay> hiya! I'm trying to do analysis on the entire blockchain and spending patterns. I've got my bitcoin-cli installed, what would be the fastest way to get all the addresses that have ever participated in any transaction?
197 2017-12-04 21:16:20 <laudiacay> i think just throwing them in a text file would probably be the best idea for now
198 2017-12-04 21:17:18 <eck> you would call getblock for each block hash, it will return you the next block hash as well as the raw transactions
199 2017-12-04 21:17:30 <eck> and then call gettransaction for each txn in each block
200 2017-12-04 21:17:43 <laudiacay> oh there's like an API?
201 2017-12-04 21:17:47 <laudiacay> where's the documentation?
202 2017-12-04 21:17:56 <eck> so you can use  bitcoin-cli itself, or there is a json rpc apik
203 2017-12-04 21:18:02 <eck> which might be easier for what you're doing
204 2017-12-04 21:18:10 <eck> bitcoin-cli help lists (most) of the api methods
205 2017-12-04 21:18:14 <laudiacay> augh json makes me sad
206 2017-12-04 21:18:44 <laudiacay> so it looks like i gotta connect first brb documentation binge
207 2017-12-04 21:18:51 <eck> you could probably whip something up with bash and jq for what you're doing, but it might be easier to use a real library like https://github.com/jgarzik/python-bitcoinrpc
208 2017-12-04 21:19:47 <eck> https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
209 2017-12-04 21:20:29 <laudiacay> w o a h this is good
210 2017-12-04 21:20:51 <achow101> eck: don't use that list, it's outdated. just use the help command
211 2017-12-04 21:21:09 <laudiacay> oh jeez this is so nice wow
212 2017-12-04 21:56:10 <gevs> arubi - *after dinner* - anything i should look out for if i want to find a timelock function in the copay code? copay uses the bitcore js implementation ; i should be able to find some things in there for my multisig key problem
213 2017-12-04 21:56:38 <gevs> tried a few key combinations and derivation paths but cant seems to find the 666 hash produced yet.
214 2017-12-04 21:56:41 <arubi> there are no time locks.  you're just missing the correct path
215 2017-12-04 21:56:56 <arubi> gevs, the preimage to that hash is exactly 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae
216 2017-12-04 21:56:57 <gevs> ah ok cool lol
217 2017-12-04 21:57:34 <arubi> try it out:
218 2017-12-04 21:57:35 <arubi> `echo -n 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae | xxd -r -p | sha256sum -b | xxd -r -p | openssl rmd160 -r`
219 2017-12-04 21:58:01 <gevs> neat
220 2017-12-04 22:14:15 <jb55> btcs now has string and data literals, automatically get compiled to minimal pushdata https://jb55.com/s/9a68a136ac0710fe.txt
221 2017-12-04 22:14:20 <jb55> :]
222 2017-12-04 22:28:08 <gevs> ha someone answered on BTT too ! with more insights about omni too :)
223 2017-12-04 22:28:46 <gevs> fixes my understanding of how receiver and sender are determined!