abubakarsadiq_ has quit [Quit: Connection closed for inactivity]
realies has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
kevkevin has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 268 seconds]
monlovesmango has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
monlovesmango has joined #bitcoin-core-dev
monlovesmango has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
monlovesmango has joined #bitcoin-core-dev
TheRec has quit [Read error: Connection reset by peer]
brunoerg has quit [Ping timeout: 246 seconds]
TheRec has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
TheRec has quit [Ping timeout: 260 seconds]
mudsip has quit []
TheRec has joined #bitcoin-core-dev
TheRec has quit [Changing host]
TheRec has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
bitdex has joined #bitcoin-core-dev
monlovesmango has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 245 seconds]
dermoth has quit [Ping timeout: 260 seconds]
dermoth has joined #bitcoin-core-dev
szkl has quit [Quit: Connection closed for inactivity]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
szkl has joined #bitcoin-core-dev
mxz has quit [Quit: cya]
mxz has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
<bitcoin-git>
[gui] pablomartin4btc opened pull request #780: Fix: Disable both "Mask Values" and "Transaction View" if no wallet is selected (master...gui-disable-mask-values-and-tx-view-if-no-wallet-selected) https://github.com/bitcoin-core/gui/pull/780
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
flooded has joined #bitcoin-core-dev
<instagibbs>
I think glozow is out today, and I'll likely be late for the meeting so I'll just give a quick update now:
<instagibbs>
"V3": #28948 is open and is ready for conceptual/approach feedback. Reminder that this is a stepping stone to enabling pin-resistant transactions
<instagibbs>
Package RBF: I opened #28984 to support 2-transaction package rbf without dependency on "v3". #25038 had them coupled together but there's no inherent reason why. By not coupling these features we can also give slight security boost to already-deployed smart contracts, even though they won't be pin-resistant without opting into "v3". I'd appreciate
<instagibbs>
quick feedback on which version of the PR we want to go forward with, and all kinds of review.
<instagibbs>
A little look ahead: #29001 is the final piece of mempool policy to allow pin-resistant transactions
<josie>
regarding the outpoints, i think we have something that works (hashing one outpoint, and some hardening), but would be nice to have a few eyes on it before i go and start updating the PRs
<josie>
ill also be reviewing #25273 this week
<gribble>
https://github.com/bitcoin/bitcoin/issues/25273 | wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction by achow101 · Pull Request #25273 · bitcoin/bitcoin · GitHub
<achow101>
please do
<josie>
(looks like it has a silent merge conflict tho)
guest-127 has joined #bitcoin-core-dev
<achow101>
hmm, thought I fixed that. will take a look today
<ryanofsky>
Main next multiprocess PR for review is #28921. There is also serialization PR #28929 which simplifies things for multiprocess code, but is not essential. There is also now a design doc being added in #28978.
<hebasto>
moreover, the recently discovered issue with Boost ASIO forces us to disable the external signer support for Windows, both cross and native builds -- #28967
<hebasto>
https://github.com/arun11299/cpp-subprocess was suggested as a potential alternative, which basically is a single header-only C++11 implementation of the Python's `subprocess.Popen` interface
<hebasto>
then theStack developed a branch that replaces Boost.Process with cpp-subprocess; however, some Windows-related issues remained
<hebasto>
I fixed all Windows-related issues and submitted a full solution in #28981. Some of my patches have been accepted upstream already; others are in progress.
<hebasto>
the question is: if we agree to use cpp-subprocess, what is the best way to integrate this header into our code base?
<hebasto>
during discussion in the pr, a few options were suggested: 1 - subtree (sipa); 2 - add to the repo directly and prune out the unused code (fanquake); 3 - our fork subtree (hebasto); 4 - external dependency (luke-jr)
<achow101>
is it actively maintained?
<hebasto>
it is
<fanquake>
depends on your definition of maintained
<sipa>
it looks maintained, but not really developed anymore
<fanquake>
the author doesn't actually review things, just insta merges etc
<sipa>
how much of the file do we need?
<sipa>
as in, for option two, how much would we keep?
<hebasto>
maybe ~60..70%
<fanquake>
I just want to avoid another boost process scenario, where upstream wasn't maintained well, and no one from our side actually reviewed any of it, or checked to see how it worked/what it was doing under the hood
<fanquake>
Obviously having a static header in our repo is an improvement, similar to nanobench/tinyformat
<hebasto>
in that case, we can adjust code for C++17/20
<fanquake>
If it's unlikely we'll be pulling many/any updates, that seems better than adding the burnden of a subtree, and we can still prune unused code
<achow101>
I'd be slightly concerned with copyright if we just included it in the repo directly, especially if people come along later and decide to refactor/split it
<sipa>
does it *need* any changes right now?
<fanquake>
Isn't it MIT licenesed?
<josie>
yeah its MIT
<fanquake>
What is the copyright concern
<hebasto>
it needs Windows-specific fixes
<achow101>
fanquake: the copyright header still needs to follow around any bits of code that we take from the project
<sipa>
hebasto: but it looks like you've had some success already getting fixes upstreamed
<fanquake>
Sure, we wouldn't delete that
<hebasto>
sipa: correct, a couple more needed
<fanquake>
Has anyone actually tested it on non-windows yet?
<fanquake>
Note that upstream also has no macOS CI, but I guess the assumption is no real platform specific code?
<Sjors[m]>
Not yet, will do soon(tm) on both Linux and macOS.
<hebasto>
I tested with ledger on windows only for now
<fanquake>
Ok, lets actually check it works on linux on mac first then
<sipa>
agreed
<hebasto>
okay
<Sjors[m]>
Make sure to test QT, not just the RPC.
<hebasto>
sure :)
<Sjors[m]>
The latter is pretty well tested in the CI
<achow101>
a potential alternative is to just completely rearchitect HWI so that it's a persistent daemon with a RPC interface
<achow101>
but that sounds like a lot of work
<Sjors[m]>
I'd also rather not have it run non stop, and/or manually start it as a seperate thing
<fanquake>
HWI is still also usable without anything subprocess in Core right? Because users could just make the same calls that Core is doing, but themselves?
<dergoegge>
or just have a native c++ (or maybe rust 🦀) lib to interface with the hw wallets?
<dergoegge>
but that's just a rust wrapper around hwi.py?
<Sjors[m]>
I think that's just a wrapper?
<achow101>
dergoegge: we don't/didn't want any of the hww stuff compiled in
<achow101>
that would include the usb stack and a bunch of vendor specific things
<josie>
ah gross. i think last time i talked with someone about it, i was under the impression they were going to move it away from being a wrapper
<josie>
but looks like that hasn't happened
<dergoegge>
we can also just delete external signer
<dergoegge>
🏃♂️
<fanquake>
Might have to get someone to add a GUI to that Rust thing
<fanquake>
Anyways, be good for some people to at least test the subprocess thing works / is a drop in, before we worry further about how to integrate it
<achow101>
indeed
<achow101>
#topic dergoegge merge access in qa-assets (fanquake)
<fanquake>
quick one for any thoughts
<fanquake>
niklas and marco are are doing 90% of the contributing into qa-assets
<fanquake>
given no one else reviews or merges there, doesn't make sense for me to always be a bottleneck
<achow101>
ack
<fanquake>
so I think it makes sense for niklas to be able to push in new inputs
<instagibbs>
ack
<josie>
ACK
<fjahr>
ack
<fanquake>
good stuff
<hebasto>
ack
<sipa>
ack
<achow101>
maflcko too?
hernanmarino has quit [Ping timeout: 255 seconds]
<darosior>
ack
hernanmarino has joined #bitcoin-core-dev
<fanquake>
I don't think he wants to merge things. You can ask
<fanquake>
That's all for that topic thought, we can sort out the admin side shortly
<fanquake>
*though
<achow101>
#topic shortly release cycle for 27.0 (fanquake)
AaronvanW has joined #bitcoin-core-dev
<fanquake>
*shorten whoops
<fanquake>
Given that the past few releases have slipped a little, and 26.0 nearly happened during Christmas/New Years
<fanquake>
I think it makes sense to have a shorter 27.0 cycle, and release in March/April. 28.0 in September/October
<fanquake>
So that we move back away from holiday type times, and then keep that cadence going forward
<fanquake>
Releasing around holiday times is bad because people are away etc
<fanquake>
i.e If we have to do a 26.(0).1 soonish, it's not going to be an ideal time
<achow101>
we should just do every 4 months to account for the slip
<fanquake>
how does that account for slip
<achow101>
+4 months from time of previous release
<sipa>
releases are primarily extra work for maintainers; if you're ok with doing more frequent releases, there is little reason not to i think
<fanquake>
So 3 major releases a year?
<sipa>
fanquake: i think what achow101 is suggesting that the effective time between releases becomes (4 months + whatever time the previous one slipped)
<fanquake>
Right, but I'm trying to remove variability
<fanquake>
Othewise you just end up with the same problem again
<sipa>
fanquake: agree
<stickies-v>
strongly in favour of picking the 2 month in the year that we think work best, and being okay with certain releases being a bit more/less spaced apart
<fanquake>
Pinning to ~April and ~Oct for example, means you shouldn't have this issue
<sipa>
i like that idea
<josie>
fanquake, stickies-v: +1
<stickies-v>
it's better for users to have a more predictable release cycle, and it doesn't make things unnecessarily difficult for us. no downsides imo?
<achow101>
is that target release in april, or branch in april?
<fjahr>
yeah, well the two months in the year where the two following months are not too bad ;)
<_aj_>
target the freeze dates, not the release dates?
<fanquake>
I think we are also somewhat on track for an April release anyways, as we've already started merging stuff for 27.0 etc
<stickies-v>
_aj_: +1
<sipa>
so freeze dates in february/august?
<josie>
freeze in feb seems pretty early, why not freeze in march?
<stickies-v>
I'd be conservative and assume 2 months between freeze and release. If we want to avoid releasing in December, I think that means freeze in march and september?
<_aj_>
branch off was last october
<fanquake>
So yea, freeze the regular amount of time before april and october
<sipa>
right, so there were basically 2 months between feature freeze and final release
<sipa>
25.0 was slightly shorter but still almost 8 weeks
<_aj_>
(late october, not last october)
<achow101>
I think we've previously targeted 6 weeks betweek feature freeze and release
<achow101>
but that seems to never pan out, so 8 weeks is fine with me
<sipa>
24.0 had a 7 week interval between feature freeze and final release
<fanquake>
and the breakdown is normally 1 month of freeze + ~1 month of rc(s)?
<achow101>
normall 2 weeks of freeze
<fanquake>
So freeze mid feb, start rc march, release april
<fanquake>
So 2 1/2 months were of merging for 27.0 from now
<fanquake>
Get those features in
<josie>
haha 2 1/2 months, with holidays in between.. I think its going to be a very small release
<achow101>
Any other topics to discuss?
<fanquake>
Maybe we can fix more bugs than we introduce this time then
<_aj_>
woah
<josie>
fanquake: a christmas miracle!
<stickies-v>
we could do a transition period where we do 27 one month later than (the new) usual before completely switching to the new schedule?
<fanquake>
Can we not
<sipa>
or we can decide that when the time comes
<maflcko>
hi
Guest20 has joined #bitcoin-core-dev
<achow101>
stickies-v: what we actually normally do is previous schedule +6 months, which is around april anyways
<josie>
stickies-v: I think what's proposed is fine, more just point out we have a pretty big priority list for 27.0 that likely wont happen
<achow101>
(the original schedule, not what actually happened)
<stickies-v>
okay
<josie>
but i dont think that should reflect badly on the priority projects experiment
<sipa>
priority list is a set of things we are committed to making progress on - we don't need to finish them
<josie>
sipa: agree!
Guest20 has quit [Client Quit]
<achow101>
#endmeeting
guest-127 has quit [Quit: Client closed]
<Murch[m]>
ACK on features freezes being ~Feb 15th and ~Aug 16th going forward, sounds great
cacrowley has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko opened pull request #29025: doc: Add link to needs-release-notes label (master...2312-doc-link-rel-notes-) https://github.com/bitcoin/bitcoin/pull/29025
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
preimage has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Quit: Leaving...]
Guyver2 has joined #bitcoin-core-dev
flooded has joined #bitcoin-core-dev
_flood has quit [Ping timeout: 260 seconds]
monlovesmango has joined #bitcoin-core-dev
monlovesmango has quit [Ping timeout: 246 seconds]
Talkless has quit [Quit: Konversation terminated!]
bugs_ has joined #bitcoin-core-dev
not_reserved has quit [Quit: Client closed]
micha_ has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<instagibbs>
maflcko circling back to this after a while, if I want fuzz coverage report against a single target is there a good way? Do I need to generate a corpus, put it in qa-assets directory, then run "make cov_fuzz"
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
Guest92 has joined #bitcoin-core-dev
Guest92 has quit [Client Quit]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
___nick___ has quit [Ping timeout: 256 seconds]
<dergoegge>
DIR_FUZZ_SEED_CORPUS="./qa-assets/fuzz_seed_corpus <target name>" make cov_fuzz
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
sipsorcery has joined #bitcoin-core-dev
monlovesmango has quit [Remote host closed the connection]
monlovesmango has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.1.1]
bugs_ has quit [Quit: Leaving]
flooded has joined #bitcoin-core-dev
test_ has quit [Ping timeout: 260 seconds]
pablomartin has quit [Ping timeout: 245 seconds]
micha_ has quit [Quit: Connection closed for inactivity]
bitdex has joined #bitcoin-core-dev
monlovesmango has quit [Remote host closed the connection]