< 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
< GitHub50>
[bitcoin] jl2012 opened pull request #8526: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH (master...minimalif) https://github.com/bitcoin/bitcoin/pull/8526
< GitHub136>
bitcoin/0.13 2f58589 Pieter Wuille: Mention dump/import support for HD wallets
< GitHub136>
bitcoin/0.13 fe20b83 Pieter Wuille: Remove refactors from list of changes
< GitHub136>
bitcoin/0.13 7f84015 Pieter Wuille: Inline mempool RPCs and feefilter into misc sections
< GitHub97>
[bitcoin] laanwj closed pull request #8519: [0.13] A few small improvements to the 0.13 release notes (0.13...relnotes-0.13) https://github.com/bitcoin/bitcoin/pull/8519
< GitHub58>
[bitcoin] laanwj opened pull request #8520: build: Remove check for `openssl/ec.h` (master...2016_08_remove_openssl_ech_check) https://github.com/bitcoin/bitcoin/pull/8520
< GitHub169>
[bitcoin] sipa opened pull request #8519: [0.13] A few small improvements to the 0.13 release notes (0.13...relnotes-0.13) https://github.com/bitcoin/bitcoin/pull/8519
< GitHub176>
[bitcoin] jonasschnelli opened pull request #8517: [Qt] show wallet version and HD state in debugwindow (master...2016/08/hd_gui) https://github.com/bitcoin/bitcoin/pull/8517
< GitHub95>
[bitcoin] jl2012 opened pull request #8514: Enforce LOW_S rules on all transactions with WITNESS BIP9 parameters (master...lows) https://github.com/bitcoin/bitcoin/pull/8514
< GitHub134>
[bitcoin] JeremyRubin opened pull request #8513: Fix a type error that would not compile on OSX. (master...fix-osx-break) https://github.com/bitcoin/bitcoin/pull/8513
< GitHub140>
[bitcoin] leijurv closed pull request #8506: Trivial: Standardize spelling of "serialize" and "optimize" in mining.cpp and main.cpp (master...serialise-typo) https://github.com/bitcoin/bitcoin/pull/8506
< GitHub47>
[bitcoin] leijurv closed pull request #8507: Trivial: Standardize spelling of "optimization" vs "optimisation" in main.cpp (master...optimization-typo) https://github.com/bitcoin/bitcoin/pull/8507
< GitHub93>
[bitcoin] leijurv opened pull request #8507: Trivial: Standardize spelling of "optimization" vs "optimisation" in main.cpp (master...optimization-typo) https://github.com/bitcoin/bitcoin/pull/8507
< 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
< TD-Linux>
they submitted a BIP draft to bitcoin-dev which only reserved the bit with no documentation of what it did
< murch>
Lightsword: Don't let yourself quote like that. You'll face endless harrassment on Reddit. :p I'm having a hard time finding the Bitcoin Classic release notes.
< murch>
By the way, while there are still lots of well-informed people reading this. Does anyone else have another list of realistic spending values for Bitcoin Nodes? I'd love to have a second scenario to test my coin selection simulation on.
< pigeons>
i asked before too, got answers about gavin making changes for CIA, "only real bitcoin address starts with a 1", etc
< luke-jr>
jtimon: to answer your earlier question best I can: I think they perceive 0.5.3 as the last release before the Bitcoin Foundation "got involved" (I know the BCF was never involved, but they're conspiracy nuts)
< gmaxwell>
e.g. if you update your bitcoin node and then days/weeks later it starts doing thing with segwit commitments that breaks your miners or pooling software, that is preferable. You would prefer the break to happen at upgrade time.