1 2017-08-24 01:01:52 <meshcollider> ap4lmtree: mastering bitcoin is a pretty good book to get you started on the more technical side, it has a lot of code examples in python iirc
 2 2017-08-24 03:22:03 <ginseng> what is going on here? https://blockchain.info/block-height/481828
 3 2017-08-24 03:25:51 <ossifrage> ginseng, Antpool being dicks
 4 2017-08-24 03:29:03 <ginseng> won't they lose miners if they are intentionally ignoring transactions? seems like a costly form of protest to me
 5 2017-08-24 03:32:52 <ossifrage> ginseng, it could be ASICBOOST, or it could be a fuck you, hard to tell which, they do it quite often, especially when the fees in the mempool start to dwindle
 6 2017-08-24 03:35:09 <meshcollider> antpool has done it before, e.g. 481387
 7 2017-08-24 03:35:47 <ossifrage> Sometimes it is a natural side effect of there not being txns in the mempool and they find the next block right away
 8 2017-08-24 03:36:32 <ossifrage> Sometimes the pools will only take the highest paying txns and not generate a full block
 9 2017-08-24 04:01:40 <sictransitgloria> *salutations to all*
10 2017-08-24 12:07:09 <waxwing> is there such a thing as a "busy" return from an rpc call? i'm encountering a weird situation where calls to 'gettransaction' are failing on txids coming out of 'listtransactions' which i thought shouldn't be possible.
11 2017-08-24 12:07:23 <waxwing> i'll try to get a printout of what the error is, just asking in case anyone's got an idea
12 2017-08-24 15:10:04 <waxwing> hmm think i managed to reproduce it on regtest: JSON-RPC connection failed. Err:error(99, 'Cannot assign requested address')
13 2017-08-24 15:10:18 <waxwing> probably i just need to fix up my code so it doesn't make a ridiculous number of requests :)
14 2017-08-24 15:20:17 <coin_trader> am i doing something wrong there? or over thinking this?
15 2017-08-24 15:20:17 <coin_trader> how does core handle segwit addy in an HD wallet? (like, for recovery, or running the wallet on a second server) it doesn't seem to automatically "find" segwit addresses from the HD keypath, and second wallet can only "see" those segwit addy as "ismine=True" if you walk the HD keypath and do 'addwitnessaddress' to each and every one.... which is... painful to say the least...
16 2017-08-24 15:53:27 <wumpus> waxwing: it might be that it exceeded the RPC work queue depth. But that looks like a network-level error.
17 2017-08-24 15:56:27 <waxwing> wumpus: thanks; i'm guessing it's the former based on what i'm doing but useful info
18 2017-08-24 15:59:10 <wumpus> waxwing: do you open a new connection for every request?
19 2017-08-24 16:11:05 <esotericnonsense> has anyone created a caching layer for bitcoind rpc? mostly interested in read only commands. i haven't done much testing but it seems that rpc can easily block
20 2017-08-24 16:11:37 <esotericnonsense> getblockcount takes almost ten seconds to return for me during a reindex
21 2017-08-24 16:12:17 <esotericnonsense> obviously the cache timeout couldn't be too high, but if say you had multiple users, it'd be useful to say everyone in the same 1s gets the same response to certain types of rpc
22 2017-08-24 16:12:27 <esotericnonsense> timeout dependent on rpc command
23 2017-08-24 16:13:23 <esotericnonsense> i'm probably better served by bashing together my own thing using zmq subscriptions and a caching layer for blocks/headers or something
24 2017-08-24 16:34:28 <ossifrage> Is addwitnessaddress supposed to work in 0.14.2? I did a getnewaddress and then a adwitnessaddress <addr> and it failed with: "Public key or redeemscript not known to wallet, or the key is uncompressed (code -4)"
25 2017-08-24 16:35:48 <abpa> ossifrage did you use it with a new address you generated?
26 2017-08-24 16:36:04 <abpa> Maybe you need 0.15.0?
27 2017-08-24 16:37:28 <ossifrage> abpa, yeah. [Recently, I had to dump my keypool, so it came from akeypool data generated with 0.14.2]
28 2017-08-24 16:37:57 <abpa> try it with this https://bitcoin.org/bin/bitcoin-core-0.15.0/test.rc2/
29 2017-08-24 16:38:53 <ossifrage> abpa, yeah, I built 0.15.0rc2, but I haven't switched to it yet
30 2017-08-24 16:42:31 <GypsyScotty> i've heard you hvae to do raw txns to take adv of it in 0.14.2,,... not certain myself, but i also hear that is risky.
31 2017-08-24 16:43:20 <waxwing> wumpus: good question :) i just looked in the old jsonrpc.py code i'm using and yes .. which explains a lot :)
32 2017-08-24 16:48:02 <wumpus> hah!
33 2017-08-24 16:54:37 <abpa> wumpus is it only 0.15.0 that supports addwitnessaddress on mainnet?
34 2017-08-24 17:01:19 <ossifrage> I was trying to get 0.15.0 to compile with -flto, complete fail...
35 2017-08-24 17:01:49 <ossifrage> But this always warms my heart: ./libtool: line 1720:  9394 Segmentation fault      (core dumped) /usr/bin/gcc-ar cru .libs/libsecp256k1.a src/libsecp256k1_la-secp256k1.o
36 2017-08-24 17:07:43 <ossifrage> ./libtool: line 1720: 18481 Segmentation fault      (core dumped) /usr/bin/gcc-ranlib .libs/libsecp256k1.a
37 2017-08-24 17:27:14 <wumpus> abpa: 0.14 too AFAIK
38 2017-08-24 17:27:24 <abpa> ok thanks
39 2017-08-24 17:30:16 <esotericnonsense> hm
40 2017-08-24 17:35:31 <esotericnonsense> i'm trying to use zmqpubhashblock and it doesn't seem to be publishing anything. will it not function until i'm synced?
41 2017-08-24 17:35:47 <esotericnonsense> my expectation would have been that it publishes as UpdateTip in debug.log, as blocks are reindexed
42 2017-08-24 17:39:21 <wumpus> ossifrage: an error in ar/ranlib? whoa, that's an unlikely bug, did your build host maybe run out of memory?
43 2017-08-24 17:39:42 <wumpus> esotericnonsense: right, it will only function once your node is up to date
44 2017-08-24 17:39:51 <esotericnonsense> wumpus: ah. bah :P
45 2017-08-24 17:40:47 <wumpus> esotericnonsense: first line in CZMQNotificationInterface::UpdatedBlockTip
46 2017-08-24 17:40:57 <ossifrage> wumpus, it is related to -flto, if I use bintools ar/randlib it fails with a complaint about "plugin needed to handle lto object", google says use gcc-ar and gcc-ranlib, and they segfault
47 2017-08-24 17:41:12 <wumpus> you can comment that out and it will notify on all blocks, I've done so before to test
48 2017-08-24 17:41:47 <wumpus> ossifrage: it's certainly possible to build bitcoind using flto with some gcc versions, though the last news I've heard is that the sync was *slower* with that :/
49 2017-08-24 17:41:59 <esotericnonsense> wumpus: cheers, will have a go.
50 2017-08-24 17:43:39 <ossifrage> wumpus, yeah, it could be a distro issue... But the segfault is uncool
51 2017-08-24 18:02:02 <ossifrage> The segfault is unrelated to -flto, it just happens when I use gcc-ar/gcc-ranlib, but the binutils version is fine as long as I don't have -flto
52 2017-08-24 18:17:19 <esotericnonsense> 2017-08-24T18:17:04.422Z        000000000000000001a204c2b8eaea7e0c6815ad5377a86bb87978f5a41faaec
53 2017-08-24 18:17:21 <esotericnonsense> 2017-08-24T18:17:06.730Z        000000000000000002021883b5c936f4c8d77d04e7eeea618e1620aea021db9a
54 2017-08-24 18:17:23 <esotericnonsense> 2017-08-24T18:17:07.713Z        00000000000000000322a92aaa1c3646743123b229532c1664f9ec84a147146f
55 2017-08-24 18:17:26 <esotericnonsense> works :) cheers wumpus
56 2017-08-24 18:18:14 <wumpus> woohoo!
57 2017-08-24 18:18:59 <esotericnonsense> (my compilation time is very slow. :P)
58 2017-08-24 18:22:15 <esotericnonsense> this is terribly exciting. not sure why i waited so long to play with this :P
59 2017-08-24 18:41:54 <esotericnonsense> success. 1.79272 seconds per block (100 block average)
60 2017-08-24 18:42:41 <esotericnonsense> don't think i'm at the period of 'every block is 1MB' yet though
61 2017-08-24 20:26:23 <ossifrage> I switched to 0.15.0rc2 and I'm still getting that error on addwitnessaddress
62 2017-08-24 20:47:39 <esotericnonsense> 'preciousblock' is a very cute name for an rpc call
63 2017-08-24 21:57:50 <esotericnonsense> does anyone know the size of the current utxo set in total?
64 2017-08-24 22:12:59 <esotericnonsense> wumpus: did you benchmark the zmq stuff at all? i'm wondering if using zmqpubrawblock is going to slow down my reindex a lot
65 2017-08-24 22:13:23 <esotericnonsense> it seems likely that it would in the early stages but not when they're taking 5 seconds per block
66 2017-08-24 22:21:41 <esotericnonsense> seems to be not far off the same time per block, though i'm testing over a different set
67 2017-08-24 22:28:30 <esotericnonsense> The last 10 blocks took an average of 0.799 seconds each.
68 2017-08-24 22:28:58 <esotericnonsense> this is really weird. like i don't believe that there are periods of blocks that are just easier to verify. some weird interaction with what i happen to have in utxo cache?