< promag>
should release notes about scantxoutset also include something more detailed about output descriptions?
< promag>
*descriptors
< promag>
or is it enough to link doc/descriptors.md?
< hebasto>
The *gui* prefix is not mentioned in the CONTRIBUTING.md. Is it valid? If "yes", what is difference between "gui" and "qt" prefixes?
< sipa>
"prefix" ?
< ken2812221_>
IMO they are the same, not sure what you mean "valid".
< jl2012>
currently, if the script engine need to change the value of a stack element, it will first pop the element and push back the new one. Would it be more efficient if we directly assign the new value to stack.back(), instead of doing pop and push?
< promag>
wumpus: pls see my question above
< hebasto>
sipa: I mean PR title prefix (e.g. "wallet", "docs", "trivial" and so on).
< wumpus>
promag: i'd say, link to the document, an actual, maintained, document is so much better than a description in the release notes
< wumpus>
promag: we've been kind of abusing the release notes as documentation for new features but it's not something to be encouraged
< promag>
wumpus: agree on that
< promag>
release notes should just say, this was added/changed/removed and see /this.md for more details
< wumpus>
yes, most useful is if it has a short description of what changed, with a link for information (or, say, a command to run) for details on how to use it
< wumpus>
'refer to the RPC help for this command' is also enough for many things
< promag>
wumpus: scantxoutset is experimental so I wouldn't detail that much in the release notes
< wumpus>
hebasto: you can use either; in a strict sense, gui is more general and would also other kinds of graphical interfaces than the qt one, but there are none within our source tree so it can't be a source of confusion
< wumpus>
(in any case, my release-notes-pull-request-list script is smart enough to regard all these prefixes, say [qt] qt: [gui] gui: even [gui]: as the same)
< wumpus>
promag: just do mention that it's experimental, then :)
< Jmabsd>
What (bignum) integer unit is used in the total work done calculation?
< hebasto>
wumpus: thank you
< sipa>
Jmabsd: we have arith_uint256
< Jmabsd>
sipa: so 256bit is always enough for the sum of all of them?
< luke-jr>
I think we'd have a serious problem if it wasn't?
< luke-jr>
that would basically mean SHA2 is broken?
< luke-jr>
(completely)
< sipa>
Jmabsd: yes, counting to 2^128 costs more energy than boiling the earth's oceans :)
< sipa>
2^256 should suffice for a while :)
< luke-jr>
sipa: to be fair, we're not counting :P
< luke-jr>
at least not by small numbers
< Jmabsd>
interesting.
< sipa>
luke-jr: well the chainwork variable is counting an estimate for how many sha256 operations have been performed
< Jmabsd>
up to what block height will the 256bit uint suffice? :)
< Jmabsd>
it *does* help that the block hash is constantly approaching zero. :)
< sipa>
Jmabsd: you're worrying about highly theoretical problems
< luke-jr>
sipa: oh, that's a good point
< luke-jr>
Jmabsd: forever, considering what sipa pointed out
< sipa>
Jmabsd: the answer could be "not within the age of the universe" if classical computation limits hold, or "milliseconds" under the existence of unbounded quantum computers
< luke-jr>
since it's based on target and not the block hash, even a lucky block hash wouldn't skew the estimate much
< luke-jr>
s/much/at all/
< * luke-jr>
wonders if the time warp attack thing would make it possible to overflow
< luke-jr>
probably not
< sipa>
no even with a tike warp attack the chainwork variable remains a truthful esrimate
< mryandao>
what are good ways to record timing events for specific functions in bitcoin without using events (but a clock timer) instead?
< sipa>
mryandao: i don't understand; what does "recording timing events" mean?
< mryandao>
sorry, let me try again. Recording the time difference between the start and end of a function.
< mryandao>
i read chrono and then flushing it to a file is not precise.
< mryandao>
s/chrono/using chrono/
< sipa>
mryandao: we have a GetTimeMicros function
< sipa>
call it once before and once after
< sipa>
the difference is the duration in microseconds
< booyah>
Jmabsd: mostl likelly it would take 2258740816895212925709483946018412684403674794507657694277808676808542634 years, 30 days, 17 hours, 3 minutes and 1 second, sir