< elichai2>
achow101: I posted the survey on multiple Israeli bitcoin forums/groups, I hope they'll answer it (I feel like the Israeli community uses the gui a lot more than the international one)
< sdaftuar>
pinheadmz: i believe we compare fee rate with directly conflicted transactions, and total fee of the new transaction versus all to-be-evicted transactions
< sdaftuar>
pinheadmz: my recollection is that there are a few issues with how rbf is implemented which we should fix though
< sdaftuar>
jnewbery may have memory/notes on that
< sdaftuar>
(even part from the more well known issues like pinning or using ancestor feerates)
< pinheadmz>
sdaftuar thanks thats my understanding as well. Don't see the rate comparison explicitly in the BIP though -- should I open a PR to the BIP? Or, what is the thinking on back-porting implementation to design notes like that
< TallTim>
"The Bitcoin Core website was modified to remove references to the whitepaper, their local copy of the whitepaper PDF was deleted, and with less than 2 hours of public review this change was merged."
< TallTim>
Way to go kowtowing to CSW.
< TallTim>
On topic, it involves Bitcoin Core website operations and the devs that are spineless.
< jnewbery>
pinheadmz: I don't think I have notes anywhere, and just a very hazy recollection of some of the details. It's all in MemPoolAccept::PreChecks(). I'd be happy to go through it with you at some point if that's helpful.
< darosior>
pinheadmz: it was in the very first implem though
< darosior>
iirc
< darosior>
pinheadmz: but then if you amend the BIP for this disrepancy, should also mention others (eg: carve-out rule)
< sipa>
i don't think these things belong in BIPs
< sipa>
at least not until there is a clear single recommended approach to dealing with these problems
< sipa>
it seems to me it's a work in progress on how to address them
< sipa>
if there really is a discrepancy between bip125 and what bitcoin core implements, it could be mentioned in doc/bips.md
< jnewbery>
but even there it's possible that it'll diverge from the code over time
< luke-jr>
TallTim: #Bitcoin (also the first part is a lie, and CSW had nothing to do with it)
< TallTim>
The problem with that spin is that it will embolden CSW anyway. You guys may be great at code, but terrible at optics.
< sdaftuar>
sipa: whether bips are the right place or not is unclear to me, but i think communicating relay policies like this so that 3rd party wallets know what behavior to aim for is helpful. in the case of bip125, my hesitation towards amending or redrafting is that we should fix the implementation in other ways anyway
< luke-jr>
TallTim: again, #Bitcoin. It is off-topic here (this is about development of Bitcoin Core, not about developers of Bitcoin Core)
< sipa>
sdaftuar: fair
< TallTim>
Sure thing, code away while your enemies advance.
< TallTim>
I said what I had to say.
< luke-jr>
TallTim: I would like to discuss it with you, but in #Bitcoin
< TallTim>
Its okay, I'm done.
< sipa>
sdaftuar: my point is not that it shouldn't described or documented, only that there isn't a clear solution (yet) that we can write up and say "this is what everyone should be doing" - it's more a work in progress
< wumpus>
two proposed topics for this week: Thoughts on a future IRC meeting discussing taproot activation? (benthecarman), USDTs (User Statically Defined Traces) tracepoints in Core (b10c)
< wumpus>
but let's start with high priority for review
< wumpus>
#topic High priority for review
< core-meetingbot>
topic: High priority for review
< wumpus>
anything to add/remove or that is (in your opinion) ready for merge?
< promag>
hi
< wumpus>
looks like not :)
< wumpus>
#topic USDTs (User Statically Defined Traces) tracepoints in Core (b10c)
< core-meetingbot>
topic: USDTs (User Statically Defined Traces) tracepoints in Core (b10c)
< b10c>
While #19866 is merged, I agree with jnewbery's comment in #20960 that there should be an approach discussion before adding USDTs all over the code.
< bitcoin-git>
[bitcoin] dongcarl opened pull request #20980: guix: Test security-check sanity before performing them (master...2020-12-guix-mingw-extra-flags) https://github.com/bitcoin/bitcoin/pull/20980
< b10c>
I personally do think it makes sense to add USDTs when there is a real longer-term use-case and user. Some example script using the USDT are always good too
< jonasschnelli>
are traces also supported on macOS?
< wumpus>
yes, agree with that
< wumpus>
jonasschnelli: no, this is a linux thing
< b10c>
for ad-hoc tracing/debugging either uprobes or temporary USDT probes can be used
< jb55>
the motivating example was to not have invasive logging code for everything that needs tracing, like logging raw net msgs. we can utilize tracepoints for that.
< jb55>
and they are nice since they are scriptable
< wumpus>
to have some dedicated static probe point handy for common tasks like logging packets, and collecting statistics (e.g. like the statoshi fork)
< wumpus>
yes
< jb55>
but yeah linux only (and in theory macos but I haven't tested that)
< wumpus>
in any case in other platforms they're simply not compiled in
< wumpus>
I'm not sure what there's actually to discuss here, it seems we agree
< jb55>
I think the general pattern should be pass in any raw struct args that might be useful for bcc scripts/etc. then maybe helper arguments for simpler bpftrace scripts
< jonasschnelli>
I think this would simplify things like getting a mempool fee histogram (15836). Concept ack.
< b10c>
jnewbery's point was to not have to many so the code becomes undreable
< wumpus>
i agree, that should not be the idea
< wumpus>
also they need to be documented, so that they can be used without consulting the source code (that was my point with tracing.md)
< b10c>
I'd be happy to open an issue to collect possible traces
< b10c>
wumpus yeah, agree
< wumpus>
sounds good to me
< jb55>
the network code one will be useful, and connectblock was useful for IBD benchmarks
< b10c>
collect and discuss ofc
< jnewbery>
jb55: I don't think BPF should be seen as an alternative to message dumping. I think they serve different purposes in different situations
< wumpus>
and yes, the idea will be to have their interface, more or less, stable
< jb55>
wumpus: :+1:
< wumpus>
this means something like statoshi can be built withou having to rebase every version, otherwise one might as well use gdb breakpoints on specific functions/code lines
< jb55>
jnewbery: yes its complimentary
< wumpus>
BPF can be used for packet dumping and much more (even packet manipulation IIRC)
< jnewbery>
the nice thing about message dumping as regular functionality is that it can be turned on/off by regular users on any platform
< jnewbery>
BPF can do much more powerful things, but requires a bit of specialized knowledge
< jnewbery>
Do we know what other projects do? Do they have USDT tracepoints in their master branch?
< wumpus>
yes, that's fine, I don't think it has to be one or the other, though I would prefer not to add and maintain a complete tracing infrastructure inside bitcoin core when there are existing solutions, but if it has a clear scope, sure
< wumpus>
yes, many daemon software does
< jonasschnelli>
DTrace is available on macOS,.. does this mean it would be conceptually possible to extend this to macOS as well?
< jb55>
yes
< wumpus>
jonasschnelli: it's conceptually possible to extend it to solaris and macos
< jonasschnelli>
ok
< wumpus>
and freebsd probably
< jb55>
it uses the same macros that should place dtrace probes, but I haven't tested
< b10c>
NodeJS and V8 are two examples where USDTs are in 'master'
< jnewbery>
Great. This is all pretty new to me, but it's very exciting. Thanks jb55, b10c and wumpus for working on it!
< jonasschnelli>
sys/sdt.h is available on mac (includes mach/machine/sdt.h)
< jonasschnelli>
DTRACE_PROBE is defined
< luke-jr>
b10c: not exactly a project I'd want to imitate :P
< jnewbery>
Lots of great resources here: http://brendangregg.com/ for people who want to learn more about BPF
< b10c>
luke-jr: agree :)
< luke-jr>
(it's also only one example: NodeJS is an extension to V8)
< wumpus>
luke-jr: would agree, except in one sense: v8 is extremely performance focused
< luke-jr>
wumpus: true
< luke-jr>
mind you I'm not objecting
< wumpus>
USDT's are very lightweight which makes them useful for counting/measuring things which might otherwise give too much overhead
< jb55>
they are basically nops until the kernel hooks into it afaik
< wumpus>
okay, I'm not exactly sure about the taproot topic, benthecarman isn't here
< luke-jr>
basically the idea is to schedule a day to finish the BIP/code reviews and make a formal proposal; not really a dev topic though
< luke-jr>
well, code review is of course
< fjahr>
IMHO the main conversation should be on the mailing list. Allows more people to participate due to it being async.
< luke-jr>
but not sure there's anything for _this_ meeting
< wumpus>
luke-jr: I agree
< jonasschnelli>
--enable-ebpf works out of the box on macOS
< luke-jr>
fjahr: the idea was simply to get us to the starting poitn for the ML
< wumpus>
jonasschnelli: wow!
< michaelfolkson>
A lot easier to hammer things out in a meeting and then communicate with the ML
< fjahr>
luke-jr: ok, that's great
< luke-jr>
BIP finalised + code reviewed + some idea what to do for activation, then propose that to the ML for further comment
< michaelfolkson>
Just need to get date, time finalized. Could communicate that to mailing list and taproot activation channel
< wumpus>
ok, that concludes the topic as far as this meeting goes, i guess
< wumpus>
any other topics?
< jb55>
jonasschnelli: good to know! very cool.
< nickler>
luke-jr: what are the relevant PRs and issues? The two from aj to the BIP8 and your #19573?
< michaelfolkson>
And needs to be US and Aus friendly time?
< aj>
luke-jr: haven't checked in a while, but i think the code changes for the bip updates are in the reviews on 19573
< aj>
luke-jr: (this time on a different day seemed to work ok for the taproot reviews fwiw; not great for .au/asia but *shrug*)
< luke-jr>
weekday or weekend? :P
< michaelfolkson>
Next week? Week after?
< michaelfolkson>
Maybe Tuesday 26th Jan or Tuesday 2nd February?
< luke-jr>
fine with me
< luke-jr>
if peopel can't make it, we can always do a 2nd meeting *shrug*
< fjahr>
Maybe give a channel for people to post their thoughts beforehand if they can't join
< michaelfolkson>
Ok let's say Tuesday 2nd February. Give some time to get the word out. Same time as this meeting.
< michaelfolkson>
There is the ##taproot-activation channel
< luke-jr>
someone want to mail the ML?
< michaelfolkson>
In the absence of other volunteers I'm happy to
< michaelfolkson>
Just the links that nickler shared?
< nickler>
perhaps also good to add link to bitcoin wiki page and aj's post
< luke-jr>
good idea, then there's a wiki page to add more info to
< michaelfolkson>
Right ok, I've got them
< luke-jr>
nickler: there's also the code, after the BIP reviews
< luke-jr>
err michaelfolkson: *
< michaelfolkson>
Ok I'll share some of the links on the ##taproot-activation channel and if I miss any please add more before I send to the mailing list
< michaelfolkson>
Can take it to that channel from here
< bitcoin-git>
[gui] MarcoFalke reopened pull request #177: Use "fusion" style on macOS Big Sur with old Qt (master...210107-style) https://github.com/bitcoin-core/gui/pull/177
< Emcy>
wumpus hey you dont know me because im just a random bitcoiner, but i know youre getting a lot of heat because of events that happened today and how you reacted. I want to say that i personally appreciate the work you do and have done for bitcoin very much, and i know many others do too, even if most of the time no one says it. So im saying it now.