ghost43 has quit [Remote host closed the connection]
___nick___ has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
hacker4web3bitco is now known as howhsu
<sipa>
fjahr: see https://github.com/sipa/asmap2, with "asmap-tool encode -f -2 input.dat output.dat" it'll convert from the v1 format to a hypothetical v2 format; latest asmap-data filled goes from 1519688 to 1261182 bytes
Holz has quit [Remote host closed the connection]
<sipa>
there is a bunch of experimentation code there, but nearly all logic for decoding/encoding the v2 format is in binfmt2.cpp
<fjahr>
sipa: Cool, I will take a look
<sipa>
there's no equivalent for the "interpreter" yet, just encoding and decoding, but it shouldn't be much harder than decodong
epicleafies has joined #bitcoin-core-dev
purpleKarrot has joined #bitcoin-core-dev
jurraca_ has joined #bitcoin-core-dev
musaHaruna has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
dzxzg has joined #bitcoin-core-dev
<abubakarsadiq>
#startmeeting
<corebot>
abubakarsadiq: Meeting started at 2026-04-02T16:00+0000
<corebot>
abubakarsadiq: Current chairs: abubakarsadiq
<johnny9dev>
For qml. This last week i added a gui functional test to my legacy wallet migration flow PR and undrafted the PR. This test will use v28 to create a wallet to migrate. I also completed the Fee selection controls for picking a couple of standard targets or entering a custom fee.
<yancy>
hi
<johnny9dev>
epicleafies: can you give status?
<abubakarsadiq>
theStack: I saw some update on the mailing list as well?
<brunoerg_>
hi
<johnny9dev>
Not sure epicleafies is here but he has a bunch of PRs up for the qml. Some of the ones he worked on the last week was the desktop tray and the BIP321 integrations
<epicleafies>
yeah, this past week I've created a pr for adding bip21 uri support and updating previous PRs
svanstaa has quit [Quit: Client closed]
<johnny9dev>
thanks
<theStack>
abubakarsadiq: ah yes, that was a demonstration of the worst-case scanning attack on signet. wallets can use this to see if/how they are affected
<johnny9dev>
I think with all of what we have in PR now we're down to 6 remaining tasks out of the original 21 list to get to feature parity
<johnny9dev>
Address Book and Contacts Management, Receive Request History and BIP21 sharing, Replace-by-fee Speedup and Cancel, PSBT Import/Export, Sign/Verify message flow, External Signer/HWI
<fjahr>
Update from pinheadmz (not here today): This week I addressed review on #34905 and #34772 both have concept ACK and stale ACK so should be the home stretch then I'll rebase the big daddy #32061 on those and incorporate new feedback there. Coverage results of libfuzzer and fuzzamoto are posted in the big PR, no crashes! I started on integration tests, first with lnd -- but there are already several non-http integration
<fjahr>
issues between LND and core, from the buried taproot deployment and mempool policy changes in 29.1 (their CI is pinned at 29.0 today).
memset has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
memset has joined #bitcoin-core-dev
eugenesiegel has quit [Quit: Client closed]
eugenesiegel has joined #bitcoin-core-dev
jon_atack has quit [Read error: Connection reset by peer]
nervana21 has quit [Quit: Client closed]
<darosior>
Hi, missed the meeting but i'd like to point something out. Our implementation of the Bitcoin protocol may send a peer a second request before the first one completed. Typically this can happen at the beginning of IBD when we request 16 blocks and request a 17th directly after receiving the response to the first one. It can happen in other places
<darosior>
as well. Of course the protocol does not mandate that requests work in lockstep, but because it is unspecified other implementations took this approach instead. For instance, Eric Voskuil pointed to me libbitcoin would disconnect some Bitcoin Core peers doing IBD because they were making interleaving requests. He's since carved out an exception for
<darosior>
compatibility, but i think it would make sense to document it so other implementations don't have to debug it.
<darosior>
Do you think this is worth documenting? More generally, do you think it would make sense to document our implementation of the protocol in the same way we document for instance our relay policy rules? I'm not sure how detailed we'd want to be but there are probably more things that could fit in this document.
winterrdog has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko closed pull request #34935: cli: Return more correct error on -norpccookiefile without -rpcpassword (master...2603-cli-coockie) https://github.com/bitcoin/bitcoin/pull/34935
eugenesiegel has quit [Quit: Client closed]
eugenesiegel has joined #bitcoin-core-dev
winterrdog has quit [Read error: Connection reset by peer]
<_aj_>
darosior: we also send many GETDATA requests for txs without waiting for a response to the first before sending the second? i don't see why this would be surprising in the first place?
<darosior>
Yeah. I think that was surprising to him because he's not implemented transaction relay
ghost43_ has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43_ has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]