< hadjiszs>
seems to work even with emoji name then :p
< hadjiszs>
last time I tried emoji unicode, only icpc was ok to compile though
< wumpus>
fanquake: sounds good to me
< wumpus>
renaming the branch would be somewhat more elegant but would also give all kinds of weird conflicts for people doing 'git pull' next time, don't know what's best here I'll just change the default branch for now
< wumpus>
haskell can also do unicode operators, that said it's not great for typing
< wumpus>
I mean having to define weird key sequences or ctrl-shift-U XXXX all the time
< wumpus>
a possibly preferable approach that some editors have is that they can *show* certain sequences of characters as a more compact unicode character, e.g. <= as ≤, vim can do this using conceal, for example
< vasild>
Allowing custom unicode operators would bring the obsuscated c code contest https://www.ioccc.org/ to a whole new level!
< elichai2>
I guess it's locale again :/ need better error
< MarcoFalke>
elichai2: you need to export an utf8 or C LC_ALL
< elichai2>
yeah and it seems to be failing really really early, so I think i'll give up on adding some meaningful error
< MarcoFalke>
export LC_ALL=C.UTF-8
< MarcoFalke>
or
< MarcoFalke>
export LC_ALL=C
< MarcoFalke>
should fix it
< elichai2>
yeah it did. thanks. was just trying to figure out if I can find the source and get it to print a meaningful error
< bitcoin-git>
[bitcoin] vasild opened pull request #18382: doc: note the costs of fetching all pull requests (master...note_fetch_all_cost) https://github.com/bitcoin/bitcoin/pull/18382
< bitcoin-git>
[bitcoin] elichai opened pull request #18383: Check for overflow when calculating sum of outputs in a transaction (master...2020-03-value-overflow) https://github.com/bitcoin/bitcoin/pull/18383
< bitcoin-git>
bitcoin/master 84a46a9 emu: doc: mention MAKE=gmake workaround when building on a BSD
< bitcoin-git>
bitcoin/master 527c398 Wladimir J. van der Laan: Merge #18340: doc: mention MAKE=gmake workaround when building on a BSD
< bitcoin-git>
[bitcoin] laanwj merged pull request #18340: doc: mention MAKE=gmake workaround when building on a BSD (master...fixup_18129) https://github.com/bitcoin/bitcoin/pull/18340
< MarcoFalke>
#proposedmeetingtopic PGP is dead
< vasild>
elichai2: MarcoFalke: what overflow are we talking about in #18383? If it is an overflow of int64_t (= CAmount), then it is not possible because both numbers are checked by MoneyRange() for being less than 21M (MAX_MONEY). If it is an overflow of MAX_MONEY, then it is possible, but then shouldn't the patch use MAX_MONEY instead of std::numeric_limits<CAmount>?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18383 | Check for overflow when calculating sum of outputs in a transaction by elichai · Pull Request #18383 · bitcoin/bitcoin · GitHub
< MarcoFalke>
vasild: It is an overflow in a result that is never read when it overflows
< MarcoFalke>
The only way you can trigger this is by enabling sanitizers
< MarcoFalke>
Compilers are smart these days, so without sanizitzers enabled, it probably will be optimized out/reorderd and thus won't overflow
< vasild>
Ah, now I see!
< sipa>
MarcoFalke: || short circuits; the right half is not evaluated if the first half is true
< sipa>
so i don't understand how this can trigger
< sipa>
it has nothing to do with reordering; any optimization a compiler performs must be indistinguishable from the correct semantics
< MarcoFalke>
sipa: nValueOut += tx_out.nValue; is always executed
< MarcoFalke>
it is not under a condition
< sipa>
oh!
< sipa>
i was misreading
< sipa>
thanks
< vasild>
kallewoof: btw, what happens if we receive some out-of-order blocks, store them in blk files, flush finalize etc and later we receive alternative blocks for those heights with higher POW, so the new guys get connected. Do we leave the first ones on disk forever, orphaned?
< kallewoof>
vasild: i believe the new blocks will go into the newer block files. when connected, the undo data for THOSE will go into the corresponding rev files like normal
< kallewoof>
i could be wrong though. definitely worth looking into, but nowadays, reorgs are rare :)
< vasild>
yes, I am wondering if we ever clean up the old ones
< kallewoof>
old block or old rev?
< kallewoof>
either way, i don't really know, myself. others may be able to answer though.. (sipa?)
< sipa>
we clean up the old ones only when pruning
< sipa>
in which case entire files are deleted
< vasild>
actually POW is not relevant here. For example: we receive block 5, write it to disk, then we receive block 7, write it to disk (it refers an imaginary parent block 6). Then we receive block 6' and decide to connect it to block 5, so block 7 is useless.
< sipa>
correct
< vasild>
sipa: I see, so we will not go to clean up block 7 "in place" inside the blk / rev files or something crazy like that which would complicate stuff even more
< sipa>
indeed
< sipa>
note that 7 would only be downloaded if we at least had a valid header for its parent
< vasild>
ah, that answers my question before I asked it - could somebody feed us a huge pile of useless blocks to fill up our disk ;)
< vasild>
Thanks!
< sipa>
you can ask the same question about headers, though
< vasild>
could somebody feed us a huge pile of useless headers to fill up our disk?
< sipa>
and the answer for that is the old checkpoint we have, making crearing fake headers pretty expensive as they have to branch off after the last checkpoint
< sipa>
actually, let me check, there may be more protections now
< vasild>
if we check that the ids of the blocks from the headers match the expected difficulty, then creating one useless header would require the same amount of work as mining a legit block. So not worth doing in order to fill somebody's disk. Right?
< bitcoin-git>
[bitcoin] gzhao408 opened pull request #18384: [test] more specific feature_segwit test error message (master...segwit-test-errormsg) https://github.com/bitcoin/bitcoin/pull/18384
< ariard>
amiti: around? I see for the privacy win in #18038, it's only make it easier for a spying node assuming it connects after initial-broadcast and in between you didn't receive any GETDATA from your honest peers
< MarcoFalke>
Pretty much only bugfixes for 0.20 should be high prio right now (until end of month). Also refactors that are not risky can go in. Other than that, features have to wait
< kanzure>
hi
< MarcoFalke>
Features can be in high prio, but they can't be merged right now
< ariard>
Okay so maybe only #17954, that's a non-risky refacto?
< wumpus>
MarcoFalke: yes good point I guess, though on the other hand if people want to review features now that's ok, they just can't be merged until the split-off
< MarcoFalke>
Would people (or maybe maintainers) object if I upload the keys to keys.openpgp.org as a backup and then request a confirmation email on their behalf?
< wumpus>
oh, you trid that too?
< wumpus>
no, of course not, though it's annoying that we have to keep changing keyservers, I don't think we've been using the ubuntu one for that long
< MarcoFalke>
jup
< luke-jr>
fine with me
< cfields>
Several folks offered to help out by "running a Hagrid server instance". We very much appreciate the offer, but we will probably never have an "open" federation model like SKS, where everyone can run an instance and become part of a "pool"
< cfields>
I don't understand what this is attempting to accomplish.
< MarcoFalke>
Yes, I changed to the ubuntu one last March, because the previous was down
< MarcoFalke>
cfields: There a no pools anymore, it is just one point/website for the keystorage
< wumpus>
if the ubuntu keyserver isn't fixed, we're all going to have this problem when we need to update our key expiration
< MarcoFalke>
What's the number for the ubuntu keyserver costumer support?
< bitcoin-git>
[bitcoin] laanwj opened pull request #18386: doc: Temporary note that release notes should be edited in wiki (master...2020_03_relnot) https://github.com/bitcoin/bitcoin/pull/18386
< bitcoin-git>
bitcoin/master b492684 Wladimir J. van der Laan: doc: Temporary note that release notes should be edited in wiki
< bitcoin-git>
bitcoin/master 5bf45fe MarcoFalke: Merge #18386: doc: Temporary note that release notes should be edited in w...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18386: doc: Temporary note that release notes should be edited in wiki (master...2020_03_relnot) https://github.com/bitcoin/bitcoin/pull/18386