< achow101> my sigs up as well. Matches michagogo's
< sipa> luke-jr: no
< sipa> eh
< sipa> Lightsword: no
< sipa> In line with recent trends, neither service bits nor protocol versions
< sipa> are particularly well-suited for this purpose. Protocol versions are
< sipa> impossible to handle sanely across different nodes on the network, as
< sipa> they cannot indicate optional features. Service bits, while somewhat
< sipa> more appropriate for this purpose, are a very limited resource which is
< sipa> generally better suited to indicating significant new features which
< sipa> nodes might need for correct operation, and thus might wish to actively
< sipa> seek out when making connections. I'm not sure anyone is suggesting that
< sipa> here, and absent that recent agreement preferred message-based feature
< sipa> indication instead of version-message-extension.
< sipa> oops, that paste was longer than i expected
< Lightsword> oh, so identification of compact blocks support is just based on MSG_CMPCT_BLOCK?
< sipa> no, based on sendcmpct
< Lightsword> sipa, so that won’t conflict with other messages unless something else used “sendcmpct” in NetMsgType here right? https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/protocol.cpp#L38
< sipa> yes
< gmaxwell> yea, and 12 bytes gives a lot more 'version space' than 32 bits. :P
< cfields> luke-jr: yes, those were already there. but in fairness, i wouldn't have caught them anyway. i'm not familiar enough with the code to review for actual correctness, i'm pretty much just looking at each commit with the assumption that everything around it is sane
< cfields> (actually, i like to think i would've spotted the uninit bug :)
< cfields> michagogo: thanks. had dinner while builds were cranking, working on sigs now
< cfields> and thanks achow101 as well
< luke-jr> cfields: I only managed to catch them as a result of the unit tests
< cfields> ah
< cfields> sipa: what's going on with your gpg key? iirc I meant to ask you a while ago (rc2 sig, maybe?). It doesn't look like any of your known (to me) keys
< sipa> uh
< sipa> which one did i sgn with?
< cfields> 9692 B91B BF0E 8D34 DFD3 3B18 82C5 C009 628E CF0C
< sipa> is that a subkey?
< cfields> oh wait, that's michagogo's
< cfields> 79A1A931
< cfields> looks like a new key. created: 2015-10-20
< sipa> yes, thT's my current key
< sipa> have you not signed that one?
< sipa> main key fingerprint is 133E AC17 9436 F14A 5CF1 B794 860F EB80 4E66 9320
< sipa> that should be on bitcoin.org even
< cfields> sipa: i just signed yours recently. must be some local issue, i'll poke around
< sipa> cfields: well the key id you're listing in the subkey
< sipa> maybe somehow you don't recognize that somehow?
< cfields> sipa: ok, fetched and all good now. thanks.
< cfields> gitian builders: detached sigs pushed for rc3
< jl2012> is it allowed to build for linux/windows/osx at the same time?
< sipa> if you have separate gitin-builder directories
< jl2012> thanks
< jl2012> the manual recommends ./bin/gbuild --memory 3000 ; could I assign more memory to make it faster?
< sipa> i don't think so
< sipa> you can give it more cpu cores if you have those, and correspondingly more memory
< btcdrak> an interesting comment from someone on Slack https://usercontent.irccloud-cdn.com/file/1xdZSObI/Screenshot_20160812-074155.png
< luke-jr> "Helped someone IBD" :P
< sipa> btcdrak: i totally support that idea
< jl2012> the linux build took 3.5 hours and is still building. Is that normal?
< luke-jr> jl2012: probably the first time for the new dependencies?
< jl2012> i don't know. the last line of build.log is currently CXX libbitcoin_server_a-miner.o
< sipa> jl2012: so the linux build is buding for 4 different architectures
< sipa> and each of those 4 rewuires building all dependencies
< sipa> including boost
< sipa> two of them require building qt
< jl2012> so >3.5 hours is normal?
< sipa> i believe so
< jl2012> i give it 8 atom cores and 3GB memory
< sipa> it's much faster when you do with a sexons te
< sipa> second time
< jonasschnelli> btcdrak: Yes. I agree that we need more "gamification"... I'm currently working on a simple mempool visualization
< jonasschnelli> Reward system... sounds a bit to close to games..
< jonasschnelli> which bitcoin definitively isn't
< sipa> "achievement unlocked! sent a raw transaction on testnet"
< jonasschnelli> hehe
< jonasschnelli> "achievement unlocked! You deleted your first private key and lost some coins"
< murch> jonasschnelli: Oh, that would be a common one ;)
< jonasschnelli> achievement unlocked! You have encountered your first block-corruption
< * jonasschnelli> does stop now
< murch> but seriously, more visibility of your contributions would be neat. I.e. how many requests your node answered, or how much data you provided to the network
< jonasschnelli> murch: Yes. This would be nice. I'm working on stats stuff for Qt
< murch> very nice. :)
< sipa> "achievement unlocked! locked all your coins in a locktime output for 1 year!"
< jonasschnelli> hehe
< * sipa> zZzZ
< murch> sipa: Do you ever sleep? :p
< jonasschnelli> He can still blame the jetlag
< murch> yeah
< sipa> murch: it's 2am here
< murch> sipa: I know. ;)
< murch> apropos jetlag: Would sometime next week in Basel be good for sipa and jonasschnelli?
< jonasschnelli> I'm here (in Basel) and mostly available for a chat
< murch> sipa and I would perhaps like to get together for a beer sometime. My sis lives close to Basel, and just made me an uncle, so I'd be around Basel sometime again. sipa proposed that in Basel we could include you. :)
< murch> sipa: correct me if I'm misrepresenting that
< sipa> sure, i can come to basel next week
< murch> jonasschnelli: I'm currently working on a Master thesis on Coin Selection. You might recognize my nickname from Bitcoin.Stackexchange.com ;)
< jonasschnelli> Yes. We know you murch.
< murch> oh dear :p
< jonasschnelli> I'm available next week, mostly afternoons or between 10:00 and 11:00 am local time.
< murch> Okay, how about Thursday afternoon?
< murch> sipa, jonasschnelli: perhaps we should take this to a private channel?
< jonasschnelli> yes.
< GitHub4> [bitcoin] jonasschnelli opened pull request #8501: Add mempool statistics collector (master...2016/08/stats_rpc) https://github.com/bitcoin/bitcoin/pull/8501
< JZA> is the linux foundation bitcoin-dev the official mailing list for bitcoin-core development?
< JZA> or is it a satelite one?
< JZA> is pretty low traffic so I wonder.
< jonasschnelli> JZA: bitcoin-dev is more for protocol discussion (must not be directly related to Bitcoin-Core)
< jonasschnelli> There is also a bitcoin-core lf mailing list,... this would be for Bitcoin-Core topics
< jonasschnelli> But low traffic.
< wumpus> but even more low-traffic. Most bitcoin developer don't like mailling lists a lot, it seems, most discussion happens on github and IRC
< michagogo> cfields: Thanks, got my signed sigs pushed.
< jonasschnelli> I just built the code-signed binares... are the detaches signatures even already uploaded?
< wumpus> I'm a bit late with building, turned it on yesterday before going to sleep, but then had the usual lxc-after-reboot issue so it didn't continue
< michagogo> jonasschnelli: yep
< michagogo> (otherwise you couldn't have built the code-signed binaries...?)
< michagogo> 06:46:49 <cfields> gitian builders: detached sigs pushed for rc3
< michagogo> (it's 15:20 now)
< michagogo> wumpus: lxc-after-reboot issue?
< wumpus> michagogo: yes http://www.hastebin.com/alehoxojen.vbs I get that every time the first time when I run any gitian command after reboot; the second and latter time don't have the issue
< michagogo> o_O
< michagogo> Doesn't happen for me in my 14.04 VM
< wumpus> this is on debian 8.5
< jonasschnelli> Anyone interested in testing this: https://github.com/bitcoin/bitcoin/pull/7783?
< jonasschnelli> Factored out to non-gui classes, has now unit tests (as recommended by sipa), would like to see this in 0.14 for the GUI
< wumpus> I don't agree that the functionality belongs in server.cpp
< wumpus> this does not act on JSON objects so it dos not belong server-side
< wumpus> apart from that I agree this is very useful, in the GUI
< wumpus> but please no string parsing in the server
< wumpus> this opens possible vulnerabilities, DoS possibilities, etc
< wumpus> fine with abstracting out, but then abstract it so that it can work with any dispatching interface (both local and remote)
< wumpus> I'm not sure that's within the scope of the pull
< wumpus> to be clear I really like this funcitonality in the GUI, and possible in bitcoin-cli, but let's not conflate this with hypothetical JSON-RPC nested commanding
< Chris_Stewart_5> In a partial merkle tree, does a txid that is appended to the binary tree to create an even number of nodes match inside the partial merkle tree?
< Chris_Stewart_5> if that makes any sense..
< jonasschnelli> wumpus: yes. Agree. I also think we should only have it in the GUI
< jonasschnelli> The reason for factoring it out was the missed possibility to do unit tests (though I think there are also GUI only unit tests).
< wumpus> yes, there are also GUI unit tests, though currently they are mostly useless, would be good to add a few
< jonasschnelli> I think I move it to a GUI only class and cleanup the server client hell.
< wumpus> in any case, if it belongs in the core it's in rpc/client.cpp, and should take a command dispatcher so that it can be used both in the GUI or in a remote client
< wumpus> but yes it's simplest to just keep it in the GUI
< wumpus> then if someone needs it for -cli do this work
< wumpus> don't overdesign in front
< cfields> jl2012: your gpg key is expired
< PascalCoin> Please, can you tell in which chanel can I give information about a new P2P cryptocurrency? (yet... another one) Thanks!
< sipa> ##altcoin-dev ?
< PascalCoin> thanks sipa
< jl2012> cfields: it's September?
< cfields> jl2012: heh, i just replied on the PR. Gitian's display order fooled me again
< cfields> luke-jr: readability suggestion: you might consider adding .json files and de-serializing them for tests. Would make test review much easier.
< GitHub137> [bitcoin] juscamarena opened pull request #8503: [doc] typos, text errors (master...Test-branch) https://github.com/bitcoin/bitcoin/pull/8503