< bitcoin-git>
bitcoin/master bd9d67b Kristaps Kaupe: Don't test against min relay fee information in mining_prioritisetransaction.py...
< bitcoin-git>
bitcoin/master 24106a8 MarcoFalke: Merge #13082: Tests: don't test against min relay fee information in mining_prioritisetransaction.py...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13082: Tests: don't test against min relay fee information in mining_prioritisetransaction.py (master...dont-hardcode-134) https://github.com/bitcoin/bitcoin/pull/13082
< * Randolf>
wonders if Nyan Cat might be a new type of unicorn...
< wumpus>
unicorns farmed: 1.5 octodecillion
< wumpus>
Randolf: a cat that is an unicorn too? is this heaven?
< sipa>
wth?
< wumpus>
github is working fine for me again, was another hiccup, though they do become awfully common
< wumpus>
moving the repository would be fairly easy but all the issue managment...
< wumpus>
can't see this working better with e.g. trac
< meshcollider>
We could move back to sourceforge ;)
< kallewoof>
Version control is overrated. Let's just email patches to the ML.
< kallewoof>
wumpus will sort it out
< wumpus>
kallewoof: I know you're sarcastic but that's how mesa/freedesktop still works, and it works ok, and they have much more patch traffic than us
< wumpus>
(also way more committers though...)
< kallewoof>
I'm amazed that it works ok. But I actually said it because I recall patches being tossed around on some mailing list some years ago.
< luke-jr>
I suspect they don't have the same review standards we do
< wumpus>
eh they do use git, it's not *instead* of source control, but I mean source patches are posted to the ML for review, testing etc
< wumpus>
luke-jr: that's true, the source code is also very compartimentalized, with reviewers for specific drivers and parts
< wumpus>
and if you post a patch you *need* to CC: the right people otherwise it will never get picked up
< wumpus>
no one reads everything on the entire ML
< wumpus>
anyhow no that's not a good fit for bitcoin core...
< wumpus>
meshcollider: I don't understand how they managed to make sourceforge such a mess, I don't hope that's the future for github
< meshcollider>
Ugh I know :(
< * fanquake>
plans on attending the dev meeting tonight
< wumpus>
fanquake: great!
< fanquake>
wumpus Sorry for lack of review over the past few days, been very busy. Should be back to normal tomorrow/saturday
< * sipa>
was briefly worried with "dev meeting tonight" thinking i missed something
< wumpus>
fanquake: no problem, we all need a break sometimes, and I think even with that you've been more active than most of us :-)
< jonasschnelli>
indeed
< wumpus>
ah yes the
< sipa>
it's past midnight here, and the meeting is at noon
< wumpus>
'tonight' part must confuse some people
< jonasschnelli>
fanquake: but wait: the meeting is 3am for you? right
< fanquake>
jonasschnelli correct, and it's 3:37pm here right now.
< * jonasschnelli>
will soon hand over the "attended-IRC-meeting-in-the-middle-of-the-night" medal to fanquake
< jonasschnelli>
I also did that in Indonesia... but mixed up the timezones.. woke up 3am and was one hour to early.
< sipa>
we should have meetings at every hour for which doubleSHA256(unix_timestamp) < 2^256 / 168
< jonasschnelli>
I guess you would be the only one who shows up on time sipa
< sipa>
that would at least be maximally inconvenient for everyone equally
< sipa>
jonasschnelli: lol, you don't know me
< fanquake>
heh
< wumpus>
randomized time-hopping meeting time allocation
< jonasschnelli>
the hopping-formula should also include a probability-shift depending on last meeting-attendees timezones and expected sleep-times.
< fanquake>
Entry and exit via wormhole only
< wumpus>
jonasschnelli: that wouldn't maximimize inconvenience for everyone anymore
< wumpus>
fanquake: yes if it wasn't for IRC it'd have to be in a random location in space, too...
< wumpus>
jonasschnelli: ideally there would be some factor (like a measurement or something that is unpredictable) that gets introduced last minute, so that it's not possible to plan ahead either
< fanquake>
wupus amount of time since any GitHub PR has 404'd for you
< fanquake>
*wumpus
< jonasschnelli>
Heh. fanquake: can you not just move to Europe or US, it seems to be less complicated. :)
< jonasschnelli>
Or do we have other non EU/US devs/timezones that want to participate at the meeting?
< wumpus>
fanquake: a very long time ago, these days it's usually timeouts
< wumpus>
fanquake: you're referring to disappearing issue issues?
< fanquake>
wumpus yes, and using that as your unpredictable factor ^
< fanquake>
jonasschnelli sure, if I can find somewhere to sleep in the US ;)
< wumpus>
fanquake: iterating the issue numbers then storing the pattern of 404 'memory holes', yes good idea
< wumpus>
github is sufficiently unpredictable at least...
< mryandao>
[O/T] is this lightning summit event in Adelaide a public event?
< mryandao>
#12240 has been squashed for months
< gribble>
https://github.com/bitcoin/bitcoin/issues/12240 | [rpc] Introduced a new `fees` structure that aggregates all sub-field fee types denominated in BTC by mryandao · Pull Request #12240 · bitcoin/bitcoin · GitHub
< aj>
mryandao: i imagine you have to be a lightning dev and register first
< fanquake>
murrayn mryandao can bring both up at the dev meeting. Looks like both are almost ready to go.
< mryandao>
when do the dev meetings happen? does it usually happen while aussies are asleep?
< bitcoin-git>
bitcoin/master 7de1de7 mryandao: Add new fee structure with all sub-fields denominated in BTC
< bitcoin-git>
bitcoin/master 6f8b345 Wladimir J. van der Laan: Merge #12240: [rpc] Introduced a new `fees` structure that aggregates all sub-field fee types denominated in BTC...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12240: [rpc] Introduced a new `fees` structure that aggregates all sub-field fee types denominated in BTC (master...fix-getrawmempool-fee-representation) https://github.com/bitcoin/bitcoin/pull/12240
< promag_>
mryandao there you go
< mryandao>
promag: oh sweet. So I dont have to wake up too early :)
< promag>
but you should
< promag>
dev meetings are fun
< mryandao>
oh man, it'd be 5am when the meeting starts
< wumpus>
if PRs are ready for merge you should just let me know, no need to wait for the meeting
< wumpus>
promag: in some more trivial cases that's enough, but changes around threading are pretty risky
< mryandao>
i've been curious, why does core perfer C stdlib over C++ stdlib?
< wumpus>
just a historical thing, it doesn't matter right?
< wumpus>
it's just not worth wasting cycles on imo
< mryandao>
i was just curious. I thought it had to do with performance
< wumpus>
eh, I think you're talking about something else than me
< wumpus>
I thought you meant include style eg. #include <stdio.h> instead fo #include <cstdio>
< wumpus>
not sure what you mean now
< mryandao>
oh no. why fprintf as oppose to just <<
< mryandao>
as an example
< wumpus>
<< is used in some places, for example the wallet dumping
< wumpus>
yes, for logging printf/fprintf is used, but that's the only thing AFAIK
< wumpus>
there's a huge list of standard library functions that should be avoided, or at least used very carefully because they're locale dependent (see #13041)
< gribble>
https://github.com/bitcoin/bitcoin/issues/13041 | build: Add linter checking for accidental introduction of locale dependence by practicalswift · Pull Request #13041 · bitcoin/bitcoin · GitHub
< mryandao>
there's another thing I wanted to address, which is core blowing up when debuglog is set to /dev/stdout because it tries to do a shrink
< wumpus>
eh definitely don't set it to a non-file
< wumpus>
you can do -printtostdout you know that right?
< luke-jr>
I thoguht it was -printtoconsole
< mryandao>
no I didnt. Now I do.
< wumpus>
printtoconsole, yes
< mryandao>
printtoconsole, i know all along
< wumpus>
if you really want to log to a device that is not a file, you can use -printtoconsole and pipe it to that. It'd be possible to add detection of special devices to the logging code, of course, and skip the shrink step...
< wumpus>
but that'd be OS dependent at least
< mryandao>
I was using core in a docker container, that's why I wanted to log to a file
< mryandao>
s/file/device/
< wumpus>
e.g. windows has a completely different convention for devices than unix
< mryandao>
and i couldnt use a pipe redirect because I wanted to allow appending of more flags as needed
< wumpus>
I don't understand that reasoning
< wumpus>
then again, I don't know anything about docker
< mryandao>
do windows users even use Core on commandline?
< mryandao>
i'd expect their usage behaviour to be just running the GUI client
< wumpus>
yes, surprisingly many do, even macosx users use bitcoind
< wumpus>
hard to believe but windows is also used for servers
< fanquake>
Maybe even more surprising given I thought it was our least tested OS
< wumpus>
it's mostly hard to troubleshoot errors
< wumpus>
on linux or osx you can just run the thing in gdb and get a backtrace... good luck with anything like that on windows
< fanquake>
Atleast you can download a Windows 10 "Dev" VM for free and throw it straight into virtualbox. Makes some testing slightly easier
< wumpus>
yes,you can use gdb on windows but it's a nightmare, and yes, other debuggers exist, but they all manage to be incompatible with mingws symbol format
< fanquake>
Still a bit absurd that I'm just about running 3 OSs to build and test a windows binary though
< wumpus>
it's interesting how much advances microsoft is making toward linux, I really hope win32 will disappear on the long run and it will be another POSIX-ish OS like macosx
< wumpus>
pretty much everything else in the world is
< fanquake>
wumpus did you want to merge #12384 even though it still has the formatting changes
< fanquake>
Not quite sure why there are <a></a> tags being used
< wumpus>
fanquake: I hate that PR...
< wumpus>
(that's why I ignore it, maybe I should just close it)
< fanquake>
wumpus heh I remember from ny. I can split out the actual change if you'd like it in. Dropping the other stuff.
< wumpus>
tried to have a reasonable discussion with the guy but it just isn't dawn on him, and it doesn't make sense to make format changes at the same time, certainly not ones that I disgaree with in the first place
< wumpus>
though he means well, I'm sure, which is why I haven't really confronted him I guess...
< wumpus>
his whole point is that "torcontrol" works from version 0.2.7.0 and higher
< wumpus>
if that was the whole of the change I'd be happy with it
< wumpus>
what he's trying to bring into it is that manually setting up the tor settings is somehow deprecated just because the automatic control exists
< wumpus>
that's just false
< wumpus>
and then some completely random formatting changes on top
< fanquake>
wumpus np. I'll sort something out.
< wumpus>
fanquake: yes, we could do that, at least we can close it then :)
< promag>
fanquake: why is <a></a> even there?
< fanquake>
promag I'm not sure, you definitely don't need it to create links in .md files.
< wumpus>
promag: I think that is to add an anchor, to refer to in the link above it
< wumpus>
promag: sections create auto-anchors though
< promag>
right
< wumpus>
and <a name=""> has been deprecated for a long time in favor of <a id="">
< fanquake>
Is the idea that all "Up for Grabs" labelled can be closed? Given that you can find them using the label?
< wumpus>
but it shouldn't be needed
< fanquake>
*labelled PRs
< wumpus>
fanquake: I think so, yes
< aj>
do up-for-grabs labels get removed when someone grabs them?
< wumpus>
at least if the author is inactive, if they're still working on it it shouldn't have 'up for grabs' in the first place
< wumpus>
yes it's one of those 'if we're going to do a 0.15.2 for some reason, that one should be in'
< fanquake>
I wonder if we should be more explicit about "You should probably be building the release.x branch if you are building an older version. Rather than the last release/tag.
< fanquake>
Noticed someone having an issue building 0.15.1 on osx, (bottom of #12009), even though we've backported that fix to the 0.15 branch.
< wumpus>
asking for rebase again is kind of pointless if we don't know whether to do it
< wumpus>
(or when, at least)
< fanquake>
agree. Maybe bring it up at the meeting. If there's no "let's do this and we'll review it quite soon" type consensus I think closing for now is fine.
< wumpus>
I do agree with the rationale though now
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #13094: tests: Add test for 64-bit Windows PE, modify 32-bit test results (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13094
< fanquake>
wumpus Agree that the note being "in" the branch isn't ideal, I'm open to other suggestions on where to put.
< wumpus>
fanquake: I think it would make sense to have a section about branches in the README.md in master, somewhere near the top
< fanquake>
wumpus ok. I guess that section could get adjusted at branching time to be more specific if required as well.
< bitcoin-git>
bitcoin/master 19fc973 Pieter Wuille: Do not expose SigVersion argument to IsMine...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13002: Do not treat bare multisig outputs as IsMine unless watched (master...201804_cleanismine) https://github.com/bitcoin/bitcoin/pull/13002
< achow101>
what happened to cflatdata?
< sipa>
achow101: gone!
< sipa>
what do you need it for?
< achow101>
rebasing psbt
< sipa>
what kind of object are you serializing?
< achow101>
std::vector<unsigned char>
< sipa>
with fixed known size?
< sipa>
READWRITE(MakeSpan(the_vector)) should work
< achow101>
sipa: I have things like this: WriteCompactSize(s, entry.second.size());
< achow101>
s << CFlatData(REF(entry.second));
< achow101>
entry.second is a CScript actually
< sipa>
s << MakeSpan(entry.second);
< achow101>
ok, thanks
< sipa>
does 's << entry.second' not work (replacing the WriteCompactSize too)?
< achow101>
I'm not sure
< achow101>
sipa: so Span effectively replaces CFlatData?
< sipa>
achow101: Span is much more :)
< sipa>
it's just a pointer to some data + length, that acts like a container on itself
< sipa>
but Span<unsigned char> has a special serializer that works like serializing arrays
< sipa>
it has a subset of the functionality of std::span that is proposed for C++20
< achow101>
ah ok
< achow101>
I made liberal use of CFlatData when implementing psbt so now I need to figure out how to fix all of that
< sipa>
oh, you can also serialize arrays of chars directly now
< sipa>
s << array;
< achow101>
What about deserializing arrays of chars?
< sipa>
also works
< sipa>
also on Spans
< achow101>
Does it have to be length prefixed?
< sipa>
no
< sipa>
vectors are serialized with length prefixed
< instagibbs>
proposed topic: the necessity of "totalFee" as an argument for bumpfee
< BlueMatt>
I mean we havent really been getting any review on the "high priority" list
< BlueMatt>
so not sure the use of bringing it up every week
< wumpus>
BlueMatt: if we don't bring it up it's even more pointless I guess
< sdaftuar>
yeah we either nag or we give up -- i vote for the former
< * sdaftuar>
nags self
< BlueMatt>
I've nagged the last two weeks (sorry wasnt prepared today) but...no dice
< aj>
BlueMatt: 10757's had review, and txindex made it in. yours is hard :(
< wumpus>
but if it doens't help we can give up on it too, fine with me
< jonasschnelli>
Agree. Though "High Priority" is probably the wrong name for that list
< wumpus>
jonasschnelli: any idea for a better name?
< sipa>
i wonder if the "everyone can get one of their PRs on the list" policy is very good
< wumpus>
sipa: any idea for a better policy?
< jonasschnelli>
I have no better name
< aj>
BlueMatt: and yours needs rebase again. :( worth tracking which non-high-pri PRs conflict with high-pri issues and avoid merging them?
< promag>
hi
< BlueMatt>
the subsection is "blockers"
< BlueMatt>
ie "this is blocking my work"
< jonasschnelli>
I think the policy seems pretty fair regarding the lack of a steering commitee
< BlueMatt>
which is correct for a few of those
< sipa>
BlueMatt: ah yes, that makes sense
< jamesob>
aj: sounds like a lot of work
< wumpus>
yes "blockers" might be a better name
< aj>
jamesob: i have a script that approximates it; haven't been running it regularly, but there's no reason i couldn't
< wumpus>
that's why they're high priority
< BlueMatt>
aj: you can still review things with trivial conflicts....
< sipa>
i started reviewing #12979 but had difficulty following
< wumpus>
or supposed to be, anyhow
< gribble>
https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
< jamesob>
aj: oh interesting
< BlueMatt>
sipa: well it got split off of 11775, so its a pure refactor
< BlueMatt>
all it is is moving things around, so on its face it looks useless and dumb
< sipa>
also, BlueMatt, do you think #11639 may not be closer to merge (as it seems like it may conflict with 12979?)
< gribble>
https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
< BlueMatt>
sipa: it is almost certainly closer to merge, but it is *not* blocking me so is not my "high-priority blocker"
< BlueMatt>
whereas 12979 is blocking about 10 other things
< sipa>
ah, i see
< BlueMatt>
however, our high-priority policy has historically been that you can nominate someone else' pr if its blocking you
< BlueMatt>
so if thats blocking someone, they can nominate it
< wumpus>
sure, you can nominate someone else's pr
< wumpus>
also I don't think we have enough other meeting topics every week that not discussing the high priority for review would help
< wumpus>
but I'm fine with dropping the topic if there's agreement to do that
< sipa>
i'd like to keep it - but if there's not much to say, not much needs to be said about it
< BlueMatt>
well we keep coming back to needing *something* to make progress move when you get blocked on something
< BlueMatt>
if not the high-priority list, what?
< wumpus>
yes, if there's nothing to be said we can just move on
< BlueMatt>
and the high-priority list seems to be pretty reliably not working
< wumpus>
well one thing got merged from it...
< instagibbs>
BlueMatt, for your PRs or for all?
< BlueMatt>
yes, but it only got review from like 2 people for several weeks where people were active and it sat on the list
< BlueMatt>
instagibbs: all
< wumpus>
so is that because it is on the list?
< LukeJr>
for all IMO; I'm at least partly to blame though - usually I just pick random PRs without checking the high prio list
< BlueMatt>
no, I'm saying about 2 people bothered to review it for many weeks
< BlueMatt>
which clearly indicates its not working
< sipa>
being on the list doesn't compel people to review
< wumpus>
it's clear that things are on the list that have a hard time getting review
< BlueMatt>
certainly I'm not great either, but we need something to get people to care about some blockers list
< instagibbs>
take it off, see if it gets less review #science
< LukeJr>
I think having the list is better than not - just a matter of remembering to use it
< wumpus>
anyhow, if this topic is only about how ineffective the list is every week, I'm going to drop it
< BlueMatt>
anyway, I'll shut up, instagibbs had a topic
< wumpus>
#topic the necessity of "totalFee" as an argument for bumpfee (instagibbs)
< * LukeJr>
pokes instagibbs
< * sipa>
concludes: no necessity of "totalFee" as an argument for bumpfee ?
< instagibbs>
ohhi
< instagibbs>
sorry
< instagibbs>
yes, is it needed
< wumpus>
what is this argument used for?
< sdaftuar>
it's optional, no?
< instagibbs>
sdaftuar, I was hoping to upgrade rbf/cpfp in not too distant future, but it complicates logic to support
< instagibbs>
I could just not support any better RBF that uses it, but was wondering if it makes sense regardless
< instagibbs>
wumpus, you pay X BTC more in fees, total, rather than bump by feerate
< sdaftuar>
not X more, X total, right?
< instagibbs>
yes
< wumpus>
instagibbs: I suppose that is useful when all of the fee computation happens on the client side?
< sdaftuar>
i dunno, i don't feel strongly about it, i think these user interface questions are hard to answer in the abstract
< sdaftuar>
so if you have a proposal for some other interface, we should talk about that
< aj>
instagibbs: error out if totalFee > old-fee + old-change?
< wumpus>
(as the topic is necessity it's good to have some use cases?)
< LukeJr>
aj: or do it as CPFP possibly
< instagibbs>
aj, hm?
< instagibbs>
ah, interesting
< LukeJr>
I'm not sure total fee really makes sense when changing the size though
< sdaftuar>
yeah i agree that seems like a confusing case at the least
< sipa>
agree
< instagibbs>
I redid everything to just use CreateTransaction, fwiw
< instagibbs>
so it will select more coins, which changes size
< instagibbs>
(if needed)
< sdaftuar>
one issue we ran into with bumpfee was nailing down all the rquirements up-front. might be worth laying out what constraints we are trying to satisfy as part of the discussion, so we can ensure we're still meeting them all
< LukeJr>
instagibbs: considering total fee is optional, we need to work without it regardless; so how does keeping it simplify anything?
< instagibbs>
BIP125 constraints are the PITA I think
< instagibbs>
LukeJr, I want to get rid of it
< instagibbs>
or think about doing so
< LukeJr>
oh
< instagibbs>
ok, just wanted to hear any good use cases if they thought of them
< sdaftuar>
i think if you're changing tx size that's a pretty good argument for dropping it
< LukeJr>
I suppose totalFee could be a kind of "if you calculated a higher fee, fail rather than bump; if lower, increase fee to match"
< aj>
yeah, what lukejr said
< LukeJr>
or even just the former might be the useful part
< instagibbs>
If want total fee, I suppose I could just forbid any new coin selection, and fail out otherwise
< instagibbs>
backwards compatible without additional cruft
< LukeJr>
I think safemode is a useful concept, but without anyone working to make it useful in practice (ie, detecting actual problem conditions), might as well drop it
< wumpus>
it's disabled by default in 0.16 and I've heard no one complaining about it
< achow101>
most people don't know it exists
< wumpus>
to be honest I don't think anyone cares
< instagibbs>
frankly ive never heard of anyone using it, and I still don't know what it does, if anything
< wumpus>
and we should drop it to simplify the code
< achow101>
instagibbs: it disables a few RPCs related to the wallet
< jonasschnelli>
If one cares about, it could be re-written as external RPC layer/proxy
< sdaftuar>
wumpus: yep seems reasonable to me as well
< wumpus>
I mean the alerts that trigger it aren't reliable in the first place
< wumpus>
and then it haphazardly disables some wallet RPCs
< LukeJr>
can always add it back if someone does the work
< LukeJr>
tbf, if it were useful, and disabled by default, the reaction of someone to not having it would probably be to just enable it, not complain
< LukeJr>
(but I don't see how it's useful as-is)
< wumpus>
if someone would make the alerts useful and reliable, that'd be a first step :)
< achow101>
has safemode ever been triggered before due to a chain fork?
< wumpus>
there's -alertnotify!
< wumpus>
achow101: not that I know of...
< LukeJr>
it might make sense to have a "setsafemode" RPC instead of automatic stuff?
< wumpus>
meh
< * LukeJr>
shrugs
< wumpus>
I don't think the current selection of RPCs to disable is useful, maybe something to disable all wallet calls then? I don't know - I don't think there is demand for this inpractice
< jtimon>
BlueMatt: you make something that seems useless and dumb and isn't supposed to change behaviour and don't ping me for review? I'm disappointed :p
< achow101>
What exactly is the purpose of safemode though? If we keep it/change it, what is it's goal?
< wumpus>
so anyhow, that was what I wanted t osay
< wumpus>
I think everyone is 'meh' about it just like me
< wumpus>
other topics?
< sipa>
i think it can just be removed
< wumpus>
yes, I'd prefer that
< LukeJr>
wumpus: walletunload :D
< LukeJr>
achow101: ideally, it would detect odd network conditions and disable confirming transactions
< LukeJr>
achow101: eg, if there was an invalid chain longer than the best valid one
< LukeJr>
(or actually, even more ideal would be to compare the chains, and only confirm transactions common to both..)
< wumpus>
#topic walletunload (Lukejr)
< sipa>
disabling RPCs is not how the bitcoin ecosystem will deal with an emergency anyway - a lot of infrastructure wouldn't even notice
< promag>
I already have unload working without UI reacting
< LukeJr>
wumpus: I wasn't suggesting it as a topic
< wumpus>
LukeJr: oh...
< sipa>
#unload walletunload
< fanquake>
maybe topic: cfields any updates on app signing/certs etc? meant to follow up with you from ny
< wumpus>
#untopic
< LukeJr>
wumpus: just saying it would have the same result as disabling wallet RPCs
< cfields>
fanquake: need to poke gmaxwell. He might've forgotten about it
< LukeJr>
promag: what happens if you try to use the GUI after unloading its wallet?
< wumpus>
LukeJr: ok yes, I understand now :)
< achow101>
has anyone seen gmaxwell recently? is he still alive?
< wumpus>
he's still alive
< promag>
LukeJr: don't know, only tested with bitcoind
< sipa>
yes
< promag>
LukeJr: after #13097 I'll submit unload in the UI
< jtimon>
LukeJr: yeah, total fee meaning "max total fee" makes sense to me without increasing it if you pay less
< sipa>
damn peer
< jamesob>
(late to party) fwiw, I like the High Priority queue. I consult it, I just rarely get a chance to actually get around to it :)
< wumpus>
jamesob: it's always the really large or difficult ones that end up the list, that doesn't help either
< jamesob>
right
< wumpus>
though it makes sense because the others don't need so much encouragement for review
< promag>
i like it too
< jtimon>
yeah, what was supposed to be the initial goal of the safe mode if nobody thinks that either the activation conditions make sense, how did it came to this state? who championed it?
< jtimon>
agree with jamesob I like it to be there even though if I don't have much time to review I tend to ignore big PRs anyway
< sipa>
jtimon: safe mode has existed since forever
< jtimon>
I see
< harding>
jtimon: didn't Nakamoto add safe mode based on the P2P protocol authenticated alert messages back in 0.3.something? I think it's just transitioned to triggering based on local conditions (I think that was something Andresen advocated after the 0.7/0.8 consensus failure).
< sipa>
jtimon: introduced in 0.3.8 under the name "lockdown"
< sipa>
ah yes, there have multiple triggers for ot
< sipa>
including alerts
< jtimon>
harding: I had no idea, that's why I asked, but thanks
< jtimon>
not sure if this is offtopic, but for elements we want a simpler approach (just stop and don't start again until a file with a huge scary name gets deleted). see https://github.com/ElementsProject/elements/pull/323
< jtimon>
I would be more than happy to upstream if there's any interest, but it's kind of orthogonal to removing the current safe mode I guess
< sipa>
yes, seems orthogonal
< jtimon>
so, sorry, were there opened prs to remove the current safe mode?
< wumpus>
right, it used to have a wider scope of triggers, in time it became less and less
< wumpus>
because no one really wants half of their RPCs to break unexpectedly
< wumpus>
certainly not because of a signed message from the P2P network
< promag>
do we want menus "File"->"Open Wallet" and "File"->"Close Wallet" ?
< jtimon>
yeah, from the people's comments just smelled like something that made sense at some point but didn't made sense anymore
< wumpus>
I guess it's not high priority because it's not blocking anything
< wumpus>
also I think it's the kind of thing that gets lots of attention without being on a list
< jtimon>
fair enough, just an idea
< jtimon>
since it seemed nothing was added to the list this week
< jtimon>
to be clear 10757 isn't blocking any work I'm doing on bitcoin core directly either
< jtimon>
I just thought the policy was "say it on a meeting if you don't have one there already and see if people consider it a priority or not"
< wumpus>
yes, in principle it is
< jtimon>
wumpus: well, you don't have any pr on the list, do you?
< jtimon>
anyway, never mind
< wumpus>
true
< jtimon>
it is very small anyway, will get plenty of review in no time, I think
< aj>
having a separate list for blockers and been-hanging-around-for-a-while-let's-knock-this-off might make sense?
< wumpus>
easy enough to add another column
< aj>
jtimon: are the getblockstats test failing for you now too btw?
< wumpus>
jtimon: exactly my point :) the kind of PRs that need nagging about are either obscure ones, or difficult ones that change a lot of code or threading semantics and such
< jtimon>
aj: no, are they failing for you? I can re-test
< aj>
jtimon: yeah. i think they fail once the block timestamps are >24h old
< aj>
jtimon: (i commented on the PR)
< jtimon>
uhm, it is running for too long, not 1 sec as expected, I'll have a look, thanks
< promag>
how should the user load a wallet from the ui? File->OpenWallet -> FileDialog ?
< wumpus>
I guess so?
< promag>
another option is a Wallet menu
< promag>
with all wallets in the wallet dir
< promag>
and then a "Open external" option
< harding>
promag: instead of a Wallet menu, you could have a Recent Wallets entry in the file menu listing the last 10 walets that have been opened.
< promag>
harding: I thought of that too, but IMO that's for "round 2"
< promag>
harding: that needs qsettings to remember wallets, cleanup of unexisting wallets...
< promag>
also, in the UI, should prompt the user if a wallet is being unloaded, for instance, via rpc?
< sipa>
i don't think so
< sipa>
if something is done through RPC you can assume that's the user explicitly acting
< promag>
just asking, I don't think so too
< harding>
promag: makes sense. I guess the question for creating a Wallets menu is whether it's something that would be around permanently or would be just temporary until a Recent Wallets submenu was added. If it's temp, then I'd suggest not adding it at all and making the user go through the file dialog each time they want to open a particular wallet.
< promag>
harding: yeah, and by default open the directory -walletdir
< promag>
and "Close wallet" should close the "current" wallet correct?
< harding>
If possible, I'd default to opening the last used directory.
< harding>
I think most apps do that.
< promag>
should we allow closing all wallets? the UI is not prepared for no wallets
< harding>
(But if there's no last used directory, then -walletdir is a good default.)
< promag>
harding: remembering the last user choice is probably "round 2" too
< promag>
"round 1" should be basic and stable support in the UI
< promag>
"the UI is not prepared for no wallets" <- i was wrong
< wumpus>
yes, it can run without wallet fine, e.g. -disablewallet
< promag>
-nowallet
< achow101>
sipa: how would I serialize a CPubKey without the leading size?
< sipa>
achow101: you could use Span<const unsigned char>(pubkey.begin(), pubkey.size())
< sipa>
or you could add a CPubKey::data() method, and then just use MakeSpan(pubkey)
< bitcoin-git>
[bitcoin] jamesob opened pull request #13099: Use thread names in logs and deadlock diagnostics (master...2018-04-26-use-threadnames) https://github.com/bitcoin/bitcoin/pull/13099