1 2018-05-04 00:06:06	0|cfields|jamesob: heh, no worries
  2 2018-05-04 00:06:40	0|cfields|sipa: it just occured to me that Span is begging to be used for scatter/gather
  3 2018-05-04 00:07:08	0|sipa|ha, yes
  4 2018-05-04 00:08:23	0|cfields|Span& even casts perfectly to iovec*
  5 2018-05-04 00:09:04	0|cfields|trying to decide if we should encourage that with a helper, or encourage iovec vec(span.data(), span.size()) instead.
  6 2018-05-04 00:10:46	0|cfields|https://0bin.net/paste/gRcNPbxui+WjB-jK#rXShNTSfMZHh6hZXiUbjxHBzcUwb4dXmy2J3aUYkBzR
  7 2018-05-04 00:12:01	0|sipa|that sounds awefully platform specific
  8 2018-05-04 00:12:07	0|sipa|*awfully?
  9 2018-05-04 00:13:14	0|cfields|i think it's pretty universal, the struct padding is the only thing i can see practically changing...
 10 2018-05-04 00:13:33	0|cfields|but I guess you're right, it doesn't save much
 11 2018-05-04 01:09:27	0|fanquake|pierre_rochard nice rupdates to bitcoinacks so far.
 12 2018-05-04 01:17:40	0|pierre_rochard|Thanks fanquake! ICYMI: https://bitcoinacks.com/ I have a few ideas for the next big iteration ( https://github.com/PierreRochard/bitcoin-acks/blob/acks/README.md ), happy to add more if you have anything that is dragging you down as a contributor/reviewer/maintainer. Something I was thinking about during today’s meeting was surfacing High Priority for review PRs in the UI.
 13 2018-05-04 01:25:28	0|fanquake|pierre_rochard Cool, I'll take a look. Even something as simple as a different background colour on the High Priority PRs might work.
 14 2018-05-04 02:14:34	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13165: doc: Mention good first issue list in CONTRIBUTING.md (06master...06good-first-issue) 02https://github.com/bitcoin/bitcoin/pull/13165
 15 2018-05-04 02:15:46	0|luke-jr|pierre_rochard: not forcing the horizontal scrollbar off would be nice
 16 2018-05-04 02:16:20	0|luke-jr|and some way to hide closed PRs
 17 2018-05-04 02:16:41	0|luke-jr|not sure why adding a filter for Closed insists on the value being a date O.o
 18 2018-05-04 03:26:55	0|fanquake|Not the most useful error message for Core to spit out heh: https://0bin.net/paste/fIINOwfRR9GIR-SZ#c7Sx1+EM3HJjYaTx0C6c5Exa6MYt7AIO-RweISgWZcG
 19 2018-05-04 03:27:22	0|fanquake|Looking at #13161, there seems to be a case where even after a database error Core just continues on, and then segfaults at shutdown.
 20 2018-05-04 03:27:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/13161 | wallet: Reset BerkeleyDB handle after connection fails by real-or-random · Pull Request #13161 · bitcoin/bitcoin · GitHub
 21 2018-05-04 05:10:55	0|ken2812221|fanquake: That happened while I was testing #12985 if Bitcoin Core cannot write wallet file
 22 2018-05-04 05:10:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/12985 | Windows: Avoid launching as admin when NSIS installer ends. by JeremyRand · Pull Request #12985 · bitcoin/bitcoin · GitHub
 23 2018-05-04 07:21:35	0|glaksmono|hi all
 24 2018-05-04 07:21:37	0|glaksmono|anyone is around?
 25 2018-05-04 07:28:27	0|luke-jr|if you have a question, just ask; don't ask to ask or if anyone is around (your client can show you there are 241 people here)
 26 2018-05-04 07:29:20	0|glaksmono|Is there a tutorial somewhere on how to fork a coin?
 27 2018-05-04 07:29:34	0|glaksmono|I want to learn how is Bitcoin born from the technical perspective
 28 2018-05-04 07:29:40	0|glaksmono|@luke-jr
 29 2018-05-04 07:32:19	0|luke-jr|it wasn't born by a fork, and such things are not on topic here
 30 2018-05-04 07:34:00	0|sipa|try ##altcoin-dev
 31 2018-05-04 07:35:47	0|glaksmono|thanks @sipa @luke-jr
 32 2018-05-04 07:35:52	0|glaksmono|in any case, how it was born?
 33 2018-05-04 07:36:04	0|glaksmono|so let's assume Satoshi on the early days finish his coding.. and then compiled
 34 2018-05-04 07:36:12	0|glaksmono|then he deployed the first bitcoind in a server i presume?
 35 2018-05-04 07:36:32	0|glaksmono|i also posted my question here: https://bitcointalk.org/index.php?topic=3526903.0
 36 2018-05-04 07:56:35	0|sipa|glaksmono: this is a place for development, not bitcoin mythology
 37 2018-05-04 09:09:15	0|jonasschnelli|external tx index via p2p with leveldb and ~1'000'000 record mem cache: full index via p2p localhost up to block 500'000: 87m41.629s
 38 2018-05-04 09:09:17	0|jonasschnelli|(SSD)
 39 2018-05-04 09:09:34	0|jonasschnelli|PoC: https://github.com/jonasschnelli/bitcoincore-indexd
 40 2018-05-04 09:20:13	0|wumpus|jonasschnelli: awesome!
 41 2018-05-04 09:20:28	0|wumpus|jonasschnelli: is that with or without my patch at the bitcoind side?
 42 2018-05-04 09:20:43	0|jonasschnelli|without... will compare performance soon
 43 2018-05-04 09:21:25	0|jonasschnelli|I'm working on a test setup where block 450'000 to 500'000 will be requested probably 100-1000 times... then print the median result
 44 2018-05-04 09:21:36	0|jonasschnelli|the client just loads the block but does not deserialize it
 45 2018-05-04 09:22:13	0|wumpus|right, you have block request logic in bitcoincore-indexd, so might be an idea to start from that and make a benchmarker that just pulls blocks and drops them
 46 2018-05-04 09:22:39	0|wumpus|I thought about making something based on the P2P functional test framework, but python is likely going to be a bottleneck then
 47 2018-05-04 09:26:31	0|jonasschnelli|yes. the current poc uses libbtc which is a straight forward p2p client using libevent2
 48 2018-05-04 10:10:27	0|wumpus|jonasschnelli: going to try to build it
 49 2018-05-04 10:11:21	0|jonasschnelli|wumpus: great. with python?
 50 2018-05-04 10:11:34	0|wumpus|jonasschnelli: I mean your indexd project
 51 2018-05-04 10:11:59	0|wumpus|and try to do some benchmarking with it
 52 2018-05-04 10:12:33	0|jonasschnelli|wumpus: it's very immature and sketchy
 53 2018-05-04 10:12:57	0|wumpus|yes but I only need a very basic node framework for this, the less overhead the better
 54 2018-05-04 10:13:04	0|jonasschnelli|also... you probably need a manual -lpthread for linking... :)
 55 2018-05-04 10:16:55	0|jonasschnelli|yes... give it a try
 56 2018-05-04 10:16:57	0|wumpus|I first have to make it find my customized libevent
 57 2018-05-04 10:17:35	0|wumpus|hopefully PKG_CONFIG_PATH does just work :)
 58 2018-05-04 10:23:21	0|wumpus|jonasschnelli: a shame, looks like the libbtc libevent2 check doesn't use pkgconfig to check where the library is
 59 2018-05-04 10:23:58	0|wumpus|I'll see if I can add that or maybe I'll just whack in CPPFLAGS=... for now
 60 2018-05-04 10:48:47	0|jonasschnelli|wumpus: Good point. happy if you open a PR at github.com/libbtc/libbtc ;)
 61 2018-05-04 10:56:11	0|bitcoin-git|[13bitcoin] 15mocacinno opened pull request #13166: Master (060.14...06master) 02https://github.com/bitcoin/bitcoin/pull/13166
 62 2018-05-04 10:57:00	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #13166: Master (060.14...06master) 02https://github.com/bitcoin/bitcoin/pull/13166
 63 2018-05-04 11:09:58	0|wumpus|jonasschnelli: also need to pass in -fPIC I suposse /usr/bin/ld: bitcoincore_indexd-btcnode.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
 64 2018-05-04 11:57:30	0|wumpus|jonasschnelli: where does it get the node configuration (where to connect to) from?
 65 2018-05-04 11:57:57	0|jonasschnelli|wumpus: btcnode.cpp
 66 2018-05-04 11:58:07	0|jonasschnelli|search after 127.0.0,1
 67 2018-05-04 11:58:24	0|wumpus|ok I see,t hanks
 68 2018-05-04 11:59:42	0|wumpus|so simply 127.0.0.1:8333, but it wasn't connecting because my node was not listening
 69 2018-05-04 12:04:44	0|wumpus|it doesn't start requesting blocks :/
 70 2018-05-04 12:06:16	0|wumpus|jonasschnelli: is there anything I need to do to make it start pulling blocks? https://0bin.net/paste/TJj0okkQanP2H++H#VgX0GogDES9a0RXqsvgyKYJC5Ed0Y-4RFQwgO2aKQYe is my output, seems to be idling
 71 2018-05-04 12:07:58	0|jonasschnelli|wumpus: What do you do in handshake_done()?
 72 2018-05-04 12:08:07	0|jonasschnelli|This is where you should ask for blocks
 73 2018-05-04 12:08:20	0|jonasschnelli|the current bitcoincore-indexd does sync headers first
 74 2018-05-04 12:08:35	0|wumpus|jonasschnelli: haven't changed the function
 75 2018-05-04 12:09:40	0|jonasschnelli|wumpus: it looks like it doesn request headers then
 76 2018-05-04 12:09:54	0|jonasschnelli|maybe set a breakpoint in void handshake_done(struct btc_node_ *node)
 77 2018-05-04 12:10:09	0|jonasschnelli|wumpus: wait..
 78 2018-05-04 12:10:18	0|jonasschnelli|your client-peer is sending a getheaders()
 79 2018-05-04 12:10:27	0|jonasschnelli|-()
 80 2018-05-04 12:10:39	0|jonasschnelli|but seems like your remote node does not answer
 81 2018-05-04 12:10:44	0|wumpus|will do - the node syncing from is not up to date with the chain, could that be a problem?
 82 2018-05-04 12:10:50	0|jonasschnelli|Are they on the same network? Mainnet/etc.?
 83 2018-05-04 12:10:56	0|wumpus|yes both on mainnet
 84 2018-05-04 12:11:15	0|wumpus|I'll look into it
 85 2018-05-04 12:11:26	0|jonasschnelli|wumpus: eventually... the client node will ask for headers from genesis... could be that your remote node is refusing that during IBD
 86 2018-05-04 12:15:41	0|wumpus|jonasschnelli: indeed - seems like the old "Ignoring getheaders from peer=%d because node is in initial block download" plague again, adding whitelist=127.0.0.1 solved it
 87 2018-05-04 12:16:12	0|wumpus|it's rolling
 88 2018-05-04 12:16:34	0|jonasschnelli|wumpus: why did you use a custom built libevent? Did you modify the sources for performance measuring?
 89 2018-05-04 12:17:43	0|wumpus|I want to have a newer one that is installed on this version of ubuntu by default, I've also made some http changes to make it work with UNIX domain sockets, though that part isn't necessary here it's the only version of libevent I have installed
 90 2018-05-04 12:18:18	0|wumpus|(and I always install manuall-compiled things into /opt/<libname>, not in /usr)
 91 2018-05-04 12:18:34	0|jonasschnelli|I see
 92 2018-05-04 12:30:56	0|wumpus|jonasschnelli: looks like it doesn't hit the fast path, I suppose your indexer doesn't request MSG_WITNESS_BLOCK?
 93 2018-05-04 12:31:59	0|jonasschnelli|wumpus: the indexer does send a inv with blockhashes... shouldn't this result in a MSG_WITNESS_BLOCK?
 94 2018-05-04 12:34:08	0|wumpus|jonasschnelli: ser_u32(inv_msg_cstr, 2);   <- that's MSG_BLOCK, not MSG_WITNESS_BLOCK
 95 2018-05-04 12:34:38	0|wumpus|needs 1 << 30 ORed in
 96 2018-05-04 12:37:23	0|jonasschnelli|Right. Yes. I guess just changing to MSG_BLOCK | MSG_WITNESS_FLAG should do the job.
 97 2018-05-04 12:37:54	0|wumpus|yes
 98 2018-05-04 12:38:23	0|wumpus|eh no, those constants are not defined anywhere
 99 2018-05-04 12:39:23	0|wumpus|would be a good idea though
100 2018-05-04 12:42:22	0|jonasschnelli|yes
101 2018-05-04 12:49:52	0|wumpus|ok, hitting the fast path now on the server side, I commented out the transaction processing code on the client side - and make it quit when current block height is 473600 (arbitrary)... just a matter of waiting now
102 2018-05-04 12:54:43	0|jonasschnelli|wumpus: I would probably start from 450000 up to 500000 for performance tests.
103 2018-05-04 12:55:44	0|wumpus|yes maybe - I don't have any more recennt blocks on this node, so this will have to do for now
104 2018-05-04 12:57:40	0|wumpus|including the small blocks in the beginning is not very useful, probably, but should not take a lot of time
105 2018-05-04 12:58:42	0|jonasschnelli|Indeed.
106 2018-05-04 12:59:27	0|jonasschnelli|wumpus: for performance benchmarks, what do you think in requesting 450k-500k, measure time, loop this for 1000 and calculate avg/med?
107 2018-05-04 12:59:41	0|jonasschnelli|450-500k should take seconds
108 2018-05-04 13:01:06	0|wumpus|requesting the same blocks over again will make them end up in the disk cache, though it's easy to average out especially when you disregard the first run
109 2018-05-04 14:23:14	0|bitcoin-git|13bitcoin/06master 14a508091 15fanquake: doc: Mention good first issue list in CONTRIBUTING.md
110 2018-05-04 14:23:14	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7eb7076f7007...627c3762ce5d
111 2018-05-04 14:23:15	0|bitcoin-git|13bitcoin/06master 14627c376 15MarcoFalke: Merge #13165: doc: Mention good first issue list in CONTRIBUTING.md...
112 2018-05-04 14:24:08	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13165: doc: Mention good first issue list in CONTRIBUTING.md (06master...06good-first-issue) 02https://github.com/bitcoin/bitcoin/pull/13165
113 2018-05-04 15:37:08	0|bitcoin-git|[13bitcoin] 15martinus opened pull request #13167: Refactoring: optimize SelectCoinsBnB (06master...06optimize-SelectCoinsBnB) 02https://github.com/bitcoin/bitcoin/pull/13167
114 2018-05-04 16:27:36	0|sdaftuar|BlueMatt: i think there might be another edge case bug in ABC that we didn't talk about yet
115 2018-05-04 16:27:55	0|BlueMatt|oh? ugh
116 2018-05-04 16:28:05	0|sdaftuar|it seems like it might be possible for pruning to run in between cs_main lock acquisitions?
117 2018-05-04 16:28:23	0|sdaftuar|and it's FindMostWorkChain's job to deal with that
118 2018-05-04 16:28:48	0|sdaftuar|probably it couldn't really happen in any "normal" scenario
119 2018-05-04 16:30:49	0|sdaftuar|anyway i think this may not be so different than other modes where pruning might fail, so i don't know that we should worry about it, except maybe add some comments to remind ourselves
120 2018-05-04 16:46:52	0|ramzo|hello
121 2018-05-04 17:07:24	0|ken2812221|Is there a way to update-alternatives in gitian builder? I'm trying to bump my gitian build to 18.04, but stuck at Windows update-alternatives to posix version.
122 2018-05-04 17:09:06	0|wumpus|ken2812221: yes, you can sudo afaik
123 2018-05-04 17:09:26	0|ken2812221|no, sudo or su does not work.
124 2018-05-04 17:12:45	0|wumpus|I think it's possible to enable that in the descriptor
125 2018-05-04 17:13:42	0|ken2812221|Ok, I would find it, thanks.
126 2018-05-04 17:16:59	0|wumpus|gbuild has to be run with --alow-sudo in that case, too
127 2018-05-04 17:19:14	0|ken2812221|Ok. I'm trying.
128 2018-05-04 17:21:02	0|ken2812221|Thanks, it does work!!
129 2018-05-04 17:32:47	0|wumpus|good!
130 2018-05-04 18:12:49	0|ken2812221|Gitian-build fails due to no 'rename' program. it's a pain after it has been compiled for a long time.
131 2018-05-04 18:17:43	0|MarcoFalke|How hard would it be to transcribe the gitian-descriptors into a docker file?
132 2018-05-04 18:19:51	0|ken2812221|I'm not using docker, I'm using lxc.
133 2018-05-04 18:27:10	0|ken2812221|I've created a PR to gitian-builder, so we can use lxc 3.0.0 to do gitian-build
134 2018-05-04 19:03:56	0|wumpus|ken2812221: great!
135 2018-05-04 20:03:00	0|TheCharlatan|Are there existing benchmarking results for the bench tests available between armv7 and armv8 ?
136 2018-05-04 20:18:09	0|skeees|sdaftuar: i'm unable to reproduce that genesis block failure - what are you doing to achieve?
137 2018-05-04 20:18:48	0|sdaftuar|while src/test/test_bitcoin -t validation_block_tests; do :; done
138 2018-05-04 20:19:07	0|sdaftuar|that was with a patch to try to get rid of that other error (i got rid of the BOOST_CHECK() call at line 160)
139 2018-05-04 20:19:34	0|skeees|hah - yeah i've been doing that a bunch too - no dice. maybe platform specific
140 2018-05-04 20:24:08	0|sdaftuar|oh i see what you're saying about the genesis block -- yes that does seem like a test bug
141 2018-05-04 20:24:55	0|sdaftuar|and i guess the callbacks are all happening in a single thread anyway, so the BOOST_CHECK calls there should be safe
142 2018-05-04 20:27:45	0|skeees|even though unable to reproduce - i've updated pr with something that i *think* will fix the error you're seeing related to that
143 2018-05-04 20:41:49	0|sdaftuar|skeees: i don't know how the threading works in the boost testing framework, but i did notice that you don't acquire cs_main before accessing chainActive.Tip() when you construct the TestSubscriber()
144 2018-05-04 20:42:06	0|sdaftuar|is it possible that there's a race where you're able to pull the value of the tip before the callback fires (very rarely?)
145 2018-05-04 20:44:22	0|skeees|hmmm you still seeing this issue even after 04176fc?
146 2018-05-04 20:44:45	0|skeees|didn't acquire because I assumed I'd be the only thread running in the test framework at that point
147 2018-05-04 20:44:49	0|bitcoin-git|13bitcoin/06master 14c3f34d0 15practicalswift: Make it clear which functions that are intended to be translation unit local...
148 2018-05-04 20:44:49	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/627c3762ce5d...f82e1c948212
149 2018-05-04 20:44:50	0|bitcoin-git|13bitcoin/06master 14f82e1c9 15MarcoFalke: Merge #13163: Make it clear which functions that are intended to be translation unit local...
150 2018-05-04 20:45:15	0|sdaftuar|i was still trying to reproduce, haven't taken your fix yet
151 2018-05-04 20:45:40	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13163: Make it clear which functions that are intended to be translation unit local (06master...06internal-linkage) 02https://github.com/bitcoin/bitcoin/pull/13163
152 2018-05-04 20:49:48	0|sdaftuar|hmm that hypothesis doesn't seem to be panning out (i tried adding a sleep before the BlockConnected callbacks after we connect the genesis block, to see if that would trigger it -- no dice)
153 2018-05-04 20:58:51	0|sdaftuar|skeees: oh, could it just be an issue of the scheduler getting to run the genesis block BlockConnected callbacks after the TestSubscriber is created?  i don't know what the callback semantics are--
154 2018-05-04 20:59:22	0|sdaftuar|do we callback only the callbacks that were subscribed at the time the event was generated, or do we callback everyone who is subscribed at the time the callback is actually fired off by the scheduler?
155 2018-05-04 20:59:56	0|skeees|i think it could be that
156 2018-05-04 21:00:08	0|sdaftuar|i can't figure out where to stick a sleep to verify that this is the issue...
157 2018-05-04 21:00:14	0|skeees|its not well defined right now because we push a callback to the scheduler that invokes the signal
158 2018-05-04 21:00:30	0|skeees|so you could subscribe after you push that callback but before signal is invoked i think
159 2018-05-04 21:00:40	0|sdaftuar|that's pretty weird behavior imo
160 2018-05-04 21:00:59	0|sdaftuar|but sort of exactly why we need these tests!
161 2018-05-04 21:01:00	0|bitcoin-git|[13bitcoin] 15jamesob opened pull request #13168: Thread names in logs and deadlock debug tools (take 2) (06master...062018-05-threadnames-take-2) 02https://github.com/bitcoin/bitcoin/pull/13168
162 2018-05-04 21:01:49	0|skeees|yeah - its strange - that behavior in particular starts to become a problem if you ever get into a state where you have a lot of dynamic subscription / unsubscription (e.g. may actually pose some challenges getting rid of mempool signals)
163 2018-05-04 21:02:07	0|skeees|but in current use case where you just subscribe on startup and those remain fixed - its not a huge deal
164 2018-05-04 21:02:24	0|sdaftuar|right
165 2018-05-04 21:07:34	0|sdaftuar|aha! i think that's it
166 2018-05-04 21:07:41	0|sdaftuar|i managed to reproduce it with a sleep added to the scheduler
167 2018-05-04 21:10:27	0|sdaftuar|so we should decide if we want to stick with that behavior or not...  seems kind of shitty to me.  perhaps registering with the validationinterface should require the queue to be drained first?
168 2018-05-04 21:10:32	0|sdaftuar|not sure if that idea works
169 2018-05-04 21:11:05	0|sdaftuar|BlueMatt: ^^^
170 2018-05-04 21:13:59	0|skeees|i think that's a separate pr - i'll put something together
171 2018-05-04 21:14:14	0|skeees|for this one - i think it'll suffice to change some of the subscription ordering
172 2018-05-04 23:12:14	0|Gabo|Hi
173 2018-05-04 23:59:28	0|ossifrage|Does upgrading the txindex database have the same io/time cost as just rebuilding the index? It seems to be grinding away rather slowly