Transcript for #bitcoin-dev 2017/08/24

01:01 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
03:22 ginseng what is going on here? https://blockchain.info/block-height/481828
03:25 ossifrage ginseng, Antpool being dicks
03:29 ginseng won't they lose miners if they are intentionally ignoring transactions? seems like a costly form of protest to me
03:32 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
03:35 meshcollider antpool has done it before, e.g. 481387
03:35 ossifrage Sometimes it is a natural side effect of there not being txns in the mempool and they find the next block right away
03:36 ossifrage Sometimes the pools will only take the highest paying txns and not generate a full block
04:01 sictransitgloria *salutations to all*
12:07 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.
12:07 waxwing i'll try to get a printout of what the error is, just asking in case anyone's got an idea
15:10 waxwing hmm think i managed to reproduce it on regtest: JSON-RPC connection failed. Err:error(99, 'Cannot assign requested address')
15:10 waxwing probably i just need to fix up my code so it doesn't make a ridiculous number of requests :)
15:20 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...
15:20 coin_trader am i doing something wrong there? or over thinking this?
15:53 wumpus waxwing: it might be that it exceeded the RPC work queue depth. But that looks like a network-level error.
15:56 waxwing wumpus: thanks; i'm guessing it's the former based on what i'm doing but useful info
15:59 wumpus waxwing: do you open a new connection for every request?
16:11 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
16:11 esotericnonsense getblockcount takes almost ten seconds to return for me during a reindex
16:12 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
16:12 esotericnonsense timeout dependent on rpc command
16:13 esotericnonsense i'm probably better served by bashing together my own thing using zmq subscriptions and a caching layer for blocks/headers or something
16:34 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)"
16:35 abpa ossifrage did you use it with a new address you generated?
16:36 abpa Maybe you need 0.15.0?
16:37 ossifrage abpa, yeah. [Recently, I had to dump my keypool, so it came from akeypool data generated with 0.14.2]
16:37 abpa try it with this https://bitcoin.org/bin/bitcoin-core-0.15.0/test.rc2/
16:38 ossifrage abpa, yeah, I built 0.15.0rc2, but I haven't switched to it yet
16:42 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.
16:43 waxwing wumpus: good question :) i just looked in the old jsonrpc.py code i'm using and yes .. which explains a lot :)
16:48 wumpus hah!
16:54 abpa wumpus is it only 0.15.0 that supports addwitnessaddress on mainnet?
17:01 ossifrage I was trying to get 0.15.0 to compile with -flto, complete fail...
17:01 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
17:07 ossifrage ./libtool: line 1720: 18481 Segmentation fault (core dumped) /usr/bin/gcc-ranlib .libs/libsecp256k1.a
17:27 wumpus abpa: 0.14 too AFAIK
17:27 abpa ok thanks
17:30 esotericnonsense hm
17:35 esotericnonsense i'm trying to use zmqpubhashblock and it doesn't seem to be publishing anything. will it not function until i'm synced?
17:35 esotericnonsense my expectation would have been that it publishes as UpdateTip in debug.log, as blocks are reindexed
17:39 wumpus ossifrage: an error in ar/ranlib? whoa, that's an unlikely bug, did your build host maybe run out of memory?
17:39 wumpus esotericnonsense: right, it will only function once your node is up to date
17:39 esotericnonsense wumpus: ah. bah :P
17:40 wumpus esotericnonsense: first line in CZMQNotificationInterface::UpdatedBlockTip
17:40 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
17:41 wumpus you can comment that out and it will notify on all blocks, I've done so before to test
17:41 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 :/
17:41 esotericnonsense wumpus: cheers, will have a go.
17:43 ossifrage wumpus, yeah, it could be a distro issue... But the segfault is uncool
18: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
18:17 esotericnonsense 2017-08-24T18:17:04.422Z 000000000000000001a204c2b8eaea7e0c6815ad5377a86bb87978f5a41faaec
18:17 esotericnonsense 2017-08-24T18:17:06.730Z 000000000000000002021883b5c936f4c8d77d04e7eeea618e1620aea021db9a
18:17 esotericnonsense 2017-08-24T18:17:07.713Z 00000000000000000322a92aaa1c3646743123b229532c1664f9ec84a147146f
18:17 esotericnonsense works :) cheers wumpus
18:18 wumpus woohoo!
18:18 esotericnonsense (my compilation time is very slow. :P)
18:22 esotericnonsense this is terribly exciting. not sure why i waited so long to play with this :P
18:41 esotericnonsense success. 1.79272 seconds per block (100 block average)
18:42 esotericnonsense don't think i'm at the period of 'every block is 1MB' yet though
20:26 ossifrage I switched to 0.15.0rc2 and I'm still getting that error on addwitnessaddress
20:47 esotericnonsense 'preciousblock' is a very cute name for an rpc call
21:57 esotericnonsense does anyone know the size of the current utxo set in total?
22:12 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
22:13 esotericnonsense it seems likely that it would in the early stages but not when they're taking 5 seconds per block
22:21 esotericnonsense seems to be not far off the same time per block, though i'm testing over a different set
22:28 esotericnonsense The last 10 blocks took an average of 0.799 seconds each.
22:28 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?