< 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
< * 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?
< 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.
< 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)?
< 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