< August 2022 >
Su Mo Tu We Th Fr Sa 123456789 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
"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
i don't believe that CT in its current form is acceptable for Bitcoin, due to its huge transactions and processing requirement
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.
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.
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.
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.
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
Great, so no matter how badly screwed up this new openssl announcement is, openssl isn't being given the opportunity to touch Bitcoin signing keys.
btcdrak: fwiw all my consensus PRs merged since 0.12 's fork are already backported (with anything that would make the rebase less clean) in https://github.com/jtimon/bitcoin/tree/backports-0.12 in case they were necessary for backporting SF functionality
Does the payment protocol use Bitcoin private (signing) keys?
gmaxwell: interesting question re: PP - does the average install of Bitcoin Core's qt wallet actually let people click on a PP link and have their wallet pop up? if not, strongly suggests it isn't being used much
btcdrak: well, so long as we can co-ordinate that with the bitcoin core release schedule - which admittedly is much easier if we continue to do that in minor version releases
instagibbs: slack notifications for bitcoin irc mentions is pretty cool, it works.
zooko: it's manual, sadly. the mailing list that moderated emails are sent to is configured to only allow email from email@example.com, that's the only configuration detail. when rejecting email, the moderator has to type firstname.lastname@example.org into the bitcoin-dev moderation queue interface.
How was the bitcoin-dev mailing list GNU Mailman configured to hold all postings for moderation?
[bitcoin] jtimon opened pull request #7564: libconsensus-p2a: Preparations to decouple libconsensus from coins.o (master...libconsensus-p2a-coins-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7564
[bitcoin] jtimon opened 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
(just for tor though, the bitcoin stuff is unchanged)
yeah, the tor stuff also verifies tag signatures, so as part of my modifications to get it co-existing with bitcoin gitian I have to maintain a minor fork. gitian doesn't play nice with itself.
phantomcircuit: yes, sandboxing that code would be nice. Although arguably, against libc exploits, no one stands a chance. If bitcoin-qt doesn't get exploited itself some other service or process will, and they'll pwn the box anyway.
for segwit transactions types that are nested in P2SH (p2sh-p2wsh & p2sh-p2wpkh), is the intent that those are there primarily for un upgraded wallets to send bitcoin to upgraded wallets? Any other usage?
cfields: Good news: for osx, the dmg and -osx64.tar.gz stayed the same, just bitcoin-0.12.0-osx-unsigned.tar.gz changed. Same as you!
c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a for bitcoin-0.12.0-linux64.tar.gz
wumpus: cfields and I have been talking for a few months about an eventual replacement, basic idea is to be able to build a deterministic toolchain on any Linux distro, then use that to build things like Bitcoin.