< Bullit>
Hello, I have a questions concerning the potential of distribution, is there a map with distribution spread network ups since 2014?
< echeveria>
Bullit: #bitcoin please.
< stevenroose>
luke-jr: people don't like BIP70, though :)
< stevenroose>
sipa: unless you want it to be usable with other networks so you just want to leave space for more values without wanting to have to go arbiter what values are legitimate
< echeveria>
"legitimate" is irrelevant really. most altcoins just re-using the same version bytes for P2PKH or P2SH should tell you that.
< cjd>
altcoins just re-using the same version bytes for P2PKH or P2SH <-- probably because they want to be able to pull from upstream with minimal patching
< echeveria>
no, it's generally because they're unaware of the impact. see Litecoin duplicating the P2SH version byte but not the P2PKH version byte.
< cjd>
In the case of segwit version bytes, I must admit I'm also unaware of the impact
< echeveria>
in any case you can't expect that people will change version bytes at all, or that bitcoin won't, so using them as identifiers would be a poor decision.
< cjd>
*nod* I wouldn't, and since I'm working on an alt I guess that's significant
< cjd>
though changing the magic is something I sort of expect people to do, since the way the code is laid out sort of encourages it
< luke-jr>
stevenroose: sure, I was just mentioning it since it has string network ids
< echeveria>
both of which are things that altcoins frequently don't change.
< stevenroose>
echeveria: I generally don't really care about altcoins ;)
< stevenroose>
mostly thinking liquid or other potential sidechains
< echeveria>
stevenroose: that's nice. back here in the real world, things exist which you may not like and you need to take them into consideration when writing specifications.
< fanquake>
wumpus #15270 probably mergable (given Ken has tested on windows), also 15252 & 15243.
< provoostenator>
promag: yeah, was about to run through my Github notifications...
< fanquake>
I think a fair bit needs rebasing now
< provoostenator>
We need rebase bots that devs can run on their computer, to handle the more trivial rebases.
< provoostenator>
That or assistants :-)
< provoostenator>
"Always two there are. No more, no less. A master and a rebaser"
< promag>
provoostenator: ty
< provoostenator>
sipa promag can you leave some more thoughts about error catching on #14978? (maybe distinguish between best long term and fine for now)
< gribble>
https://github.com/bitcoin/bitcoin/issues/14978 | Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. by gwillen · Pull Request #14978 · bitcoin/bitcoin · GitHub
< promag>
I tend to avoid exceptions, and I don't see a strong reason to use them. I usually try to distinguish exceptions from validations and failures. In that case exception is something that the code doesn't handle so it is interrupted.
< promag>
Also, I think it's bad practice to use exceptions as a way to do control flow
< provoostenator>
My suggestion for using exceptions was mostly based on how RPC currently already uses that pattern. I'm also fine with functions returning status codes and passing &error strings e.g.,
< cjd>
I always felt like in a parser, throwing is the right way to bail out of deeply nested parsing when you hit something that's invalid and wrong
< cjd>
otherwise it's layer after layer of if err { return err; }
< cjd>
sorry if err != nil { return err; } :)
< promag>
MarcoFalke: not sure if serious or trolling :D
< promag>
cjd: maybe it should not have such call stack depth
< cjd>
there are non-recursive ways to parse nested structured data, but you're just putting the stack somewhere else
< cjd>
I agree that runtime exceptions in c++ are monsters because of constructors and destructors, but I think exceptions have been wrongly blamed for that
< cjd>
IMO throw is the correct way to say "none of what we're doing is useful anymore, bail out and fail whatever we were trying to do"
< promag>
cjd: the problem is not at throw, but where it is catched
< promag>
you never know to where you are throwing, and what is ditched in between
< cjd>
you mean what was allocated ?
< promag>
not only that, but what was changed, written to disk, displayed on the screen whatever
< promag>
I think it is always preferable to return to the caller with enough information
< cjd>
Ahh, you're talking about public API throwing, that's a good point
< cjd>
I tend to confine my throws to either what will stay in a file or what will terminate the program
< provoostenator>
You could have a rule that a caller MUST catch any exception class defined in the callee. I think some languages do that. Not sure how easy to automagically enforce though.
< promag>
provoostenator: return a typed error instead?
< promag>
take Qt for instance, it is a mature c++ framework, it avoids exceptions
< cjd>
throwing unchecked exceptions from an API is basically like calling abort() IMO
< provoostenator>
When it comes to the wallet RPC there's another problem, namely that we can't really do atomic operations.
< provoostenator>
I think I have in the past yes. It's pretty ugly in the animated gif though :-)
< provoostenator>
I would probably reuse the bottom progress bar (used during IBD) and when you click on that, show different interuptable processes.
< provoostenator>
(I'll leave a comment to that effect)
< promag>
provoostenator: ah I see you are a man of taste XD
< promag>
well I'm point out that because of the load wallet progress
< provoostenator>
I think instagibbs ownes the man-of-taste trademark.
< promag>
I think something like that must be in place to correctly implement non-blocking UI.
< provoostenator>
I don't mind blocking the UI for one-off long stuff like rescanning a long unused wallet. Non-blocking of course would be nice.
< provoostenator>
Did Travis get slower again? A few weeks ago it seemed to finish a lot of runs in <15 minutes, but now I'm seeing 30+ minutes for my PR again.
< instagibbs>
it's extremely variable for my repos
< MarcoFalke>
provoostenator: Might be one of the sanitizer jobs
< MarcoFalke>
wumpus: Mind adding dongcarl to the github org? Would make it easier to use the pull request filter auto-suggestion.
< wumpus>
huh I got a transient error "test_framework.authproxy.JSONRPCException: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)" while running rpc_createmultisig.py locally, once, but cannot reproduce it
< wumpus>
happened during tx = node0.sendrawtransaction(rawtx3["hex"], True)
< jonasschnelli>
wumpus: do you get that on current master?
< jonasschnelli>
test runs successful on my end (master)
< MarcoFalke>
Hmm, looks like the intermittent errors are returning at just in time for the branch-off