bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
vnogueir- has joined #bitcoin-core-dev
vnogueira has quit [Remote host closed the connection]
<darosior>
b10c: (sorry to ping you every time in need some stats but) would you happen to have stats about the historical use of CPFP? I'm looking into making the fee estimator CPFP-aware
<darosior>
If you don't i can just make a script it was just in case i can avoid doing it
Yihen has quit [Remote host closed the connection]
vysn has joined #bitcoin-core-dev
babasancheti has joined #bitcoin-core-dev
babasancheti77 has joined #bitcoin-core-dev
b10c has joined #bitcoin-core-dev
babasancheti has quit [Ping timeout: 256 seconds]
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<b10c>
darosior: please continue pining me for stats, that's part of why I collect them! However, I I currently don't have any mempool CPFP stats.
<b10c>
I guess your script calls `getrawmempool true` and calculates the number of packages and size of packages based on the ancestor and descendant information?
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] kcalvinalvin opened pull request #22995: doc: Update stale comment about secure allocators. (master...update-stale-allocator-comment) https://github.com/bitcoin/bitcoin/pull/22995
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<darosior>
b10c: i don't have one atm but i was thinking of just crawling the chain and look for each transaction if they have childs in the same block which increase the package feerate. Think it'd be a good enough heuristic
jespada has joined #bitcoin-core-dev
<darosior>
Maybe on the last 100k blocks it shouldn't take too long (esp. with RCasatta[m]'s awesome block_iterator)
babasancheti77 has quit [Quit: Client closed]
babasancheti has joined #bitcoin-core-dev
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<darosior>
Nope, i will be trying to make CBlockPolicyEstimaor not assume that the first transaction in a chain paid its fees itself. (don't think it'll be hard but i wanted to gather some usage statistics to further motivate this change)
<darosior>
Similar to my PR to re-include replacement txs into estimates
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] theStack opened pull request #22998: test: use MiniWallet for make_utxo helper in feature_rbf.py (master...202109-test-use_miniwallet_for_make_utxo) https://github.com/bitcoin/bitcoin/pull/22998
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
gene has joined #bitcoin-core-dev
dviola has quit [Quit: WeeChat 3.2.1]
prayank has joined #bitcoin-core-dev
<prayank>
I had added some topic for meeting today according to bitcoin core wiki. It's 12 AM here and I want to sleep early today. Shared my thoughts here which most probably would not matter, but better than suggesting a topic and saying nothing: https://gist.github.com/prayank23/e385e31427989c47e715d61556772d02
prayank has quit [Remote host closed the connection]
dviola has joined #bitcoin-core-dev
<laanwj>
ok, thanks for the heads up
Talkless has quit [Quit: Konversation terminated!]
<jonatack>
ajonas: not sure the analytics (gaug.es) is needed
<jonatack>
but very cool (thank you!)
<ajonas>
yeah, that's not hooked up to anything
<ajonas>
but happy to remove
<achow101>
currently CFeeRate::GetFee always rounds down (via truncation), but this seems to be incorrect behavior to me, although we have tests for it
<achow101>
it means that at some feerates and sizes, we end up paying a feerate that is less than intended
Guest57 has quit [Quit: Client closed]
<achow101>
this can also lead to an assertion failure in coin selection
<laanwj>
would "always round up" lead to better behavior?
<achow101>
I propose in #22949 that we change to rounding up, but there are concerns that this could affect policy
<gribble>
https://github.com/bitcoin/bitcoin/issues/22949 | fee: Round up fee calculation to avoid a lower than expected feerate by achow101 · Pull Request #22949 · bitcoin/bitcoin · GitHub
<achow101>
so I just wanted to get more people familiar with policy to have a look at that and figure out whether it would actually affect policy
<achow101>
laanwj: yes. it both avoids the assertion failure, and guarantees that the targeted feerate is being met
<laanwj>
so for policy you'd ideally want to round down, but for the wallet up?
<laanwj>
could make it an explicit flag
<achow101>
I guess? I don't think it actually affects policy since GetFee is only used to get the minrelayfee and incremental relay fee
<laanwj>
if it doesn't affect policy then it's moot
<achow101>
it's a bit odd to me that policy and the wallet would have different behavior for calculating at the same feerate
<laanwj>
well one is for what you want paid, the other is for what you pay, it's different sides of the transaction
<achow101>
I'm pretty sure it has no affect on policy, but I don't know policy well enough to definiteively say so
<laanwj>
ok, that would be something to figure out for sure
<laanwj>
no one else weighing in now, i guess that concludes the topic
<laanwj>
anything else to discuss today?
<jonatack>
hm, few existing tests needed to be updated, given how much functional fee rate testing we have. will review
<michaelfolkson>
Just inform the mailing list that this change is being proposed if it is touching policy? I don't see any bad implications and neither does darosior on that issue you linked achow101
<laanwj>
yes, if it (noticibly) affects policy it would be good to discuss on the ml
<michaelfolkson>
I can't see there being any discussion but good to follow what is most likely best practice going forward
<laanwj>
that concludes the meeting i guess, thanks everyone
<jamesob>
Hey, is anyone working on a patch for bitcoincoreorg that includes new binary verification instructions based on the aggregate sigs? If not I was going to start on a patch. cc dongcarl harding wumpus BlueMatt
<harding>
Not at the moment, would love your help!
<achow101>
while you're at it, perhaps update contrib/verifybinaries/verify.py
<BlueMatt>
or maybe do that and update bitcoincoreorg to just mention/point to that script?
<BlueMatt>
tho i guess that doesnt help winblowz users
sipsorcery has quit [Ping timeout: 260 seconds]
<jamesob>
cool, will get on it. Good idea about verify.py.
bomb-on has joined #bitcoin-core-dev
<jamesob>
BlueMatt: I would love to know how big the intersection is of people are both running on windows and have a serviceable gpg installation
<achow101>
there are a bunch of windows pgp/gpg software
<BlueMatt>
achow101: yes, but that make it easy to fetch trusted keys, verify a file, then hash-check other files based on that file?
<jamesob>
achow101: I'm sure the software's there, but users who run it...
<BlueMatt>
you'd also need a sha256sum copy...
<BlueMatt>
and, of people who have all those things, how many dont have python3?
<laanwj>
some people do verify signatures on windows
<laanwj>
manually, with a pgp program
<jamesob>
I'm sure someone in this room has some kind of elaborate cygwin/WSL setup, please chime in :)
<achow101>
windows has a different (GUI I think too) tool for calculating sha256 hashes
<achow101>
no automatic comparison like sha256sum though. I think people just verify the hashes match visually
<laanwj>
yes, it's a more manual process
<achow101>
the old verification docs had windows instructions
<laanwj>
it's always funny how GUIs are supposed to make things easier, but often make for more manual work
sipsorcery has joined #bitcoin-core-dev
<sipa>
gleb7: re your comment about addrman rationale... i do not remember
<BlueMatt>
jamesob: ideally the new script should be something that runs on bitcoincoreorg as well, preventing binaries from being uploaded unless it passes.
<jamesob>
BlueMatt: oh good point
roconnor has joined #bitcoin-core-dev
<roconnor>
has anyone reviewed the implementation of sha256sum? I've been meaning to do it because I'm somewhat nervious that there exists some sort of obtuse input to it that would trick it into returning a successful comparision somehow.
<laanwj>
wouldn't need to upload binaries at all if bitcoincoreorg could do the guix build :)
<laanwj>
and produce the torrent, i guess
<BlueMatt>
probably could do that too, someone should totally make that happen :p
<laanwj>
roconnor: given how many projects rely on it it'd be a huge CVE if so
<roconnor>
Oh? Do lots of project rely on the sha256sum verificaiton mode?
<BlueMatt>
yes
<laanwj>
that said, i'm not sure it'd be an issue in our case? you *first* check the signatures, if they don't match, you don't verify the sha256sums at all, if the signatures match well... why would everyone sign a sha256sums that contains weird data
<roconnor>
That does make me feel better.
<laanwj>
yes, sha256sums -c is incredibly common in instructions
<roconnor>
okay I feel a little bit better then.
<laanwj>
and if you don't verify the PGP signatures at all and JOLO shasums256, you've not gained any security, because the same attacker replacing binaries could also replace that file
vysn has joined #bitcoin-core-dev
<roconnor>
IIUC at least some of these signers are not using dedicated bitcoin signing keys, and thus may use the same key for signing emails or whatnot.
<laanwj>
yes, but they have to sign the specific file for it to work
<BlueMatt>
at least that way there's usually a pgp verification path, though of course these days its impossible to fetch signed pgp keys anymore cause all th keyservers are dead :(
<roconnor>
I get that it is far fetched, but you just need to get some threshold many of these entities to sign some email that happens to tickle sha256sum -c in some way.
<roconnor>
and, having not looked at sha256sum myself, my prior is that these text tools will correctly verify or report failure on well-formated text files.
<roconnor>
and invoke arbitrary behaviour on non-well-formed text files.
<BlueMatt>
luckily no one uses pgp signing in emails anymore :p
<laanwj>
let alone multiple people signing the same mail
<laanwj>
but sure it's not impossible
<laanwj>
if you're that level of paranoid you should probably run your own guix build and compare against other's output
<roconnor>
For the time being I've been manually checking the sha256sums, so I'm not too worried about becoming tricked by a improperly formated file.
<roconnor>
Just to be clear, I'm not actually worried. I just want to understand where and how things could fail.
<laanwj>
sure, makes sense
<harding>
shasum on linux has an option to ignore invalid input, which was used on the BitcoinCore.org instructions. For OSX, there's no such option, and I wonder if you could just insert a line in the SHASUMS file that said "bitcoin-22.0.blah.tar.gz SUCCESS" and make it look like it passed or something. For the Windows instructions, I think you had to do by-eye verification anyway.
<roconnor>
harding: what is the option?
<luke-jr>
#12677 has 4 ACKs and some doc improvement suggestions; shall I address them and wait on re-acks, or would someone prefer to merge it and I do a followup doc improvement PR?\
<laanwj>
luke-jr: I think it makes sense to address the small remaining comments before merge
<luke-jr>
k
<laanwj>
ignore-missing ignores missing files, which is necessary because the attestation attests to files (like un-codesigned intermediate output, debug files) that aren't shipped in the release
<harding>
Yeah, I guess I misremembered that. It's actually used on BitcoinCore.org because we expect people to only download the binaries for their arch, so the other files listed in the SHASUMS won't be present (normally).
<laanwj>
(also, someone might not download all the files before verifying)
<laanwj>
right
<harding>
Still, it ends up printing a lot less random crap, which reduces the risk of introduced false positives or negatives.
<laanwj>
it prints the names of skipped files though, what if you call a file bitcoin-22.0.blah.tar.gz-SUCCESS :)
<laanwj>
or, no, it doesn't
<roconnor>
bicoin-22.0: SUCCESS : FAILED :)
<roconnor>
*bitcoin
<roconnor>
can filenames have carriage returns in them?
<harding>
roconnor: in Linux/modern Unixes, yes. I don't know about how sha256sums handles that, but it brings up the question of whether you can put terminal ANSI escape sequences in a file name
<sipa>
$ echo >$'\n'
<sipa>
seems to work
<harding>
Yeah, I've created files with newlines by mistake lots of times over the years; they're kinda a pain to delete.
<laanwj>
our build system can't handle directories with spaces, please don't try even directories with newlines...
<laanwj>
i guess you can literally have any character in a filename except / and \0
Henrik has joined #bitcoin-core-dev
<roconnor>
Can you name a file "bitcoin-0.22: SUCCESS\n"? I'm having trouble doing this myself?
<roconnor>
er s/SUCCESS/OK ... but anyhow.
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<laanwj>
(will try, in /tmp to make sure the OS cleans it up next reboot)