<bitcoin-git>
bitcoin/master 5cd15ff Sebastian Falbesoner: random: use arc4random on OpenBSD
<bitcoin-git>
bitcoin/master a7e8044 laanwj: Merge bitcoin/bitcoin#24238: random: use arc4random on OpenBSD
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] laanwj merged pull request #24238: random: use arc4random on OpenBSD (master...202202-random-use_arc4random_on_OpenBSD) https://github.com/bitcoin/bitcoin/pull/24238
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #24309: test: test that OP_1-OP_16 (but not lower/higher) start witness programs (master...cherrypick_test_13062) https://github.com/bitcoin/bitcoin/pull/24309
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
i already considered blocking that one yesterday, they were doing some really strange things like concept ACKing from another repository, i thought it was a one-time test of some kind, but apparently it continues
<laanwj>
either people are confused how to use github or it's something more insidious but i don't get it
<laanwj>
something like, do longer-term github accounts that have some comment/repository history (at first glance) bring money to sell
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
rottenstonks_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Sjors opened pull request #24313: Improve display address handling for external signer (master...2022/02/displayaddress) https://github.com/bitcoin/bitcoin/pull/24313
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<michaelfolkson>
prayank: Some proof of work would be nice. I don't think any of us want to discourage new contributors or opposing viewpoints but maintainers spending their time blocking spam doesn't seem like the best use of their time
brunoerg has quit [Ping timeout: 252 seconds]
prayank has joined #bitcoin-core-dev
<prayank>
michaelfolkson: It was sarcasm for some privacy wallets writing non sense that affect privacy of Bitcoin in general but nobody wants to talk about it. I understand your point and no disagreement.
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
<laanwj>
sure, if there is an implementation the question could be 'why is it not being merged'
<fjahr>
hi
<hebasto>
hi
<fanquake>
hi
<michaelfolkson>
hi
sipsorcery has joined #bitcoin-core-dev
<laanwj>
two proposed meeting topics then: libbitcoinkernel initial discussion + Q&MaybeA (dongcarl), Discontinue release notes wiki (MarcoFalke)
<laanwj>
any last minute ones?
<Kaizen_Kintsugi_>
hi
<laanwj>
the feature freeze is in 5 days, so i think instead of high priority for review, it might be more useful to review what has the 0.23 milestone and is a feature
<laanwj>
don't actually know what it's involved, would it need a PR?
<MarcoFalke>
fanquake promised somewhere that it will be fixed for 23.0 ;)
<laanwj>
ok
<laanwj>
will ask him personally then
<MarcoFalke>
fanquake: ^
<MarcoFalke>
He might be present
<fanquake>
it will be fixed
<laanwj>
i don't think we have any other features tagged 23.0?
<laanwj>
fanquake: awesome!
vysn has joined #bitcoin-core-dev
<laanwj>
is there anything not tagged that might be realistic to make the feature freeze?
<jonatack>
not a feature so apologies if irrelevant, but #20196 seems to be a bugfix that has been around since Oct 2020, has seen quite a bit of review, and had acks by sipa and myself
<dongcarl>
Hi all, I’ve been working libbitcoinkernel: on a plan to extract our consensus engine. I’ve written enough code to see that it can work, and I’d like to share it with you all!
<dongcarl>
I’ve written up quite a lot between the issue and the PR description and the commit messages, and I’m happy to answer questions and discuss! (Sorry jeremyrubin I just saw your response from yesterday, will reply)
<jonatack>
nice
<dongcarl>
:D
<laanwj>
glad to hear you're making progress there
<laanwj>
and that your conclusion was that it can actually work, not unimportant
<dongcarl>
Yeah I think I had to do some exploring at first, but I think the MVP (stage 1) turned out to be less work than I thought!
<laanwj>
great! we've come a long way with modularization and untangling things that should help
<dongcarl>
I think there will be some idiosyncrasies in how the API/library works, but I think it is a big win to get the decoupling work done, and we can make the library/API ergonomic at any time
<laanwj>
absolutely
<dongcarl>
One key insight here is that after we decouple, any re-coupling results in a linker/compiler failure
<dongcarl>
So it's good to get the decoupling through first, since that's a big win
<michaelfolkson>
Why was a new approach required from libbitcoinconsensus? Or is this building on top of the work done in libbitcoinconsensus?
<michaelfolkson>
I know you say "it is a stateful library that can spawn threads, do caching, do I/O, and many other things which one may not normally expect from a library." Sounds like libbitcoinconsensus couldn't do that
<laanwj>
basically because it's stateful
<laanwj>
yes
<dongcarl>
michaelfolkson: libbitcoinconsensus also only does scipt verification last time I checked
<cfields>
+100 for libbitcoinconsensus. I've been hacking on carl's branches a bit, and some single-use tools quickly emerged. It's VERY cool.
<jonatack>
michaelfolkson: if I may, just posted a file with notes I took on this
<cfields>
er, libbitcoinkernel. sorry :)
<michaelfolkson>
So libbitcoinconsensus was like a first attempt and this is now a second attempt learning lessons from libbitcoinconsensus?
<michaelfolkson>
jonatack: Thanks!
<dongcarl>
Hehe yeah cfields built a cool bitcoin-reindex tool with it!
<cfields>
michaelfolkson: bitcoinconsensus was very limited and not all that useful with what it can do realistically. libbitcoinkernel is more like a minimized version of a core node impl with no useful interfaces baked in.
<jonatack>
michaelfolkson: (those were comments on IRC here by laanwj)
<dongcarl>
If anyone thinks they're even remotely suited to the task, lmk!
<provoostenator>
dongcarl: how does this jibe with ryanofsky's multiprocess stuff?
<laanwj>
maybe someone can do a rust binding :-)
<provoostenator>
I guess this just takes a chunck out of what was already contained in the node?
<laanwj>
multiprocess is about running multiple processes, this is about splitting the code, it's related but not the same
<provoostenator>
Right, but if both involve splitting code
<provoostenator>
E.g. we got rid of all these globals and now have interfaces.
<dongcarl>
Right, I think in practice libbitcoinkernel will probably be a subset of bitcoin-node (is that the right binary?), as in bitcoin-node can link against libbitcoinkernel (not proposing that we do this yet)
<laanwj>
it could help multiprocess
<larryruane>
would libbitcoinkernel be a separate repo?
<laanwj>
larryruane: n-no plans like that for the forseaable future
<MarcoFalke>
I'd say it shouldn't affect multiprocess, as libbitcoinkernel will be wrapped in the "Node" (from the view of multiprocess interfaces)
<dongcarl>
Yeah right now I have a src/kernel/ directory where I keep libbitcoinkernel specific stuff. No plans yet of repo separation
brunoerg has quit [Ping timeout: 240 seconds]
<dongcarl>
Great questions btw :-)
<MarcoFalke>
so validation.cpp would eventually move to src/kernel/validation.cpp ?
<laanwj>
the actual validation parts, i suppose
<dongcarl>
Exactly right. The parts of src/validation.cpp that we absolutely require for the consensus engine would be moved to src/kernel/validation.cpp
<dongcarl>
The rest can stay in src/validation.cpp
<lightlike>
isn't it more the other way round, that the index rework of #24230 helps for this project too? If the indexes could run as their own process, doesnt this mean that they are also out of libbitcoinkernel?
<gribble>
https://github.com/bitcoin/bitcoin/issues/24230 | indexes: Stop using node internal types and locking cs_main, improve sync logic by ryanofsky · Pull Request #24230 · bitcoin/bitcoin · GitHub
<laanwj>
or renamed to something else if there's a better match for the remaining functionality
<cfields>
dongcarl: if I'm not mistaken, you started by globbing everything into there, then move things out piece-by-piece.
<dongcarl>
lightlike: So in my "vision quest" branches, I've found that if we merge the prune blocker PR, then we can drop the blockfilterindex, and then we can rearchitect GetUTXOStats to not unconditionally depend on the coinstatsindex, then we don't have any indices in libbitcoinkernel
<laanwj>
huh nice
<dongcarl>
Yes! It's actually quite satisfying to see every bulk of change culminate in the removal of a .cpp file in the _SOURCES list :-)
<cfields>
there are obviously some things that don't belong in that list, but are currently pulled in by something. those are basically the TODOs. util/asmap.cpp as a good example, should be moved out, but that presumably requires some refactoring first.
<laanwj>
asmap seems decidedly P2P related
<cfields>
right
<laanwj>
it might be useful as an external library for some P2P purposes in itself, but that's a whole other topic :)
<provoostenator>
p2p is not considered kernel I guess
<laanwj>
right
<dongcarl>
Nope P2P is not considered part of the kernel
<dongcarl>
However, for stage 1, we are including the mempool
<MarcoFalke>
Would it be possible to link libbitcoinkernel into bitcoind from the beginning (in #24230)?
<gribble>
https://github.com/bitcoin/bitcoin/issues/24230 | indexes: Stop using node internal types and locking cs_main, improve sync logic by ryanofsky · Pull Request #24230 · bitcoin/bitcoin · GitHub
<MarcoFalke>
sorry, 24303
<MarcoFalke>
This means that the SOURCES can be removed from libbitcoin_node?
<MarcoFalke>
(Maybe I should leave this as a code review comment)
<dongcarl>
I explored doing that, and there's no clear hierarchy between our internal .a libs and libbitcoinkernel
<lightlike>
for asmap, there is jnewbery's #22910 which, as a side-effect, might result in being able to remove the dependency
<dongcarl>
MarcoFalke: But I think that's a great idea worth exploring later on when we've decoupled more things!
<cfields>
lightlike: aha, +1. sounds like that's very possible.
<dongcarl>
Oh I think I had an easier fix for asmap in my branches :-)
<dongcarl>
I think overall, we should also make some developer notes on how to code in a way that doesn't introduce too many dependencies/coupling
vysn has quit [Ping timeout: 240 seconds]
<dongcarl>
Anyway, that's probably a topic for another day
<MarcoFalke>
Couldn't the hirarchy issue be solved by linking libbitcoinkernel in between every .a lib?
<laanwj>
we have another (probably short) topic to go, might want to wrap up
<dongcarl>
MarcoFalke: I think the brute-force way is just to add it to the top of LDADD for all binaries, but that doesn't seem "right" to me
<dongcarl>
I'm all done! We can move on
<dongcarl>
Thanks all
<laanwj>
thank you
<laanwj>
#topic Discontinue release notes wiki (MarcoFalke)
<core-meetingbot`>
topic: Discontinue release notes wiki (MarcoFalke)
<provoostenator>
So this bitcoin-chainstate binary won't actually do anything right?
<provoostenator>
It just makes sure we don't break the build.
<MarcoFalke>
Yeah, so we introduced the wiki back when no release notes were written in pull requests. They were written before a release. Obviously that approach isn't sustainable, and we switched to writing release notes when the code was written.
<MarcoFalke>
So I am thinking if we still need the wiki
<laanwj>
there's still organization + editing work left
<achow101>
We still use the wiki for finishing up release notes during the RC process
<dongcarl>
provoostenator: I'll answer after this topic
<MarcoFalke>
IIRC last time there were only a few minor typo fixes and other minor edits
<laanwj>
we definitely dont' want a PR for every little typo fix
<jonatack>
Quite a bit of editing happens in the wiki, I did a fair amount
<MarcoFalke>
My thinking is that edits will need review either way
<laanwj>
yes
<provoostenator>
But maybe a wiki is more suitable for just letting people change things, check the history, and revert if needed?
<laanwj>
but that's possible to do post-hoc for documentation
<laanwj>
i do think a wiki is a better fit in general for documents than PRs
<laanwj>
yes
<jonatack>
Some was rewriting/fixups, and some was moving similar notes together / reorganizing IIRC
<laanwj>
also the wiki can only be edited by organization members, so we don't really have to be afraid of vandalism
<prayank>
laanwj: agree and had shared this a few months back
<prayank>
agree with: i do think a wiki is a better fit in general for documents than PRs
<laanwj>
in any case i don't see a strong reason to move away from the wiki approach, at least for major releases
<MarcoFalke>
ok
<laanwj>
so it's not so much about writing the release notes (though some need to be written) but more about combining, ordering, and the final touches
<laanwj>
it's really inconvenient to do that cooperatively in PRs
<MarcoFalke>
Ideally, we'd do all of that over the year and not last minute
<laanwj>
some stuff always needs to be done last minute
<laanwj>
but yes, doing more in sync with the code is of course better
<prayank>
engineers
<MarcoFalke>
At least I've been trying to do that (#24068, ...)
<jonatack>
Subjecting release note edits to the review process seems daunting (to me :D)
<michaelfolkson>
+1
<laanwj>
i mean what could work is to have a separate repo with higher throughput than the usualy review process, and doesn't mind the noise, but that's effectively a wiki then
<MarcoFalke>
It doesn't need to be a separate repo. If someone fixes a typo in the release notes, the pull can be merged by the first maintainer that sees it
<laanwj>
also: i can't stress this enough please don't write too many release notes, it's not documentation, only a list of changes, it can refer to the actual documentation
<laanwj>
i don't like how much spam that implies
<MarcoFalke>
It is not like we need 37 ACKs and wait a week to fix a typo
<laanwj>
i really dislike PRs that just fix a typo
<MarcoFalke>
ok, that's a good point
<laanwj>
definitely not going to merge them faster :)
<MarcoFalke>
I am mostly worried about a last-minute rewrite of the release notes in the wiki (that introduce errors), but no one notices until after release
<laanwj>
well, watch the changes then
<MarcoFalke>
I mean "last-minute"
<laanwj>
i'm not particularly afraid of that tbh
<MarcoFalke>
ok
<MarcoFalke>
Heh, let's end the meeting
brunoerg has joined #bitcoin-core-dev
<laanwj>
people in the org don't usually do stupid stuff, but sure, it's good to pay attention, especially before merging them back to the branch
<warren>
Would it be harmful to point at a webpage for the latest release notes instead of being part of the distribution?
<laanwj>
i think having them (eventually) part of the distribution is fine
<provoostenator>
And having the full archive of release notes in the source code is useful too.
<laanwj>
webpages tend to disappear etc
<laanwj>
i mean who knows we'll lose the lawsuit and bitcoincore.org disappears :p just kidding i guess but good to keep things self-contained
<core-meetingbot`>
Meeting ended Thu Feb 10 20:01:42 2022 UTC.
<Kaizen_Kintsugi_>
If no one else has anything, I was in chaincode recently, and signature aggregation got brought up for optimizing a block. I'm wondering if anyone could elaborate. I assume this would be to speed up transaction validation. Does it allow more data to be packed into a block?
<Kaizen_Kintsugi_>
It was in relation to taproot
<dongcarl>
provoostenator: bitcoin-chainstate does do something! It will print out information about a datadir and wait for new blocks (encoded in hex) to process on stdin. I found it pretty cool to start it and start feeding it block 1, 2, 3, and see it work :-)
<dongcarl>
provoostenator: E.g. ./src/bitcoin-chainstate ./test-datadir (This is a draft PR please don’t use it on your actual datadir).
<provoostenator>
dongcarl: ah that's very cool, I might play with that
<laanwj>
fwiw for RCs i do link to the wiki for the preliminary release notes, for -final it gets merged back into the branch, after that the wiki is emptied and changed to a link to the release notes on the master
<prayank>
Responding to the things I checked later when meeting was going and they were shared just before meeting:
<prayank>
laanwj: I can review. I dont think Its always the case that person who implements would want to discuss it in the meeting (open source). One example was: UTXO locks saved in db. provoostenator: With this logic it would be impossible to discuss anything in wallet meeting (backlog). MarcoFalke: I think I had this idea already so suggested someone to create a bounty for it in the reddit thread shared but not sure about real issues
<prayank>
. There are lot of things that you assume, create a pr and one of the maintainers comment: this has xyz problem so always better to discuss before wasting your own time or requesting others to confirm in meeting.
<laanwj>
prayank: if you simply have questions, you can ask any time, either on github (apparently a issue already exists), no need to reserve time for it in the meeting
<laanwj>
(or here, but for longer ongoing discussion github is better)
<prayank>
laanwj: this is not a simple question and already has a github issue with no activity
<MarcoFalke>
prayank: Yeah, that means that maybe no one has looked at the BIP in-depth yet?
<prayank>
Maybe
<laanwj>
if there's no activity there's probably no developer interest
<michaelfolkson>
Kaizen_Kintsugi_: Perhaps #bitcoin-core-pr-reviews is better channel for these types of general questions. But with Schnorr we can do key aggregation schemes (e.g. MuSig2) but not signature aggregation across say inputs
<prayank>
laanwj: I have followed your comments since last few years and you are one of the devs who is always for-privacy and even in coin control disccusions i could see it. Why do you think it never made it to core?
<provoostenator>
prayank: a good place to start is probably to write a Python script that implements PayJoin using RPC calls.
JimBer110 has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<belcher>
payjoin requires a http server with ssl, is that appropriate for core? maybe im biased since i dont use core's gui myself, only bitcoind
<laanwj>
no one with expertise in bitcoin privacy methods works on bitcoin core, they all decided to make their own projects
<belcher>
payjoin is already implemented in btcpayserver, but from what i see its not very common for merchants to turn it on
<prayank>
provoostenator: that looks like discussing solutions. thanks. I will try it.
<provoostenator>
prayank: it could be a dead end, but it could also evolve to become it's own project
<provoostenator>
Proojects like Specter and Wasabi now end up using Bitcoin Core in the background.
<belcher>
i agree with provoostenator's suggestion, it shouldnt be too hard as python already has a bunch of libs for http servers/ssl
<laanwj>
belcher: yeah, it's hard to do within bitcoin core's architecture, it's very much a stand-alone wallet, fitting in any kind of coordination between wallets is going to be very difficult
<belcher>
the way joinmarket does it (it can receive as well as send payjoins) is by using tor's control port to create a one time hidden service that the other side can connect to to coordinate the payjoin
<provoostenator>
And I and others are _very_ slowly trying to chip away at some of Specter's magic to get multisig hardware wallet support directly in Core :-)
<prayank>
belcher: is it possible without sever? using ln or someting like nostr?
<provoostenator>
A server is trivial to build in Python. Not necessarily a secure one, but good enough for proof-of-concept and demos.
<belcher>
prayank bip78 says it uses http
<belcher>
note that in python you can just do "import http.server" or whatever the lib is, its easy
<prayank>
provoostenator: Wasabi has no background with core to use it and its non sense if they dont allow coin control in ww2
<belcher>
i just realized, _sending_ to payjoin invoices is much easier to implement than receiving
<prayank>
provoostenator: I work for wasabi since a few months. it can be used without full node. you can use it with full node but it does not use everything.
<belcher>
i tunnel-visioned in creating a http server in python, but thats only needed for receiving, for sending you just need to make a http request
<prayank>
belcher: you have good points. I need time.
<belcher>
implementing sending of payjoins in electrum or other wallets is also useful i think
<prayank>
and you should try nostr
<belcher>
once more wallets support sending to, maybe more merchants will end up supporting receiving (they just need to enable to option in btcpayserver, no coding is needed if they use that)
<prayank>
99% nodes use core, I am sure most of them also use core wallet RPC
<prayank>
so its impossible to improve privacy without core
<achow101>
prayank: that's an assumption that is definitely not true (that most use core wallet's rpc)
<belcher>
plenty of those nodes might use other wallets on top, such as electrum via their own server, or spectre, or samourai's dojo thing
<achow101>
there are a lot of people who run nodes and use some other wallet
JimBer110 has quit [Quit: Konversation terminated!]
<prayank>
hmm maybe makes sense
<prayank>
not sure
<belcher>
one thing worth noting, the way equal-output coinjoins work is that multiple senders come together to protect all their privacy together... the way payjoin works is that a customer and merchant together protect both their privacy, so it only makes sense to you as a customer if you think the merchant isnt spying on you, therefore payjoin is pretty pointless to be adopted by exchanges which do kyc, i.e. theres no point begging coinbase to adopt
<belcher>
payjoin
<belcher>
much more useful would be to ask places like bitcoin casinos, p2p exchanges and individual web stores to adopt payjoin
<belcher>
indeed the very first payjoin BIP was written by the operator of a bitcoin casino whos customers kept getting banned because they transferred coins straight from a kyc exchange to the casino
<prayank>
belcher: I am not sure why merchange and customer is used in this example it can be any peer1 and peer2 or alice-bob. If bitcoin was used for merchant and customer thing today maybe this thing was already solved.
<prayank>
*merchant
<belcher>
the merchant/customer relationship is used because payjoin requires a payment to be happening
<prayank>
and it can be achieved with any peers looking for privacy
<belcher>
only if theres some kind of payment going between those peers
<achow101>
if I pay you, you are the merchant, and I am the customer. merchant/customer does not mean "big company" and "single person"
<belcher>
compare that to equal-output coinjoins which generally involve different people coming together to make a transaction and not really paying each other
<michaelfolkson>
Coinjoin - you get back what you put in Payjoin - funds are actually moving from individual A to B. But I think this should be on another channel
<prayank>
I was a merchant in 2017 and I know merchants do not care about privacy in most of the case unless their brand is about privacy
<achow101>
and that is probably why payjoin does not see almost any adoption
<Kaizen_Kintsugi_>
@michaelfolkson: will do
<prayank>
I agree with most of the things you shared: achow101: belcher: I will quit and need a few days break to think about it how to make payjoin great again. Also thanks to everyone else who shared their feedback.
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]