--- Day changed Thu Sep 29 2016
00:05 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
00:05 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
00:19 < GitHub3> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7d563cc16d64...489a6ab5073c
00:19 < GitHub3> bitcoin/master 64047f8 Wladimir J. van der Laan: depends: Add libevent compatibility patch for windows...
00:19 < GitHub3> bitcoin/master 489a6ab Wladimir J. van der Laan: Merge #8730: depends: Add libevent compatibility patch for windows...
00:19 < GitHub165> [bitcoin] laanwj closed pull request #8730: depends: Add libevent compatibility patch for windows (master...2016_09_libevent_windows_gcc_531) https://github.com/bitcoin/bitcoin/pull/8730
00:20 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
00:20 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
00:21 < GitHub162> [bitcoin] laanwj closed pull request #7522: Bugfix: Only use git for build info if the repository is actually the right one (master...bugfix_gitdir) https://github.com/bitcoin/bitcoin/pull/7522
00:24 < wumpus> cfields_: I've assigned some build-system issues to you, hope you don't mind
00:31 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
00:31 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
00:33 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
00:34 -!- Alina-malina [~Alina-mal@37.157.216.181] has quit [Changing host]     
00:34 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
00:37 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 272 seconds]     
00:46 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
00:46 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
00:57 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
00:58 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 244 seconds]     
01:02 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev     
01:34 -!- DigiByteDev_ [~JT2@185.29.164.149] has joined #bitcoin-core-dev     
01:34 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:34 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Ping timeout: 276 seconds]     
01:34 -!- DigiByteDev_ is now known as DigiByteDev     
01:49 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
01:49 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
01:49 -!- DigiByteDev [~JT2@185.29.164.149] has quit [Quit: DigiByteDev]     
01:50 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
01:50 < GitHub87> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/489a6ab5073c...8ca69a2a88a7
01:50 < GitHub87> bitcoin/master 54e5d7c jnewbery: Add bitcoin-tx JSON tests
01:50 < GitHub87> bitcoin/master 8ca69a2 MarcoFalke: Merge #8829: Add bitcoin-tx JSON tests...
01:51 < GitHub21> [bitcoin] MarcoFalke closed pull request #8829: Add bitcoin-tx JSON tests (master...test-bitcoin-tx-json) https://github.com/bitcoin/bitcoin/pull/8829
01:55 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev     
01:59 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]     
01:59 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev     
02:00 < wumpus> weird, I'm on testnet and trying to rebroadcast a transaction using "sendrawtransaction" but it's not working, I don't see anything appear in my wireshark session
02:01 < wumpus> maybe all the current nodes already know of it, otoh the "broadcast through 1 node(s)" in status doesn't increase either
02:03 < sipa> could it be that your peers knew about it, but evicted it?
02:03 < wumpus> but for they they'd have to request it first
02:04 < MarcoFalke> What about resendwallettransactions
02:04 < sipa> not necessarily from you
02:05 < wumpus> MarcoFalke: this should work with sendrawtransaction
02:05 < wumpus> could be that the net refactoring work changed the assumptions, will add some debugging...
02:06 < sipa> i don't think so
02:06 < MarcoFalke> its a noop when fHaveMempool?
02:07 < sipa> no     
02:07 < wumpus> I don't hope so
02:07 < MarcoFalke> sendrawtransaction will only put in in your mempool
02:07 < sipa> and then loop over all peers 
02:07 < sipa> and call PushInventory
02:07 < MarcoFalke> oh     
02:08 < sipa> but PushInventory is a noop if filterInventoryKnown for that peer already contains the tx
02:09 < wumpus> but it can't be there unless the peer requested it from *us*right?
02:09 < wumpus> hm or if they inved it for relay to us, I guess
02:10 < wumpus> I don't have a capture of the whole session so we'll never know for sure
02:10 < sipa> well you can enable -debug=net and see if any messages go out in response to sendrawtransaction
02:10 < sipa> oh     
02:11 < sipa> you're already doing that
02:11 < wumpus> no, no messages went out
02:11 < wumpus> and according to the tx metadata apparently one peer ever requested the transaction
02:11 < wumpus> but that was before I started logging
02:13 < wumpus> it could also be that that counter is broken, of course, I don't think that functionality is tested anywhere it's UI only
02:16 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
02:16 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
02:33 < wumpus> ok, seems the behaviour was correct. After restart the transaction is no longer in the filter, so I do sendrawtransaction again, it sends out an inv to every node.
02:33 < sipa> i wonder if we should add some random memory/cpu intensive task occasionally during block validation (so it doesn't consume more than 1% cpu rate or so)
02:33 < sipa> and if that fails, tell the user their hardware is too unreliable
02:33 < wumpus> yes, some games have that, it's not a bad idea
02:33 < wumpus> it allows distinguishing bugs from hw failures
02:34 < wumpus> we have the same problem, 'support' is overflowed with issues that are probably hw failures but we can't be sure so it wastes a lot of time
02:38 < paveljanik> We could ask users for the result of bitcoind -sanitychecks or something if we suspect HW issue...
02:39 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
02:39 < sipa> paveljanik: the problem is that such a sanitycheck would need to run for several hours or so to be reliable
02:40 < paveljanik> sure, but 90% rule...
02:40 < sipa> if a failure is detectable within minutes, it also means their block validation like fails within minutes
02:40 < sipa> and many other things
02:41 < sipa> most random failure i hear about happen after several hours of sync
02:42 < wumpus> the sanity check definitely needs to run automatically and periodically for it to be useful
02:42 < wumpus> because otherwise it won't run in the right conditinos
02:43 < wumpus> we should start selling a hardware quality certificates: has synced the bitcoin block chain succesfully
02:43 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:43 < wumpus> if it can do that, it won't crash on games either. Well. Maybe after GPU secp256k1 verification is implemented ;)
02:44 < sipa> maybe we should instead just market secp256k1 asics
02:45 < wumpus> would be a very interesting project if there's a market for that
02:46 < wumpus> hm, scrap that. THe market for that is key-cracking :(
02:47 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
02:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds]     
02:47 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
02:47 -!- Guyver2_ is now known as Guyver2     
02:50 < wumpus> searching around a bit, apparently, many people *started* on a verilog/vhdl FPGA implementation of secp256k1, but there's no code to be found anywhere
02:57 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
02:58 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
02:58 < wumpus> I'm pleasantly surprised how well the wireshark dissector for the bitcoin protocol works, can just do "tcp port 18333" then use a display filter of "bitcoin" and gets a running list of bitcoin packets easy to inspect using the tree structure
03:01 < wumpus> compared to trying to mentally parse debug.log output this is a breeze
03:02 < waxwing> wumpus: they've had that dissector for years, i remember being pleasantly surprised in like 2013/14
03:02 < waxwing> not that i need it or anything, but it's cool :)
03:02 < wumpus> yeah yeah it's probably not new
03:03 < wumpus> but just in case someone didn't discover it 20 years ago yet, there you go...
03:03 < waxwing> sorry wasn't trying to be a hipster :)
03:03 < wumpus> :-)     
03:03 < sipa> damn. i believe this is a blocker for bip151.
03:04 < wumpus> agree sipa
03:08 < wumpus> though it is possible to have dissectors with parameters, such as a key, but it's so much less user friendly!
03:08 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
03:08 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
03:12 < wumpus> a more practical way to go at this, post-bip151, would be add functionality to dump packets to disk after decryption on receive and before encryption on send, it's for debugging anyhow not snooping
03:14 < waxwing> iirc there are per-dissector settings, for ssl you can enter the session key there etc.
03:14 < wumpus> yes     
03:14 < waxwing> there's an env variable you can set when running firefox that dumps the keys for you, and you can import it in
03:14 < sipa> implementing bip151 in wireshark will be fu 
03:14 < waxwing> and chrome i think
03:14 < wumpus> waxwing: but if you deal with lots of different sessions, or sessions that are created on the fly
03:15 < waxwing> right, which i guess might be of particular import in your case (/me hasn't read bip151 tho)
03:15 < wumpus> it's certainly possible, the only remark I was making was in regard to what was the most practical way :)
03:16 < wumpus> one advantage of doing the decryption in the dissector would be that it could detect crypto problems
03:18 < sipa> i don't know what language wireshark uses... but reimplementing sha256, chacha20 and poly1305 doesn't sound trivial
03:18 < sipa> (unless those are already available as primitives)
03:18 < wumpus> C     
03:19 < sipa> oh, the filters too?
03:19 < wumpus> it's also possible to write dissectors in lua, but that's only recommended for one-off projects, as performance is abysmal
03:19 < sipa> i thought those would be in a plugin language like lua or so
03:19 < wumpus> yes, most of them
03:19 < sipa> ah.     
03:20 < sipa> the bitcoin dissector is in c currently?
03:20 < wumpus> let me see
03:21 < sipa> i vaguely remember seeing the code for it, years ago
03:22 < wumpus> https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-bitcoin.c
03:24 < GitHub156> [bitcoin] MarcoFalke opened pull request #8834: [qa] blockstore: Switch to dumb dbm (master...Mf1610-qaBlockstoreDumb) https://github.com/bitcoin/bitcoin/pull/8834
03:24 < wumpus> apparently it's not yet updated for 0.12.0+, no handler for sendheaders, feefilter etc
03:27 -!- mmeijeri [525f5ca0@gateway/web/freenode/ip.82.95.92.160] has joined #bitcoin-core-dev     
03:27 < mmeijeri> The same environment variable (SSLKEYLOGFILE) also works for Chrome.
03:29 < wumpus> oh it's a dynamic file? that's a good idea
03:29 < waxwing> mmeijeri: it's coming back to me, i have a feeling that it handles multiple sessions transparently, by just checking which key material works for which session. not that this matters, sorry for OT :)
03:30 < waxwing> ah yes that was it, i think it stores the premaster secrets for all sessions, then in each handshake it tries them out until it finds what works. something like that.
03:34 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 276 seconds]     
03:42 -!- droark [~droark@172.56.5.76] has joined #bitcoin-core-dev     
03:57 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
03:57 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
04:08 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
04:08 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
04:10 < GitHub26> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ca69a2a88a7...cc9e8aca5f95
04:10 < GitHub26> bitcoin/master a0f8482 Suhas Daftuar: [qa] Split up slow RPC calls to avoid pruning test timeouts
04:10 < GitHub26> bitcoin/master cc9e8ac MarcoFalke: Merge #8827: [qa] Split up slow RPC calls to avoid pruning test timeouts...
04:10 < GitHub122> [bitcoin] MarcoFalke closed pull request #8827: [qa] Split up slow RPC calls to avoid pruning test timeouts (master...fix-pruning-timeout) https://github.com/bitcoin/bitcoin/pull/8827
04:15 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
04:16 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
04:19 < luke-jr> any reason for me to NOT switch to 64-bit after I sleep?
04:22 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
04:22 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
04:22 < phantomcircuit> luke-jr: something about  #8828 results in a null pointer dereference
04:22 < phantomcircuit> afaict i just moved code around basically
04:23 < phantomcircuit> you wrote the original method
04:23 < phantomcircuit> can you take a look?
04:23 -!- benma [~benma@46-126-157-175.dynamic.hispeed.ch] has joined #bitcoin-core-dev     
04:23 < luke-jr> phantomcircuit: too sleepy now, can you ask me after I finish switching into 64-bit (probably tomorrow)? :x
04:24 < phantomcircuit> luke-jr: whoa now
04:24 < phantomcircuit> you're moving to 64bit?
04:24 < luke-jr> phantomcircuit: unless someone stops me before I wake up
04:24 < phantomcircuit> also the line gdb thinks it's segfaulting on makes no sense
04:25 < luke-jr> ?     
04:25 < phantomcircuit> nOrderPosNext = 0;
04:25 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:25 < luke-jr> so this is NULL? O.o
04:25 < luke-jr> +    int64_t& nOrderPosNext = nOrderPosNext;
04:25 < luke-jr> wtf is this
04:26 < luke-jr> bet that's your problem, it makes no sense
04:26 < luke-jr> prob undefined behaviour
04:26 < luke-jr> but I'm half asleep, so who knows
04:28 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
04:28 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
04:35 -!- harrymm [~wayne@104.222.140.117] has left #bitcoin-core-dev []     
04:40 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 268 seconds]     
04:40 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
04:40 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
04:45 -!- harrymm [~wayne@104.222.140.84] has joined #bitcoin-core-dev     
04:52 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
04:55 < luke-jr> oh well, hope that helped, otherwise ping me tomorrow I guess :x
04:55 < luke-jr> night
04:55 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
04:57 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev     
05:01 < phantomcircuit> luke-jr: that's weird but apparently correct
05:05 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 265 seconds]     
05:10 < midnightmagic> that's a weird scoping problem
05:10 < midnightmagic> lol     
05:13 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
05:15 -!- fengling [~fengling@58.135.95.136] has quit [Quit: WeeChat 1.4]     
05:16 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
05:19 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
05:31 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
05:31 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
05:40 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
05:50 -!- droark [~droark@172.56.5.76] has quit [Quit: ZZZzzz…]     
06:00 < GitHub52> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cc9e8aca5f95...9b94cca41f3e
06:00 < GitHub52> bitcoin/master 64d9507 Pavel Janík: [WIP] Remove unused statement in serialization
06:00 < GitHub52> bitcoin/master 9b94cca Wladimir J. van der Laan: Merge #8658: Remove unused statements in serialization...
06:00 < GitHub41> [bitcoin] laanwj closed pull request #8658: Remove unused statements in serialization (master...20160902_nVersion_serialization_cleanup) https://github.com/bitcoin/bitcoin/pull/8658
06:02 < kanzure> wumpus: tcpdump if you want to generate .pcap files without wireshark's gui
06:05 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: Connection reset by peer]     
06:05 -!- limpkin_ is now known as limpkin     
06:05 < GitHub166> [bitcoin] jgarzik closed pull request #6451: BIP 102: Increase block size limit to 2MB (master...2015_2mb_blocksize) https://github.com/bitcoin/bitcoin/pull/6451
06:06  * midnightmagic stabs wireshark's gui
06:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:09 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Quit: Leaving.]     
06:12 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
06:12 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
06:24 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
06:24 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
06:27 -!- benma [~benma@46-126-157-175.dynamic.hispeed.ch] has quit [Remote host closed the connection]     
06:33 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
06:35 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
06:36 < GitHub180> [bitcoin] MarcoFalke opened pull request #8835: [qa] nulldummy.py: Don't run unused code (master...Mf1610-qaNulldummyUnused) https://github.com/bitcoin/bitcoin/pull/8835
06:45 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
06:45 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
06:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]     
07:01 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
07:01 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
07:02 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit []     
07:05 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []     
07:22 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
07:22 < GitHub8> [bitcoin] jnewbery opened pull request #8836: bitcoin-util-test.py should fail if the output file is empty (master...bitcoin-tx-no-empty-outputs) https://github.com/bitcoin/bitcoin/pull/8836
07:22 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
07:25 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]     
07:26 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev     
07:27 < GitHub100> [bitcoin] jnewbery opened pull request #8837: allow bitcoin-tx to parse partial transactions (master...bitcoin-tx-partial-transactions) https://github.com/bitcoin/bitcoin/pull/8837
07:31 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
07:34 < GitHub16> [bitcoin] jnewbery opened pull request #8838: Only log block size if block size is being accounted (master...dont_log_size) https://github.com/bitcoin/bitcoin/pull/8838
07:35 -!- mmeijeri [525f5ca0@gateway/web/freenode/ip.82.95.92.160] has quit [Quit: Page closed]     
07:41 -!- aalex_ [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer]     
07:41 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
07:41 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
07:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
07:46 < GitHub177> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9b94cca41f3e...2dd57e4f9f58
07:46 < GitHub177> bitcoin/master fa156c6 MarcoFalke: [qa] nulldummy: Don't run unused code
07:46 < GitHub177> bitcoin/master 2dd57e4 Wladimir J. van der Laan: Merge #8835: [qa] nulldummy.py: Don't run unused code...
07:46 < GitHub194> [bitcoin] laanwj closed pull request #8835: [qa] nulldummy.py: Don't run unused code (master...Mf1610-qaNulldummyUnused) https://github.com/bitcoin/bitcoin/pull/8835
08:03 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
08:03 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
08:04 < GitHub44> [bitcoin] laanwj opened pull request #8839: test: Avoid ConnectionResetErrors during RPC tests (master...2016_09_freebsd_rpctest_fix) https://github.com/bitcoin/bitcoin/pull/8839
08:05 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
08:07 -!- laurentmt [~Thunderbi@80.215.138.172] has joined #bitcoin-core-dev     
08:08 < GitHub42> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2dd57e4f9f58...c84181665f34
08:08 < GitHub42> bitcoin/master 16f8823 fanquake: [depends] Boost 1.61.0
08:08 < GitHub42> bitcoin/master c841816 Wladimir J. van der Laan: Merge #8819: [depends] Boost 1.61.0...
08:09 < GitHub98> [bitcoin] laanwj closed pull request #8819: [depends] Boost 1.61.0 (master...depends-boost-1-61-0) https://github.com/bitcoin/bitcoin/pull/8819
08:10 -!- laurentmt [~Thunderbi@80.215.138.172] has quit [Client Quit]     
08:18 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
08:21 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
08:23 < GitHub53> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c84181665f34...c9d7b0de2fc9
08:23 < GitHub53> bitcoin/master fa9cd25 MarcoFalke: [qa] blockstore: Switch to dumb dbm
08:23 < GitHub53> bitcoin/master c9d7b0d Wladimir J. van der Laan: Merge #8834: [qa] blockstore: Switch to dumb dbm...
08:23 < GitHub36> [bitcoin] laanwj closed pull request #8834: [qa] blockstore: Switch to dumb dbm (master...Mf1610-qaBlockstoreDumb) https://github.com/bitcoin/bitcoin/pull/8834
08:27 < GitHub17> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9d7b0de2fc9...f560d9564f74
08:27 < GitHub17> bitcoin/master 7e5fd71 Pavel Janík: Do not include env_win.cc on non-Windows systems
08:27 < GitHub17> bitcoin/master f560d95 Wladimir J. van der Laan: Merge #8826: Do not include env_win.cc on non-Windows systems...
08:27 < GitHub75> [bitcoin] laanwj closed pull request #8826: Do not include env_win.cc on non-Windows systems (master...20160928_leveldb_no_win) https://github.com/bitcoin/bitcoin/pull/8826
08:44 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
08:44 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
08:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
08:55 -!- cryptapus__ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
08:58 -!- laurentmt [~Thunderbi@80.215.138.172] has joined #bitcoin-core-dev     
08:58 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 272 seconds]     
09:03 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
09:04 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
09:05 < GitHub51> [bitcoin] laanwj opened pull request #8840: test: Explicitly set encoding to utf8 when opening text files (master...2016_09_textfiles_locale) https://github.com/bitcoin/bitcoin/pull/8840
09:08 -!- laurentmt [~Thunderbi@80.215.138.172] has quit [Quit: laurentmt]     
09:23 < GitHub57> [bitcoin] jl2012 opened pull request #8841: [qa] fix nulldummy test (master...nulldummytest) https://github.com/bitcoin/bitcoin/pull/8841
09:32 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 272 seconds]     
09:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
09:35 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
09:35 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
09:35 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
09:46 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]     
09:47 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
09:51 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 272 seconds]     
09:57 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
09:57 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]     
10:03 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
10:16 < cfields_> wumpus: no problem
10:17 < cfields_> jonasschnelli: i had a look at your circular dep issue. No luck here. The (hack) solution is to use grouping libs, but I'd really rather not go down that road. I've started untangling dependencies instead.
10:20 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]     
10:23 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
10:25 < wumpus> which dependencies are the problem there? the circular dependency between libbitcoin_server and libbitcoin_wallet?
10:26 < wumpus> that would "just" require solving https://github.com/bitcoin/bitcoin/issues/7965
10:26 < arubi> jnewbery, :)  I was just about to whine about 'if (!DecodeHexTx(txDecodeTmp, strHexTx)'  
10:26 < arubi> thanks!
10:36 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
10:36 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
10:38 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
10:38 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]     
10:47 -!- cryptapus__ [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]     
10:48 -!- cryptapus__ [~cryptapus@87.254.202.203] has joined #bitcoin-core-dev     
10:48 -!- cryptapus__ [~cryptapus@87.254.202.203] has quit [Changing host]     
10:48 -!- cryptapus__ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
10:48 -!- cryptapus__ is now known as cryptapus_     
10:54 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
10:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
10:57 < arubi> too bad, I wanted to ask him about it here
10:57 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:01 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
11:12 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
11:12 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
11:20 < jonasschnelli> wumpus, cfields_: Yes. I think we need to complete 7965 first
11:23 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
11:23 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
11:32 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
11:36 -!- Squidicc is now known as squidicuz     
11:37 < jl2012> Travis test failed for #8841 with an unrelated test
11:37 < jl2012> https://www.irccloud.com/pastebin/pWEgvccJ/
11:38 < jl2012> https://travis-ci.org/bitcoin/bitcoin/jobs/163788152
11:39 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
11:40 < luke-jr> phantomcircuit: correct for what?
11:40 < MarcoFalke> jl2012: We should probably create an issue for those failures
11:43 -!- Soligor_ [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
11:44 < MarcoFalke> and a minor nit: I think the if(msg) is redundant. (The empty string already evaluates to false in python)
11:44 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 244 seconds]     
11:45 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 272 seconds]     
11:47 < jl2012> indeed
11:48 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Remote host closed the connection]     
11:48 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
12:00 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has joined #bitcoin-core-dev     
12:00 < jonasschnelli> bingbong
12:00 < luke-jr> hi     
12:00 < sipa> ovatobat
12:00 < CodeShark> yo     
12:01 -!- cdecker [~quassel@2a02:aa16:1105:4a80:4825:67e1:2e05:bd1f] has quit [Quit: No Ping reply in 180 seconds.]     
12:01 < wumpus> #startmeeting
12:01 < lightningbot> Meeting started Thu Sep 29 19:01:19 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < BakSAj> hi     
12:01 < CodeShark> meeting time!
12:01 < MarcoFalke> meeting!
12:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:02 < MarcoFalke> (oh already started)
12:02 < btcdrak> here
12:02 < cfields_> hi     
12:02 < kanzure> hi     
12:02 < wumpus> any proposed topics?
12:02 < jonasschnelli> topic proposal: pruning and blockrelay
12:02 < petertodd> hi     
12:02 < sipa> policy against uncompressed keys or not
12:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]     
12:03 < wumpus> #topic pruning and blockrelay
12:03 < jonasschnelli> I think we should add a service flag for block relay with a min-height
12:03 < jonasschnelli> NODE_PRUNENETWORK or something
12:03 < sipa> there have been multiple ideas around that
12:04 < petertodd> IMO whatever we do, we should recognise that w/ segwit's larger blocks we can expect a lot of full nodes to run out of disk space quite soon
12:04 < sipa> the easiest is just to add a flag that says you relay valid blocks and transactions, but not historical blocks more than a few deep
12:04 < jonasschnelli> I guess people slowly start to prune the blockchain to a max of 80GB or similar... but I guess not everyone is aware of the fact that you don't relay then
12:04 < wumpus> it would be nice to support more than one range, e.g. also archive nodes that host part of the old blocks
12:04 < sipa> it becomes harder when you want multiple ranger
12:04 < petertodd> do we have a reason for more than one range?
12:05 < jonasschnelli> We could introduce another message type... blockrange  or so
12:05 < sipa> it becomes even harder when you want to support sharding in an efficient way
12:05 < wumpus> I'm not sure why itb ecomes hard, just add a query message that returns what ranges are supported
12:05 < petertodd> sipa: what do you mean by sharding exactly?
12:05 < sipa> petertodd: you'd configure your node to maintain a certain % of blocks
12:05 < jonasschnelli> wumpus: query, yes, why not, or just inform like we do with sendheaders
12:05 < petertodd> sipa: see, given that the bitcoin protocol can't be safely sharded right now, I think we can safely say that we don't need to support sharding in block relay yet
12:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:05 < petertodd> sipa: doing so might even be dangerous if people start using it
12:05 -!- cdecker [~quassel@2a02:aa16:1105:4a80:7d39:b0e3:868e:8873] has joined #bitcoin-core-dev     
12:06 < sipa> petertodd: not in block relay
12:06 < sipa> petertodd: for block archival
12:06 < petertodd> sipa: but why shard vs. keep ranges?
12:06 < petertodd> sipa: (ranges of full blocks)
12:06 < luke-jr> BitTorrent already does this. Surely we can learn from that?
12:06 < petertodd> luke-jr: I don't think so - bittorrent is a very different problem than bitcoin
12:06 < wumpus> this is for letting other peers know what ranges of blocks are hosted, I don't think this should affect releay
12:06 < sipa> so, i've been running statistics on what block depths are being requested from nodes
12:06 < luke-jr> petertodd: learn from it, not use it directly
12:07 < luke-jr> petertodd: BitTorrent's problem isn't very different from IBD
12:07 < jonasschnelli> sipa: interesting.. do you have the stats public available somewhere
12:07 < jonasschnelli> I wanted to do this a long time
12:07 < petertodd> luke-jr: so, the thing is bittorrent has the problem of a diverse set of files, we just don't have that problem and can optimise differently because everyone needs access t othe same set of data
12:08 < sipa> there are something like 4 meaningful 'ranges' 1) the top 2 blocks (just relay) 2) up to ~2500 blocks deep... requested very often 3) up to ~10000 deep... requested a few times more than the next range 4) the rest
12:08 -!- veleiro [809aa323@fsf/member/veleiro] has joined #bitcoin-core-dev     
12:08 < wumpus> otoh bittorrent has a fixed block size :)
12:08 < sipa> wumpus: so do we *ducks*
12:08 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
12:08 < petertodd> sipa: that probably corresponds to how long people leave their nodes offline :)
12:08 < btcdrak> inb4 Bittorrent XT
12:08 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
12:09 < sipa> jonasschnelli: they're not available, and the ranges i gave above are just from me quickly glancing over the result
12:09 < petertodd> btcdrak: I use Bittorrent Unlimited myself
12:09 < jonasschnelli> What about fingerprinting issued in conjunction with available ranges?
12:09 < jonasschnelli> *issues
12:09 < petertodd> jonasschnelli: make them powers of two?
12:09 < sipa> well 4 ranges can be done with 2 service bit flags
12:09 < sipa> gmaxwell: you've worked on these ideas before, comments?
12:09 < jonasschnelli> But would that work with the flexible pruning option based on MB?
12:10 < petertodd> jonasschnelli: sure, just find the biggest range less than the pruning amount
12:10 < sipa> jonasschnelli: you'd change your service bits on the fly
12:10 < wumpus> why would the ranges need to be in the flags?
12:10 < gmaxwell> sorry, I missed that the meeting started.
12:10 < jonasschnelli> Yes. Why? Better add an explicit message for the range
12:10 < sipa> how would you otherwise discover what nodes to connect to?
12:10 < sipa> just randomly try?
12:10 < petertodd> jonasschnelli: oh right, you mean if MB != blocks... sorry.
12:10 < wumpus> I think you'll need a service flag to show support for the protocol, but not what ranges you have
12:10 < jonasschnelli> query or inform the other node if proto-ver > NODE_PRUNENETWORK
12:11 < wumpus> well that can be negotiated later, like bittorrent does I guess
12:11 < sipa> wumpus: well you do want addr messages to contain this information
12:11 < wumpus> I doubt bitcoin has 'service flags' in its tracker what blocks nodes have
12:11 < petertodd> sipa: so the nice thing about bitcoin, is just randomly try will probably work fairly often due to the low number of ranges out there
12:11 < wumpus> as that changes all the time anyhow
12:11 < gmaxwell> I was strongly of the view that we needed to signal at least two ranges. Sipa's latest measurements make me think at least three are needed.
12:11 < wumpus> s/bitcoin/bittorrent/
12:11 < jonasschnelli> I think informing other nodes ranges over addr is another thing...
12:11 < jonasschnelli> A first step would be a information after connect
12:11 < wumpus> yes, addr is another thing
12:12 < gmaxwell> I think ranges in service bits are no big deal, the harder question is what to do about the history. having nodes with 150GB of history in order to serve the last range is not very viable. 
12:12 < wumpus> could be done later if an efficient way is needed to *locate* peers with certain ranges
12:12 < wumpus> but that seems premature optimization
12:12 < gmaxwell> We will need to redo addr sometime relatively soon in any case, as our messages are not compatible with HS-NG.
12:12 < petertodd> gmaxwell: oh, you mean Tor's new hidden services standard right?
12:12 < gmaxwell> petertodd: yes.
12:13 < gmaxwell> (also I2P though thats not new)
12:13 < wumpus> I think the number of ranges should be variable
12:13 < wumpus> redesigning addr is a different topic
12:13 < wumpus> also necessary, but again, doesn't need to be on one heap
12:13 < gmaxwell> wumpus: when I'm saying ranges I am specifically referring to the top-N zomes.
12:14 < petertodd> well, so if we add service bits for recent history ranges, that should be possible to implement as a separate feature to archival history ranges, and it'd be a big first step
12:14 < wumpus> I think it should be possible to, say, only host the first 20GB of blocks
12:14 < jonasschnelli> historic only nodes
12:14 < wumpus> I don't see why it should be restricted to only recent history
12:14 < petertodd> I don't think it's likely we'll see the two different features collide, so maybe implement recent history ranges first
12:14 < wumpus> or I mean first 20GB + last 144 blocks 
12:15 < gmaxwell> For history storage, I was previously working on a proposal where nodes could signal a small (32 bit) seed and a size and from that everyone would know what parts of the history they would store.  I was so far unable to unify two different schemes, one which was computationally efficient to figure out who had what, and one which never required a peer to fetch a block it had previously deleted.
12:15 < sipa> so very quick breakdown: out of 7M requested blocks, 100k were for the tip, range 2-2500 has around 200-2000 requests per block, and from 10000 to genesis deep there are around 20 per block
12:16 < gmaxwell> I think for now we should not worry about the old history part and only worry about Top-n vs everything, as that fits into the pruning we already have and can be accomplished purely with service bits.
12:16 < wumpus> the bittorrent problem is different in that there the goal of each node is to have everything
12:16 < petertodd> so a social consideration here, is we can think in terms of recent history as "if there's a flaw, how much would we ever reorg w/o just saying bitcoin has failed?"
12:16 < gmaxwell> petertodd: thats partly why we have the 288 block maximum amount of pruning.
12:17 < petertodd> gmaxwell: indeed, and that's only two days...
12:17 < jonasschnelli> Using multiple service bits for 4 ranges seems to be a hackish-design IMO
12:17 < gmaxwell> at 100 blocks any reorg will _necessarily_ cause unrecoverable losses. So 288 basically gives a day plus an extra day for overhead. 
12:17 < petertodd> there's also a natural time criteria from how the difficulty adjustments reduce your resistance to 51% attack - if your node is offline longer, the minimum attacker size to fool you goes down
12:17 < sipa> strangely enough: i see much more requests around 1000 deep than around 100 deep
12:18 < gmaxwell> jonasschnelli: I don't see anything hackish.
12:18 < wumpus> jonasschnelli: I also think it's a strange use of service bits
12:18 < jonasschnelli> I'd prefere using a single service bit to state pruned blockchain and then a new message (or append something to version?)
12:18 < petertodd> sipa: probably because people don't turn their nodes on and off every day
12:18 < gmaxwell> sipa: you probably want to filter out the bitnodes spider, as I believe it requests a block to check the node is working.
12:18 < sipa> gmaxwell: ah.
12:18 < gmaxwell> petertodd: someone who hasn't turned their node on will request all of 0 to -1000. so it will not make 1000 greater.
12:19 < gmaxwell> jonasschnelli: NAK.
12:19 < petertodd> gmaxwell: oh! I didn't know we did that
12:19 < sipa> i'm a bit surprised people think there is no need to have the available block ranges indicated in addr messages
12:19 < sipa> (whether through service bits, or some extension)
12:19 < jonasschnelli> I think there is a need... but it could be a second step
12:19 < wumpus> jonasschnelli: appending to version should be unnecessary, that's also a hack :)
12:19 < sipa> jonasschnelli: if it's a second step, we need to extend addr, and the whole management of addresses
12:19 < jonasschnelli> Okay. Agree. What about a new message type?
12:19 < jonasschnelli> blockrange
12:19 < sipa> jonasschnelli: you don't understand.
12:20 < gmaxwell> jonasschnelli: look at pieter's request figures, if nodes are effectively forced to go to peers that have everything whenever they connect becuase if they don't know they'll be able to fetch any blocks at all, then it will put lots more load on them.. causing people to stop offering blocks... causing more pressure on what remains.
12:20 < sipa> jonasschnelli: the point of having it in service bits is so nodes can find peers that have the range they need
12:20 < wumpus> but addr information gets old really fast
12:21 < sipa> wumpus: much less so with feeler connections
12:21 < wumpus> nodes may dynamically change what blocks they have, so there will always be cases of nodes connecting and realizing they have nothing to offer each other
12:21 < jonasschnelli> Okay. I see the point.
12:21 < sipa> (presumably, i don't have numbers)
12:21 < wumpus> just like currently nodes will try to connect into black holes that no longer host a node
12:22 < petertodd> so another interesting thing here is that ranges are queried linearly - you download blocks in a roughly linear fashion - so we could take advantage of that by making sure that nodes with one range keep track of nodes with adjacent ranges
12:22 < wumpus> sipa: sure, feeler connections make it somewhat better
12:22 < gmaxwell> wumpus: yes, sometimes the data is wrong. But there is a big difference between having 80% of the nodes on the network giving you no idea if they'll be useful at all until after you connect, vs a suggestion that might sometimes be wrong.
12:22 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
12:22 < wumpus> but I don't think addr is a very up-to-date information source
12:22 < petertodd> thus, as you sync the first time, ask nodes with the range you're syncing at this moment for the next range you need
12:23 < luke-jr> wumpus: if ranges are deterministic, they don't need to be up to date
12:23 < sipa> petertodd: yes, any sharding plan wouldn't randomly distribute the kept blocks, but keep randomly distributed ranges
12:23 < gmaxwell> wumpus: I don't know if you realize that sipa and I are not thinking in terms of absolute ranges here. but nodes saying "I keep the last 288" or "I keep the last 2016" or "I have all of history". 
12:23 < wumpus> gmaxwell: but indeed this is a different problem from the bittorrent problem where everyone's goal is to have everything
12:23 < sipa> gmaxwell: well that's sharding... maybe that is something to postpone for later
12:24 < petertodd> sipa: sure, I'm more talking about how the linearity affects the network p2p design - prefentially peering with peers with the adjacent range may even be a reasonable design
12:24 < luke-jr> wumpus: eh, everyone needs to get everything
12:24 < wumpus> there, nodes can just connect randomly and have a high change the other nodes has something to offer them
12:24 < gmaxwell> wumpus: and I wouldn't expect that data to go out of date fast.. pretty much only when nodes go up and down.
12:24 < sipa> oh, nvm, i'm misreading
12:24 < wumpus> luke-jr: only initially
12:24 < luke-jr> oh, I see the distinction
12:24 < wumpus> luke-jr: bittorrent nodes don't throw away blocks, generally
12:24 < luke-jr> f(best-height, seed-in-addr) -> ranges
12:25 < gmaxwell> for the spreading the history around, as mentioned I came up with concrete schemes (based on consistent hashes) that have nice properties. 
12:25 < sipa> i wonder whether we need to have that in the first go at this
12:26 < jonasschnelli> I think a first simple solution that allow to extend it further would be appriciated.
12:26 < sipa> even just having serve-everything and server-the-last-288-and-relay-at-tip would be a good addition
12:26 < wumpus> making the ranges deterministic makes some sense, on the other hand, it does restrict the flexibilty of nodes to choose what ranges they host, it means everything has to be got right in first try
12:26 < gmaxwell> sipa: thats what I am saying.
12:26 < jonasschnelli> sipa: agree
12:26 < gmaxwell> I do not think we can do better immediately anyways.
12:26 < sipa> 21:18:07 < jonasschnelli> I'd prefere using a single service bit to state pruned blockchain and then a new message (or append something to version?)
12:26 < gmaxwell> sipa: though your latest figures suggest that the 2016 depth is important too.
12:26 < sipa> 21:19:07 < gmaxwell> jonasschnelli: NAK.
12:27 < petertodd> if nodes attempt to maintain a few connections to peers that have the next range after they have, maybe it doesn't matter exactly what the ranges actually are? any given node would have a few connections to the next range, and anyone syncing from them could ask for those connections
12:27 < gmaxwell> sipa: my understanding of jonasschnelli comment was there should be a bit that says "I relay blocks but don't have history" I am NAK on that.
12:27 < wumpus> as there is no scope for later optimization, because all nodes have to agree what ranges are implied
12:27 < jonasschnelli> We could add a service bit that says "I relay only the last 288 blocks"
12:27 < wumpus> jannes: yes that would be the initial idea
12:27 < wumpus> jonasschnelli*
12:28 < sipa> gmaxwell: how is that different from what i suggested?
12:28 < sipa> 21:26:10 < sipa> even just having serve-everything and server-the-last-288-and-relay-at-tip would be a good addition
12:28 < jonasschnelli> I think my initial idea with the general pruning sevice bit and a new message type is to complex and inflexible
12:28 < gmaxwell> jonasschnelli: yes, that would be better, though pieter's data suggests that there are a LOT of requests at 1000. I think if I had that data I would have been suggesting the maximum pruning should be 2016, and then had the bit at that dep. 
12:28 < gmaxwell> sipa: the ability to relay blocks at depth -10.
12:29 < sipa> gmaxwell: less than 2% of blocks requested from my node are at the tip
12:29 < sipa> (but the tip is still 100x more frequent than any other individual depth)
12:29 < sipa> gmaxwell: "a service bit to indicate pruned blockchain" implies you can serve 288 deep :)
12:30 < petertodd> gmaxwell: re: maximum pruning depth, it's reasonable for that to be a similar % of the total data that storing the UTXO set takes - if you have 10GB of UTXO, 2GB of block data isn't a big change
12:30 < wumpus> yes, you could define it as that
12:30 < gmaxwell> I don't think there is any remaining disagreement on using bit(s) to signal I have a top-n.  But I have some doubt on N. it needs to capture the largest amount of the block realy bandwidth without being unduely pruning incompatible.
12:30 < wumpus> 288 is the minimum pruning amount in bitcoin core already so it'd be a valid choice
12:30 < morcos> as a first pass, i wonder if you preferentially downloaded from pruned peers whenever you were behind by less than 288 blocks, that would take enough load of peers serving full history?
12:30 < gmaxwell> morcos: absolutely.
12:30 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
12:30 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
12:31 < jonasschnelli> Good idea
12:31 < wumpus> yes, that would make sense
12:31 < gmaxwell> unfortunately, sipa's data suggests that 288 sheds less traffic than measurements years ago suggested.
12:31 < sipa> maybe i should compute statistics in bytes rather than blocks
12:31 < morcos> gmaxwell: it wasn't clear to me what the integral from 1 to 288 was compared to 288 to inf
12:31 < wumpus> well it is a compromise
12:31 < wumpus> putting the threshold higher makes some peers completely useless
12:31 < sipa> to see what percentage of bandwidth is needed in 1-288
12:31 < wumpus> which reduces morcos 's argument
12:32 < jonasschnelli> Yes. I guess you convinced me to use two service bits then. -288 and -2016
12:32 < gmaxwell> which is why it might be useful to use two bits and be able to signal 1-288, 1-2016... and perhaps start encouraging people to not prune shorter than 2016.
12:32 < sipa> i think we're getting into a design discussion here
12:32 < sipa> my number are very premature and not well analysed
12:32 < wumpus> it'd also be possible to add a 288-flag now, and then consider a 2016 flag later
12:32 < gmaxwell> sipa: indeed, thought that was the input you requested from me. 
12:32 < morcos> wumpus: yes, thats what i'm saying
12:32 < gmaxwell> wumpus: yes! indeed.
12:33 < jonasschnelli> Agree with wumpus 
12:33 < wumpus> if it turns out to be necessary
12:33 < petertodd> wumpus: ACK
12:33 < sipa> yes, i think just a 1-288 one seems useful
12:33 < wumpus> good :)
12:33 < jonasschnelli> Start with a simple tip-288 relay, and get some experience
12:33 < gmaxwell> wumpus: it looks pretty clearly necessary but no need to do everything at once.
12:33 < petertodd> wumpus: basically advice is, turn your node on at least once every two days
12:33 < wumpus> petertodd: yes
12:33 < gmaxwell> petertodd: we really should have cron mode for the daemon where it just syncs up and shuts off. :P
12:34 < gmaxwell> bitcoind -oneshot
12:34 < gmaxwell> :P     
12:34 < petertodd> gmaxwell: heh, that's not a crazy idea - I'd use it on my laptop
12:34 < jonasschnelli> didn't we once had a proposal for the pause option?
12:34 < wumpus> right, there's a flag that quits after reindex, but none that exits after sync
12:34 < wumpus> would be easy to add tho
12:34 < morcos> we could just ask for the utxo set, shoudl we discuss ideas how to do that
12:34 < CodeShark> ^ yes :)
12:34 < petertodd> make -oneshot run in the foreground with a progress bar :)
12:34 < wumpus> without utxo commitment that's a no-go
12:35 < morcos> thanks codeshark
12:35 < petertodd> wumpus: +1
12:35 < gmaxwell> morcos: pointless when we were unable to get past the discussion for the security model change to not validate the past history based on proof of work. 
12:35 < petertodd> and lets not underestimate how dangerous UTXO commitments can be - I'm very dubious about committing to the (U)TXO set more recently than maybe a month or two
12:35 < CodeShark> would be great to query utxo for quick sync, then go backwards in time fetching blocks to increase security...but yes, this is a design discussion
12:35 < morcos> i was making a joke, sorry
12:36 < CodeShark> alas, quick sync doesn't look feasible in the nearterm
12:36 < wumpus> ok, next topic?
12:36 < gmaxwell> but since that was brought up... Can we talk about removing checkpoints? 
12:36 < wumpus> #topic removing checkpoints
12:36 < sipa> what % of transactions are before the last checkpoint
12:37 < sipa> does anyone know?
12:37 < morcos> someone should write up a design proposal for that to be evaluated
12:37 < gmaxwell> Right now they're used for two things, preventing header flooding with low difficulty headers; and skipping signatures in earlier blocks.
12:37 < petertodd> gmaxwell: just removing checkpoints, or assuming sigs are valid if buried deep enough?
12:37 < sipa> gmaxwell: and 3) estimating progress
12:37 < wumpus> keeping something for estimating progress would make sense
12:37 < sipa> i think 1) remains needed and 3) remains useful
12:37 < wumpus> that doesn't need to be checkpoints
12:38 < gmaxwell> because very few percentage of the transactions are below the checkpoint .. since libsecp256k1 (and I expect the checkqueue)-- my point two is basically pointless, and I think it could just be removed
12:38 < gmaxwell> I think on a desktop it only adds 15-20 minutes to the sync.
12:38 < petertodd> gmaxwell: I'd ACK simply removing checkpoints entirely; I'm not happy to see them replaced with another scheme to skip sig checking
12:38 < wumpus> a block-height-to-relative-difficulty map would have much less of a stigma
12:38 < wumpus> eh, verification difficulty that is
12:38 < sipa> gmaxwell: really?
12:38 < gmaxwell> petertodd: I think we could remove CP from reason two without implementing the replcement.
12:39 < gmaxwell> petertodd: morcos is right that needs a design proposal outside of the meeting.
12:39 < sdaftuar> i'm a bit confused about how to think about checkpoints for signature skipping
12:39 < gmaxwell> sipa: I benchmarked before but I'm going off of memory, I could be wildly wrong. I will test again if there is interest.
12:39 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-fbqfpfayfjsuqdbq] has quit [Ping timeout: 252 seconds]     
12:39 < jonasschnelli> Removing checkpoints would slow down (maybe insignificant) a scan in a possible SPV hybrid mode?
12:39 < gmaxwell> For reason (1) the only answer I have is that I think we should proposal a bit to perpetually increase the minimum difficulty from 1 to something else.
12:40 < sdaftuar> for instance the recent ISM change caused us to do less validation for certain blocks in our history (blocks in a softfork between the 75% and 95% thresholds)
12:40 < sipa> jonasschnelli: SPV mode won't validate *anything* at all
12:40 -!- mturquette [sid66043@gateway/web/irccloud.com/x-wfluekpafpcxaxkd] has quit [Ping timeout: 252 seconds]     
12:40 < gmaxwell> (with a checkpoint like bypass of that new rule, for existing blocks that break it) As little as 100,000 would eliminate the header flooding vulenrablity.
12:40 < jonasschnelli> Yes. But assume we would add an SPV hibrid mode in oder to received payment during IBD
12:40 < jonasschnelli> One would need to download 400k headers without a checkpoint at h400k
12:40 < luke-jr> maybe checkpoints should just be disabled by default before complete removal?
12:41 < sipa> jonasschnelli: i think you're confused
12:41 < gmaxwell> for Sipa's (3) reason for 'checkpoints' I don't give a darn, use chicken bones for progress estimation for all I care. :P it's historical accident that checkpoints and progress use the same data structure.
12:41 -!- jl2012 [77f6f5f1@gateway/web/freenode/ip.119.246.245.241] has joined #bitcoin-core-dev     
12:41 < morcos> gmaxwell: :) +1
12:41 < wumpus> gmaxwell: yes, my point too
12:41 -!- jl2012_ [uid133844@gateway/web/irccloud.com/x-xfqvuqvlsjfzvyhx] has joined #bitcoin-core-dev     
12:41 < sipa> gmaxwell: agree, those could be completely separated
12:41 < petertodd> gmaxwell: ACK checken bones
12:41 < gmaxwell> Might as well fit a cubic spline to the height vs txn count... and store the parameters.
12:41 < wumpus> right
12:42 -!- jl2012 [77f6f5f1@gateway/web/freenode/ip.119.246.245.241] has left #bitcoin-core-dev []     
12:42 < petertodd> gmaxwell: heh, if we do that with floating point math that has the advantage that it _can't_ be used for consensus :)
12:42  * sipa now remembers a song our student organization wrote to the melody of staying alive, called 'cubic spline'
12:42 < gmaxwell> so my proposal, if there is interest, is that I'll measure the performance impact of removing the signature skippingentirely (esp post checkqueue). And if it's not awful, we'll remove.
12:42 < wumpus> +1     
12:42 < sipa> gmaxwell: i'm unconvinced
12:42 < wumpus> it doesn't hurt to benchmark
12:42 -!- mturquette [sid66043@gateway/web/irccloud.com/x-thdwjhafddzjgnzb] has joined #bitcoin-core-dev     
12:43 < gmaxwell> and maybe I'll tender a proposal to up the minimum difficulty, but I'd like to know what people think about that.
12:43 < wumpus> measuring is always better than making assumptions
12:43 < sipa> with a replacement for sig skipping that isn't based on checkpoints we could significantly improve things
12:43 -!- zmanian___ [sid113594@gateway/web/irccloud.com/x-zxxxxyhdkhqrcqpr] has quit [Ping timeout: 252 seconds]     
12:43 < petertodd> sipa: I don't think such a replacement can exist without changing the security assumptions; I'd *rather* have checkpoints than trusting hashing power for that
12:43 < sipa> the last checkpoint currently is very old for the very reason that we've been planning to replace it
12:43 < gmaxwell> sipa: would you like to help work on a proposal for that? it has been controversial in the past. I'd like to do something good, because otherwise imprudent attempts will be adopted instead.
12:44 < sipa> so it's unfair to use the "the last checkpoint is old" as a given; it's something we've affected indirectly
12:44 < petertodd> sipa: though what checkpoints should do is say "Something big has changed; you can disable checkpoints with --no-checkpoints, but you should find out what this means before doing so."
12:44 < gmaxwell> (for example Bitcoin Classic's current behavior simply looks at block header timestamps and ignores signatures when they're more than 24 hours (*par) old by the local clock. It's easily exploited and makes me sad.
12:44 < sipa> petertodd: it's my opinion that on a timescale of months, it doesn't matter
12:44 < sipa> IF you can guarantee it's actually a timescale of months
12:44 < wumpus> yes that makes me sad too
12:44 < petertodd> sipa: on a timescale of months, checkpoints shouldn't matter either...
12:45 < wumpus> anything based on time seems very brittle
12:45 < sipa> petertodd: look at the current hashrate; what's 3 months worth of chain work at that hashrate
12:45 < petertodd> wumpus: and anything based on work isn't much better if you're running an old client, and mining has advanced significantly
12:45 < jonasschnelli> sipa: I (hope) I'm not confused. If we would add a SPV hybrid mode directly fetch blocks at the tip (in order to received payments), no available checkpoint would result in downloading all headers *losing* maybe 3-4mins before you can start using SPV... minor issue though, I agree
12:45 < petertodd> sipa: that assumes you know what the current hashrate is
12:45 < gmaxwell> wumpus: the prior proposals were based on work,  e.g. skip if the best chain you see dominates the next conflicted chain at that hight by N months of work.
12:45 < Chris_Stewart_5> gmaxwell: How have we solved the problem that checkpoints were originally created for? You have an excerpt in here: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Checkpoints
12:45 < petertodd> sipa: your node might be surrounded by sybils
12:45 < gmaxwell> wumpus: with a 'minimum total work' coded in as part of the release proces.
12:46 < sipa> Chris_Stewart_5: headers first sync
12:46 < sipa> Chris_Stewart_5: 0.10
12:46 < gmaxwell> Chris_Stewart_5: headers first sync.
12:46 < wumpus> gmaxwell: right. Well, at the least it should be measured whether such a change is really worth it.
12:46 < sipa> petertodd: yes, i know...
12:46 < sipa> so, let's measure.
12:46 < sipa> and discuss later
12:46 < gmaxwell> Chris_Stewart_5: and the signature skipping behavior in checkpoints was actually a result of a bug fixed years ago.. mlock being used on all allocations making script validation INSANELY slow.
12:46 < wumpus> so much of the verification overhead is looking up UTXOs
12:46 -!- zmanian___ [sid113594@gateway/web/irccloud.com/x-arrrnejhhzkzodmj] has joined #bitcoin-core-dev     
12:46 < gmaxwell> sipa: okay.
12:46 < wumpus> something you'll not avoid
12:46 -!- Lauda_ [~quassel@185.122.59.11] has joined #bitcoin-core-dev     
12:47 < gmaxwell> Chris_Stewart_5: but then with chain growth we became dependant on it to keep sync times reasonable. but libsecp256k1 made signature validation >5x faster.
12:47 < wumpus> especially for recent blocks
12:47 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Disconnected by services]     
12:47 -!- Lauda_ is now known as Lauda     
12:47 < wumpus> if you do any benchmarking please look at the recent blocks, not the first N
12:47 -!- Lauda [~quassel@185.122.59.11] has quit [Changing host]     
12:47 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
12:48 < gmaxwell> wumpus: it's still a major speed up on existing blocks.
12:48 < sipa> in a side node: i've already updated my logging to measure bandwidth vs blockdepth instead of just count.
12:48 < Chris_Stewart_5> So header sync solves the attack of flooding disk space, but not having your entire network hijacked, correct?
12:48 -!- harambea [~bea@95.215.44.99] has joined #bitcoin-core-dev     
12:48 < wumpus> Chris_Stewart_5: huh?
12:48 < wumpus> gmaxwell: sure, could be
12:48 < gmaxwell> Chris_Stewart_5: isolation can be resolved by simply knowing what the total work of the best chain was at release.
12:48 -!- lesderid_ [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev     
12:49 < gmaxwell> Chris_Stewart_5: sorry, this was discussed prior times removing checkpoints had come up, I haven't completely described the background.
12:49 < Chris_Stewart_5> gmaxwell: Thanks for the explanation, i'll keep digging. 
12:49 < wumpus> Chris_Stewart_5: ah, you mean being isolated and being fed a wrong chain, sorry I was imaginging some wacky things at having your network hijacked :)
12:50 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 252 seconds]     
12:50 < wumpus> ok, next topic?
12:50 < gmaxwell> wumpus: just the "you got a faithful bitcoin core download but the attacker controls your network"... but that doesn't need a checkpoint to fix, a simple partitioning detction that knows the total work of the best chain at releast time is sufficient.
12:50 < gmaxwell> Thanks for the discussion.
12:51 < wumpus> #topic segwit against uncompressed keys or not
12:51 < wumpus> (10 minutes to go)
12:51 < wumpus> (9 minutes to go)
12:51 < petertodd> so to be clear, *just* segwit right?
12:51 < CodeShark> does anyone still use uncompressed keys?
12:51 < wumpus> yes, only segwit
12:51 < achow101> CodeShark: armory does
12:51 < luke-jr> seems uncontroversial
12:51 < petertodd> I'm happy to ACK that given just segwit
12:51 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
12:51 < achow101> having segwit enforce uncompressed keys would delay segwit adoption for armory users
12:52 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
12:52 < achow101> *compressed
12:52 < jl2012_> it's in #8499
12:52 < luke-jr> achow101: why? just compress them
12:52 < wumpus> gmaxwell: yes, though we had a lot of trouble with partitioning detection, I remember some code being stripped out and such. But anyhow, yes that's the better approach if it can be gotten to work.
12:52 < sipa> achow101: sigh, does armory still not do that?
12:52 < achow101> luke-jr: we have to change the whole wallet structure (it's still going to happen anyways)
12:52 < wumpus> gmaxwell: without too much false positives
12:52 < luke-jr> achow101: why?
12:52 < sipa> achow101: alan said somewhere in 2013 he was implementing it...
12:52 < achow101> alan's gone now..
12:52 < luke-jr> afaik the only downside to using compressed keys is it changes the address, which segwit is changing anyway
12:52 < CodeShark> it's not a very complicated change
12:52 < wumpus> armory still uses uncompressed keys?!
12:53 < luke-jr> there's no reason you'd need to change the wallet structure I can see
12:53 < wumpus> in any case this only applies to segwit, not to old transactions
12:53 < achow101> the plan is to have a new wallet structure with bip32 that supports segwit and compressed keys
12:53 < gmaxwell> wumpus: "you're partitioned until you see a header chain with at least work X" is a pretty simple critera. :P
12:53 < sipa> luke-jr: it had fixed size records in its wallet format for pubkeys
12:54 < sipa> achow101: well if a new wallet format is needed for segwit anyway, it doesn't matter right?
12:54 < gmaxwell> achow101: oh god please do not use uncompressed keys with segwit. why would you do that?
12:54 < luke-jr> sipa: zero-pad it?
12:54 < achow101> sipa: well no, we don't need a new wallet for segwit as it could still work with the old one with a little bit of hacking
12:54 < achow101> that was the original plan
12:54 < luke-jr> achow101: no less than compressed could
12:55 < luke-jr> sipa: or store the uncompressed key, and compress it at address-generation/signing
12:55 < gmaxwell> achow101: why cant the same hack that indicates segwit is in use indicate compressed.. you just chop off some bytes of the key pretty much.
12:55 < sipa> btw, uncompressed keys account for 0.7% of used keys in succesful sigs on the network (in the past 2 hours)
12:55 < gmaxwell> it could be done entirely inside the process that seralizes the segwit scriptpubkey.
12:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
12:55 < achow101> gmaxwell: idk. ask goatpig
12:56 < gmaxwell> achow101: okay
12:56  * michagogo pokes his head in belatedly
12:56 < CodeShark> I think we should encourage all wallets to use compressed keys - achow101, if you need help with this I'd be willing to help
12:56 < sipa> agree - we should help
12:56 < gmaxwell> yes, lots of people would be glad to help.
12:56 < sipa> instead of just yell
12:56 < gmaxwell> well I offered to help armory move off uncompressed keys to alan several times, including offering to pay to do it.
12:56 < gmaxwell> so please don't say anyone just yelled.
12:58 < CodeShark> I initially designed my account structures to only use compressed keys - but later added a compressed bit to support legacy stuff
12:59 < petertodd> CodeShark: what legacy stuff specifically? legacy armory users?
12:59 < wumpus> CodeShark: bah,it's kind of sad that to hear some things seem to be going back instead of forward :)
12:59 < CodeShark> yes, to support other wallets
12:59 -!- anchow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
12:59 < wumpus> it's time
12:59 -!- lesderid_ [~lesderid@anna.lesderid.net] has quit [Quit: bai]     
12:59 < CodeShark> but I think we really do need to prod all wallets to move to compressed keys
12:59 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev     
12:59 -!- anchow101 [~achow101@unaffiliated/achow101] has quit [Client Quit]     
13:00 < CodeShark> there's really no reason to continue to support uncompressed keys - other than perhaps some migration tools
13:00 < wumpus> #endmeeting
13:00 -!- anchow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
13:00 < gmaxwell> CodeShark: as pieter notes, virutally nothing is already.
13:00 < lightningbot> Meeting ended Thu Sep 29 20:00:15 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-29-19.01.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-29-19.01.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-29-19.01.log.html
13:00 < gmaxwell> 0.7% percent
13:00 < anchow101> Yes, help would be appreciated
13:01 < wumpus> well supporting it in consensus for the normal network keeps making sense, but segwit is just such a great oppertunity to get rid of it
13:01 < petertodd> wumpus: yeah, I don't see how we can remove backwards compatibility for it w/o confiscating funds, but no reason to not remove support in new addresses
13:01 < wumpus> petertodd: indeed
13:01 < gmaxwell> yes, thats why its important to get rid of now. otherwise I wouldn't care if action were taken n months later.
13:01 < luke-jr> if anything, we should be discussing whether to make it a consensus rule rather than a policy ;)
13:02 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
13:02 < gmaxwell> luke-jr: I like to but many people feel that addining an additional consensus rule for segwit now wouldn't be prudent.
13:02 < gmaxwell> making it non-standard is sufficient in my view, such that we'd be able to make it a consensus rule later.
13:02 < btcdrak> achow101 seems to be having connection problems
13:02 < luke-jr> sure
13:02 < achow101_> btcdrak: just a little bit. switching computers
13:02 < CodeShark> gmaxwell: having to deal with the additional case complicates implementations
13:02 < luke-jr> just saying the rule shouldn't be controversial itself really
13:03 < CodeShark> not very much, but still
13:03 < petertodd> gmaxwell: well, so long as we loudly warn that this is intended to become unspendable later if you bypass the standardness
13:03 < morcos> gmaxwell: if so, we should be as clear about it being not allowed now as if we were to make it a consensus rule now.
13:03 < gmaxwell> for those thinking that we have to verify all the old stuff for all time, that might be true for bitcoin core, but in the future I could imagine some implementations just not bothering to verify old stuff. 
13:04 < gmaxwell> morcos: petertodd: agreed for sure. 
13:04 < sdaftuar> petertodd: ntoe that it's standard to create an output with an uncompressed pubkey hash, as we can't detect the issue until a spend attempt (right?)
13:04 < jtimon> I agree with luke-jr on not seeing the controversy in it being consensus rule with the rest of segwit
13:04 < petertodd> gmaxwell: I don't mean verifying old stuff, I mean verifying new txs spending old coins
13:04 < petertodd> sdaftuar: yes, nothing we can do about that though
13:05 < gmaxwell> jtimon: well in the case of low-S which we also wanted to make a consensus rule, jl2012 discovered that there were corner conditions we wanted to think about more carefully before making it a consensus rule.
13:05 < sdaftuar> petertodd: right; just want to make sure we're all on the same page as i think communicating this widely/loudly is important
13:05 < petertodd> for example, we've made hybrid pubkeys non-standard, and given basically no-one's ever used them in production for anything I'd have no issues with making them unspendable in a soft-fork
13:05 < jtimon> gmaxwell: thanks
13:06 < gmaxwell> jtimon: I don't think the same applies to uncompressed keys, because the criteria there is even simpler. but the lowS reason is part of why we punted this collection of improvements to policy for now.
13:06 < jtimon> mhmm
13:06 < michagogo> I saw a movie that depicts a form of distributed/decentralized system, to avoid it getting shut down. Or in the words of the character that explains it, "everyone that logs on is a server". It's said to be "open source", but then that's explained as "anyone can edit the code, like Wikipedia.
13:07 < achow101_> so if anyone wants to help armory with segwit support, bip32, compressed keys, we accept PRs. All our work happens in the dev branch, not master
13:07 < michagogo> And the code is deployed when a majority of users approve it
13:07 -!- veleiro [809aa323@fsf/member/veleiro] has quit [Ping timeout: 240 seconds]     
13:08 < wumpus> michagogo: heh, open source in some weird twisted mirror world
13:08 < gmaxwell> achow101: is there a IRC channel where things are discussed? E.g. where should I ask goatpig about compressed pubkeys in segwit.
13:08 < sipa> michagogo: i believe they're mistakingly not describing a computer network, but politics.
13:08 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has quit [Ping timeout: 240 seconds]     
13:08 < achow101_> #bitcoin-armory
13:08 < jtimon> michagogo: that is, when sybil decides so...
13:08 < luke-jr> achow101_: meh, should just collapse that into #bitcoin-dev :p
13:09 < michagogo> And it's completely vulnerable to Sybil attacks…
13:09 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 264 seconds]     
13:09 < michagogo> Gah, lagging
13:09 < michagogo> Yeah
13:10 < michagogo> And of course, when the last user logs off, it doesn't just stop working
13:10 < michagogo> The sybil attackers are able to watch it dramatically implode with special effects, "graphical corruption" type stuff
13:11 < michagogo> And there's the obligatory "they're blocking all our foreign IPs" and that kind of stuff, with no explanation of who "they" are
13:12 < jtimon> so what was there a conclusion for the range service bits? nothing/top-288/everything? 
13:12 < jtimon> what about the getrange message and "sharding"
13:12 < GitHub159> [bitcoin] laanwj opened pull request #8843: rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` (master...2016_09_getinfo_clientside) https://github.com/bitcoin/bitcoin/pull/8843
13:12 < wumpus> conclusion was to add one service bit: last-288-served
13:13 < wumpus> and maybe later one for last-1000-served
13:13 < jtimon> wumpus: I see, and leave the rest for later, thanks
13:13 < luke-jr> 1024 would be rounder. ☺
13:13 < wumpus> and a jackpot for whoever enabled both at once
13:13 < luke-jr> if you set both, does it mean last 288000? :P
13:14 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
13:14 < jtimon> would it be crazy to just have last-1024 without last-288 and just change prunning's default?
13:14 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
13:14 < wumpus> 288 is not just the default, it's the minimum
13:15 < wumpus> I'd be okay with changing the default not the minimum, but that'd keep some nodes completely useless
13:15 < wumpus> whereas by far most requests are in the last 288
13:15 < luke-jr> wumpus: useless for syncing*
13:15 < luke-jr> frankly, there are enough full-archive nodes out there that we really don't *need* to do anything right now, so meh :p
13:16 < sipa> wumpus: actually, not true.
13:16 < jtimon> well, the users know what to do to stop being useless...
13:16 < wumpus> which, as morcos remarked, preferentially downloading the last blocks from would take a lot of load of nodes that do keep more blocks
13:16 < sipa> there are more requests in 101-1000 deep then 2-100 deep
13:16 < wumpus> ok...
13:16 < sipa> *than
13:16 < wumpus> I misremembered apparently, never mind
13:16 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:16 < luke-jr> an unsyncable-from node is still more useful than a syncable node that isn't used for a wallet
13:16 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
13:17 < luke-jr> syncable-from*
13:17 < jtimon> maybe we can changethe prunning minimum if that simplifies things?
13:17 < sipa> wumpus: well, sample of 1 long-term-running node over the course of a few weeks of data
13:17 < sipa> wumpus: more samples welcome
13:17 < wumpus> sipa: do you have a special patch for statistics collection?
13:18 < gmaxwell> sipa: need to filter out bitnotes. 
13:18 < sipa> gmaxwell: right; how do you suggest to do that?
13:18 < wumpus> sipa: or a script for parsing logs?
13:18 < sipa> wumpus: both; i'll publish them after a little cleanup
13:18 < wumpus> I could put it up on a few nodes, no problem
13:19 < sipa> it just logs an extra line with depth and block size for each requested block
13:19 < wumpus> nice
13:19 < jtimon> I guess it's not completely crazy, but nobody seem to specially like it
13:19 < sipa> en then
13:19 < sipa> S=0; fgrep DEEP ~/.bitcoin/debug.log | cut -d ' ' -f 4 | sort -g | uniq -c | tac | while read C D; do S=$(($S+$C)); echo "$D $C $S"; done | tac | less
13:19 < sipa> to inspect :)
13:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:20 < wumpus> jtimon: no, it's not completely crazy, using only one service bit is kind of elegant
13:21 < jtimon> :)     
13:22 < wumpus> jtimon: if 1000 is really one-size-fits-all, and <1000-keeping nodes may as well be ignored. It's just hard to say without better statistics.
13:22 < wumpus> also statistics about what pruning sizes people prefer
13:22 < wumpus> I mean if everyone prefers the minimum and no one sets 1000 in practice
13:23 -!- anchow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 244 seconds]     
13:23 < gmaxwell> sipa: just do Satoshi:(recent) useragents.
13:23 < jtimon> well, independenlty of the statistics we will eventually need a more generic solution for flexible sharding, right?
13:23 < sipa> jtimon: maybe
13:24 < sipa> "need" is a big word imho
13:24 < sipa> but i agree it would be nice
13:24 < gmaxwell> jtimon: I think we do, would you like to finish the solution for that I started on?
13:24 < wumpus> jtimon: well there needs to be a different solution for historical block hosting IMO, but that's a different thing
13:25 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
13:25 < gmaxwell> sipa: I think excepting participants to keep around hundreds of gigs of blockchain is not conducive to the surival of the network, the alternative I see is a hardfork that drops off the history past some point. (e.g. just restarts the chain from a utxo commitment made a year before)
13:25 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
13:26 < sipa> gmaxwell: well, or just stop supporting historical block fetching more than 1 year or whatever number back on the p2p protocol, and use http
13:26 < wumpus> or bittorrent *ducks*
13:26 -!- brainwave [4e99cc65@gateway/web/freenode/ip.78.153.204.101] has joined #bitcoin-core-dev     
13:26 < jtimon> wumpus: yeah, historical hosting is what I mean
13:27 < jtimon> gmaxwell: maybe, but it sounded deterministic like luke-jr proposed instead of flexible like wumpus wanted
13:27 < wumpus> it could be anything that supports downloading ranges of data...
13:27 < brainwave> Under overview, balances, on the right side of  available, pending, total, add ~ exchange rate for dollars, pounds, euro 
13:28 < sipa> brainwave: bitcoin core does not and cannot know exchange rates
13:28 < sipa> (because it would require contacting a centralized service, which we don't do by design)
13:29 < wumpus> yes or someone would need to commit them to the chain, but that'd still be trusting a central issuer/signer of the information
13:29 < wumpus> it's just a no-go
13:30 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:32 -!- brainwave [4e99cc65@gateway/web/freenode/ip.78.153.204.101] has quit [Ping timeout: 240 seconds]     
13:35 < gmaxwell> well if the users of bitcoin accepted that kind of security model change, what I would suggest is something like every 26280 blocks the block is required to have a commitment to the utxo set (could be a linear hash) as of 2016 blocks prior. and then six months of work after that, that commitment becomes usable for initial sync. and so then no one need process more than a year of blocks at sync. 
13:35 < gmaxwell> .. though you would have to store three copies of the utxo set (though perhaps deduplicated)
13:36 < gmaxwell> jtimon: I don't know why anyone would find determinstic less desirable.
13:37 < sipa> gmaxwell: well i expect the controversy to not be about the change in security model, but about the perpetual requirement of having a utxo set
13:37 -!- bad_duck [~arthur@area51.powaaa.com] has quit [Ping timeout: 252 seconds]     
13:37 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
13:38 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
13:38 -!- bad_duck [~arthur@2001:bc8:c087:1001::1] has joined #bitcoin-core-dev     
13:40 < wumpus> gmaxwell: I explained that: if you make it deterministic you have to be sure of the parameters in advance, there is no room for tweaking or optimizing later on
13:42 < gmaxwell> wumpus: well you simply extend the protocol to have a new signaling mechenism for the tweaked thing.
13:42 < wumpus> sipa: yes the bigger problem is the ever-growing UTXO set
13:42 < wumpus> gmaxwell: but then it loses backwards compatibility every time
13:42 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]     
13:43 < gmaxwell> something that just signals absolute heights has the problem that the communicated information will always be out of date. .. or if nodes don't change the ranges they host, we will end up with highly irregular distributions of information.
13:43 < sipa> the type of tweaking needed, and the potentially aging problem depend on the specific proposal
13:44 < sipa> i'm sure we can come up with something that seems reasonable to all
13:44 < wumpus> agree, there may be a compromise that is somewhat flexible and still deterministic
13:44 < gmaxwell> well what I suggested might not be viable after all too. I'm not sure, I wasn't successful in achieving all my goals at once.
13:45 < wumpus> I just don't think setting it all in stone in advance is a good idea, for the whole reason that it's so hard to achieve all your goals all at once
13:45 < wumpus> especially if you don't know some of those goals yet
13:45 < gmaxwell> I wanted a scheme that would result in a uniform distribution of blocks, that didn't depend on peers to look to see what other peers had (because that could be spoofed), required minimal communication (not a long list of blocks in an addr message).. and retainined uniformity as the chain grew, without causing peers to redownload blocks they already forgot.
13:47 < gmaxwell> So I had found two schemes, one where peers had a ID and the amount of blocks they would store, and from that they could determine which they would store, and as new blocks came in they might store then and drop some group of old ones.  The problem with it was that to figure out if a particular peer had block X you had to do computation linear in the number of blocks in the chain.
13:47 < wumpus> darn, also fingerprinting will be hard to avoid
13:47 < gmaxwell> Then I had another scheme that was sublinerar work, BUT a peer might drop a block but later have to go fetch it again. 
13:47 < gmaxwell> wumpus: thats unavoidable with any split up scheme.
13:48 < wumpus> yes     
13:48 < sipa> make the IP address part of the seed
13:48 < sipa> if your dhcp changes, you have to resync, sorry.
13:48 < wumpus> unless a substantial part of nodes are the same
13:48 < gmaxwell> sipa: then when you change IP, you have to go download a different set of blocks.. :P hah
13:48 < wumpus> e.g. there are only 8 IDs, pick one
13:48 < gmaxwell> wumpus: well I was thinking 32 bits, but perhaps a smaller collection would be fine. 
13:49 < gmaxwell> but that gives you at best only 1/8th spitting storage. :( maybe fine now, but not in the long term.
13:49 < wumpus> maybe the number of groups can grow over time, a doubling every so many blocks :)
13:50 < sipa> hah: if you get a request through an IP that doesn't correspond to your local storage, just proxy all requests through to another node which does, and use that to gradually resync for the new seed.
13:50 < gmaxwell> Part of why I haven't given this that much more thought is because I think bitcoin will need to move to the commit state and forget history model; the ever growing sync time is too big a tide to stand against.
13:50 < gmaxwell> sipa: lol!
13:50 < gmaxwell> sipa: I think thats actually how the freenet location swapping works, funny enough.
13:50 < wumpus> hehe
13:50 < sipa> downside: if you want this to be fingerprint resistant, you have no way to determine how many proxies your blocks actually went through
13:50 < sipa> => instant mixnet
13:51 < gmaxwell> sipa: freenet nodes change position over time, and they do it by swapping their location with a direct neighbor, when that location swap makes them both closer to where they want to be, ... when requests come in for the new location, they don't have the data, but it's only one hop away..
13:52 < wumpus> gmaxwell: I've always thought that, it's hard to imagine this continuing for 10's of years, but where to put the anchor...
13:52 < gmaxwell> in any case. if there were only 8 flavors of nodes, then it all becomes simple, block_height//1000 % 8 = flavor. 
13:53  * gmaxwell lunch
13:54 < wumpus> that seems kind of elegant and straightforward, there must be a catch
13:58 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
13:59 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
13:59 < jtimon> gmaxwell: sorry, well the deterministic seems to come at the cost of less flexibility
14:00 < sipa> wumpus: i'm trying to think about why 8 isn't enough
14:00 < wumpus> if you want to automatically scale the number of flavors up with height you could divide height 0..N into X flavors, the N..3N into 2*N flavors, and so on, where each flavor gets flavor (x<<1)+randbit()
14:01 < jtimon> only 8 flavors requires you to store 1/8 of the blockchain
14:01 < sipa> and we could have names for the first 8 top-level flavours or so... so your wallet could report "Looking for a bittersweet node..."
14:01 < wumpus> (well those numbers are arbitrary but the idea is that if a doubling of the # is needed, the new flavor, a member of a twice as big set, would contain the previous one)
14:02 < wumpus> hehe, yes assigning names would be nice
14:13 -!- jasonv76 [~jasonv75@178.62.254.214] has quit [Ping timeout: 252 seconds]     
14:14 -!- jasonv76 [~jasonv75@178.62.254.214] has joined #bitcoin-core-dev     
14:18 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
14:18 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]     
14:19 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Ping timeout: 272 seconds]     
14:19 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
14:20 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
14:21 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
14:22 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Client Quit]     
14:31 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
14:40 -!- sipa [~pw@2a02:348:86:3011::1] has quit [Changing host]     
14:40 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev     
14:40 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
14:40 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
14:41 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []     
14:46 -!- cdecker [~quassel@2a02:aa16:1105:4a80:7d39:b0e3:868e:8873] has quit [Ping timeout: 272 seconds]     
14:46 < GitHub131> [bitcoin] jnewbery opened pull request #8844: change sigops cost to sigops weight (master...sigops_weight) https://github.com/bitcoin/bitcoin/pull/8844
14:48 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has quit [Quit: gabridome]     
14:49 < GitHub72> [bitcoin] jnewbery opened pull request #8845: Don't return the address of a P2SH of a P2SH (master...trivial-P2SH-P2SH) https://github.com/bitcoin/bitcoin/pull/8845
14:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
14:51 < gmaxwell> jtimon: "less flexible" -- everything is less flexible short of sending someone arbritary x86 bytecode that they run.
14:51 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
14:51 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
14:53 < jtimon> less flexible in the amount of data you store, but maybe 8 flavors can be subidivided in 16 flavors half the size as wumpus was suggeting, then 16 to 32, etc. That may be flexible enough
14:54 < gmaxwell> jtimon: I was recommending 2^32 'flavors' but wumpus was concerned about reducing fingerprinting.
14:55 < gmaxwell> the whole reason to reduce the amount was to make it more difficult to follow a node around as it changes network identity.
14:55 < gmaxwell> sipa: 8 isn't enough if the chain is perpetually growing.
14:56 < jtimon> I see
14:56 < sipa> yeah, increasing number, the further back you go, may make sense
14:56 < gmaxwell> a year from now the chain will be 200 gb, a year after 300 gb-- at that size it is larger than the most common ssd size currently. a year after that 400gb.... and at that point an 8 way split is again running common hosts out of disk even if the common ssd size has moved up to 500gb by then.
14:56 < jtimon> well, maybe archive nodes that don't want to store everything have to get a privacy hit
14:57 < gmaxwell> who will bother running one if it takes speical effort above and beyond running a node, and draws more resources? 
14:57 < sipa> well if only we'd have a separate network for archivsl
14:57 < sipa> there are no privacy issues at all then
15:01 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit []     
15:06 < gmaxwell> and no one run them.
15:06 < gmaxwell> s/run/running/
15:07 < sipa> i was about to say that separate network doesn't need to imply separate nodes
15:07 < sipa> but of course, that doesn't work because you'd get a privacy leak from correlating
15:08 < sipa> however, you can reconcile those by only having nodes with a long-term IP provide archival further back than some threshold
15:09 -!- jannes [~jannes@178.132.211.90] has quit [Remote host closed the connection]     
15:10 < gmaxwell> sipa: not just that, but if it's a special very resource intensive mode.. few will do it, pliling more resources onto it... causing fewer to do it...
15:10 < sipa> it's true that it's resource intensive, but it's a different kind of resources than most of the rest of running a node
15:10 < sipa> it needs disk space and bandwidth
15:10 < gmaxwell> I might think it's not over the threshold of that, except already people don't run regular nodes due to costs. 
15:11 < sipa> rather than memory and cpu
15:11 < gmaxwell> which are what people usually complain about.
15:11 < sipa> then why aren't we seeing more pruned nodes?
15:11 < sipa> one reason may be that pruned nodes don't advertize, so we just don't know about them
15:12 < gmaxwell> because you have to edit a config file or change an obscure setting, we don't advertise it, and it breaks rescan and reindex. (which is part of why we don't really advertise it)
15:12 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
15:12 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
15:14 < sipa> well people mostly complain about the sync time for a node
15:15 < gmaxwell> yes, though I think thats most because so many stop there and give up before they get a chance to complain about the rest.
15:15 < sipa> perhaps
15:18 < TD-Linux> a first-run dialog box with a slider for disk usage and an estimated sync time would be very nice
15:18 < sipa> except the sync time does not depend on the value of the slider
15:19 < TD-Linux> yes, I meant it there so it'd appear at start. I guess having it in the status bar is sufficient
15:20 < sipa> ah     
15:20 < sipa> well there will be an overlay with sync time indication in 0.14
15:21 < gmaxwell> doesn't it still incorrectly say you can't transact while syncing?
15:21 < sipa> we still have a lot time until 0.14
15:23 < gmaxwell> :)     
15:23 < wumpus> well you can, but most people probably shouldn't do so
15:23 < gmaxwell> yes they should
15:23 < wumpus> during the initial sync they won't have any coins to send anyway, and receiving them is a bad idea as they'll only see them when the entire thing is done
15:23 < wumpus> oh?     
15:24 < wumpus> why?
15:24 < gmaxwell> initial sync isn't my concern there:
15:24 < gmaxwell> probably one of the most common usage patterns for a wallet user is that you start your wallet up in order to pay someone, and it's three weeks behind. You can go ahead and pay, no problems.. why wouldn't you?
15:24 < gmaxwell> during initial sync you just won't have any coins, indeed. :)
15:24 < wumpus> the biggest problem is people giving out addresses during initial sync
15:24 < wumpus> then realizing how long it takes
15:25 < wumpus> this is what the overlay is designed to prevent
15:25 < wumpus> sure, you can send coins if you're three weeks behind, no problem, although fee computation could be off
15:25 < gmaxwell> yes, that is a large source of complaints, but we shouldn't tell people that they cant send funds already in their wallet when they start up and they're a bit behind, it's already a common mistaken belief that they cant (and then they complain about how long it takes to catch up a month of blcks)
15:25 < TD-Linux> the warning could be conditional on having zero funds
15:26 < gmaxwell> TD-Linux: the earlier warning text was fine-- saying that you won't see payments to you yet, but for some reason it was changed to say that you cannot send funds.
15:26 < wumpus> yeah fix one thing and they'll start complaining about another, it's a never ending source of fun...
15:26 < sipa> i don't think anyone will read the text anyway
15:26 < gmaxwell> I also complained that the text is now too long and won't get read.
15:26 < wumpus> of course people will read it
15:26 < sipa> the important thing is that it's in the way, and gives accurate (by then, hopefully) information
15:26 < wumpus> heck, users aren't stupid
15:26 < gmaxwell> The first text was better.
15:27 < sipa> gmaxwell: PR welcome
15:27 < wumpus> maybe some are, but not all of them, some will actually read and understand
15:27 < gmaxwell> Well I'm stupid, and looked at the notice in its updated state and didn't read the list line.
15:27 < gmaxwell> first*
15:27 < gmaxwell> because when there is too much text many people go a bit banner blind and skim past headings and such.
15:27 < wumpus> if we don't believe peopel actually pay attention then why do anything at all
15:28 < gmaxwell> saying that a wall of text is too much is not saying that people don't pay attention.
15:28 < wumpus> I think it's an improvement to what was there, indeed, if you want to imrpvoe further then pulls are welcome
15:28 < sipa> right, that's what i'm saying - having there being an overlay at all is more important than what the text says
15:28 < gmaxwell> and re: being able to send, people already complain that they have to wait a long time after starting to send because they already frequently mistakingly believe they can't.
15:28 < sipa> and we have time to improve the latter
15:29 < wumpus> but I'm a bit tired of people always saying "users won't read anyway" to everything that adds documentation , help or warnings
15:29 < wumpus> a lot of users are definitely looking for more help and guidance when they first open the program, and a bit of text helps there
15:29 < gmaxwell> wumpus: why should I waste my time when I point out that THE TEXT IS OUTRIGHT UNTRUE and your response is to accuse me of thinking users are stupid?  my comment was that the earlier version of the text which was simple and NOT UNTRUE was better.
15:29 < sipa> please guys
15:30 < sipa> gmaxwell: go propose something
15:30 < gmaxwell> I did!
15:30 < wumpus> gmaxwell: well if the text is wrong then it should be fixed obviously, change it to a better text
15:30 < wumpus> I don't know what the previous version of the text was
15:31 < sipa> it's been changed a dozen times in the lifetime of the pull
15:33 < sipa> also, it says "Spending bitcoins may not be possible until synchronization has finished."
15:33 < sipa> which is not untrue.
15:34 < gmaxwell> okay, it was changed after I last saw it.
15:35 < wumpus> ok that was useless :)
15:35 < gmaxwell> by saying 'may' which is still misleading, but worse, that text is the bold. 
15:35 < gmaxwell> er is the only bold part.
15:35 < sipa> well, improvements welcome
15:35 < gmaxwell> So now it says "mumble mumble mumble  Spending bitcoins may not be possible during that phase!" :-/
15:36 < gmaxwell> it's a waste of my time, I already raised these issues and it was then merged.
15:36 < wumpus> it had to be merged at some point, with the idea it could be improved later
15:36 < gmaxwell> well to be fair the last change did improve it, its true.
15:37 < gmaxwell> but created the problem that if you skim it is that all you extract is that you can't spend, .. which misses the really critical thing: which is that you wallet may look empty when it isn't.
15:37 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
15:37 < wumpus> that doesn't mean it's final, most will only see the message when it is merged, and can improve it then, there are already some pulls open to improve that overlay
15:38 < gmaxwell> but okay, I can open a PR.
15:38 < wumpus> (but I don't think they change that message)
15:38 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
15:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
15:39 < sipa> gmaxwell: i think people didn't really understand the point of your concern (i didn't): if you're looking at it from a point of view that this would be be mostly seen (and intended to convey information) during IBD, it's perfectly reasonable to warn users they won't be able to spend the money they're still to receive... and a simplification to reduce the length of the text may be warranted
15:39 < sipa> it's a good point that it's also seen during non-IBD
15:39 < gmaxwell> It will mostly not be seen during IBD.
15:39 < gmaxwell> during IBD sure someone will see it then, say of course I knew that (even if they didn't) minimize and go on with life. :P
15:40 < gmaxwell> but then users will see it every single time they start.
15:40 < sipa> i'm aware, you don't need to argue about this
15:40 < sipa> i'm just explaining why maybe you felt misunderstood
15:40 < gmaxwell> sorry, not arguing-- clarifying.
15:40 < gmaxwell> Yes, I see that and I didn't before.
15:41 < gmaxwell> when I first saw this PR I even took the time to go through the code carefully to check to see if there was anything that made it IBD only.
15:42 < gmaxwell> because I couldn't understand why people wanted the text that it had.
15:42 < gmaxwell> it did not occure to me that other people might be only thinking about IBD.
15:42 < gmaxwell> sorry for being thoughtless there.
15:42 < wumpus> #8805 fixed a few minor grammar nits, #8821 fixes a blocking problem with the overlay, there are no pulls yet that improve the message
15:43 < sipa> sorry, we (including me) aren't being careful with terminology here... IBD is also used for syncup when you were previously synced to a month ago
15:43 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
15:43 < wumpus> it's very easy to forget about catching up nodes
15:44 < wumpus> but yes we shouldn't
15:44 < sipa> well it's mostly designed to help with that first sync
15:45 < gmaxwell> more obvious to me just by chance of hering more people complain about it, also I've stopped running a node 24/7 on my laptop because I've been watching the battlestar galactica series in evenings and bitcoin interupts video playback. :)
15:45 < wumpus> during catch-up it's reasonably useful too, people may not know they won't see transactions newer than their sync point and worry, but yes it's mostly important for the initial IBD (lol)
15:45 < gmaxwell> so every time I go to use bitcoin I'm stuck waiting for it to catch up.
15:45 < gmaxwell> yes, we should have this message during catch up. But it's important to not make people think they can't spend funds that they can see.
15:46 < gmaxwell> The important message is that you may not see all payments to you yet (and you can't spend what you can't see).
15:46 < wumpus> bitcoin interrupts video playback? even in steady state mode?
15:46 < TD-Linux> one option would be to put it on the payment request generation page instead. but even in its current state it's far better than what was there before (nothing)
15:47 < gmaxwell> wumpus: yes. on my laptop... playback from a local file. The issue is IO or cpu related, probably the former but I haven't tested extensively to know for sure.
15:48 < wumpus> that's very strange. I'd expect that during intial sync when it maxes out CPU and I/O usage, but not when it's up to date
15:48 < gmaxwell> TD-Linux: the big problem we should be solving here is that people see a balance of zero then delete the wallet. I think thats the priority because any other issue doesn't cause irrecoverable loss.
15:48 -!- cryptapus is now known as cryptapus_afk     
15:48 < gmaxwell> wumpus: I notice it during ordinary computer use.. causes IO hangs, but its not irritating except when watching video.
15:49 < wumpus> do you have a lot of mlocked memory? is it swapping?
15:50 < gmaxwell> no, not swapping 8gb ram. I think that when a bunch of random writes happen it causes long delays for garbage collection in the SSD.
15:50 < wumpus> swapping seems to be the foremost cause of I/O related hangs here, as essentially the memory subsystem has to wait for I/O to complete
15:50 < wumpus> heh as if 8gb ram means no swapping these days :)
15:50 < gmaxwell> well on my laptop its enough most of the time.
15:51 < gmaxwell> The stalls seemed to get better for a while after I freed up a bunch of space and trimmed the drive, but got worse after which is why I think SSD GC plays a roll.
15:51 < gmaxwell> but in any case, while watching the show every block arrival causes a second-long pause in playback.
15:51 < wumpus> maybe someone is requesting a lot of blocks from you with a bloom filter? :-) it would be interesting to find out what your node is actually doing at those times
15:52 < gmaxwell> nah, outbound only.
15:52 < gmaxwell> I know its at the same time as blocks showing up.
15:52 < TD-Linux> gmaxwell, easy way to verify that would be to increase your video player's lookahead cache
15:52 < wumpus> ok so it's block verification, leveldb seeks
15:52 < gmaxwell> TD-Linux: think mpv uses non-blocking reads of the disk?
15:53 < TD-Linux> gmaxwell, yup it does. I've increase the setting to 10s when using sshfs and it works fine
15:54 < gmaxwell> in any case, performance distraction aside, when this happens I shut down bitcoind then it may stay off for a week before I need to do something with it, then waiting for it to catch up is irritating.
15:55 < gmaxwell> (and of course my systems performance is seriously impacted while it catches up)
15:55 < wumpus> yes, nothing to do about that, I guess if hybrid SPV mode is implemented it could also work during catch-up
15:55 < wumpus> indeed, it's either slow down the catch up or tolerate it hogging the whole system
15:58 < gmaxwell> I have wondered if it might be useful to split the chainstate into two parts, one with txouts created in the most recent N blocks, and one with the rest. Then on start we could just load the whole first one into the cache.
15:58 < wumpus> the default setting of hogging all cores during IBD/catch-up is a bit rude, certainly if it is a background process
15:58 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
15:59 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
15:59 < gmaxwell> if we did that much of the cost would then be signature valdation instead of random IO, and signature validation could run in the background, following behind the blocks.. and at lower priority.
15:59 < wumpus> so that would be like a 'prefer keeping recent UTXOs' cache policy?
16:00 < gmaxwell> I guess thats a stat that I still haven't collected.  "what is the average age-in-blocks of inputs that are consumed" (/what is the distribution of that age)
16:00 < gmaxwell> we know recent ones are spent more often but I don't have good numbers on it.
16:00 < gmaxwell> wumpus: yes.
16:02 < gmaxwell> probably not the highest priority improvement in any case.
16:02 < wumpus> well, currently the whole cache is emptied at a write, I think there are many eviction policies that would do better
16:03 < gmaxwell> right, also the in memory representation of the cache entries is quite inefficient.
16:04 < gmaxwell> so its effective size could potentially be doubled if its entries were flat allocated.
16:04 < wumpus> though that helps it actually being an efficient cache, a more efficient representation shouldn't come at a higher access cost
16:06 < wumpus> I did an experiment once with storing the UTXOs in serialized form in memory: https://github.com/laanwj/bitcoin/tree/2016_04_dummy_db
16:09 < gmaxwell> interesting!
16:09 < wumpus> although that's for the entire UTXO set, not just a limited cache
16:10 < gmaxwell> yea, the on disk seralization is most efficient, but not fast.
16:11 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
16:11 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
16:11 < gmaxwell> I wouldn't be surprised though for the current in memory representation if there wasn't more bytes spend in malloc/container overhead than actual transaction data though.
16:11 < wumpus> but given that most time is wasted on disk seeks anyway, it may not make too much difference in practice
16:11 < wumpus> depends on the system...
16:12 < wumpus> yes, the malloc overhead is somewhat bad
16:12 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
16:12 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
16:14 < wumpus> but not more than the actual data size, from what I remember
16:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 264 seconds]     
16:15 < wumpus> in any case improvements are certainly possible there, without any rocket science, it's just that it's such risky code to change
16:15 < wumpus> if it was any other project people would have optimized the shit out of it by now
16:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
16:21 < wumpus> unfortunately the damages of a bug there are unfathomable, not just skipping a few video frames
16:22 < gmaxwell> well the hope I had there was that with making the cache more efficient, it could be increased in size and avoid more disk IO. :)
16:24 < gmaxwell> on the earlier subject of 'alt' implementations doing inadvisable things, some of them have a genius performance optimization which they're crowing about, -- where they only validate transactions that weren't already in the mempool; something we explicity decided not to do because of the long history of subtle mempool corruption issues.
16:25 < wumpus> exactly, there are tons of ways to optimize and get things just slightly wrong
16:25 < gmaxwell> I worry that there will be a race to the bottom, where by making risky / security reducing optimizations implementations will gain significant performance advantages, and suffer no cost until the inevitable spectacular failure that results.
16:26 < wumpus> which doesn't matter if no one runs your code anyway, but we have to be really careful
16:26 < gmaxwell> and being safe doesn't matter if peopel don't run it in favor of things that are faster.
16:26 < gmaxwell> people*
16:26 < wumpus> we also shouldn't overestimate how important the performance is to most users, many just run it on a server or otherwise unused computer
16:27 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
16:27 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
16:27 < wumpus> well you'd say safeness is really important, if the inevitable spectacular failure happens you don't want to be at the center of it
16:28 < gmaxwell> well sure. indeed.
16:28 < wumpus> better slow than dead :)
16:29 < gmaxwell> but for things like the security model change to use a 6 month old utxo commitment instead of syncing the history... the potential for a spectacular failure there which a more conservative approach could have stopped is negligible.
16:29 < TD-Linux> gmaxwell, still think you should verify that it's actually IO that's the problem before going too deep :)
16:29 < gmaxwell> And if we don't investgate things like that, someone will do something dumber.
16:30 < wumpus> TD-Linux: yes, measuring is better than assumptions :)
16:30 < gmaxwell> TD-Linux: Oh IO is an issue for sure regardless of whats causing my mpv stalls. I'll find out tonight (I'm not going to sit here and watch video for an hour just to check)
16:31 < gmaxwell> TD-Linux: SSD vs a fast spinning disk with small dbcache here is a <4 hour sync (from a local peer) vs a >9hour sync.
16:32 < wumpus> and sure, it's good to investigate things like that
16:33 < wumpus> I/O is absolutely a problem sometimes, leveldb generates *tons* of seeks and small reads, better caching would help avoid some of that
16:34 < wumpus> I had no luck with other databases, I remember trying with lmdb at some point, which was faster in reading, but instead... does tons of seeks and small writes at write, so it just moves the problem
16:35 < TD-Linux> yeah, on a SSD at least, the former is much less detrimental to system latency
16:35 < wumpus> indeed!
16:35 < gmaxwell> for operation at the tip, using the mempool instead of validating would be a big aid... but the safty of that remains dubious. :)
16:36 < sipa> gmaxwell: i believe for the mempool it's approximately a factor 2 overhead
16:36 < sipa> gmaxwell: that that is also indexes, orderings, accounting, ...
16:38 < wumpus> yes that remains dubious, especially with regard to isFinal and such
16:38 < wumpus> I mean there is a part of transaction validation that can be obviously cached, and a part that may change in time
16:39 < gmaxwell> fortunately the MTP change made that much safer.
16:41 < gmaxwell> e.g. before a block could come in with a time before your local time, and contain txn which are isfinal invalid according to the block but okay with respect to the local time, and you'd accept it. I wonder if the alt implementations had that bug.
16:48 < wumpus> I remember that one, tricky... and there may be more problems of that kind not yet found
16:49 < gmaxwell> looks like their change dodged it, because the finality test is in the ContextualCheckBlock, and the bypass patch only bypasses checkinputs...
16:49 < gmaxwell> (which also means that it doesn't manage to avoid accessing the utxo cache entries)
16:51 < wumpus> I just realized, if the problem is that the block validation hiccups other things happening on your PC, the solution may be actually to slow it down :)
16:52 < wumpus> put a small sleep between each UTXO lookup, limit the validation to one thread
16:52 < wumpus> not something you'd want to do during initial sync if you're waiting for it, but if you don't care and it runs in the background...
16:54 < wumpus> after all you run it to keep up, you don't need to outrace it
16:56 < gmaxwell> I've thought before that if we have bandwidth limiting enabled we should delay announcement of new blocks to reduce the number of peers that request them from us... but slowing down the validation would work as well.
16:56 < gmaxwell> small sleeps perhaps aren't so good because it may busy spin. :P
16:57 < wumpus> heh, not that small
16:58 < wumpus> or use some OS-dependent way to reduce the I/O priority
16:59 < wumpus> as long as it's done by the time the next block comes in, so taking 10 minutes would take it too far :)
17:04 < wumpus> it's also not completely unprecedented, for example Transmission torrent client has a turtle icon, which can be clicked to slow down, indeed meant when using the computer for other things
17:06 < sipa> LOL https://git-man-page-generator.lokaltog.net/
17:06 < sipa> </offtopic>
17:06 < gmaxwell> well a 10ms sleep per 20 transactions would pretty much take care of it, I expect.
17:07 < wumpus> although as an idea for bitcoin it's new, I think. THere has been a patch to add a button to disable networking completely but that kind of misses the point. That means a full catch-up has to be done when re-enabling
17:07 < wumpus> sipa: hahaha 
17:07 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
17:07 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
17:08 < gmaxwell> thats old. :P
17:08 < wumpus> I hadn't seen it yet
17:08 < gmaxwell> damn repost supporters. :P
17:09 < gmaxwell> okay, I'll permit it, since where I saw it was in a private msg from my SO,
17:09 < gmaxwell> mindspillage.log:00:33 <mindspillage> hahah: http://git-man-page-generator.lokaltog.net/
17:10 < sipa> i heartily endorse reposts. of things i hadn't seen.
17:10 < gmaxwell> wumpus: I suspect that in the long run to really address the resource usage we'll need something like bittorrent's utp to transfer blocks during catchup and ibd.
17:11 < sipa> we'll need rainbow tables.
17:13 < gmaxwell> https://en.wikipedia.org/wiki/LEDBAT
17:14 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Remote host closed the connection]     
17:15 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev     
17:15 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
17:16 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
17:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qhssmdyjfjmfrphw] has quit [Quit: Connection closed for inactivity]     
17:28 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
17:28 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
18:00 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 272 seconds]     
18:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
18:16 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has quit [Ping timeout: 250 seconds]     
18:16 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has quit [Quit: Leaving]     
18:19 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
18:19 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
18:22 -!- Guest40115 [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]     
18:22 -!- stan [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
18:23 -!- stan is now known as Guest97182     
18:23 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
18:27 -!- Guest97182 [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 264 seconds]     
18:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
18:31 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
18:32 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
18:36 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev     
18:46 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
18:46 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
19:17 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
19:17 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
19:17 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
19:39 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
19:54 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
19:54 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
20:06 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
20:06 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
20:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:13 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 264 seconds]     
20:13 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
20:21 -!- stan [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
20:21 -!- stan is now known as Guest9149     
20:23 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
20:23 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
20:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:47 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:48 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
20:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:48 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
20:52 -!- fengling [~fengling@58.135.95.136] has quit [Quit: WeeChat 1.4]     
20:55 -!- HellO [83af37ad@gateway/web/freenode/ip.131.175.55.173] has joined #bitcoin-core-dev     
21:01 -!- cryptocrypt [~user@91.108.183.18] has joined #bitcoin-core-dev     
21:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:09 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
21:09 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
21:13 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:14 -!- HellO [83af37ad@gateway/web/freenode/ip.131.175.55.173] has quit [Ping timeout: 240 seconds]     
21:26 -!- Guest9149 [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has quit [Remote host closed the connection]     
21:27 -!- stan [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
21:27 -!- stan is now known as Guest50775     
21:30 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
21:30 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
21:31 -!- Guest50775 [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]     
21:33 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds]     
21:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:47 -!- cryptocrypt [~user@91.108.183.18] has quit [Quit: Lost terminal]     
21:49 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
21:51 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
21:51 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
22:02 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
22:02 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
22:05 -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
22:07 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 240 seconds]     
22:07 -!- e4xit_ is now known as e4xit     
22:32 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
22:32 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
22:38 -!- mrkent [~textual@unaffiliated/mrkent] has quit []     
22:40 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
22:41 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
22:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit]     
22:49 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]     
22:53 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
22:57 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has quit [Ping timeout: 244 seconds]     
23:03 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
23:03 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
23:08 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
23:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zulhhjqommnmorxk] has joined #bitcoin-core-dev     
23:14 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
23:14 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
23:17 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
23:23 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer]     
23:24 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev     
23:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:40 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 272 seconds]     
23:43 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:50 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]     
23:50 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
23:54 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: No route to host]     
23:54 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev