< GitHub23>
[bitcoin] laanwj closed pull request #7640: Removes forward slash (/) from user agent in peers tab UI. (master...master) https://github.com/bitcoin/bitcoin/pull/7640
< GitHub55>
[bitcoin] laanwj closed pull request #7553: Remove vfReachable and modify IsReachable to only use vfLimited. (master...2016-02-17-reachable) https://github.com/bitcoin/bitcoin/pull/7553
< GitHub32>
bitcoin/master 9f14e5a Wladimir J. van der Laan: Merge #7553: Remove vfReachable and modify IsReachable to only use vfLimited....
< achow101>
well it looks like the rpc tests do have regtest mining stuff there, but I'm not sure that it will work well with not being in the Bitcoin Core project.
< achow101>
warren: I suppose I could do that, but that just make things annoying since this is just for rpc tests for Armory. Do you know if the Bitcoin Core rpc tests have mining implmented in them? If so I can just borrow that
< achow101>
Is there any way in Bitcoin Core to mine to a specific address when in regtest mode?
< GitHub191>
[bitcoin] MarcoFalke opened pull request #7666: [0.12.1] Fix doc and output for rpcauth (0.12...Mf1603-012fixdocrpcauth) https://github.com/bitcoin/bitcoin/pull/7666
< GitHub50>
[bitcoin] jtimon opened pull request #7665: Contrib: Introduce script to tag compiled binaries for convenience (py) (master...0.12.99-contrib-tag) https://github.com/bitcoin/bitcoin/pull/7665
< GitHub45>
[bitcoin] sipa opened pull request #7663: Make the generate RPC call function for non-regtest (master...generatenonreg) https://github.com/bitcoin/bitcoin/pull/7663
< GitHub152>
[bitcoin] sipa closed pull request #7642: Avoid "Unknown command" messages when receiving getaddr on outbound c… (master...GetAddrUnknownCommand) https://github.com/bitcoin/bitcoin/pull/7642
< GitHub95>
bitcoin/master c8d2473 Pieter Wuille: Merge #7642: Avoid "Unknown command" messages when receiving getaddr on outbound c…...
< GitHub95>
bitcoin/master 9988554 R E Broadley: No "Unknown command" for getaddr command.
< GitHub107>
[bitcoin] MarcoFalke opened pull request #7661: [wallet] Round up to the next satoshi on odd fee rates (master...Mf1603-walletCeil) https://github.com/bitcoin/bitcoin/pull/7661
< wumpus>
this logic in CFeeRate::GetFee is giving me a headache: https://github.com/bitcoin/bitcoin/blob/master/src/amount.cpp#L24 so it computes the fee from the fee/kb and the size of the transaction, so far so good. But why is there a check to set the fee to nSatoshisPerK if the resulting fee is 0?
< GitHub63>
[bitcoin] Lewuathe opened pull request #7653: Suppress unused variable warning in automated test (master...suppress-unused-variable-warn) https://github.com/bitcoin/bitcoin/pull/7653
< GitHub19>
[bitcoin] rebroad opened pull request #7651: Only need to subtract 1 (originally time was in seconds). (master...AskforTime) https://github.com/bitcoin/bitcoin/pull/7651
< GitHub70>
[bitcoin] promag opened pull request #7649: Prevent multiple calls to CWallet::AvailableCoins (master...enhancement/prevent-multiple-calls-availablecoins) https://github.com/bitcoin/bitcoin/pull/7649
2016-03-07
< GitHub188>
[bitcoin] laanwj closed pull request #7461: Make internal (core) errors show up in the Qt client. (master...propagateAlert) https://github.com/bitcoin/bitcoin/pull/7461
< GitHub126>
[bitcoin] instagibbs closed pull request #7602: [WIP] [RPC] Add call zaptransaction to delete transaction from wallet (master...zaponetx) https://github.com/bitcoin/bitcoin/pull/7602
< gmaxwell>
Naphex: you can try #bitcoin-wizards; but without a more coherent view of the applicability I don't know if it will be productive, but someone there might want to discuss it with you.
< gmaxwell>
You might want to take your brainstorming elsewhere, this channel is for concrete activity around bitcoin core today.
< gmaxwell>
this is unrelated to bitcoin---- an entirely different and largely inapplicable area of science which refers deals with adaptive rate control against invisible remote buffers of unknown capacity.
2016-03-06
< GitHub188>
[bitcoin] laanwj closed pull request #7643: Remove always true cases in wallet/crypter.cpp encrypt and decrypt function (master...master) https://github.com/bitcoin/bitcoin/pull/7643
< GitHub4>
[bitcoin] btcdrak opened pull request #7648: BIP9 versionbits softfork for BIP68, BIP112 and BIP113 (master...vb_68_112_113_1) https://github.com/bitcoin/bitcoin/pull/7648
< GitHub165>
[bitcoin] raedah closed pull request #7569: show multiparty transactions clearly in qt transaction list (master...fixtxdisplay) https://github.com/bitcoin/bitcoin/pull/7569
2016-03-05
< GitHub179>
[bitcoin] pstratem closed pull request #7629: Order CTxMemPool::queryHashes result by feerate including descendents. (master...2016-03-01-queryhashes) https://github.com/bitcoin/bitcoin/pull/7629
< GitHub118>
[bitcoin] promag opened pull request #7646: Fix lockunspents help message (master...support/fix-lockunspent-help-message) https://github.com/bitcoin/bitcoin/pull/7646
< gmaxwell>
https://news.ycombinator.com/item?id=11223266 latest timing attacks on ECDSA paper is now published. #bitcoin-core-user-not-impacted. Though perhaps we should CVE versions prior to 0.10.
< GitHub116>
[bitcoin] JeremyRubin opened pull request #7643: Remove always true cases in wallet/crypter.cpp encrypt and decrypt function (master...master) https://github.com/bitcoin/bitcoin/pull/7643
< GitHub22>
[bitcoin] rebroad opened pull request #7642: Avoid "Unknown command" messages when receiving getaddr on outbound c… (master...GetAddrUnknownCommand) https://github.com/bitcoin/bitcoin/pull/7642
< GitHub59>
[bitcoin] laanwj closed pull request #7586: fixes/refactoring for building against LibreSSL (master...2016/02/fix_openssl_libressl) https://github.com/bitcoin/bitcoin/pull/7586
< GitHub45>
[bitcoin] laanwj closed pull request #7605: Remove openssl info from init/log and from Qt debug window (master...2016/02/rm_openssl_log) https://github.com/bitcoin/bitcoin/pull/7605
< GitHub137>
bitcoin/master 7f001bd Wladimir J. van der Laan: Merge #7605: Remove openssl info from init/log and from Qt debug window...
< GitHub137>
bitcoin/master 5ecfa36 Jonas Schnelli: Remove openssl info from init/log and from Qt debug window
< GitHub198>
[bitcoin] jtimon closed pull request #7563: libconsensus-p2a: Decouple pow.o from chain.o and move it to the consensus package (master...libconsensus-p2a-chain-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7563
< jouke>
bitcoind -help-debug checks if bitcoin core is running?
< GitHub153>
[bitcoin] makevoid opened pull request #7636: Add bitcoin address label to request payment QR code (master...request_payment_qrcode_address_label) https://github.com/bitcoin/bitcoin/pull/7636
< GitHub133>
[bitcoin] jtimon closed pull request #7566: WIP: Implement BIP9 and get BIP113 to be ready to be deployed with it as an example (master...bip9-0.12.99) https://github.com/bitcoin/bitcoin/pull/7566
< GitHub57>
[bitcoin] jtimon closed pull request #6907: Chainparams: Use a regular factory for creating chainparams (master...chainparams-factory-0.12.99) https://github.com/bitcoin/bitcoin/pull/6907
< GitHub21>
[bitcoin] jtimon closed pull request #7310: MOVEONLY: Move consensus functions out of main (master...consensus-moveonly-0.13.99) https://github.com/bitcoin/bitcoin/pull/7310
< GitHub106>
[bitcoin] pstratem opened pull request #7629: Order CTxMemPool::queryHashes result by feerate including descendents. (master...2016-03-01-queryhashes) https://github.com/bitcoin/bitcoin/pull/7629
< Giszmo>
Looking into bip142 I wonder if there is a schema to optionally allow segWit that would be compatible with bip21? some bitcoin:1....?amount=12&segWitAllowed=true kind of downwards compatible style we could use in mycelium to leave it to the sender if he wants to use segwit?
< GitHub130>
[bitcoin] luke-jr opened pull request #7625: Bugfix: Check for bench_bitcoin being enabled where needed, and skip UniValue dependency when unused (master...bugfix_bench_checks) https://github.com/bitcoin/bitcoin/pull/7625
< GitHub168>
bitcoin/0.12 ca8f160 Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
< gmaxwell>
mostly unchanged over the last several years" --- kristov claimed this to me in #bitcoin several weeks ago, and I refuted it at list listing pages of features.
< gmaxwell>
I wonder if anyone connected to OBPP ever ran bitcoin core, their screenshot is four years old. It's especially disappointing that it claims "the Qt client has remained
< btcdrak>
This channel is for Bitcoin Core development discussion. please move to #bitcoin.
< randy-waterhouse>
except the report is NOT for experts ... I might be the most paranoid bitcoin user out there (of the ones i know of), I use only core and that report seems to come to highly erroneous conclusions
< btcdrak>
shouldnt this conversation be in #bitcoin ?
< gmaxwell>
catlasshrugged: some people are. I am, and I had one person in here contact me privately and suggest that the report attacked bitcoin core specifically for political reasons related to blocksize drama (citing comments by you and other OBPP) folks. For what its worth, I told them that I didn't think that was the case here.
< catlasshrugged>
I really appreciate any help people can put forth, especially with improvements to the threat model, the way that different attacks are weighted, and the correct modeling of full node clients like Bitcoin-Qt
< gmaxwell>
I think bitcoin.org wallet criteria did some disclosure requirement stuff, I'm looking for it now.
< gmaxwell>
bitcoin.org has disclosure requirements, IIRC.
< gmaxwell>
warren: why not go work on improving Bitcoin Core's privacy documentation? :) it's scattered in many places.
< gmaxwell>
in any case, catlasshrugged offered to go break out some of the analysis on Bitcoin Core. I think that would be super useful to us--- and much better a use of time then the circular argument now.
< gmaxwell>
Luke-Jr: and electrum is accordingly ranked lower than bitcoin core for privacy. I'd agree. (I think the armory developers would agree too)
< gmaxwell>
Yes, I think most people would agree that electrum has significantly worse privacy than bitcoin core due to the server model.
< gmaxwell>
catlasshrugged: many people have been basically begging you to substantiate placing many of these wallets that phone home the users addresses over bitcoin core. You haven't. Perhaps it will take you some research to do that-- I understand you didn't make this report all yourself--... probably you should go do that and we can continue discussions later.
< catlasshrugged>
NEWS FLASH: Everyone has access to a massive information that could be used to denanonymize a large % of all bitcoin addresses -- it's called the blockchain and Google
< petertodd>
catlasshrugged: right now bc.i as an example has access to a massive amount of information that could be used to deanonymise a large % of all bitcoin addresses - lets be clear on that
< catlasshrugged>
what bitcoin privacy engineering did you do during those 6 years?
< catlasshrugged>
aknix: can you remind me about your expertise in bitcoin privacy engineering?
< catlasshrugged>
as you've pointed out a billion times in public, it's easy to sybil the bitcoin network anyway, so it's not like SPV wallets are a lot better off
< sipa>
catlasshrugged: in what way is Bitcoin-Qt's privacy worse than Samurai's?
< dirtynewshoes>
I do not believe the goal of bitcoin-qt is not to be easy privacy for the average user.. but to be a solid foundation that works well
< warren>
Your report would be better to exclude Bitcoin-Qt entirely, then you're at least comparing apples to apples, or "of the lite wallets which is least bad for privacy".
< sipa>
catlasshrugged: then you should at least be able to give one aspect at which bitcoin-qt ranks lower than your #1
< catlasshrugged>
bitcoin-qt is a wallet. I'm not going to exclude it.
< catlasshrugged>
petertodd: that's relatively true, though when I wrote about the use of Bitcoin-Qt in a book, I found that people desperately needed the directions. Especially setting connecting it to Tor, etc.
< petertodd>
sipa: Bitcoin Core is something non-experts can and do run mind you
< sipa>
If expert bitcoin users is not the audience, perhaps you should exclude Bitcoin Core and say you consider it out of scope, instead of ranking it lower than others without any argument for doing so
< petertodd>
catlasshrugged: you don't need to be an expert to run bitcoin core I'll note
< catlasshrugged>
I don't think there's anything in the report that suggests that its primary audience is expert bitcoin users.
< randy-waterhouse>
"If they are expert users who know their way around Bitcoin-Qt, they don't need the report." ... perhaps this caveat needs to be displayed prominently somewhere in the front of the report?
< catlasshrugged>
pigeons: no. the best information that I have available (unresolved objections notwithstanding) is that users would be well served to make decisions based on the report. If they are expert users who know their way around Bitcoin-Qt, they don't need the report.
< dirtynewshoes>
catlasshrugged: Would it be used by the average bitcoin user? (Stable enough?)
< gmaxwell>
I'm still hoping to hear of _any_ blockchain analysis resistance features implemented by, say, ledger that are lacking in Bitcoin Core. I may not agree with the relative ranking of these two critical areas, but ... I don't think bitcoin-core should fair poorly vs the other available wallets even when blockchain analysis is ranked much more highly than network facing privacy.
< aknix>
I mean cmon you recoomend a fake UI for a bitcoin wallet
< aknix>
what are you gonna do open tinder to use bitcoin?
< pigeons>
catlasshrugged: i didnt ask about the "average bitcoin user" I asked about "new users seeking privacy with privacy needs"
< gmaxwell>
I think you do _devistating_ harm to the bitcoin ecosystem when you present privacy disaster personal data phone-homing lite wallets as _superior_.
< gmaxwell>
catlasshrugged: I would arugue, and I think I would bury you in a public debate that in terms of practical privacy Bitcoin QT (or other FN wallets like armory) are strictly superior in actually delivered privacy; and-- their vastyly superior privacy is a primary reason why a user should want to use them.
< gmaxwell>
I think you're underemphasicing network; esp since the primary purpose of the current analysis companies are tying addresses to identities and geographies which cannot be done without a network component; but .. I don't think we need to resolve that weighing disagreement, because I think that Bitcoin Core does at least as well as almost everyone else in both. (ignoring e.g. coinjoin functionalit
< catlasshrugged>
pigeons: practically speaking, I am not concerned at all about the average bitcoin user deciding not to use Qt based on the report. The average Bitcoin user simply isn't using Qt, full stop. That's not a knock on Qt, just a statement of fact about market share.
< gmaxwell>
catlasshrugged: great, now, for all the things in the list that aren't doing coinjoin; what network analytics protection do they do better than Bitcoin Core?
< gmaxwell>
Not reusing addresses? Bitcoin core does as much as is possible there short of actually forbidding the users from doing it.
< gmaxwell>
catlasshrugged: yes, virtually all of the wallets you've reviewed send deanonmizing data to third parties. Bitcoin Core does not. Too bad it's ranked way down on your list.
< gmaxwell>
You just recommended to end users that to preserve their privacy they should run https://www.reddit.com/r/Bitcoin/comments/447s7c/samourai_is_the_most_private_and_anonymous/ If you can't acknoweldge that something is _seriously_ wrong that your process caused you to do that, or even make an _attempt_ to convince someone here that this was justfied than I don't see how futher progress is possib
< gmaxwell>
If you're saying the user is the target audience then you're currently telling them to run samouri wallet over bitcoin core; a closed source wallet that phones home the users addresses.
< gmaxwell>
catlasshrugged: if your message is that they all suck than your audience isn't an actual bitcoin user, it's the industry.
< catlasshrugged>
how do I make that meaningful to the average Bitcoin user?
< catlasshrugged>
again, I'll remind you that #bitcoin-core-dev is not the primary target audience for these reports.
< catlasshrugged>
take-aways I am not looking to express: Ledger is better than Bitcoin-Qt; Bitcoin-Qt sucks!
< gmaxwell>
I do think the comparison is a false dichotomy though; your highest rated wallet _I think_ does nothing better than bitcoin core for blockchain analysis resistance, but it's far weaker to 'network' and 'server' analysis resistance.
< catlasshrugged>
I mention the blockchain analysis vs network stuff as probably the primary determinant of Bitcoin-Qt's rank relative to other wallets. Getting the weights is the hardest part, but I want it to be the absolute best we can make it.
< gmaxwell>
petertodd: it doesn't help that many of the names on the project have been very adversarial towards Bitcoin Core in the past, work for wallets included in the report etc.
< gmaxwell>
petertodd: it's not like anyone involved failed to know that if you rank "doesn't send your address info to third parties" very highly the result will be to put armory and bitcoin core very highly.
< gmaxwell>
petertodd: I don't know that this has much value though; after all, I was arguing with catlasshrugged in #bitcoin a few weeks ao about the importance of not sending your address information to third parties.
< catlasshrugged>
primarily what I think the bitcoin core team would want to nitpick on would be our weights.wiki page (which unfortunately does not give good detail about why we chose the weights, I'd like to improve that next edition)
< aknix>
hmm thats not very bitcoin like.
< catlasshrugged>
I'd be happy to send you a copy of the ratings for Bitcoin-Qt
< gmaxwell>
catlasshrugged: where are the actual ratings for the wallet? I'd like to make for myself a list of things that your process rated other wallets higher than bitcoin core... both for a mixture of nitpicking and improvement.
< petertodd>
catlasshrugged: yes, my way of using Bitcoin Core is definitely not an average user's way - but all the same, it's not a *negative* for privacy
< gmaxwell>
catlasshrugged: well it would be, I'm not saying that I would be surprised that bitcoin core wasn't rated top or whatever, rather that things that were rated about it were ones that phone home the users addresses... thats horrifying to me. And I'd like to know what in particular you think these half dozen other wallets did better to justify the higher rating than core while they had that fundime
< petertodd>
catlasshrugged: e.g. I personally use bitcoin core as a day-to-day spending wallet, and then delete my wallet.dat files regularly to prevent making mistakes that accidentally combine inputs I don't want combined
< catlasshrugged>
N.B. ***no one in this room is an average Bitcoin user.***
< catlasshrugged>
I would consider doing a point-by-point comparison between Ledger and Bitcoin-Qt, although I am seriously wondering whether this will be an invitation to be nitpicked to death
< gmaxwell>
catlasshrugged: users cannot escape that by reusing addresses in bitcoin core, due to change.
< catlasshrugged>
gmaxwell: oops, you're right about the clicks -- Bitcoin-Qt got 0 clicks for that = full score
< gmaxwell>
E.g. Bitcoin core displays no static "wallet adresse", to get an address you hit a button which always gives you a fresh one.
< catlasshrugged>
An expert Bitcoin user can probably do everything and more with Bitcoin-Qt that he can do with Ledger.
< gmaxwell>
Bitcoin Core almost forces users to not reuse addresses, to get an old address you need several clicks (I think one is a right click).
< catlasshrugged>
HD wallets are hugely useful for incentivizing users to not reuse addresses. Keep in mind, this review is focused on the average Bitcoin user largely, and not expert users.
< gmaxwell>
catlasshrugged: uh.. you know that it's externally undetectable to users if bitcoin core uses HD wallets; right?
< gmaxwell>
catlasshrugged: what does ledger (for example) do for resistance to blockchain analysis that Bitcoin Core does not.
< kanzure>
catlasshrugged: i think you should include disclaimers like "review by bitcoin core developers has said x about this rating scheme"
< gmaxwell>
catlasshrugged: well bitcoin core has "PIR" in the naieve form: send everyone the whole database is PIR. :)
< catlasshrugged>
I would love to get some input from Bitcoin-Qt devs on this, but at the moment I'm not really clear on how to form a working relationship here
< * aknix>
would prefer being told the truth than anything else. I have always come to some bitcoin channel for that over the years ;)
< catlasshrugged>
"... like are we being negatively marked here for doing the _only_ thing known to provide strong privacy?" nope, only Bitcoin-Qt and armory got points for this criteria, all other wallets got 0
< aknix>
Also is providing a pseudo UI for a bitcoin wallet a good idea either?
< aknix>
"Unless the user explicitly requests for them to be displayed, do not display Bitcoin addresses in text or QR code form, or transaction hashes" - This seems a bit cumbersome, I dont think people would treat this much differently than a check anyway..
< catlasshrugged>
"onsidering those questionare answers which were mostly privacy positive (BIP 69 where kristov gave a misleading answer-- I don't think we should implement BIP69, it doesn't improve privacy and could hurt it); it's remarkable to me that they rated Bitcoin-QT poorly if thats where their information was coming from." the only criteria relevant Bitcoin-Qt received full marks for for random sorting of outputs.
< catlasshrugged>
"Likewise, they rated Bitcoin-Qt at 0 for physical security;" nope, Bitcoin-Qt got a zero for physical privacy. I know there is overlap, but this wasn't a security-focused assessment. It's all 100% driven by our threat model.
< * aknix>
hehheheehe bitcoin so hawt righ naow
< sipa>
i don't believe that CT in its current form is acceptable for Bitcoin, due to its huge transactions and processing requirement
< gmaxwell>
Considering those questionare answers which were mostly privacy positive (BIP 69 where kristov gave a misleading answer-- I don't think we should implement BIP69, it doesn't improve privacy and could hurt it); it's remarkable to me that they rated Bitcoin-QT poorly if thats where their information was coming from.
2016-02-29
< gmaxwell>
Likewise, they rated Bitcoin-Qt at 0 for physical security; when I believe it's the only wallet software in their test which is hardned against timing and RF sidechannels (some of the hardware wallets, like ledger are). Most of their wallets in their test do not implement meaningful KDFs for wallet encryption, thouh Bitcoin Core does.
< gmaxwell>
The reports is quite ... remarkable. For example, it places "Samourai" wallet ahead of Bitcoin-QT.... this wallet was recently in some reddit controversy when someone reverse engineered their closed source binaries and found that they were, without disclosure, sending all the user's addresses to BC.i.
< gmaxwell>
Was anyone here ever contacted by a group called the "Bitcoin Privacy Project"? They just put out a report that said that we did not respond to repeated contact attempts.
< go1111111>
a bit of friction for new devs that it might be worth it to avoid: on linux if i follow the build instructions all tests pass except for zmq_test.py, because python-zmq isn't on the build dependency list. on one hand this is fine, because it's not needed for non-devs. on the other hand, it'd be nice if tests passed after following build instructions. worth it to submit a PR like this? https://github.com/elliotolds/bitcoin/commit/bc48a5b89e1
< GitHub72>
[bitcoin] laanwj closed pull request #7537: wallet: Warn on unexpected EOF while salvaging wallet (master...2016_02_salvage_unexpected_eof) https://github.com/bitcoin/bitcoin/pull/7537
< GitHub183>
bitcoin/master 78e81b0 Wladimir J. van der Laan: Merge #7537: wallet: Warn on unexpected EOF while salvaging wallet...
< GitHub183>
bitcoin/master ca8fb59 Wladimir J. van der Laan: wallet: Warn on unexpected EOF while salvaging wallet...
< GitHub173>
[bitcoin] laanwj closed pull request #7606: [depends] builders: No need to set -L and --location for curl (master...Mf1602-curl) https://github.com/bitcoin/bitcoin/pull/7606
< GitHub24>
bitcoin/master b53d201 Wladimir J. van der Laan: Merge #7606: [depends] builders: No need to set -L and --location for curl...
< GitHub24>
bitcoin/master fa7a5c5 MarcoFalke: [depends] builders: No need to set -L and --location for curl