< wumpus>
should probably update my key at bitcoin.org with all the new signatures though
< gmaxwell>
someone in #bitcoin said it didn't, which primed me to conclude it didn't when I looked. :)
< wumpus>
gmaxwell: do I need to do anything special for that? I just did gpg --export --armor 0x90C8019E36C2E964 > ../websites/bitcoin.org/laanwj-releases.asc and git sees no difference
< gmaxwell>
wumpus: https://bitcoin.org/laanwj-releases.asc should probably come with the signature of that key by your personal key. Keyserver retention of keys that are leafs isn't always all that good.
< GitHub112>
[bitcoin] laanwj closed pull request #8450: [Test] Replace rpc_wallet_tests.cpp with python RPC unit tests (master...2016-08-03-remove-rpc-wallet-tests) https://github.com/bitcoin/bitcoin/pull/8450
< GitHub65>
bitcoin/master 21857d2 Wladimir J. van der Laan: Merge #8450: [Test] Replace rpc_wallet_tests.cpp with python RPC unit tests...
< GitHub65>
bitcoin/master 9578333 Patrick Strateman: Remove rpc_wallet_tests.cpp
< gmaxwell>
wumpus: fyi there was a thread on bitcointalk recently where someone profiled bitcoin core, and was asking why we weren't using faster sha2 because it was 35% in their benchmarks. I pointed them to your work with the SIMD sha2. They seemed to think that there would be 10x speedups, so I was sad to have to disappoint them. :)
< GitHub188>
[bitcoin] sipa closed pull request #8560: Trivial: Fix two VarInt examples in serialize.h (master...fix_varint_examples) https://github.com/bitcoin/bitcoin/pull/8560
< GitHub15>
bitcoin/master f12d2b5 Pieter Wuille: Merge #8560: Trivial: Fix two VarInt examples in serialize.h...
< GitHub15>
bitcoin/master 7bd5ff4 Christian Barcenas: Trivial: Fix two VarInt examples in serialize.h
< GitHub193>
[bitcoin] jonasschnelli opened pull request #8573: Set jonasschnellis dns-seeder filter flag (master...2016/08/filter_seed) https://github.com/bitcoin/bitcoin/pull/8573
< GitHub121>
[bitcoin] rebroad opened pull request #8571: Don't disconnect just because a node's services have changed. (master...UnexpectedServicesNoDisconnect) https://github.com/bitcoin/bitcoin/pull/8571
< luke-jr>
midnightmagic: it makes me more confident Bitcoin in general can gain user awareness and security needed to succeed
< GitHub117>
[bitcoin] nomnombtc opened pull request #8568: new var DIST_CONTRIB adds useful things for packagers from contrib (master...DIST_CONTRIB) https://github.com/bitcoin/bitcoin/pull/8568
< GitHub129>
[bitcoin] rebroad opened pull request #8561: Show "end" instead of many zros when getheaders request received with… (master...LessGetheadersZeros) https://github.com/bitcoin/bitcoin/pull/8561
< GitHub27>
[bitcoin] laanwj closed pull request #8548: [wallet] Use __func__ to get function name for output printing (master...Mf1608-walletFunc) https://github.com/bitcoin/bitcoin/pull/8548
< GitHub157>
[bitcoin] laanwj closed pull request #8376: [Wallet][Trivial] Fix exception message to reference actual thrower. (master...2016-07-19-cwallet-sethmasterkey) https://github.com/bitcoin/bitcoin/pull/8376
< GitHub30>
bitcoin/master a55a018 Wladimir J. van der Laan: Merge #8548: [wallet] Use __func__ to get function name for output printing...
< GitHub30>
bitcoin/master fa785d1 MarcoFalke: Use __func__ to get function name for output printing
< c0der0>
so this is where the developers that sign bitcoin core reside? I saw the message at bitcoin.org and needed to verify if 01EA5486DE18A882D4C2684590C8019E36C2E964 is the right key
< GitHub196>
[bitcoin] MarcoFalke opened pull request #8548: [wallet] Use __func__ to get function name for output printing (master...Mf1608-walletFunc) https://github.com/bitcoin/bitcoin/pull/8548
< jonasschnelli>
For creating the signatures, I guess it can be a third party tool.. don't need to be part of Bitcoin-Core
< jonasschnelli>
we provide the verification-feature in Bitcoin-Qt and in the new cli only verify tool
< gmaxwell>
Yes, but using a web wallet because bitcoin core install required an extra, foreign, step would not be. :)
< gmaxwell>
I mean the bitcoin core update and the signatures for it should be a single file. The download/verifying tool can both be included in it, and available seperately (for the first time user).
< gmaxwell>
By two files I mean "bitcoin" and "the witness" if there are two files someone watching the network can tell which users check and which don't, and someone checking on an offline computer has two files to download and copy across, so they won't.
< gmaxwell>
it's important that its also easy to use the tool without it making network connections, so that it can be used on offline hosts, and also not "phone home" every time bitcoin is installed, which would make it easy to track who is using it. (both who is using bitcoin and who is using it with/without verifying-- we want a network attacker to not be able to tell users who verify from users who don'
< jonasschnelli>
(for core, except your using -server/d with bitcoin-cli
< jouke>
They should wake up indeed. But I lost a bit of confidence in "people" to be able to do so since I started with Bitcoin. On the other hand, a police officer once told me: "These people are allowed to vote".
< wumpus>
that's a much bigger problem than just bitcoin
< wumpus>
stupid fuckers, sometimes I'm about to believe the story that bitcoin is just making it easy for people to be scammed out of their money
< LeMiner>
And perhaps a topic message in #bitcoin that states to be cautious when people try to "help" you through pm's
<@sipa>
of course, then people may get users to run bitcoin-qt with -server...
< wumpus>
<gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :(
< da2ce7>
jonasschnelli we need a constant 'Project CN', so that somebody doesn't release 'bitcotn-core' and project will ignore all the signing policies. - The verify app should also spit out warnings: "bitcotn-core" is very similar to "bitcoin-core".
< luke-jr>
then your clients should hire people of their own to work as Bitcoin Core developers; off-topic anyway, #bitcoin
< catsAREnotSECURE>
signing key. During this "unofficial" meeting in #bitcoin, there were a minimum of 123 lines of comment from Wladimir van der Laan, all of which are not included in the "official" meeting log. Given the recent advisory on the website, regarding "state actors", there is speculation amoung my clients that conflict of interest disclosure and transparency may be insufficient amoung the Bitcoin Core developers.
< da2ce7>
catsAREnotSECURE, well, I'm sorry for your mistake, please move it back to #bitcoin, or elsewhere.
< catsAREnotSECURE>
This question was intended for midnightmagic. The conversation began in #bitcoin, but for transparency reasons, I sought to move it to this channel.
< catsAREnotSECURE>
Is there public disclosure of bitcoin holdings / wallets associated with specific developers?
< jonasschnelli>
sipa, gmaxwell: about the binary ecdsa signing. We could create a standard ecdsa sig along with the GPG assets sig. Something like bitcoin-osx-0.13-build.assert.ecsig, where we just place a 64byte compact sig. ecdsa(sha256(sha256(<filecontent>)), P)
< GitHub144>
[bitcoin] petertodd opened pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (master...2016-08-anyonecanpay-if-spendzeroconfchange-disabled) https://github.com/bitcoin/bitcoin/pull/8543
2016-08-18
< gmaxwell>
Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :(
< gmaxwell>
Kanzure, achow101. Regarding your public comments on the bitcoin.org notice.
< gmaxwell>
So part of why I was deflecting on the endless rathole of the bitcoin.org stuff is because I had more to say that that I didn't fit in the scope of the meeting, and we had other things to accomplish that unfortunately we didn't have time for. :(
< kanzure>
wumpus: yeah, there should be a peer review process for posts to bitcoincore.org -- and bitcoin.org would be wise to adopt a similar practice.
< anchow101>
Why not host binaries on GitHub and move completely off of bitcoin.orgs system
< kanzure>
yes it makes sense to not use "Bitcoin Foundation" -- perhaps chaincode would be a good org to blame instead? :D (kidding- let's be nice)
< wumpus>
btcdrak: we already provide torrents for people that don't want to download from bitcoin.org - it solves nothing of the verification problems ofc
< kanzure>
re: posting hashes, i also suggest we consider posting hashes and maybe sigs on bitcoincore.org -- we can also ask bitcoin.org to do the same if they feel up to that
< jonasschnelli>
Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core".
< jonasschnelli>
We still sign with "Bitcoin Foundation"
< kanzure>
should we be complaining about hkp to the bitcoin.org people?
< jonasschnelli>
Okay. I'll work on a short design and post it to bitcoin-core-dev ML
< MarcoFalke>
So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular?
< jonasschnelli>
this would allow to build a "trusted-chain" of bitcoin-core binaries
< jonasschnelli>
The only concern is – and this is why i borugh it up – the ec-pubkeys together with dev-name should be placed in bitcoin/bitcoin
< MarcoFalke>
So how do you verify bitcoin-core-verify?
< wumpus>
I suppose it will be a separate executable within the bitcoin core distribution, other software can also include it if they want, but that's not initially very important
< jonasschnelli>
bitcoin-core-verify will list valid signatues of devs by listing devs name.
< jonasschnelli>
bitcoin-core-verify <folder-or-file> -> 1) hashes file(s) 2) download gitian assets files together with ECDSA sigs 3) verify hashed against downloaded assets files 4) verify assets ECDSA sigs against in-binary-pubkeys (dev-name/pubkey)
< jonasschnelli>
bitcoin-core-verify and bitcoin-core-sign
< jonasschnelli>
I propose to add to cli tools to the bitcoin-core package
< luke-jr>
you can gitian-build things besides Bitcoin
< GitHub103>
[bitcoin] laanwj opened pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (master...2016_08_qt_choosedatadir_crash) https://github.com/bitcoin/bitcoin/pull/8540
< GitHub62>
[bitcoin] sipa closed pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453
< GitHub188>
bitcoin/master 8250de1 Pieter Wuille: Merge #8453: Bring secp256k1 subtree up to date with master...
< GitHub188>
bitcoin/master 0237096 Wladimir J. van der Laan: Merge commit 'b2135359b3ad37cf2ac09b008079ddb237eff2c9'
< GitHub188>
bitcoin/master b213535 Wladimir J. van der Laan: Squashed 'src/secp256k1/' changes from 6c527ec..7a49cac...
< GitHub32>
[bitcoin] MarcoFalke opened pull request #8536: [WIP] [qa] Adjust timeouts for micro-optimization of run time (master...Mf1608-qaOptSync) https://github.com/bitcoin/bitcoin/pull/8536
< GitHub68>
bitcoin/master 35f64e4 Wladimir J. van der Laan: Revert "[qa] Adjust timeouts for micro-optimization of run time"...
< jonasschnelli>
And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git
< jonasschnelli>
For the binary verification problem, we should have a verification process in Bitcoin-Qt/bitcoin-cli (or maybe an additional tool) that can verify a downloaded binary by downloading the gitian.sigs
< Chris_Stewart_5>
In the bitcoin developer reference, when decoding a partial merkle tree it says: Fail if there are unused flag bits—except for the minimum number of bits necessary to pad up to the next full byte.
< GitHub176>
bitcoin/0.13 40d705c Luke Dashjr: doc/release-notes: Mention the relevance of Compact Blocks on non-mining nodes' influence on network policy
< GitHub176>
bitcoin/0.13 4f55293 Luke Dashjr: doc/release-notes: Misc
< GitHub55>
[bitcoin] laanwj closed pull request #8490: [0.13] release notes: Mention new relevance of non-mining nodes on network policy; and misc fixes (0.13...relnotes_013_misc) https://github.com/bitcoin/bitcoin/pull/8490
< GitHub110>
bitcoin/master 65e6444 Wladimir J. van der Laan: Merge #8513: Fix a type error that would not compile on OSX....
< GitHub110>
bitcoin/master 8194a6e Jeremy Rubin: Fix a type error that would not compile on Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
< sipa>
Chris_Stewart_5: the sighash type is something bitcoin specific
< GitHub26>
[bitcoin] sipa opened pull request #8527: Take minRelayTxFee into account in FEEFILTER messages (master...clampfeefilter) https://github.com/bitcoin/bitcoin/pull/8527