< mryandao> has anyone looked at https://help.github.com/articles/about-codeowners/ for the bitcoin core repo?
< bitcoin-git> [bitcoin] khorben opened pull request #12513: Scripts and tools: Portability fix for the configure scripts generated (master...khorben/configure-portability) https://github.com/bitcoin/bitcoin/pull/12513
< meshcollider> mryandao: who would be set as owner of any file though? Maybe sipa as the bech32.cpp file but its probably not that useful in our case?
< meshcollider> Since anyone can review anything, and there are only like 5 people with write access
< mryandao> oh i thought the owners could be the 5 people with write access
< mryandao> it just provides extra feedback
< meshcollider> mryandao: then they'd be requested for review for all files, would just be a pain I think :)
< meshcollider> Places too much emphasis on the maintainers control of the repo too imo
< GitHub170> [bitcoin-detached-sigs] jonasschnelli opened pull request #5: 0.16: osx signatures for 0.16.0 (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/5
< * esotericnonsense> is doing code excavation at the moment.
< esotericnonsense> i'm looking at the boost signals to get a handle on what exactly validationinterface is doing.
< esotericnonsense> so my understanding is that these boost.signals2 things are just 'callback managers' you can register a number of callbacks with them, when you 'fire' a signal you're just executing those functions serially wherever you are right now.
< esotericnonsense> i haven't knocked them all off yet but NewPoWValidBlock seems to only be used in one place yet has a lot of boilerplate. some others are used "once" plus zmq as well. it feels like a lot of boilerplate, am I missing something or is it just kind of a historical quirk and/or 'here's an extension point'?
< cfields> michagogo: uh oh, mismatches
< cfields> michagogo: any idea what's up with that?
< cfields> wumpus: I'm going to hold off on signing for Win until we figure out what's going on there, or get a bunch more matching sigs
< midnightmagic> I am attempting to find some additional triangulation for all the new gpg keys doing gitian builds -- sjorsnado, meshcollider, is there somewhere else you've published your key that I could triangulate on? A twitter bio.. or .. ?
< midnightmagic> also, are akx20000, fivepiece, and wampy "known" to peeps in here?
< midnightmagic> nvm I found wampy
< midnightmagic> meshcollider: course. thanks.
< meshcollider> building 0.16 as we speak btw
< midnightmagic> -- catching up, still on rc3.
< midnightmagic> drat my rc3 gitian isn't matching up.
< CubicEarths> midnightmagic: You gonna build rc4 before final?
< midnightmagic> yes.
< CubicEarths> for archival purposes?
< midnightmagic> I'm gonna wait to even bother tracking it down until final succeeds/fails.
< midnightmagic> for completeness' sake. I always do it this way.
< bitcoin-git> [bitcoin] fanquake closed pull request #12513: Scripts and tools: Portability fix for the configure scripts generated (master...khorben/configure-portability) https://github.com/bitcoin/bitcoin/pull/12513
< meshcollider> well my 0.16 is done and matches all except michagogo too
< meshcollider> but michagogo's had a number of mismatches in the past too https://github.com/bitcoin-core/gitian.sigs/issues/658
< bitcoin-git> [bitcoin] practicalswift opened pull request #12516: Avoid unintentional unsigned integer wraparounds in tests (master...unsigned-integer-wraparounds-in-tests) https://github.com/bitcoin/bitcoin/pull/12516
< arubi> <- fivepiece . gonna build a bit later on when I can free resources for the vm
< arubi> midnightmagic,
< bobby__> hi guys, am I right here to ask question in regards of creating a p2sh transaction?
< mmgen> bobby__: that's more a question for #bitcoin
< mmgen> bobby__: or #bitcoin-dev
< bobby__> ok cool, thanks
< midnightmagic> arubi: Oh! oh wxcellent. where do I find your key, outside of the key servers..?
< arubi> midnightmagic, I don't think it's out there anywhere. belcher has it from me and not a keyserver
< midnightmagic> okay I'll go bug him. \o
< arubi> well, from me on email, not me irl :)
< provoostenator> midnightmagic there's rumors of a key signing party in a few weeks. I've used for signing releases for the Blockchain wallet back in the day for at least a year. It's on my Twitter profile. I should put it on my slides next time I give a presentation...
< wumpus> cfields: agreed, good call
< wumpus> mryandao: I didn't know about the CODEOWNERS feature, will take a look
< midnightmagic> provoostenator: thanks!
< wumpus> mryandao: something that suggests automatically reviewers for a piece of code would be useful, they've had suggestion based on the last persons to touch the code for a while, but this seems a more formal scheme
< wumpus> (akin to MAINTAINERS in linux kernel and such)
< wumpus> ooh you can even assign certain file types to a certain reviewer
< wumpus> that could be useful to have a specific reviewer for build files, documentation, icons, etc
< wumpus> esotericnonsense: "so my understanding is that these boost.signals2 things are just 'callback managers' " yes - boost signals are an implementation of signals/slots pattern, similar to that in qt and 'delegates' in some other languages, it is a generic pattern for decoupling the sender of an event from the handler
< wumpus> one-to-many broadcasting within the thread/address space
< wumpus> we're kind of in the middle of getting rid of it, in favor of more convential c++ish dispatch using interfaces
< booyah> wumpus: why get rid of it?
< wumpus> apart from the general move away from boost, performance reasons, and annoying debugging due to huge tracebacks due to all the templating high magic happening in boost
< michagogo> cfields: really? That’s odd.
< michagogo> One sec, I’ll get them out to see what’s going on.
< michagogo> https://1drv.ms/f/s!AvCguGMVwWzLgxcDhVPN2iRMdHNQ
< michagogo> As soon as it finishes uploading the results will be here
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aae64a21ba25...8c33961313d9
< bitcoin-git> bitcoin/master 42e1b5d Karl-Johan Alm: [test] Round target fee to 8 decimals in assert_fee_amount...
< bitcoin-git> bitcoin/master 8c33961 Wladimir J. van der Laan: Merge #12486: [test] Round target fee to 8 decimals in assert_fee_amount...
< bitcoin-git> [bitcoin] laanwj closed pull request #12486: [test] Round target fee to 8 decimals in assert_fee_amount (master...round-assert-fee-amount-target-fee) https://github.com/bitcoin/bitcoin/pull/12486
< AndyS2> if I have a CPubKey via GetPubKey() and I do a Hash(pubkey.begin(), pubkey.end()) on it I'm not getting the right hash (I'm using http://gobittest.appspot.com/Address to compare). What function should I use to hash a pubkey with SHA256, like bitcoin core does it for addresses (in the first step)?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c33961313d9...28b8061d9f1c
< bitcoin-git> bitcoin/master ac91ea6 Henrik Jonsson: [depends] Allow depends system to support armv7l
< bitcoin-git> bitcoin/master 28b8061 Wladimir J. van der Laan: Merge #12474: [depends] Allow depends system to support armv7l...
< bitcoin-git> [bitcoin] laanwj closed pull request #12474: [depends] Allow depends system to support armv7l (master...fix-armv7-depends) https://github.com/bitcoin/bitcoin/pull/12474
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/b0f692f81e22587ca98e893a6eb0b6246c5b62b0
< bitcoin-git> bitcoin/0.16 b0f692f Henrik Jonsson: [depends] Allow depends system to support armv7l...
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/28b8061d9f1c...acd1e6155ca6
< bitcoin-git> bitcoin/master fadb39c MarcoFalke: test: Plug memory leaks and stack-use-after-scope
< bitcoin-git> bitcoin/master acd1e61 Wladimir J. van der Laan: Merge #12477: test: Plug memory leaks and stack-use-after-scope...
< bitcoin-git> [bitcoin] laanwj closed pull request #12477: test: Plug memory leaks and stack-use-after-scope (master...Mf1802-qaMemLeaks) https://github.com/bitcoin/bitcoin/pull/12477
< wumpus> AndyS2: Hash160
< AndyS2> wumpus: but it's 256 first, 160 second, right?
< wumpus> or just GetID(), which does it for you
< AndyS2> wanted to play it through 'manually'. I only want the result after the first round, i.e. a single sha256 hash
< AndyS2> of the public key.
< wumpus> Hash160 is RIPEMD160(SHA256(x))
< AndyS2> I want SHA256(x)
< AndyS2> any chance to get that?
< wumpus> then use a SHA256? Hash and Hash160 are 'cooked' functions for the specific purposes in bitcoin
< wumpus> I'm sure there's low-level cryptography functions buried under there
< AndyS2> ah, I thought CHash256-stuff was for the bitcoin specific ones
< AndyS2> thanks. so hash.h only has the higher level but doesn't provide single hashes
< wumpus> right - crypto/sha256.h has the base algo, in CSHA256, it's named after the specific algorithm
< wumpus> hash.h is definitely bitcoin specific, apart from murmur and siphash I suppose
< AndyS2> I'll look at crypto/sha256.h then, thank you
< AndyS2> this all seems like stuff that's extremely obvious to people already familiar with the code, but to someone diving into it (and with sub-par c++ experience), he comments can be kind of misleading ^^
< AndyS2> *the comments
< wumpus> would have been borderline nicer to add low-level headers for murmur and siphash (analogous to sha256 and ripemd160) instead of embedding their interface into hash.h
< wumpus> feel free to improve the comments :) people familiar with the code likely read over them
< cfields> I think it's too low-level to be useful for us, but still very interesting
< wumpus> cfields: right, it seems a method of checking compilers, not so much projects compiled in compilers. Indirectly useful to use if it increases the reliability of LLVM, of course.
< cfields> right. It'd be great if all compiler optims began shipping with correctness proofs :)
< wumpus> something like KLEE would be more useful if we want to do proofs about bitcoind itself
< wumpus> I agree. maybe after CPUs start shipping with correctness proofs
< cfields> heh
< wumpus> (that's not just joking, Clifford Wolf etc are working on that for RISC-V)
< cfields> oh really? that's awesome. My first thought was Intel and how fast their marketing dept. would shut that down due to non-determinism-as-a-feature
< cfields> I'll read up on the RISC-V work, that's exciting.
< wumpus> I agree, with Intel (and AMD) I wouldn't ever expect it, I'm sure they're doing all kinds of testing and verification, but no way they'll ever release such info to customers. Also not sure how realistic it is with all the cruft that x86 architecture has grown with level after level of backwards compatibility. ARM did release a machine-parseable architecture specification, that's neat.
< wumpus> yes many exciting things are happening in RISC-V
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #12518: [0.16] Bump leveldb subtree (0.16...Mf1802-leveldbSubtreeBump) https://github.com/bitcoin/bitcoin/pull/12518
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/acd1e6155ca6...07090c533943
< bitcoin-git> bitcoin/master face722 MarcoFalke: qa: Move common args to bitcoin.conf
< bitcoin-git> bitcoin/master 07090c5 MarcoFalke: Merge #12443: qa: Move common args to bitcoin.conf...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12443: qa: Move common args to bitcoin.conf (master...Mf1802-qaCommonArgsToFile) https://github.com/bitcoin/bitcoin/pull/12443
< jojeyh> i've been git cloning to always get the newest version of bitcoin
< jojeyh> can i just git pull in my local /bitcoin repository
< jojeyh> to get 0.16.0
< jojeyh> for segwit, is voluntary malleability of a transaction possible still ?
< jojeyh> BIP141 only says segwit prevents involuntary malleability
< jojeyh> what are some possible voluntary malleabilities ?
< gmaxwell> Sure, you can still use sighash flags to set anyone can pay or whatever.
< jojeyh> cool
< jojeyh> can a transaction have multiple scriptPubKey ?
< jojeyh> nvm i need to read way more before i start asking questions
< jojeyh> will be back!
< belcher> the transaction could have multiple outputs, with a scriptPubKey in each
< belcher> also #bitcoin might be a better channel
< jojeyh> belcher, thx
< jojeyh> belcher, says i cannot join without being 'identified by services'
< jojeyh> 'identified with services'
< jojeyh> is #bitcoin on freenode ?
< belcher> that's nickserv on freenode
< bitcoin-git> [bitcoin] whitslack opened pull request #12519: Net: Pass MSG_MORE flag when sending non-final network messages (master...MSG_MORE) https://github.com/bitcoin/bitcoin/pull/12519
< belcher> read /msg NickServ help