I am not surprised, it is good software 😎
Sometimes I think making non-system-memory size describing integers a size type, was a mistake. E.g. why should the integer describing the length of a vector vary in its bit width depending on the platform it is computed on?
Shameless podcast plug, if you want learn more about #MilkSad after the #38c3 talk this morning. https://bitcoinexplainedpodcast.com/@nado/episodes/episode-83-the-milk-sad-vulnerability
The open q and a they did after the talk was excellent, learned a lot.
Had a great time at this years CCC; some new things to follow up on and motivated to push harder over the next year.
It is time to start talking more about the kernel lib and multiprocess. I really do think kernel could ship some time next year and multiprocess will be in the next release. We need tooling, docs, examples, etc.
I found an issue in vscode describing the same problem some time ago and it doesn't seem like there is an easy workaround. It made me switch back to neovim and I use will clark's config https://github.com/willcl-ark/neovim
Vscode has problems with some of the templates used in the code. I recommend clangd as a language server in either vim or emacs.
I love the way down from the station towards piazza riforma. Something about it just always makes me feel very homely.
And if you'd tell him so, he'd try to argue the opposite
Ugh, the spammers are back in numbers.
👏 Congrats to all our contributors on finishing the final `bdk_wallet` 1.0.0 release! This tag also contains small improvements to the wallet `transactions` function and `next_unused_address` API docs. https://github.com/bitcoindevkit/bdk/releases/tag/wallet-1.0.0
Congratulations 🎉
Mostly redundant logic, like allocating twice, initializing data twice, or checking bounds inefficiently. But also unearthing past, snuck-in crash fixes, and finding stale or wrong docstrings.
Pretty cool how these kernel refactoring PRs all keep on finding minor bugs and inconsistencies.
Some people need to accept that oss devs will always be at odds with each other, their users, and their code to a certain extent.
If you like the waitfornewblock RPC and would like it to be reliable, and no longer considered a test-only feature, here's an easy PR review: https://github.com/bitcoin/bitcoin/pull/30635
Should I ACK it twice? 😛
I now host docs for the currently proposed kernel API http://thecharlatan.ch/kernel-docs/
Good question from four years ago, anyone know the answer? https://bitcoin.stackexchange.com/q/100221/4948
No, but I'm pretty sure a single hash would be slower in any case with all the time spent getting the data to the GPU and getting back the result. Mining is kind of unique, because you can really massively parallelize the hashing. Maybe you could parallelize the required hash work between the various scripts in a block and e.g. pre-compute the required sighashes in parallel. For merkle trees it is a bit ambiguous, since you have interim results that you'd have to share between jobs. My intuition is it would not be worth it.
I just spent the day kicking back and thinking today.
I think I have a similar intuition about it too. Maybe you can get a single logical gate, but hundreds or thousands... I'm not sure. My understanding is you'd have to share state between them, and what is left from my physics degree tells me that is going to be very difficult.


