< 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.
< GitHub104>
[bitcoin] jtimon opened pull request #8498: Optimization: Minimize the number of times it is checked that no money... (master...0.13-consensus-inputs) https://github.com/bitcoin/bitcoin/pull/8498
< jtimon>
kanzure: https://github.com/bitcoin/bitcoin/pull/8493 looks like a long branch (because it has many tiny steps commits that could be squashed) but it's only +373 −94 , please check it out
< GitHub7>
[bitcoin] laanwj closed pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< GitHub52>
bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
< jonasschnelli>
gmaxwell: So using tor hidden service over 443 would probably allow bypassing firewalls (assume some large company firewalls where only 80,443 is open) to connect to the bitcoin network?
< GitHub28>
bitcoin/0.13 edc2c70 Wladimir J. van der Laan: Merge #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them...
< GitHub79>
[bitcoin] laanwj closed pull request #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them (0.13...btc-13-sigops) https://github.com/bitcoin/bitcoin/pull/8438
< GitHub28>
bitcoin/0.13 3f65ba2 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
< jonasschnelli>
Would ICE works for Bitcoin? Or would that require UDP? (maybe off-topic here)
< jonasschnelli>
Does bitcoin-cores UPNP (or UPNP in general) uses nat traversal or ICE? Or is the only way to get connection from the outside if your router supports uPNP and opens the port?
< GitHub86>
[bitcoin] sipa closed pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
< GitHub128>
bitcoin/master 484312b Pieter Wuille: Merge #8467: [Trivial] Do not shadow members in dbwrapper...
< GitHub128>
bitcoin/master 4a35e0f Pavel Janík: Do not shadow members in dbwrapper