<fanquake>
jamesob: see #22936. I'd assume the descriptors failure is intermittent, which results in the other error, neither of which are related to your change
<bitcoin-git>
bitcoin/master 9aa4ddb MarcoFalke: Merge bitcoin/bitcoin#23287: test: get and decode tx with a single `gettra...
<bitcoin-git>
bitcoin/master 130ee48 Sebastian Falbesoner: test: get and decode tx with a single `gettransaction` RPC call
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #23287: test: get and decode tx with a single `gettransaction` RPC call (master...202110-test-fetch_and_decode_tx_with_single_RPC_call) https://github.com/bitcoin/bitcoin/pull/23287
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<bitcoin-git>
bitcoin/master be7f413 =: Fix K1/K2 use in the comments in ChaCha20-Poly1305 AEAD
<bitcoin-git>
bitcoin/master f41aa81 W. J. van der Laan: Merge bitcoin/bitcoin#23271: crypto: Fix K1/K2 use in the comments in ChaC...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] laanwj merged pull request #23271: crypto: Fix K1/K2 use in the comments in ChaCha20-Poly1305 AEAD (master...fix-k1-k2) https://github.com/bitcoin/bitcoin/pull/23271
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
sipsorcery has quit [Ping timeout: 260 seconds]
sipsorcery has joined #bitcoin-core-dev
yanmaani1 has quit [Ping timeout: 276 seconds]
Guest48 has joined #bitcoin-core-dev
white5moke has quit [Quit: Leaving...]
white5moke has joined #bitcoin-core-dev
white5moke has quit [Remote host closed the connection]
<jonasschnelli>
#proposedmeetingtopic some personal information from myside
<josibake>
hi
Guest59 has joined #bitcoin-core-dev
<sipa>
#proposedmeetingtopic: 23306 proposes (and is a first step towards) getting rid of the prefer-port-8333 policy on the network
Guest5960 has joined #bitcoin-core-dev
Guest59 has quit [Client Quit]
<laanwj>
other proposed meeting topics: tag 0.20.3-final (fanquake) Encouraging people to propose meeting topics for the weekly IRC Core dev meetings (michaelfolkson) Attempting to transition to full RBF over multiple major versions (michaelfolkson)
<laanwj>
#topic High priority for review
<fjahr>
hi
<michaelfolkson>
Mine aren't urgent and can be pushed to another week
lsilva_ has joined #bitcoin-core-dev
Guest5960 has quit [Client Quit]
yanmaani1 has quit [Remote host closed the connection]
<laanwj>
ariard: i don't have an opinion which one, maybe someone else has
<ariard>
yeah if glozow is around :)
Talkless has quit [Quit: Konversation terminated!]
<cfields>
just a quick note: #23114 (minisketch integration, already listed as hi prio) is ~ready, but also requires review of minisketch itself. So... review beg for minisketch itself as well :)
<sipa>
regarding testing, there are exhaustive tests for various small fields (smaller than the one we'd use, but most code is shared across)
<cfields>
heh, ok, review beg retracted. I was just responding to a few "reviewed the integration but not the impl" on that PR, but apparently review has been happening too :)
<michaelfolkson>
cfields: A few months ago :)
<laanwj>
cfields: it wasn't entirely clear to me either so it's good to have brought it up imo
<michaelfolkson>
+1
<laanwj>
#topic Some personal information from myside (jonasschnelli)
<jonasschnelli>
As most of you have probably recognized, I was pretty inactive during the last months
<jonasschnelli>
Today, I'd like to inform you that I will step down as maintainer and contributor
<sipa>
jonasschnelli: sad to see you go
<cfields>
:(
<jonasschnelli>
I will remove my committer rights immediately
<laanwj>
hope you'll be back some day!
<jonasschnelli>
The reasons are mostly a shift in interest as well as rising legal risks (it wasn't you :)
<laanwj>
but i get it
<jonasschnelli>
and who know,... i might come back later down the road.
<cfields>
jonasschnelli: hope everything's ok. there will always room for you here :)
<jamesob>
Sad to see you go jonasschnelli but enjoy what other things life has to offer
<jamesob>
Come back anytime :)
<sipa>
and of course, good luck on wherever your path may lead
<jonasschnelli>
thanks all.
<jonasschnelli>
As for the macOS signing keys, I think either achow or fanquake would be a good fit
<hebasto>
come back soon :)
<luke-jr>
aren't the signing keys held by a corporate entity?
<laanwj>
yes,good luck in whatever else you're going to do
rex4539 has joined #bitcoin-core-dev
<jonasschnelli>
luke-jr: legaly yes,.. but technically someone needs to sign it
<jonasschnelli>
I’ll remain the legal „president“ of the „Bitcoin Core Code Signing Association“ in Switzerland (the construct for getting code sign certificates, currently active for macOS but only a backup for the Delaware LLC that holds the win certificate)
<jonasschnelli>
Off course, I’ll stick around here and can help where requested.
<jonatack>
sad to hear that but understandable...i hope you'll be catching some waves and enjoying life
<cfields>
jonasschnelli: also, thanks for being responsible and being willing to revoke your own access. much appreciated.
<laanwj>
jonatack: that's good to hear
<jonasschnelli>
sure things!
<laanwj>
cfields: +1
<sipa>
indeed
<jonasschnelli>
If someone likes to continue bitcoinbuilds.org, please DM me (server costs are covered)
<meshcollider>
Thanks for all your work over the years jonasschnelli! Best of luck for whatever comes next for you :)
<jonasschnelli>
thanks meshcollider!
<achow101>
sad to see you go, and good luck with whatever else you decide to do
<michaelfolkson>
+1
<luke-jr>
jonasschnelli: does it need much babysitting?
<jonasschnelli>
luke-jr: yes... it need some tweaking (and some love)
<ariard>
Yeah thanks for the numerous years of hard work, hope you'll be back
<achow101>
in terms of the macOS code signing key, I can take that over if everyone feels that isn't too centralizing
<laanwj>
jonasschnelli: re if no one else does it i'm ok with doing it
<achow101>
I can also get one issued to the Delaware LLC
<laanwj>
+bitcoinbuilds
<luke-jr>
achow101: we shouldn't be putting trust in these keys either way *shrug*
<josibake>
echoing everyone else, thank your for your contributions and best of luck in whatever you do next
<luke-jr>
laanwj: thanks
<josibake>
thank you*
<jonasschnelli>
laanwj: great to hear. It's quite a mess and someone really loving shell scipts and virtualization should tackle it
<fjahr>
jonasschnelli: thank you also from me for all the things already mentioned!
<laanwj>
#topic Getting rid of the prefer-port-8333 policy (sipa)
<sipa>
just a very short topic
<laanwj>
[#23306 proposes (and is a first step towards) getting rid of the prefer-port-8333 policy on the network]
<sipa>
it's all in the PR, i just wanted to make sure people saw
rex4539 has quit []
<laanwj>
will check it out!
<sipa>
as it's a potentially far-reaching policy change (the PR doesn't actually change the policy, but it's a preparation for it)
<jonatack>
+1
<sipa>
unless someone has questions/comments, that's it for my topic
<laanwj>
concept ack anyhow
<michaelfolkson>
I would guess there are some lazy habits where 8333 is etched into people's minds.
<michaelfolkson>
But not a strong rationale for not changing that
<laanwj>
i'll skip fanquake's topic as i think he meant 0.20.2, and that already happened Oct 18
<fanquake>
yes I’ve made that tag already
<fanquake>
we’ve had a few signed builders for 0.20.2 as well
<laanwj>
i also built it but not uploaded sigs yet, will do
<laanwj>
#topic Encouraging people to propose meeting topics for the weekly IRC Core dev meetings (michaelfolkson)
<fanquake>
jonasschnelli: ! Hope you are doing ok, and maybe back to Core dev some day.
<josibake>
are there any existing guidelines for what a "good" topic is?
<michaelfolkson>
Ok very short one. Just to encourage people to propose meeting topics for this meeting. The number of topics have been pretty sparse in recent weeks/months and it is much better to have too many than next to none
<michaelfolkson>
We can always push non-urgent to future weeks
<michaelfolkson>
josibake: No but that sounds like a good idea
<michaelfolkson>
It can be a PR though or a mini Core project though (imo)
<michaelfolkson>
There is the Core PR review club too of course
<laanwj>
josibake: dunno, you know you can always just ask in the channel
<michaelfolkson>
And we are doing an online livestreamed session on AssumeUTXO
<laanwj>
if it's relevant to current development in the repository and there's people willing to talk about it it's a good topic, that's pretty wide
<sipa>
i like having short meetings tbh
<michaelfolkson>
You can leave early though sipa :)
<sipa>
i mean: we don't need to fill meetings because meetings should be filled
Kaizen_Kintsugi has quit [Remote host closed the connection]
<michaelfolkson>
The P2P ones have effectively been cancelled
<sipa>
sure, if there is a topic, let's discuss it
<josibake>
laanwj: thanks
<ariard>
michaelfolkson: some people are attending multiple meetings, lightning, etc, short meetings are good :)
<michaelfolkson>
I guess but people can leave if they aren't interested in the topic
<laanwj>
i like short meetings but also, it's good if the time available is used in a productive way
<laanwj>
if it ends with "high priority for review" every time it's also a bit demotivating
<jamesob>
yeah, agree
<michaelfolkson>
Just a thought that there are avenues for getting more review on your PR if you are frustrated (which imo includes this meeting)
jarthur_ has joined #bitcoin-core-dev
<jamesob>
I'm going to go on a tirade about nits at some point, so I'll queue that up for a future meeting :)
<laanwj>
hehh
<michaelfolkson>
PR review nits?
<jamesob>
yes
<michaelfolkson>
The TL;DR?
<laanwj>
i mean some things you acn also bring up outside meeting, not everything needs to be in the meeting
jarthur has quit [Ping timeout: 264 seconds]
Kaizen_Kintsugi has joined #bitcoin-core-dev
<laanwj>
just depends
<jamesob>
ugh I don't know. They can just be really demotivating and distracting, but I need to collect my thoughts and figure out if I have any actually-actionable things to say
<michaelfolkson>
Ok
<laanwj>
any cast this gets veeeery meta
<jamesob>
it was 40% a joke
<michaelfolkson>
Haha ok next topic (as we've got ariard here and he doesn't like meetings)
<michaelfolkson>
Let's cover the full RBF topic
<laanwj>
#topic Attempting to transition to full RBF over multiple major versions (michaelfolkson)
<laanwj>
jamesob: 40% joke is the best approach to things
<luke-jr>
how about just stop trying to dictate to users what policies they can or can't use? <.<
<jonatack>
jamesob: (i see nits ideally as suggested lightly, and up to the author and that's, that really)
<michaelfolkson>
luke-jr: Core has to pick a default
<laanwj>
luke-jr: i understood that's the idea with full RBF, it drops a fair amount of policy restrictions
<ariard>
luke-jr: if you mean simplifying our policy, this proposal is going in that sense ? but ultimately we *do* have to pickup defaults and they're free of implications
<luke-jr>
michaelfolkson: not really; and right now, Core is forcing its "default" on users
<sipa>
my view is generally: come up with an actual workable and worked-out policy, and propose it - beyond that it seems like a ML discussion primarily
<laanwj>
you can't really get rid of policy entirely because we need it for anti-DoS etc
<sipa>
at a very high level, i'm concept ack - i think it's inevitable long term that the network will tend to more rational policies, and full RBF is a step towards that
<luke-jr>
Knots has configurable RBF, and I'm happy to re-open the Core PR if people are willing to accept/review it
<michaelfolkson>
sipa: It has been proposed by ariard. And I think he's right to attempt a roadmap for changing it
<sipa>
but it all depends on the details
<ariard>
michaelfolkson: do you have a link towards achow101 BerkeleyDB deprecation plan you were mentioning offline last week ?
<sipa>
michaelfolkson: i don't see a concrete policy, but i may have missed it
<sipa>
"full RBF" isn't a policy, it's an aspiration :)
<michaelfolkson>
There still has to be a default even with configurable option
<luke-jr>
ariard: ^
<luke-jr>
ariard: the code already exists, just a matter of people accepting/reviewing it for Core
<sipa>
i have some thoughts, but i'll respond on the ML
<ariard>
luke-jr: for now, i'll only to propose a config knob with full-rbf=false, i don't think you can configure that for now ?
<michaelfolkson>
There will be some business opposition but if we think long term this is the right thing to do we should attempt to change it over multiple versions giving people plenty of advance warning
<luke-jr>
ariard: yes, that's one of the 3 configurations in that branch/Knots
<laanwj>
having a config know for it in core at all is a start
<laanwj>
changing the default is much further away
<josibake>
laanwj:+1 just adding it as a config option shouldn't be controversial, right?
<ariard>
yes i'm still worried about the Dos against multi-party funding transactions but we have years ahead before i think it starts to be a real issue
<luke-jr>
josibake: it was last time I tried
<laanwj>
josibake: not to me at least, given how many people want this
<michaelfolkson>
Right, there will be some opposition. I have tried speaking to some Lightning businesses to understand their use of Lightning zero conf channels
<laanwj>
luke-jr: when was that? 2015?
<luke-jr>
laanwj: probably
<ariard>
luke-jr: ah okay for the branch, gonna look
<michaelfolkson>
Maybe last words but I think that was wrapped up in the block size drama. I am hoping a long(ish) term plan this time around will be less controversial
<michaelfolkson>
But we'll see. I think we should attempt this long term (over multiple major versions) transition to full RBF
<laanwj>
luke-jr: it does seem attitudes changed a bit since then
<michaelfolkson>
It may fail
<luke-jr>
ariard: just pushed the latest rebase (Oct 8th)
<luke-jr>
laanwj: great
<ariard>
michaelfolkson: though i've been reached out privately by a exchange operator disagreeing with full-rbf after posting on the ML
<cfields>
ariard: suggest they respond publicly :)
<sipa>
+1
<michaelfolkson>
Right, I think the discussion should be out in the open
<michaelfolkson>
If people really don't want it then the attempt may fail
<ariard>
cfields: yeah will ping them back once PR is open!
<michaelfolkson>
Or at least summarize their arguments ariard
<cfields>
ariard: great, thanks!
<michaelfolkson>
We don't need to know who it is if they want to stay anonymous
<luke-jr>
michaelfolkson: eh? it's not a consensus change
<luke-jr>
anyone can run full RBF today if they want to. or block RBF entirely if they prefer that.
<michaelfolkson>
luke-jr: Right but we should still consult? If people really don't want it?
<michaelfolkson>
At least collect those arguments
<luke-jr>
michaelfolkson: if people don't want it, they can just not enable it..
<laanwj>
right, but it's good to give people time to adapt to it at least before changing the default
<sipa>
luke-jr: i don't think that's a useful response
<sipa>
luke-jr: in their mind - for good or bad reasons - the problem is others enabling it
<sipa>
(presumably)
<luke-jr>
sipa: but they have no say over what other people do
<michaelfolkson>
I think generally if we expect opposition/controversy it is good to reach out
<michaelfolkson>
Even if it isn't consensus change
<laanwj>
no, they don't, but a default change would not be something done lightly
<sipa>
luke-jr: which is much easier to address publicly :)
<luke-jr>
laanwj: perhaps, but that's down the road past just an option ;)
<laanwj>
clearly for your own nodes you can run with whatever policy you want
<michaelfolkson>
Also whether we like it or not we are going to have to consider policy more seriously because of Lightning and higher levels
<laanwj>
and i definitely expect miners to start acting rationally in this regard
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<luke-jr>
michaelfolkson: anything that depends on policy for security, is broken by design
<sipa>
laanwj: yeah, it may take a few halvings, though
<laanwj>
i mean, it's not something you can just post a rant against on the mailing list then ignore
<michaelfolkson>
luke-jr: It isn't optimal sure. But I still think having Lightning ecosystem is better than ignoring it
<luke-jr>
michaelfolkson: Lightning shouldn't depend on policy
<michaelfolkson>
But anyway, let's move it to GitHub issue an mailing list
<michaelfolkson>
luke-jr: But it does!
<luke-jr>
last I heard, quite a few nodes and miners already use full RBF for years
<luke-jr>
michaelfolkson: they should fix it then, regardless of this discussion
<michaelfolkson>
It is suboptimal but the best we can do currently for Lightning design
<sipa>
i feel like this is a bit like the Linux mantra "don't break userspace"; userspace may be depending on un-guaranteed behavior for dumb/bad reasons, but that doesn't mean you can just go and break it
<ariard>
luke-jr: can you make the expectation that the most economically-rational policy is going to be run in majority over the p2p network ?
<luke-jr>
ariard: no
<laanwj>
i'd prefer to leave it at adding an option for now as well
<laanwj>
1 minute to go
<michaelfolkson>
Ok we should wrap up. Want to respect people's time
<michaelfolkson>
Thanks
<laanwj>
michaelfolkson: please leave time management to me
<michaelfolkson>
Sorry :)
<laanwj>
but you're right anyhow
<laanwj>
#endmeeting
Kaizen_Kintsugi has quit [Ping timeout: 260 seconds]
<jonasschnelli>
(and yes, happy to shared the tweaked code of the meeting irc bot)
<luke-jr>
ariard: anyone can start mining (in theory), so to expect *some* miners to have such a policy may be reasonable
<laanwj>
jonasschnelli: you run the meetings irc bot?
<jonasschnelli>
fanquake: Thanks. All good here. No drama or so. Just time to move on.
<jonasschnelli>
laanwj: yes. But looks like its down
<ariard>
(btw if you have coredev travel reimbursements applications to submit, please send then on my mail antoine.riard@gmail.com)
<bitcoin-git>
bitcoin/master fa6c62f MarcoFalke: test: Replace log with assert_equal in wallet_abandonconflict
<bitcoin-git>
bitcoin/master 12ff899 MarcoFalke: Merge bitcoin/bitcoin#23331: test: Replace log with assert_equal in wallet...
core-meetingbot has joined #bitcoin-core-dev
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #23331: test: Replace log with assert_equal in wallet_abandonconflict (master...2110-testAssert) https://github.com/bitcoin/bitcoin/pull/23331
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<cfields>
sipa: sorry if I implied that minisketch was desperate for review btw. clearly just a case of me being out of the loop for a while.
<jonasschnelli>
laanwj: it's a modified version of supybot.plugins.MeetBot from debian I think
<ariard>
luke-jr: i got a point that users might be willingly to adopt a more privacy-preserving policy, and it might at odd with an economically-rational one (though hopefully not!)
<ariard>
it has been discussed multiple times on the Lightning side to have LN nodes connecting directly to few miners, but i'm still meeeeh on the censorship-resistance of that
<laanwj>
cfields: it can always use more review :)
<luke-jr>
ariard: btw, should I open the fullrbf branch as a PR?
<laanwj>
jonasschnelli: thanks; i know very little about existing IRC bot projects tbh, but it was kind of useful, and we should probably keep it going
<fanquake>
Also, in regard to the macOS signing keys, fwiw I also currently have access to the Apple developer account that is associated with those keys
<luke-jr>
(bleh, looks like it needs another rebase)
<jonasschnelli>
fanquake: great. I think you should keep that. You can't download the private key from there (but create a new one AFAIK).
<jonasschnelli>
happy to hand over the key to either you or achow101 (depending on how you all think how we should do it)
<achow101>
it's a shared developer account?
<jonasschnelli>
it can have multiple accounts/roles
<glozow>
oh no i missed the meeting 😅 thanks ariard laanwj, #22674 is my top priority as well
<gribble>
https://github.com/bitcoin/bitcoin/issues/22674 | validation: mempool validation and submission for packages of 1 child + parents by glozow · Pull Request #22674 · bitcoin/bitcoin · GitHub
<sipa>
cfields: no worries
<achow101>
it'd definitely be easier if we had just one code signer
<ariard>
luke-jr: i have time for doing it in the coming weeks, wanna observed first the deprecation plan from #20160 and explain at best the impact of opt-in RBF on upper layers