Transcript for #bitcoin-dev 2017/12/05

00:10 deego can you/how do you rescan without having to restart the client?
00:10 deego (I don't see a rescan option in bitcoin-cli help)
00:12 gevs oh my god i think i found the keys
00:12 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
00:20 gevs arubi: gevs, that is the exact redeemscript : 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae
00:20 gevs <arubi> it's a 2-of-3 with pubkeys 02109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2 0318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8 0350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f303
00:20 gevs never mind my bad
00:24 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
00:26 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"
01:10 tyranny what c++ toolkit to use for implementing thin wallet (lightweight) for my pet project? libbitcoin is for full node, as far as understood
01:17 cncr04s we don't need a pet app running over bitcoin, already have enough transactions
01:27 mlz lol
01:28 tyranny cncr04s: it will use test net, that's why it's toy educational project
01:29 mlz he thinks you're going to run many dumb kitties over bitcoin :D
01:31 tyranny mlz: not answered the question though /sigh
01:32 mlz i have no clue, wait for the geeks to wake up
01:33 tyranny mlz: i mean the other dude, not you ;)
01:33 mlz oh sorry lol
01:33 gevs OH
01:34 gevs MY GOODNESS
01:34 gevs 0 => 'OP_HASH160 666e5e7041cd7a9df7075d2f3fc79b6d53df7963 OP_EQUAL',
01:35 gevs i reproduced the hell of a hash :D noiicceee awesome help here arubi !! thank you very much
01:39 gevs elligius wont broadcast my transaction and smartbit pushtx tells me "Missing inputs"
01:40 gevs but my signing part is definitely right now. so very much thanks :+1:
01:56 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)
02:29 gevs ok that input has a different hash though
02:29 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 ^^)
02:30 gevs so - now the hash im trying to reproduce is vout=1 in :
02:30 gevs GET
03:58 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.
04:39 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
05:08 eck for the rpc messages or what?
05:26 jb55 just the whole round trip between http -> blocks -> json, would rather access them directly.
05:26 jb55 to do stuff like output every single distinct script in the blockchain, etc. very quickly.
05:44 fishtop jb55: have you given a go at writing your own? it's a pretty quick process tog et one up and running
05:45 jb55 fishtop: I will if there isn't one readily available
05:47 fishtop have you looked at john ratcliff's?
05:47 jb55 fishtop: yeah but it looks windows specific
05:48 jb55 I guess I could try fixing it. maybe it's worth writing my own for learning purposes 🤔
05:48 fishtop it's a good exercise to write your own. he has a great post about parsing the blockchain here
05:49 jb55 ohh I remember there was a site that visualized the block format...
05:59 jb55 fishtop: this works too, thx!
06:00 jb55 but has the format changed since then...
06:00 jb55 looks simple enough
10:09 MrBar why best hash always exists? it mathematically proven?
10:09 MrBar what if at some point it just not exist?
11:12 Sentineo MrBar: there is no such thing as best hash
11:13 Sentineo MrBar: there is a hash that is valid according to consensus
11:13 Sentineo and there is way to tell which one has more "work" in case you need to compare them
11:13 Sentineo by more work you simply look at the odds of finding that hash, the smaller the odd the better the hash in comparison
11:14 MrBar but more zeros more good hash?
11:15 Sentineo if you compare 2 blocks one has 64 leading zeros in the hash, the other 66 the 64 wins in that comparison
11:16 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
11:21 MrBar someone who find better hash is win?
11:22 Sentineo lets bring this to #bitcoin, this is more a dev channel
11:24 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?
11:25 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
11:30 MrBar there maybe some time to block ack
11:31 MrBar consensus time window?
11:32 MrBar at #bitcoin only stupid miners
11:43 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
15:09 AndyS2 Sentineo: thank you :)
15:44 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.
15:55 instagibbs dansmith_btc, "assumevalid" forgoes any signature checks until that blockhash, but still has to build the utxo set
15:55 instagibbs fastest possible is just importing blocks/chainstate from another machine, although that's completely trusted solution naturally
16:37 MrBar only two days needed to download and verify blockchain
17:12 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?
17: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
17:13 gevs so, since now i am referring to input "VOut 1" in:
17:14 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
17:18 gevs this redeem script error happens when i try to sign the transaction now
17:21 gevs hold on i was passing the sign() method the outputscript of the P2sh. my bad.
17:27 arubi doesn't seem like there's a tether op_return in that transaction gevs ?
17:28 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?
17:36 gevs yes
17:36 gevs the tether is *not* in there
17:36 gevs but thats what some other guy explained on the forum - doesnt need to be in the inputs
17:37 gevs because Omni doesnt work with inputs/outputs - its a state machine instead
17:37 gevs destination is: the last output in the transaction which is not the sender
17:37 gevs oh
17:37 gevs >>>> sender is: the first input in the transaction
17:37 gevs now the first input doesnt contain the tether - is that what you mean ?
17:38 arubi yep
17:38 arubi well, the input you're redeeming doesn't have a transaction with a tether output sent to it
17:38 arubi so not sure how omni tracks it
17:39 gevs ha you must be right though
17:40 gevs because that other guy from the forum was using another input, which has the address who owns tether
17:40 gevs adding the input with the tether back would solve this no?
17:40 gevs because i got signing right, i think it wouldnt hurt
17:47 arubi what was the path that you used for the keys eventually?
19:32 gevs arubi, m/44'/0'/0'/0/2
19:32 gevs sorry for the delay, i need a little sport in between hexadecimal numbers lol
19:32 arubi no worries at all
19:32 gevs *needed
19:33 arubi so that was the root for the rest of the signers?
19:33 arubi or just one of them?
19:33 gevs no, for each cosigner i have to derive the bip39 seed with m/44'/0'/0'/0/2 to have the right keys
19:33 gevs makes sense?
19:33 arubi ah, so three different seeds
19:33 gevs yes 3 different mnemonics i input
19:34 arubi cool, gtk
19:34 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..
19:35 gevs that thing with the OP_EQUAL might be a false guess of mine though
19:35 arubi that's wrong
19:36 arubi "64: scriptpubkey" -- probably entered it wrong, maybe invalid character, odd length
19:36 arubi gevs, forget about the op return stuff for now
19:36 gevs oh ok yeah then thats just because adding the OP_EQUAL, it fails validation of that output
19:37 gevs exactly yep forgetting
19:37 arubi it makes 0 difference for the validity of your signature
19:37 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?
19:38 arubi which software validates your transaction that's returning these errors?
19:39 arubi is it bitcoin core?
19:39 gevs those errors actually happen on broadcast
19:39 gevs
19:39 gevs using the PUSHTX from that url ^
19:39 gevs i integrated it in my script so that it automatically tries to broadcast when i tell it to
19:40 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.
19:41 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?
19:41 gevs not trying to do that - the redeemscript is meant only to sign the inputs if i am not mistaken
19:42 gevs why do you think im doing this? maybe i missed some part :$
19:42 arubi what's currently the transaction that you're trying to spend?
19:42 arubi use pastebin pls :)
19:44 arubi I'm wondering because you said "whenever i add a OP_EQUAL to the OP_RETURN output."
19:44 arubi to me that makes absolutely no sense :)
19:45 achow101 why are you adding an OP_EQUAL to an OP_RETURN script?
19:45 achow101 such a script will be a non standard output script and be rejected
19:45 arubi that's not what's happening. I'm almost positive
19:45 gevs you mean the payload ?
19:46 arubi well, just the op return stuff will at least assure us that you're not trying crazy stuff :)
19:46 achow101 gevs: what output are you spending and what does the spending transaction look like?
19:46 gevs oh wait
19:46 arubi it's tether achow101, the log is long
19:46 gevs adding op_equal to op_return was just a debug test xD
19:47 arubi pfft
19:47 gevs sending you guys a pastebin with the payload
19:47 arubi whatever you pass to the "here sign this" function is the best
19:47 achow101 arubi: oh, I didn't see the scrollback went back super far
19:48 arubi yea I'm pretty curious about how this plays out. never interacted with tether
19:48 arubi or copay, or that other .io that was mentioned :)
19:48 gevs
19:48 gevs so there is a payload in there
19:48 gevs and the decoded version of it in JSON just underneath :)
19:50 arubi lol
19:50 gevs so now im trying to spend input 517a0... but it doesnt contain the address with tether
19:50 arubi you're the same "wrong" again :)
19:50 gevs so i will add back the tether
19:51 arubi using the wrong redeemscript
19:51 gevs yes sorry didnt add the tether thingy input yet
19:51 gevs oh
19:51 gevs ah yes, you mean the one that doesnt specify having tether? or someting else?
19:52 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
19:52 gevs ok
19:52 gevs yes :) thats what i understood
19:52 arubi 3B2d4gAe51A6yEPG9qAxRfKxdVA1Zfpq9R has thwe the tether, 3B2JEDkAB9nSnvAj7ehPRCY1s13APLKnnd, does not
19:52 gevs cool im following now :D
19:53 arubi what's in the op_return data?
19:53 arubi tether you want to send to 1Ajqkh2foqMGLRAe9YkS7mwMgsAEiAx3aM ?
19:54 gevs yes exactly
19:54 gevs and the other output with 25000 is to make sure i control the fee (and have the rest sent to that address)
19:55 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
19:55 arubi also, you need to move the redeemscript from the input it is at now to this one that you're adding
19:55 gevs adding it
19:55 gevs ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
19:55 gevs gimme 2 min
19:55 arubi gl :)
19:56 gevs $transaction->spendOutpoint($secondInput, $outputScript);
19:57 gevs secondInput being the NOT TETHER input
19:57 gevs what outputscript should i use there then since it seems it shouldnt be the same?
19:58 gevs never mind wait im leaving it blank for the first.
20:00 arubi also gevs, don't use 4294967295 as the sequence number. use 4294967293
20:02 arubi the amounts in the outputs are also wrong. you're losing a bunch of change. is 143f5QPkc5mJurEr2kGPPoecJqkhvaQ2u2 your address ?
20:13 gevs yes
20:13 gevs well "my"... bittrex btc wallet
20:13 gevs and the other bittrex tether wallet
20:13 gevs out of disk storage on my laptop :'(( i cant use the omniwallet because i dont have enough space ..
20:13 gevs <arubi> also gevs, don't use 4294967295 as the sequence number. use 4294967293
20:14 gevs i dont do this- must be the lib itself, where should i look in the inputs somewhere?
20:14 arubi don't bother if it's not exposed to you. it's just setting RBF, not a requirement
20:15 arubi you'll have to send change from the second input to somewhere. currently it all goes to fees which is bad
20:15 gevs first input has 2700 Sat and second input 134382 Sat
20:16 gevs i spend 27500 Sat
20:16 gevs hui thats a happy miner isnt it
20:16 gevs (this is not the *real* scenario, thats why i have been careless about those amounts. looking into those more precisely too)
20:17 gevs no matter how bad that sounds - it was actually wanted xD
20:17 gevs copay tells me "high fees needed" ... so i thought high fees needed. :)
20:17 arubi hehe ok :) weird
20:18 arubi I mean, that copay message
20:18 gevs ok back to it - im going to add the input correctly and give you a new payload when im done
20:18 arubi cool
20:18 gevs oh yeah the copay message is probably because they detect something weird
20:19 gevs one thing arubi, the 2 inputs i will be producing will be different OP_HASH160 xxx values each right ?
20:19 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.
20:20 gevs but if i got you right, i must produce one input with 666 and one with 665
20:20 arubi the input at 9141346500a45fb588e2ee2908583d9d2b0484b1941dcb0e50fbf9bf1e4e5b51:1 needs the 666.., the one currently encoded needs the 665..
20:20 gevs respectively first input 666 - second input 665
20:20 arubi yep :)
20:21 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 :)
20:21 arubi oh, that's probably it
20:22 gevs yeah but go tell that my script xD
20:22 gevs didnt foresee this one
20:23 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 :)
20:23 gevs makes perfect sense now
20:26 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
20:27 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
20:27 waxwing arubi, any tool except `bc`
20:27 arubi man my scripts would've been done with this by now :)
20:31 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
20:31 gevs because at least i have some understanding of all this :)
20:31 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
20:31 gevs haha
20:32 gevs gotta feel respectful for all this knowledge :)
20:35 arubi fwiw the txids are published on multiple boards by now (btctalk, se), now a publicly logged channel. our debugging will live on forever :)
22:03 gevs arubi,
22:04 arubi ya
22:04 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
22:04 gevs i have extended my code a little to allow multiple signing derivation paths
22:04 gevs would like to see if im on the right way with the 0/3 thought now :)
22:05 gevs echo -n 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae | xxd -r -p | sha256sum -b | xxd -r -p | openssl rmd160 -r
22:05 gevs this magic trick
22:05 gevs but for 665 if its somehow possible :?
22:05 arubi I just got the redeemscript from the input at
22:06 arubi you used one of the two inputs that were sent to 3B2d4gAe51A6yEPG9qAxRfKxdVA1Zfpq9R. you can see that hex in the input
22:06 arubi you did that spend using the copay wallet. I just did `bitcoin-cli decodescript 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae`
22:07 arubi if you were running bitcoin core, you could do `bitcoin-cli decodescript <that hex>` and see the pubkeys in prettyprint :)
22:10 arubi they're right there encoded in hex. 522102109c754588a5e6de512a68b0e82fa8ed6520f5fd57f6b41315e3d3c2b8f92ac2210318e0167d697e9366f17c2e83ac21c7e66ecc9427884d083887c8d3b6aa3857d8210350bc7cb1f4632c42ad092b1b825beea81ad4a663fa1c365c95d09ff44a11f30353ae`
22:11 gevs ah ok :) great
22:12 gevs yeah
22:12 gevs so looking at that:
22:13 gevs input n 1
22:13 gevs and my second input is:
22:20 gevs yep so that input from 517 is the one with the 665 hash
22:20 gevs n 1
22:21 gevs is the output 1 maybe another part of that asm?
22:21 gevs ah wait :) we got this redeemscript because i created this transaction
23:28 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?