--- Day changed Mon Jan 02 2017 00:09 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 245 seconds] 00:30 -!- blur3d [~blur3d@d49-187-8-205.rdl1.qld.optusnet.com.au] has joined #bitcoin-core-dev 00:30 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:31 -!- Saucery [~Saucery@c110-20-8-231.rivrw8.nsw.optusnet.com.au] has quit [Read error: Connection reset by peer] 00:35 -!- Saucery [~Saucery@c110-20-8-231.rivrw8.nsw.optusnet.com.au] has joined #bitcoin-core-dev 00:36 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:37 < wumpus> btcdrak: yes 00:37 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/1d2d67692c74a5539f3736754d84f0aa6a702c56 00:37 < bitcoin-git> bitcoin/master 1d2d676 Wladimir J. van der Laan: qt: Set transifex slug to 0.14... 00:38 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds] 00:43 < bitcoin-git> [bitcoin] jonasschnelli pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d2d67692c74...53442af0aac3 00:43 < bitcoin-git> bitcoin/master 09aefb5 Cory Fields: build: Fix 'make deploy' for OSX... 00:43 < bitcoin-git> bitcoin/master b01667c Jonas Schnelli: Mention RSVG dependency when creating the disk image on OSX 00:43 < bitcoin-git> bitcoin/master 2fb98f6 Don Patterson: Fix bug in dmg builder so that it actually reads in the configuration file 00:44 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9412: build: Fix 'make deploy' for OSX (master...2016/12/fix_mac_deploy) https://github.com/bitcoin/bitcoin/pull/9412 00:52 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has joined #bitcoin-core-dev 00:55 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/0d719145b018e28d48d35c2646a5962b87c60436 00:55 < bitcoin-git> bitcoin/0.13 0d71914 Wladimir J. van der Laan: doc: Remove ... from release notes 00:57 < wumpus> * [new tag] v0.13.2 -> v0.13.2 01:09 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 245 seconds] 01:09 < jonasschnelli> \o/ 01:11 -!- blur3d [~blur3d@d49-187-8-205.rdl1.qld.optusnet.com.au] has quit [Quit: blur3d] 01:11 < wumpus> *almost* new year tag :p 01:13 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:24 < jouke_> I updated a .10 node to .13.1. It connects to an other .13.1 node, but it doesn't seem to sync the blockchain. But when I look at the blockheight, it might already got "stuck" when it was a .10 node. I updated it, because some rpc calls were a bit slow. 01:27 < jouke_> In debug log I see that it is receiving "invs". 01:35 < gmaxwell> jouke_: if you were stuck it is presumably because corruption made you reject a block. you can try running 'reconsiderblock ' 01:40 < jouke_> I retreived the blockhash from an other node, but that doesn't seem to do anything. 01:42 < gmaxwell> jouke_: I assume you don't have historic logs from the point where it got stuck? 01:42 < jouke_> no, I don't unfortunately 01:46 < jouke_> It just received information about the latest block and I see it is retreiving and receiving the headers of that block, but that's it. 01:48 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev 01:52 < jouke_> Hmm, we use that node to gather information about mempool size, and it stopped accepting blocks at around the 29th, but it did receive transactions which it added to it's mempool. 01:53 < gmaxwell> jouke_: do you have logs that cover the 29th? 01:54 < jouke_> no 01:59 < gmaxwell> the reconsiderblock did nothing? can you try invalidateblock then reconsider? 01:59 < gmaxwell> can you also run getchaintips and pastebin the results? 01:59 < jouke_> And thatblock = currentheight+1 right? 02:00 < gmaxwell> right what is your current height? 02:00 < jouke_> It's stuck at 445623 02:01 < gmaxwell> can you getblockhash for 445623 ? 02:02 < jouke_> 000000000000000002c45ed9057608b268a447499fcd8bea8e7930bfed11eaaf 02:03 < gmaxwell> jouke_: okay run reconsiderblock 000000000000000000fc97c4cd1f956f46a420536ca4851c31ad9d32f4e8ec0c 02:03 < jouke_> already did that 02:04 < jouke_> Didn't do anything 02:04 < gmaxwell> jouke_: can you try doing a getblock 000000000000000000fc97c4cd1f956f46a420536ca4851c31ad9d32f4e8ec0c and see if it says anything? grep your logs for that hash and see if there is any mention? 02:05 < gmaxwell> unfortunately I think there are types of rejection that reconsider will not reconsider, it's really just intended to be the compliment to invalidateblock 02:05 < jouke_> error code: -32603 02:05 < jouke_> error message: 02:05 < jouke_> Can't read block from disk 02:06 < jouke_> chaintips: https://www.zerobin.net/?70af58e5db340709#1i/w7FQhQE0ubu1+9QO5ANJPRSJ+V24C0LgiYVl15gU= 02:06 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub 02:07 < gmaxwell> jouke_: okay your blockchain data is corrupted. the block isn't on your disk (or is corrupted on disk) but is in the blockindex. 02:08 < jouke_> Hmm. nothing strange in syslog about file corruption or anything. 02:09 < gmaxwell> any chance you had a unclean power loss? the block isn't added into the block index until its written to disk and fsynced, but if your system is ignoring fsyncs or there is some other misbehavior in your storage it could be lost during a power failure. 02:10 < jouke_> no, system has been up for a whie 02:10 < jouke_> while 02:10 < gmaxwell> oh this was 0.10 before? 02:10 < jouke_> yes 02:11 < gmaxwell> ah ha. 02:11 < gmaxwell> I believe we actually had a bug that could cause that before. 02:12 < jouke_> I was already looking through the issues, but I did not come across it yet. 02:13 < gmaxwell> jouke_: in any case, I believe there is no other resolution right now to your condition but to reindex. setting a higher dbcache than default, if you have the ram will make it run much faster. 02:14 < jouke_> Shame I don't have the logs. I am making a note to push all bitcoin node logs to a log server. 02:14 < jouke_> gmaxwell: thanks for the help! 02:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 02:22 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 02:23 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 02:27 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 264 seconds] 02:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 02:28 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 02:33 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:36 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9457: WIP: [qt] translate bitcoin.cpp and libbitcoin_common_a_SOURCES (master...Mf1701-qtTrans) https://github.com/bitcoin/bitcoin/pull/9457 04:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 04:44 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has quit [Ping timeout: 258 seconds] 04:52 < jonasschnelli> Hmm... full block SPV with random peers is horrible slow. 10-12 blocks per minute around height 445100 04:52 < jonasschnelli> (on a 100MBit link) 04:52 < jonasschnelli> Maybe I just had bad luck with remote peers 04:52 < gmaxwell> increase your socket recieve buffer maximum size. 04:53 < gmaxwell> by like a factor of 10, you'll likely see it much faster. 04:53 < gmaxwell> Does your fetching code fetch in parallel? 04:54 < jonasschnelli> Yes. Same code. 04:54 < jonasschnelli> Maybe I need to unset NODE_NETWORK? 04:54 < jonasschnelli> debug=net shows plenty of tx invs 04:55 < gmaxwell> increase your socket recieve buffer maximum size. 04:56 < gmaxwell> One problem (no doubt there is more) is that it cannot achieve high throughput for transfers because the recieve buffers are so small that almost any processing delay and they fill. 04:57 < jonasschnelli> gmaxwell: Thanks. I'll try that. 05:10 -!- JackH [~laptop@82-132-218-98.dab.02.net] has joined #bitcoin-core-dev 05:13 -!- JackH [~laptop@82-132-218-98.dab.02.net] has quit [Remote host closed the connection] 05:23 < jonasschnelli> gmaxwell: -maxreceivebuffer=50000 = 1block per second. Better,... need to profile.. but I guess SyncTransaction with IsMine, etc. is the bottleneck 05:26 < gmaxwell> thanks for checking and, it sounds like, validating my theory. Not just how long sync takes, but the block deseralization isn't fast, ans I assume your sync runs in order, which means that when blocks arrive out of order and eventually the missing one shows up, it is probably processing many blocks at once, which creates a long delay in the message handling loop which will stall the recieve buf 05:26 < gmaxwell> fers. 05:27 < jonasschnelli> The blockdownload im using (#9171) does download in parallel, then store them on the disk and, process them in order (unserialize again probably). 05:27 < gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub 05:29 < gmaxwell> right, and say that you recieve blocks 0 2 3 4 5 6 7 8 9 1 will it end up processing 9 of them at the moment it recieves block 1 in the message handler? if so... it is not emptying the recieve buffers during that time. 05:30 < jonasschnelli> gmaxwell: I think it does empty the receive buffer,... ProcessNewBlock gets called for all blocks where only the header gets verified, the stored to the disk. I guess this drains the buffer... 05:30 < jonasschnelli> *then 05:32 < gmaxwell> the recieve buffer is drained as the blocks are saved to disk. it saves 1 to disk but then processes it and then will connect 1 2 3 4 5 6 7 8 9 all within that function call. 05:32 < gmaxwell> and during that time the message handler is not handling any messages. :) 05:32 < gmaxwell> so the recieve buffers fill. 05:33 < jonasschnelli> hmmm... 05:33 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9171/files#diff-6905024871a5ac748c4465bb25973c39R37 05:36 < jonasschnelli> Ah. Right... all the processing (LoadBlock, SyncTransaction, etc.) is done in thread "bitcoin-msghandler". 05:39 < gmaxwell> which fine, but not if it's processing a bunch of blocks at once. 05:39 < gmaxwell> e.g. it should just process two and then return control to the message handler loop. 05:39 < jonasschnelli> Okay.. I'll try that. Is 16 atm. 05:40 < jonasschnelli> *It's 05:41 < gmaxwell> where is it limited to 16? like.. if you get 0 2 3 4 5 ... 999 1 doesn't end up processing 1000 at once? 05:41 < jonasschnelli> I guess an explicit thread "process spv" (or similar) doesn't make that much sense. SyncTransaction does hold cs_main anyways. 05:41 < jonasschnelli> 16 is the limit for the max amount of blocks per auxiliary request 05:42 < jonasschnelli> If block 1 comes in last, it processes 15 blocks in a row. 05:42 < jonasschnelli> Once the 16 are processed, it continues with the next batch of 16 05:42 < jonasschnelli> (through findNextBlocksToDownload()) 05:42 < jonasschnelli> Ah. no, MAX_BLOCK_TO_PROCESS_PER_ITERATION == 5 05:44 < gmaxwell> oh that isn't many blocks to have in flight at once. 05:45 < gmaxwell> it should be possible to have many in flight but only process a few at a time. 05:45 < gmaxwell> if you cut the number in flight your throughput will decrease due to round trip delays. 05:46 < jonasschnelli> I just got in 16 blocks nice in order. It took more then 5s per block. I think its a slow peer. 05:47 < gmaxwell> thats one of the reasons you want to have lots of blocks in flight at once. :) 05:48 < jonasschnelli> Okay. Let me try that. 05:48 < jonasschnelli> 16 is max per peer. Maybe the request should contain 16*16 or similar. 05:49 < gmaxwell> yes 16 max per peer is probably fine. 05:50 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 05:51 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev 05:56 < jonasschnelli> gmaxwell: Oh yes. That was the bottleneck, not enough blocks in flight, parallelism was not ideal 05:56 < jonasschnelli> now 450 blocks in 1min. 05:57 < jonasschnelli> (at height 445761) 05:58 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:59 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 06:02 < MarcoFalke> wumpus: No, the translations were never added back 06:02 < MarcoFalke> As of today we are missing the ones that were moved to warnings.cpp 06:03 < MarcoFalke> (additionally) 06:03 < MarcoFalke> I don't understand the translation process code enough to fix this, but something like #9457 should do it 06:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9457 | WIP: [qt] translate bitcoin.cpp and libbitcoin_common_a_SOURCES by MarcoFalke · Pull Request #9457 · bitcoin/bitcoin · GitHub 06:16 < gmaxwell> oh interesting, I didn't really realize translations were file specific, I thought they were string to string conversions? 06:17 < MarcoFalke> It is an issue with some files are not picked up by the translation process code 06:20 < gmaxwell> oh I see. 06:36 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 06:39 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds] 06:41 -!- jouke_ is now known as Jouke 06:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:55 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 06:56 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 07:06 * BlueMatt is willing to review in exchange for review on #9289, #9419 or #9375 :) 07:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub 07:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub 07:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub 07:26 < gmaxwell> Is there a reason that make check doesn't run qa/pull-tester/rpc-tests.py ? 07:26 < gmaxwell> the tests in that are far more meaningful than most of the unit tests, IMO. 07:27 < BlueMatt> someone was complaining the other day that there is no way (afaik) to run rpc-tests from make ... 07:54 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 07:54 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has quit [Max SendQ exceeded] 07:54 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 07:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 07:57 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:01 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 245 seconds] 08:21 -!- MarcoFalke [~marco@5.199.182.203] has quit [Remote host closed the connection] 08:22 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev 08:32 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 08:39 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:2c9e:e25e:346f:2766] has quit [Quit: .] 08:40 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:2c9e:e25e:346f:2766] has joined #bitcoin-core-dev 08:54 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:2c9e:e25e:346f:2766] has quit [Quit: .] 08:54 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:56 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:9520:12cc:53a4:125c] has joined #bitcoin-core-dev 08:56 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:9520:12cc:53a4:125c] has quit [Client Quit] 08:57 -!- f0nky [590bcd84@gateway/web/freenode/ip.89.11.205.132] has joined #bitcoin-core-dev 08:58 < f0nky> hi all, can i ask u guys a question? 08:59 -!- f0nky [590bcd84@gateway/web/freenode/ip.89.11.205.132] has left #bitcoin-core-dev [] 08:59 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:fcdb:beda:2e8d:f8c9] has joined #bitcoin-core-dev 09:02 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has quit [Ping timeout: 248 seconds] 09:07 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:51 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-ovekpyinvfqfazqh] has quit [Ping timeout: 260 seconds] 09:52 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-pmjggjdizfsmurmx] has quit [Ping timeout: 258 seconds] 09:52 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-cfqbxjjntlhvgzlk] has quit [Ping timeout: 260 seconds] 09:52 -!- eragmus [sid136308@gateway/web/irccloud.com/x-ptbpwyjeahuylguj] has quit [Ping timeout: 246 seconds] 09:52 -!- rubensayshi [uid201751@gateway/web/irccloud.com/x-bucopmbcglcanxjr] has quit [Ping timeout: 245 seconds] 09:52 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-eubqzdmhxpqvwuzh] has quit [Ping timeout: 245 seconds] 09:53 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-dfbxtqvfxgrjotaf] has quit [Ping timeout: 246 seconds] 09:54 -!- limpkin [sid20909@gateway/web/irccloud.com/x-xqsryradyxysstov] has quit [Ping timeout: 258 seconds] 09:55 -!- rubensayshi [uid201751@gateway/web/irccloud.com/x-abzmgeqwaoftkvny] has joined #bitcoin-core-dev 09:56 -!- limpkin [sid20909@gateway/web/irccloud.com/x-mcetcjkiamdkpyws] has joined #bitcoin-core-dev 09:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-euxyuxjomobthsex] has joined #bitcoin-core-dev 09:57 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-klifigpymrwpvszu] has joined #bitcoin-core-dev 09:58 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-vvasrnoejqsmtbeo] has joined #bitcoin-core-dev 10:02 -!- Saucery [~Saucery@c110-20-8-231.rivrw8.nsw.optusnet.com.au] has quit [] 10:07 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-eyvjffchogqhtiwa] has joined #bitcoin-core-dev 10:12 -!- eragmus [sid136308@gateway/web/irccloud.com/x-vziknecpraftvkgi] has joined #bitcoin-core-dev 10:18 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds] 10:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 10:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 10:48 -!- bitcog [~douglas@dhcp-5-103-49-243.seas-nve.net] has joined #bitcoin-core-dev 10:53 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:18 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:18 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 12:02 -!- lol_ [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev 12:03 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Ping timeout: 252 seconds] 12:03 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-xixdtzucozqnqbxk] has joined #bitcoin-core-dev 12:03 -!- lol_ [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Remote host closed the connection] 12:04 -!- lol_ [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev 12:04 -!- lol_ [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Remote host closed the connection] 12:04 -!- negatratoron [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev 12:18 -!- bitcog [~douglas@dhcp-5-103-49-243.seas-nve.net] has quit [Ping timeout: 252 seconds] 12:19 -!- bitcog [~douglas@dhcp-5-186-121-138.cgn.ip.fibianet.dk] has joined #bitcoin-core-dev 12:21 -!- negatratoron [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Quit: Leaving] 12:21 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev 12:24 -!- bitcog [~douglas@dhcp-5-186-121-138.cgn.ip.fibianet.dk] has quit [Ping timeout: 245 seconds] 12:26 -!- bitcog [~douglas@dhcp-5-103-49-243.seas-nve.net] has joined #bitcoin-core-dev 12:27 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 12:29 < achow101> are the 0.13.2 detached sigs ready yet? 12:34 -!- bitcog [~douglas@dhcp-5-103-49-243.seas-nve.net] has quit [Ping timeout: 256 seconds] 12:36 -!- bitcog [~douglas@dhcp-5-186-121-138.cgn.ip.fibianet.dk] has joined #bitcoin-core-dev 12:41 < cfields> achow101: running sanity tests. eta ~10 min. 12:50 < cfields> gitian builders: 0.13.2 detached sigs pushed 12:56 < luke-jr> crap, forgot to save a copy of the intermediate files 13:06 -!- bitcog0 [~douglas@dhcp-5-103-49-243.seas-nve.net] has joined #bitcoin-core-dev 13:08 -!- bitcog0 [~douglas@dhcp-5-103-49-243.seas-nve.net] has quit [Client Quit] 13:08 -!- bitcog [~douglas@dhcp-5-186-121-138.cgn.ip.fibianet.dk] has quit [Ping timeout: 260 seconds] 13:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:48 -!- wvr [~wvr@215.red-83-59-62.dynamicip.rima-tde.net] has quit [Quit: Leaving] 14:00 < bitcoin-git> [bitcoin] isle2983 opened pull request #9459: Improvements to copyright_header.py and some minor copyright header tweaks. (master...PR-copyright-script-improve) https://github.com/bitcoin/bitcoin/pull/9459 14:44 -!- Saucery [~Saucery@c110-20-8-231.rivrw8.nsw.optusnet.com.au] has joined #bitcoin-core-dev 14:46 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 15:01 < cfields> BlueMatt: right, so does making CNodeState::cs static not enforce the only-one-nodestate-at-once rule? 15:19 -!- robert__ [~robert@cpe-107-184-212-50.socal.res.rr.com] has quit [Ping timeout: 248 seconds] 15:31 -!- robert__ [~robert@cpe-107-184-212-50.socal.res.rr.com] has joined #bitcoin-core-dev 15:48 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev 16:27 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:30 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds] 16:35 -!- dviola [~diego@unaffiliated/diegoviola] has joined #bitcoin-core-dev 16:37 -!- lejitz [~lejitz@2602:302:d151:2a0:1c53:39ec:535:41e8] has joined #bitcoin-core-dev 16:50 -!- justan0theruser is now known as justanotheruser 16:55 < dviola> hello, the archlinux bitcoin-qt package maintainer builds bitcoin-qt using "--with-incompatible-bdb" and bdb 5.3.28, I have heard there could be potential problems by taking a wallet.dat that was created with newer bdb and then using it on a bitcoin-qt that was compiled with an older version of bdb, are there any tests I could run to know I won't run into issues? 16:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jgizpqsgquwvhlff] has quit [Quit: Connection closed for inactivity] 17:00 < phantomcircuit> dviola, 5.x has a different format than 4.8 which is not backwards compatible 17:00 < phantomcircuit> if you open a wallet in 5.x it wont open in 4.x 17:00 < phantomcircuit> so that's a one way trip 17:08 < dviola> phantomcircuit: I see, so would it be better if I create the wallet using the bitcoin-qt builds from bitcoin.org? 17:09 < dviola> I'm a little confused because I created a wallet.dat using Arch's build, then used the wallet.dat with bitcoin-qt from bitcoin.org, and it seems to have worked just fine, but I don't have funds in this wallet of course 17:09 < dviola> I could still see the address and such 17:09 < dviola> which was the same 17:13 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 17:14 -!- MarcoFalke [~marco@5.199.182.203] has quit [Quit: MarcoFalke] 17:15 < dviola> just tested again 17:15 < luke-jr> dviola: *using* the wallet.dat with bdb5 should break using it with bdb4.. no matter how it was created. 17:17 < dviola> hrm 17:19 < dviola> here's what I did: I installed bitcoin-qt with pacman, started a fresh ~/.bitcoin and wallet.dat, I created 5 addresses with name, etc. I copied the wallet.dat to my home dir, I downloaded bitcoin-qt from bitcoin.org, started that with the old wallet.dat and all the address were there 17:22 < dviola> luke-jr: I understand, but isn't what I did the equivalent of what you said? I'm a little confused over this 17:27 < dviola> let me show you something... 17:28 < dviola> this is bitcoin-qt from archlinux (bdb 5.3.28): https://i.imgur.com/iL6MVB2.png 17:28 < dviola> this is bitcoin-qt from bitcoin.org (bdb 4.8.x): https://i.imgur.com/G50bTJi.png 17:28 < dviola> same wallet.dat 17:29 < dviola> I can still read the data from wallet 17:29 < dviola> I'm confused and I apologize if I should have asked in #bitcoin instead, please let me know if I should go there 17:31 < luke-jr> dviola: are you sure Arch isn't using bdb4 for the wallet? 17:31 < luke-jr> if both are installed, I think we prefer it even if incompatible-bdb is allowed via option 17:35 < dviola> I'm sure, this is how they build it: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/bitcoin#n166 17:35 < dviola> ldd shows this also: libdb_cxx-5.3.so => /usr/lib/libdb_cxx-5.3.so (0x00007f3aaa8bc000) 17:36 < dviola> I asked Timothy Redaelli (archlinux bitcoin maintainer) and he said this: https://i.imgur.com/bfvsEcZ.png 17:42 < dviola> not saying I don't believe what you just said, I guess I'm puzzled as to why it works 17:55 < dviola> luke-jr: hrm, I only have bdb5 system-wide 18:01 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:04 < dviola> even with an intact ~/.bitcoin it still works fine with both binaries 18:04 < dviola> bdb4 and 5 18:05 < dviola> I can see the info from getwalletinfo and do dumpwallet, etc 18:06 < dviola> I wonder if there is a way to exhaust this and see where it starts to fail 18:14 -!- lejitz [~lejitz@2602:302:d151:2a0:1c53:39ec:535:41e8] has quit [Quit: Leaving.] 18:14 -!- lejitz1 [~lejitz@45-21-16-42.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 18:21 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 19:07 -!- dviola [~diego@unaffiliated/diegoviola] has quit [Quit: WeeChat 1.6] 19:08 -!- abpa [~abpa@2602:306:b837:dbf0:3d30:198:c7ad:eadb] has joined #bitcoin-core-dev 19:09 -!- abpa [~abpa@2602:306:b837:dbf0:3d30:198:c7ad:eadb] has quit [Client Quit] 19:17 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 19:20 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 258 seconds] 19:27 < gmaxwell> anyone interested in picking up #8660 ? it's a nice feature, but has gone fallow after main was killed. 19:27 < gribble> https://github.com/bitcoin/bitcoin/issues/8660 | txoutsbyaddress index (take 2) by djpnewton · Pull Request #8660 · bitcoin/bitcoin · GitHub 19:28 < gmaxwell> droark: it should just fail to even open, always did in the past. 19:29 < gmaxwell> maybe some time in BDB 5 they changed the format to be backwards compatible if shut down cleanly? 19:34 -!- Netsplit *.net <-> *.split quits: justanotheruser 19:35 -!- Netsplit over, joins: justanotheruser 19:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Max SendQ exceeded] 19:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 19:54 -!- robert__ [~robert@cpe-107-184-212-50.socal.res.rr.com] has quit [Ping timeout: 265 seconds] 19:59 < phantomcircuit> gmaxwell, does it have to handle reorgs correctly? 20:00 < phantomcircuit> i dont think it would actually if you were saving address -> [block hash/tx index/out index] 20:01 < phantomcircuit> but that's maybe slightly bigger than just address > txout 20:06 < phantomcircuit> oh it's just for the utxo? 20:07 < phantomcircuit> yeah i guess 20:10 -!- robert__ [~robert@cpe-107-184-212-50.socal.res.rr.com] has joined #bitcoin-core-dev 20:19 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 20:22 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 21:31 < gmaxwell> phantomcircuit: it's just for the utxo set, the PR is somewhat poorly named! 21:48 < CodeShark> utxosbyaddress? :) 21:48 < CodeShark> utxosbyscriptpubkey might even be more useful 21:53 < CodeShark> I might take a look at it, it is a pretty nice feature 21:55 < gmaxwell> assuming the database is constructed correctly (lets hope) the difference between by address vs by scriptpubkey is purely a RPC parameter one. 21:55 < CodeShark> yeah, indeed :) 21:56 < CodeShark> but we don't have address formats for all scriptpubkey types 21:58 < CodeShark> how big is the extra index here? 22:00 < gmaxwell> CodeShark: should be roughly similar in size to the utxo set. 22:00 < CodeShark> it's something of a reverse lookup, no? 22:00 < CodeShark> when validating we need to grab scriptpubkey from blockhash:txindex 22:01 < gmaxwell> right. 22:01 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 264 seconds] 22:01 < gmaxwell> I don't recall what it implements, but 22:01 < CodeShark> or txhash:outindex, rather ;) 22:01 < gmaxwell> e.g. it could map(h(scrippubkey)[64 bits]) -> [txid:vout,...] which would potentially equal in size or smaller even though it's going to be more sparse. 22:01 < gmaxwell> Well my right was responding to what you meant, of course. 22:02 < gmaxwell> at least if I'd written this from scratch I would have done that kind of hash, probably with a per database salt to keep clowns from intentionally making your queries slow by causing collisions. 22:05 < CodeShark> I'm a little ambivalent about using an in-process storage engine for things not required for full validation. I'd love to see an architecture with an external storage engine that can be configured for different kinds of queries. But I guess this index isn't too huge 22:07 < CodeShark> pulling the consensus-critical stuff out to an external storage engine is perhaps a bit risky, though 22:07 < CodeShark> and perhaps there are optimization issues as well here with the caching 22:07 < CodeShark> I'm not too familiar with the cache stuff 22:09 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev 22:09 -!- robert__ is now known as spinNspiral 22:09 < CodeShark> the main advantage here is that different people could extend the functionality of the storage engine and queries supported without having to touch any consensus code at all 22:09 < CodeShark> nor having to rebuild the validation engine 22:11 < CodeShark> but we already have the existing RPC framework...which encourages just adding more in-process RPC calls 22:23 < CodeShark> people always talk about keeping these indices external to bitcoind...but without a framework for it that people can easily extend everyone has to reinvent the wheel 22:24 < CodeShark> ...poorly :p 22:30 < gmaxwell> You can always index whatever you want talking to things over the rpc. but there are plenty of uses for this just from the commandline. 22:32 < CodeShark> no question it's useful. but there could be a bunch other useful queries for app developers (or even for interactive use from commandline) - and having to merge another in-process RPC call everytime is a bottleneck 22:33 < CodeShark> or it encourages people to have to maintain their own forks of the entire project so they can customize it 22:35 < CodeShark> as for an external index, we could get far better performance foregoing the RPC and using a different IPC 22:35 < CodeShark> also, the indices could be built up during IBD 22:36 < CodeShark> but these are longer term objectives - I still like this PR :) 22:48 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev 22:52 -!- spinNspiral [~robert@cpe-107-184-212-50.socal.res.rr.com] has quit [Remote host closed the connection] 22:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zkgkbvgmhxkizjkq] has joined #bitcoin-core-dev 23:06 -!- Squidicc is now known as squidicuz 23:13 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.red.bezeqint.net] has joined #bitcoin-core-dev 23:27 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 265 seconds] 23:48 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.red.bezeqint.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 23:58 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 258 seconds] 23:59 < jonasschnelli> Is it okay to use GPG's (v2.1+) Ed25516 or even secp256k1 keys for gitian signing?