< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18641: test: Create cached blocks not in the future (master...2004-qaNoCacheFuture) https://github.com/bitcoin/bitcoin/pull/18641
< bitcoin-git>
[bitcoin] naumenkogs opened pull request #18642: Use std::chrono for the time to rotate destination of addr messages + tests (master...2020_04_mock_addr_rotation_time) https://github.com/bitcoin/bitcoin/pull/18642
< sipa>
I wasn't aware before, but the 201 opcode limit, and the 20 keys in CHECKMULTISIG limit were initially only active for blocks >84000; in 0.3.13.5 it was changed to apply to every block
< aj>
block 84000 was a week away when the rule was added, and 10 days old when the rule was buried, give or take; neat
< sipa>
Yeah, best practices around timelines for these things *do* seem to have changed a bit since.
< sipa>
Also, the commit message is great. "misc fixes"
< fanquake>
I guess the covert change hiding commit messages have improved since then too
< sipa>
i think satoshi wrote commit messages like we write release notes
< sipa>
try to remember everything that changed since the last one, probably forget some parts
< midnight>
satoshi hid all kinds of weird stuff that I wish he'd been more posthoc open about. :(
< sipa>
midnight: i'm speculating of course, but i think he simply didn't really have an open-source minded process
< sipa>
as in, i don't think he was trying to hide anything - i think he just didn't care enough to write good notes
< midnight>
sipa: I felt the store-proxy-for-later-use-in-spite-of-what-the-user-wants was a bit anti-user.
< sipa>
?
< sipa>
elaborate
< midnight>
At one point I gave my bitcoind a proxy to connect through, which worked successfully. Later I wanted to stop using the proxy, but I hadn't correctly opened the network up on that machine. The proxy settings were stored in wallet.dat and (IIRC) the software tried to use it anyway when it couldn't connect normally. In my view this was super sneaky.
< sipa>
heh, that sounds like a bug
< midnight>
IMO based on his fairly mercenary attempt to force open incoming sockets for global connectivity it was a deliberate and not accidental design decision.
< sipa>
at the time every setting was stored in wallet.dat
< midnight>
I hope it was a bug, but.. he was pretty mercenary about incentives and user control. I hope it was buggy and not intended behaviour. :)
< sipa>
of course - you may be right
< sipa>
but also, don't ascribe to malice that which is adequately explained by incompetence
< midnight>
He never answered my question about it. That was around the time people were bashing him a lot about code quality.
< midnight>
I was trying to be polite but the avalanche of inexplicable "your code sucks" might have made me sound like them. Hope not. Maybe he just didn't get my emails. :)
< midnight>
I don't think it was malice. Not quite how I'd describe it. More just.. taking user control out of the picture for the good of the early network.
< sipa>
to an extent that is still the case - e.g. you can't request more than 8 outgoing connections
< midnight>
Yeah I was okay with it. The source was available, and of course I could just manually edit wallet.dat to remove the proxy config.
< midnight>
"You must be this tall to be able to control this feature.."
< midnight>
Also possible: it was so long ago I am misremembering what actually happened and it was all just something I misconstrued. lol
< bitcoin-git>
[bitcoin] practicalswift opened pull request #18649: tests: Add std::locale::global to list of locale dependent functions in lint-locale-dependence.sh (master...locale-dependent-functions) https://github.com/bitcoin/bitcoin/pull/18649
< bitcoin-git>
[bitcoin] practicalswift opened pull request #18650: qt: Make bitcoin.ico non-executable (master...bitcoin.ico-executable-flag) https://github.com/bitcoin/bitcoin/pull/18650
< theStack>
can anyone tell me how i know if the fuzz test found something significant? (as far as i remember the fuzz test never stops, i.e. only after receiving CTRL+C)
< andrewtoth>
so I guess the fuzz harness should consider all "significant events" and assert them
< theStack>
jonatack: oh, i didn't even use the fuzz test-runner yet, but rather called the binaries in src/test/fuzz/ directly
< theStack>
andrewtoth: ah, just by using assertions -- that makes sense
< jonatack>
theStack: that's probably best, i haven't got the runner to work yet and iiuc it's for the ci. was just looking in https://github.com/google/afl for more info on configurations
< jonatack>
theStack: calling directly like you're doing is more useful for testing PRs with new harnesses
< bitcoin-git>
[bitcoin] jonatack opened pull request #18653: test: add coverage for bitcoin-cli -rpcwait (master...rpcwait-test-coverage) https://github.com/bitcoin/bitcoin/pull/18653
< theStack>
jonatack: it seems like test_runner.py was mentioned in doc/fuzzing.md some weeks ago but now it's not anymore
< jonatack>
theStack: makes sense, i seem to recall MarcoFalke saying the runner script was really for the ci, after instagibbs and i were trying to run it unsuccessfully a couple months ago
< jonatack>
i was just peeking inside to see the config options
< MarcoFalke>
test_runner is for running over all inputs, which is useful for running against every commit
< MarcoFalke>
So mostly ci, not for extending fuzz coverage
< theStack>
jonatack: MarcoFalke: ok, so i will ignore that script for now
< bitcoin-git>
[bitcoin] achow101 opened pull request #18655: gui: Add bumpFeePSBT action instead of changing normal bumpfee behavior (master...split-bumpfeeaction) https://github.com/bitcoin/bitcoin/pull/18655
< bitcoin-git>
[bitcoin] achow101 opened pull request #18656: gui: Add a `Make unsigned` button next to `Send` (master...make-unsigned-button) https://github.com/bitcoin/bitcoin/pull/18656
< bitcoin-git>
[bitcoin] achow101 closed pull request #18627: rpc: gui: Don't change behavior based on private keys disabled, instead add new buttons/rpcs/menu items (master...split-watchonly) https://github.com/bitcoin/bitcoin/pull/18627
< vasild>
dongcarl: If you use `-onlynet=torv3`, then there is no way that you would connect to an old node that does not understand `addrv2` because such node cannot exist - there is no way that it can advertise its `torv3` address using the old `addr` messages.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #18657: chain: Do not fill out parameters in findCommonAncestor(...) if ancestor is not found (master...out-parameters-in-findCommonAncestor) https://github.com/bitcoin/bitcoin/pull/18657
< elichai2>
ariard told me there is past interaction with oss-fuzz and it was decided that the disclosure policy doesn't fit Core, is that right? I'm interested to hear about it :)
< sipa>
ping BlueMatt
< sipa>
though if i remember correctly, at the time there also was no (meaningful) fuzzers for bitcoin core, so it was mostly a philosophical point
< bitcoin-git>
bitcoin/master 808ef36 John Newbery: [doc] Update thread information in developer docs
< bitcoin-git>
bitcoin/master e84a5f0 MarcoFalke: Merge #18645: [doc] Update thread information in developer docs
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18645: [doc] Update thread information in developer docs (master...2020-04-doc-threads) https://github.com/bitcoin/bitcoin/pull/18645
< bitcoin-git>
[bitcoin] practicalswift closed pull request #18657: chain: Do not fill out parameters in findCommonAncestor(...) if ancestor is not found (master...out-parameters-in-findCommonAncestor) https://github.com/bitcoin/bitcoin/pull/18657
< BlueMatt>
elichai2: yea, oss-fuzz has some rather-strict rules about how they will disclose issues publicly after N days of reporting them.
< BlueMatt>
elichai2: at the time, and imo quite reasonably, we decided that was completely unacceptable for a p2p consensus system which may, depending on the type of failure, require network-wide update for something to be safe, and some rapid disclosure policy is not compatible with that
< BlueMatt>
elichai2: also note that oss-fuzz primarily just provides cpu hours, it doesn't do any actual implementation work for you, and getting access to a few hundred cores for bitcoin core fuzzing is rather easy :p
< sipa>
BlueMatt: on the other hand, we currently have fuzzers for the codebase (yay), and we can't prevent anyone from running them secretly on a massive cluster
< BlueMatt>
(as a reminder: lots of cpu cores are available in a few locations for those doing bitcoin open source work)
< sipa>
so perhaps... either we keep the more delicate ones private (how?), or we're ok with having the ones we have publicly participate in oss-fuzz?
< BlueMatt>
well, someone should give them more cpu hours. afair marco had previously done stuff, but...
< sipa>
of course - we can also just increase how much cpu we spend ourselves
< BlueMatt>
or we could, you know, use the cluster(s) we have to get fuzz hours :)
< sipa>
well, or both
< BlueMatt>
there's probably at least 120 cpu cores lying around for such usage, just need someone to step up and write scripts
< BlueMatt>
i mean how many cpu hours does oss-fuzz provide? I cant imagine it is anything significantly more than the 100 cores/project full-time that we already have?
< BlueMatt>
and the tradeoffs for using it...kinda suck
< sipa>
if it's indeed not (significantly more than) 100 cores, there isn't much to be gained from using it
< BlueMatt>
a few bitcoin groups gave them some funds afaiu
< BlueMatt>
but, you know, we should probably use our own cpus first.
< BlueMatt>
anyway, really just need someone to step up and manage VMs that run fuzzing. I can help a bit, I have it all set up for rust-lightning and regularly pull ~100 cores for that, but I dont really have the bandwidth to manage that all the time, let alone also for core.
< BlueMatt>
someone just let me or dongcarl know and we can get you set up with a few VMs with a bunch of cores, I presume there's soeone at blockstream who can do the same
< elichai2>
BlueMatt: are these bare metal? because running something like this to detect improvements/regressions can be very helpful: https://perf.rust-lang.org/
< BlueMatt>
kvm, but there are separate bare-metal servers intended for benchmarking cc jamesob
< BlueMatt>
(which are slower, but bare-metal and more 'average-grade' hardware)
< elichai2>
yeah but sadly you need bare metal for profiling, VMs are too dynamic for that AFAIK
< BlueMatt>
right, kvm just for non-benchmark things
< BlueMatt>
we have ~9 servers which are provisioned bare-metal for benchmarking
< BlueMatt>
9 being 8-outbound-1-target for ibd benchmarking :)
< BlueMatt>
though you'd have to ask james as to the status of those
< elichai2>
I have my own PC dedicated for profiling benchmarking, trying different system wide changes to Bitcoin Core
< BlueMatt>
anyway, hardware/cpu resources isnt the issue, just gotta have someone write bash scripts :)
< BlueMatt>
well by the time you've done that much work you might as well run it on our own hardware (without the aggressive public-disclosure timelines that may put bitcoin users at risk...)
< elichai2>
and if I understand correctly Google will actually pay you if you integrate into oss-fuzz https://github.com/bitcoin-core/secp256k1/issues/739 "We want to stress that anyone who meets the eligibility criteria and integrates a project with OSS-Fuzz is eligible for a reward."
< elichai2>
BlueMatt: right. the disclosure thing is a problem, I think they're saying either 90 days from finding or 30 days from fixing
< BlueMatt>
lol, thats kinda obnoxious that they're auto-opening issues on open source projects.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18662: refactor: Replace gArgs with local argsman in all utility tools (master...2004-toolsArgsman) https://github.com/bitcoin/bitcoin/pull/18662