< kallewoof>
If anyone has topics they wanna talk about, we could gather those and bring them up after the next PR review, assuming people are up for doing more. I'm not actually sure how #bitcoin-core-dev maintains meeting topic proposals tho.
< aj>
kallewoof: so i saw signet on hi-pri and thought it'd be fun to discuss, but i see you posted about bip322/msg signing yesterday, so could do that instead?
< kallewoof>
aj: to be honest, I'd love to focus on signet. the msg signing stuff is more a "is this really bad, and people just don't want to hurt my feelings" kind of stage
< aj>
kallewoof: for me, msg signing is "this is cool, but none of the ideas seem quite like the right thing, so i dunno"
< kallewoof>
yeah, that seems to be most people's opinion. i'm gonna let that ML post sit and focus on signet. after signet, i'll probably go and ultra-simplify the proposal to single-proof no-extensibility case. at least that gives us a starting point..
< kallewoof>
aj: that aside, yes, i'd love to discuss signet. I'd love to do a PR review ON signet, but either I wake up in the middle of the night to do both ends, or I find someone on EU/US-land willing to host the main one...
< aj>
kallewoof: if you write up notes for it, i think it'd be pretty easy for someone else to run the actual meeting
< kallewoof>
aj: Yeah and it oges in the wrong order too.. If I want to see the *latest* hidden comments I have to click on it untli the end...
< aj>
kallewoof: might be complicated to do in a single meeting though? don't know
< aj>
kallewoof: so, was wondering where you were at with the common-genesis, diverge at block #1 idea? that's where the PR comments seem to trail off?
< kallewoof>
aj: everyone seems to like the static genesis block idea, except for one or two people, who thinks it will make testing multi-chain stuff harder. I honestly just wanted to get *something* merged, even if it is patched later, so I was hesitant to change anything but maybe I should go ahead and do that.
< kallewoof>
I think multi chain testing can be done by simply changing the genesis hash for the other chain(s) manually since you'llbe doing other stuff anyway.
< kallewoof>
right. so you agree with the static hash idea?
< aj>
well, common genesis means you can grind it manually which seems like a simplification?
< kallewoof>
the one icky thing is if a light client accidentally connects to a different signet with longer chain. since they won't validate the block sig, they will (I think) wipe out their whole chain and replace with the other one. but it looks increasingly like we'll msotly have a single signet running for the most time, so probably not a big deal
< kallewoof>
aj: yeah. the signet genesisnonce goes away which is great.
< aj>
kallewoof: well pchMessageStart = sha256d(sn_chal) fixes the accidentally one, and light clients that don't check signet sigs and aren't just connected to a trusted node are trivially attackable no matter what, so that seems fine?
< kallewoof>
Yeah, makes sense
< aj>
oh, what's with enforcescript vs blockscript for reorg mode?
< kallewoof>
basically, you can have the main signet require a 2-of-2 and then you can have a "fake" signet requiring a 1-of-2 where the keys are the same.. if you accept the 1-of-2 case (enforce) you can get reorgs every X blocks, whereas the 2-of-2 chain will never (or rarely) reorg
< aj>
so you'd replace 2 a b 2 checkmultisig with... "depth dup 1 GT VERIFY a b 2 checkmultisig" ?
< kallewoof>
actually hm... i think it would have to do something tricky to allow both, yeah. i hadn't thought about that. I think BlueMatt and/or gmax were talking about this idea on the mailing list before.
< kallewoof>
Will have to find that again
< aj>
oh, DUP 2 B DUP 2 CHECKMULTISIG would probably do
< aj>
what? no it wouldn't grr
< aj>
maybe "verificationprogress" should be a mainnet only thing?
< kallewoof>
2-of-2 case: <null> <sa> <sb> 2 <ka> <kb> 2 cms; 1-or-2-of-2 case: depth 8 equal if <2 of 2> else <1 of 2> endif... i think?
< kallewoof>
that makes sense to me (verificationprogress mainnet only), yeah
< aj>
depth 3 equal -- you've only got the 2 sigs and the null on the stack at that point
< kallewoof>
oh, right
< aj>
so "depth 2 equal if 2 else 1 endif A B 2 cms"
< aj>
3 equal
< aj>
grr
< kallewoof>
looks good yeah!
< aj>
"depth 2 equal 1add A B 2 cms" even :)
< aj>
oh ffs, depth 3 equal
< kallewoof>
lol
< aj>
so light clients will see all the reorgs this way i guess
< aj>
if they happen to connect to a reorg aware node anyway
< kallewoof>
right. i guess the big problem is, how do you prevent nodes from banning each other when they use different enforcements..
< aj>
oh, eww, good point
< aj>
i don't think that approach works with taproot either, you could change the sPK, but without ANYPREVOUT every sig commits to the sPK anyway
< aj>
reserve one of the bip320 miner-roll versionbits to signal "this block will get reorged out" instead maybe?
< bitcoin-git>
[bitcoin] kallewoof opened pull request #18265: build: add data.h dependency to raw files (master...2003-makefile-bench-data) https://github.com/bitcoin/bitcoin/pull/18265
< kallewoof>
aj: I think it would require some logic in the block validation where it silently rejects without punishing when the solution contains the same keys somehow.
< kallewoof>
Perhaps I shoudl remove the enforcescript flag until this all has been sorted out. It's not really needed for signet v1 I think.
< aj>
kallewoof: could set the error as BLOCK_RECENT_CONSENSUS_CHANGE in theory
< kallewoof>
ohh... true.
< kallewoof>
with schnorr, it would probably be "if sigs = 0, block is REALLY invalid and peer should be punished; if 0 < sigs < threshold, do BLOCK_RECENT_CONSENSUS_CHANGE; if sigs >= threshold, accept.
< kallewoof>
I mean, wit script v1
< aj>
haven't looked at the contrib/signet/ bits, but the other commits all look respectable fwiw
< aj>
hmm, i guess with schnorr/tapscript you'd need to work out what you're signing, since there's not really a transaction to apply the specced signature digest algo to, and then we're back to the signed-message debate
< kallewoof>
i haven't really given schnorr/tap* a lot of thought wrt signet. other than "signet should help with testing taproot"
< kallewoof>
aj: thanks for reviewing btw. I am probably going to strip that down to MVP and split into multiple PR's. I think I was a bit optimistic when I hoped it could be reviewed in its current state..
< kallewoof>
406 lines. Still a lot, but better than 1.2k...
< kallewoof>
Managed to get it down to +358 -26. Hopefully this is reviewable.
< mantoshelis>
Hello, can someone share testnet bitcoins with me? My address is: my5rQeSvwpjF4ssSBrD5PcGx3hRakXCHgF
< provoostenator>
mantoshelis: done
< mantoshelis>
Thanks a lot
< mantoshelis>
If there is a possibility to get more tBTC please share with me up to 100. It is for testing purposes, especially load testing.
< provoostenator>
Why not use regtest for load testing?
< provoostenator>
Or Signet
< provoostenator>
(regtest is great if you test inside your own network, (a custom) signet is more suitable if you need to interact with others.
< mantoshelis>
We created a custom fork of bitcoinj to support database based wallet so we need to test it with interraction with others on testnet.
< provoostenator>
mantoshelis: testnet is pretty terrible in general. It might be worth looking into adding Signet support to BitcoinJ. Should be pretty easy: https://en.bitcoin.it/wiki/Signet
< mantoshelis>
It's good idea but unfortunately we don't have enough time resources to implement this. As a result, we choose to perform tests on official Bitcoin testnet. :(
< goatpig>
hello
< goatpig>
is there an equivelant to sendrawtransactions to broadcast a batch of transactions through the RPC?
< jonatack>
kallewoof: could be a good PR for the review club, want to host?
< kallewoof>
jonatack: I would love to do that, but it's in the middle of the night for me. :o Would you be up for doing it?
< jonatack>
oh that's right. sure, why not.
< kallewoof>
nice! :) I'll see about making notes and such
< stevenroose>
Q about relaying: If you've broadcasted a tx that is not relayed by standard nodes. But a few of your peers do accept/relay it (even though all their peers won't accept it so their "relay" is futile). So this means that that tx is in the mempool of those few nodes. Now lets say after some time, more nodes have been configured to accept this kind of tx; how can I get my earlier tx to
< stevenroose>
broadcast again without personally connecting to new nodes?
< stevenroose>
I.e. can I get those few peers that know about the tx to re-relay it somehow?
< stevenroose>
IIRC nodes don't do any effort to make txs in their mempool discoverable by peers. Like mempool reconciliation, that doesn't happen (yet?), right?
< goatpig>
stevenroose: my experience with the p2p interface is that you'll get the inv for a tx only once, and a node you connected to will not try to inv its mempool to you, so basically you are the only who'd know to rebroadcast your tx to other nodes
< goatpig>
other nodes on the network will not do this for you
< stevenroose>
Yeah but if you rebroadcast it, your peers that already accepted the tx previous time won't relay it again, right?
< goatpig>
no, they won't even send you the getdata packet to get the tx body
< stevenroose>
Even though at this time, *their* peers might accept it while they did not the time before that.
< stevenroose>
Kay, yeah that's what I thought.
< goatpig>
i dont think there's any mechanism for a node to keep track of its peers mempool filters either
< stevenroose>
This is quite an annoring aspect of trying to make certain tx standard again or f.e. lowering the minrelayfee. It only makes sense if a bunch of nodes do it together. If say 20% of the network accept lower-fee txs, there's a good chance your tx won't reach those 20% ever, even if after some time ,that 20% increases
< goatpig>
if you expect your tx to be below the network's relay floor, you're best bet is to connect to known miners
< stevenroose>
goatpig: no of course there is not, and I do agree it doesn't make sense to even assume their mempool filter might have changed in any way, so it's correct for them to not rebroadcast.
< stevenroose>
goatpig: yeah true
< goatpig>
you can setup strategies to know if your tx has propagated if you're willing to run several nodes
< stevenroose>
goatpig: hmm, I just notice that peers actually do communicate minfeefilters: "minfeefilter": 1e-06. But I'm sure there's no code that detects changes in that field.
< stevenroose>
Anyway, thanks :) Got my suspicion confirmed.
< goatpig>
that's to filter what they ought to inv to the peer, i doubt there's a feedback loop to rebroadcast existing mempool entries
< bitcoin-git>
[bitcoin] dangershony closed pull request #18223: Add new filter type v0 for segwit only Scripts to blockfilterindex (master...nutrino-p2wpkh-filters) https://github.com/bitcoin/bitcoin/pull/18223
< instagibbs>
stevenroose, amiti has a PR that would result in unstuckness in these kind of situations.
< instagibbs>
changing feefilter is done on restart for Core so would only be announced after re-connect
< instagibbs>
but by then I don't think you'll send the INV
< instagibbs>
10 days until feature freeze, get those reviews in folks
< amiti>
stevenroose: lmk if you have any thoughts / questions. I'm also interested in hearing about your angle / use cases. feel free to DM me :)
< amiti>
instagibbs: thanks for sharing
< harding>
stevenroose: what do you mean "I'm sure there's no code that detects changes in that [minfeefilter] field"? Are you familar with BIP133? The whole point of that is to allow peers to detect changes to a peer's minfeefilter and avoid relaying transactions to a peer that won't accept them.
< sipa>
the feefilter is also re-sent from time to time, i think
< sipa>
if the minfeerate of the receiver mempool changes
< stevenroose>
harding: well that's used generally right after the handshake, right?
< stevenroose>
What I mean was that a node that sees the minfee from a peer go from 10 to 20 won't relay all mempool txs it has between 10 and 20.
< stevenroose>
Unless I'm mistaken. But IIRC the minfee is more a static thing that just gets updated when the message is received and checked only on newly received txs.
< instagibbs>
sipa, ah of course it does change over the lifecycle of a node
< harding>
I think you mean 20 to 10, but yeah, AFAIK mempool txes that were not relayed previously won't be relayed just because the min rate dropped.
< instagibbs>
again, rebroadcast being reworked would fundamentally fix these edge cases
< harding>
stevenroose: my point was that feefilter is sent when a node changes its min, not just once during initial negotiation.
< harding>
(In theory; it's not like we've had a full mempool in two years to demonstrate that. :-)
< stevenroose>
harding: yeah I realize that. My statement "it doesn't detect changes" should have been "doesn't act retroactively on txs when it detects a change". Sorry
< bitcoin-git>
bitcoin/master b054c46 Ben Woosley: refactor: Convert ping time from double to int64_t
< bitcoin-git>
bitcoin/master e6fc63e Ben Woosley: refactor: Convert min ping time from double to int64_t
< bitcoin-git>
bitcoin/master 7a810b1 Ben Woosley: refactor: Convert ping wait time from double to int64_t
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18260: refactor: Fix implicit value conversion in formatPingTime (master...2020-03-ping-time) https://github.com/bitcoin/bitcoin/pull/18260
< jonasschnelli>
fanquake: I saw that your tx for the coredev.tech refund has been final-signed and broacasted: 31ee555fc1f92fc0ef834fb49b8087e3f33a44efa47b1fc5ff8a3c920a48b783
< wumpus>
PSA: 0.19.1 has been tagged, please gitian build if you haven't yet :)
< wumpus>
the 0.20.0 feature freeze is in roughly a week, see https://github.com/bitcoin/bitcoin/issues/17432, I think it makes sense to focus review on the feature PRs that have a chance to still make it in
< luke-jr>
wumpus: still a Concept NACK on any rust stuff..
< wumpus>
some of the things currently on high priority for review, for example
< ariard>
elichai2: IIRC lack of review by people understanding both Rust and code affected but people would like to raise the subject at coming physical meetup
< luke-jr>
elichai2: still not practical to securely bootstrap Rust, and it has ABI issues
< luke-jr>
#15600 seems to be of interest (we have a IMO-bogus CVE assigned about it), and very simple
< gribble>
https://github.com/bitcoin/bitcoin/issues/15600 | lockedpool: When possible, use madvise to avoid including sensitive information in core dumps by luke-jr · Pull Request #15600 · bitcoin/bitcoin · GitHub
< wumpus>
adding 0.20 milestone to those, hopefully they can get enough review in time
< luke-jr>
shoot, the first one needs rebasing again - will try to get to that later today
< wumpus>
I think that concludes the 0.20.0 / high priority for review topic
< wumpus>
#topic Coredev SF (moneyball)
< moneyball>
We need to discuss cancelling/postponing CoreDev SF. There are numerous reasons why. There is risk of getting stuck / quarantined and not be able to return home in a timely fashion. There is of course a real health risk and the logic to reduce the speed of spreading coronavirus. And there is the actions of many other organizations such as SF and California declaring states of emergencies, with Square,
< moneyball>
Coinbase, Stripe, Microsoft, Twitter all strongly encouraging working from home. Lastly, there is a high probability Bitcoin 2020 will be postponed.
< moneyball>
What do others think? Is there an argument to be made to continue holding it?
< moneyball>
Would there be interest in a remote/virtual CoreDev? IMO the biggest value of the CoreDev _is_ the f2f interactions, so we'd be losing out on that. However, it may be interesting to experiment with a 1 day virtual format and see how it goes. Maybe we could get Udi to do a VR thing(?!).
< kanzure>
when will we know about bitcoin2020?
< luke-jr>
is there free software VR stuff?
< BlueMatt>
it sounds like bitcoin2020 is going ahead
< BlueMatt>
unless the city of sf tells them they have to cancel, that is
< jeremyrubin>
i heard recent rumour it's cancelled
< luke-jr>
O.O
< BlueMatt>
they were pretty adament it was going ahead, like, three days ago, so dunno about rumors
< jeremyrubin>
Or that they at least advised some people to delay booking travel
< jeremyrubin>
As of today
< jeremyrubin>
I saw their message in the telegram a few days ago
< moneyball>
For the purpose of this discussion, let's say it is a very high probability that Bitcoin 2020 conference may be postponed.
< kanzure>
my only concern with coredev.tech would be if we have nearly ~everyone which is ungood for the usual reasons
< achow101>
I think some people already said they weren't going
< wumpus>
I don't think cancelling it is a bad idea, there's a large chance things will become more complicated in the next weeks, at least I'm not going to make the trip.
< luke-jr>
kanzure: I wasn't going to make it regardless
< jonasschnelli>
Agree with wumpus. I'm also not tthere.
< luke-jr>
but even still, a majority of devs getting badly ill could be a bad idea :p
< jonatack>
i was keen to go but atm it's a no-go... i'd be for holding off until we more clarity on the situation
< kanzure>
luke-jr: are you prepared to continue the project without us? (kidding)
< BlueMatt>
right, i guess the question is - things may be completely fine in two weeks, or ca will be telling everyone to not go outside. and we need to decide ~now for travel booking
< kanzure>
are these things even refundable... i already booked.
< * BlueMatt>
will be in sf either way
< luke-jr>
kanzure: Core's current policy doesn't make it possible for a one-man show :P
< wumpus>
could still organise something for the people in SF I guess
< BlueMatt>
kanzure: they are not (yet), though some airlines are starting to change, at least alaska/virgin is refunding anything you want to cancel iiuc
< luke-jr>
BlueMatt: considering the ridiculous lack of preventative measures by the US government, I expect things to only get worse in the coming weeks
< kanzure>
that's helpful
< BlueMatt>
I would not hold your breath if you're booked on the US Big Three airlines, though
< BlueMatt>
sounds like cancel/postpone/anyone whos in sf anyway can get a drink through their face masks. any nacks?
< jnewbery>
moneyball: I agree that the sensible thing to do is cancel if Bitcoin2020 is cancelled. I'm personally not interested in a remote/virtual coredev. I think it's very difficult to make it fair/convenient for people in different timezones. Much better to just reschedule a coredev in three-six months time.
< elichai2>
FWIW even though no one from Israel is coming the official Israel health minister guidelines from a few days ago are not to fly anywhere if it's not an emergency and if you came from a conference you must be in 14 days isolation,
< elichai2>
So I can expect other countries to start doing the same soon enough
< wumpus>
yes, I very much doubt this will be cleared up in two weeks
< achow101>
I think we'd have significantly reduced attendance so it probably isn't as useful
< jonasschnelli>
I doubt it is cleared up in months. :)
< luke-jr>
jonasschnelli: ☹ I'm reverse-quarantined until it's cleared up
< BlueMatt>
wumpus: especially not in the us. its spreading fast in some areas and no testing means no followup/monitoring. its just getting started here :/
< jeremyrubin>
kanzure: looking at what people submitted as topics to cover do you think there might be a useful remote agenda? Maybe we can just do daily morning/afternoon IRC meetings for a few days
< kanzure>
jeremyrubin: sure... maybe zoom for presentations, otherwise just hang out on irc?
< kanzure>
will pm you the link
< luke-jr>
Zoom appears to work in free software HTML5 browsers if you jump through some hoops FWIW
< wumpus>
trying to do something remote sounds good to me, would be good to coordinate more around the 0.20.0 feature freeze and release anyway--haven't ever used VR so can't comment on that
< kanzure>
OK, well, if we want a remote event then let's decide (doesn't have to be right now) whether we just want people to commit to being online, or if we want to schedule presentations / specific discussions on a conference video tool
< kanzure>
s/conference/meeting
< kanzure>
no whiteboards though... hm.
< luke-jr>
wumpus: maybe take #15987 out of 0.20 - just remembered I was waiting on #18192 to re-do it without the bloom stuff
< moneyball>
schmidty and i can send out a survey with some options. if the majority want to do virtual we can help organize. if just a few, i'd suggest self-organizing.
< kanzure>
anyway, it would be helpful if coredev.tech can send out an email once someone learns about bitcoin2020's decision
< luke-jr>
kanzure: screen sharing in Zoom as whiteboarD?
< wumpus>
luke-jr: ok
< moneyball>
yes i will send an email, and i will include a survey for people to indicate preferences for doing virtual or nothing at all
< achow101>
moneyball: ack
< jeremyrubin>
I'd do a virtual thing but I don't own any vr hardware -- do most devs these days?
< wumpus>
moneyball: thanks!
< bitcoin-git>
[bitcoin] luke-jr closed pull request #15987: Wallet, GUI: Warn when sending to already-used Bitcoin addresses (master...wallet_no_reuse) https://github.com/bitcoin/bitcoin/pull/15987
< luke-jr>
moneyball: nothing | video conf | VR
< kanzure>
luke-jr: or... blockchain?
< luke-jr>
jeremyrubin: I suspect you're not alone; video conf seems more logical IMO anyway
< moneyball>
i mean i joined udi's VR thing without a headset.
< moneyball>
i'm not advocating VR, just saying a headset isn't needed to participate
< achow101>
jeremyrubin: I don't, but valve index is supposed to be back in stock Monday. I'm planning on getting one of those
< luke-jr>
moneyball: it is if it's anything liek Sword Art Online 8)
< sipa>
hi!
< wumpus>
anything else to discuss today?
< sipa>
fwiw, i'll be in the sf area for coredev, so happy to meet up with whoever is there
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Mar 5 19:39:52 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< wumpus>
BlueMatt: sorry to see you closing the rust PRs due to lack of interest
< BlueMatt>
eh, happens. not everything makes it through
< BlueMatt>
and there was a definite lack of interest on those.
< luke-jr>
BlueMatt: there's been some interest in keeping the PPA using the bitcoin/bitcoin URI; can you add me to the org?
< BlueMatt>
luke-jr: if someone wants to replace the ppa with something that checks gitian signatures and downloads official binaries, as I've been saying needs to happen ~forever, then maybe its worth maintinaing again. but no one has ever shown a desire to do that, and the ppa has had many issues due to ubuntu insanity. its definitely a bad idea to use those build scripts for bitcoin nodes.
< luke-jr>
gitian binaries are not comparable
< luke-jr>
BlueMatt: I respect your decision to not maintain it; but are you really suggesting you should decide for everyone else?
< sipa>
if we as a project want to support PPAs again that's perhaps something to do discuss
< BlueMatt>
luke-jr: bitcoin core, as a project, maintains packaging scripts for fetching official release binaries and suggests users run those. if you disagree and want to start suggesting users run packages linked against os libs that have a long history of only half-working, its probably something that needs to be discussed as a project, not the two of us.
< BlueMatt>
I got tired of doing it, in large part, because they broke very regularly due to different dependencies than upstream supported. imo it only makes sense to ship the release binaries, but, again, that can be a broader discussion if you want to open it.
< luke-jr>
the ideal is users compiling their own; after that, PPAs are next best for Ubuntu; gitian binaries are nice to have as downloads, but in their current form not a good recommendation
< bitcoin-git>
bitcoin/master 470e2ac practicalswift: tests: Avoid hitting some known minor tinyformat issues when fuzzing strpr...
< bitcoin-git>
bitcoin/master 8914649 MarcoFalke: Merge #18109: tests: Avoid hitting some known minor tinyformat issues when...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18109: tests: Avoid hitting some known minor tinyformat issues when fuzzing strprintf(...) (master...fuzzers-strprintf-errata) https://github.com/bitcoin/bitcoin/pull/18109
< BlueMatt>
I'm not not doing it cause it took some small amount of effort, I'm not doing it cause things were failing test suite left and right and I felt like that was an unacceptable risk to user funds. I dont think you nor I have enough info by ourselves to decide otherwise. we can discuss it at the next meeting, if you want.
< luke-jr>
there's no reason it should require anything more than someone willing to do the work. and the tests _aren't_ failing (except on old platforms, which simply don't end up with packages).
< BlueMatt>
they were at the time i stopped. sounds like you want to discuss it at the next meeting, so lets do that.
< bitcoin-git>
bitcoin/master c2bd588 practicalswift: Add missing includes
< bitcoin-git>
bitcoin/master 3c82b92 practicalswift: tests: Add fuzzing harness for functions taking floating-point types as in...
< bitcoin-git>
bitcoin/master 8f6fb0a practicalswift: tests: Add serialization/deserialization fuzzing for integral types
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17996: tests: Add fuzzing harness for serialization/deserialization of floating-points and integrals (master...fuzzers-float) https://github.com/bitcoin/bitcoin/pull/17996
< bitcoin-git>
[bitcoin] practicalswift opened pull request #18270: util: Fail to parse space-only strings in ParseMoney(...) (instead of parsing as zero) (master...parsemoney-followup) https://github.com/bitcoin/bitcoin/pull/18270
< sipa>
MarcoFalke: it seems my bitcoind (commit a71c34742) died with boost::condition_variable::do_wait_until failed in pthread_cond_timedwait: Invalid argument in debug.log
< MarcoFalke>
Did you close your laptop and open it after some time passed?
< sipa>
after waking up from standby
< sipa>
for 14.5 hours
< sipa>
yeah
< MarcoFalke>
This is the same bug we are seeing in the mockscheduler test
< MarcoFalke>
(I think)
< sipa>
Right, that's why i'm mentioning it... we thought it only affected tests, no?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18234 | refactor: Replace boost::mutex,condition_var,chrono with std equivalents in scheduler by ajtowns · Pull Request #18234 · bitcoin/bitcoin · GitHub
< luke-jr>
does the boost<1.50 code work on newest boost versions?
< luke-jr>
(timed_wait)
< luke-jr>
maybe we should just remove the wait_until version for now?
< MarcoFalke>
I am pretty sure the 1.49 code is untested as well at this point. So instead of replacing one broken boost code with other broken boost code, we better remove boost
< luke-jr>
MarcoFalke: I'm not sure that's a good approach for backports
< MarcoFalke>
How far should this be backported? All currently supported versions of Bitcoin Core are affected.
< luke-jr>
MarcoFalke: as far back as we still support, afaik just 0.18?
< luke-jr>
and even 0.18 might not see another release
< MarcoFalke>
Given that the issue happens only on machines that are human-attended (hibernate, standby), I'd say it is likely that when they upgrade they upgrade to the latest version, which would be 0.20
< luke-jr>
looks like timed_wait is implemented using the same code as wait_until
< MarcoFalke>
ouch
< luke-jr>
humans do not necessarily want to upgrade to the latest branch
< luke-jr>
also, we have wait_until in other places with no <1.50 conditional.. do we actually still work wtih boost<1.50? O.o