< wumpus>
luke-jr: no, it's not even clear the issue exists on the rc binaries, jonasschnelli tried on a few windows VMs andcouldn't reproduce with the rcs
< jonasschnelli>
luke-jr: I could reproduce the GUI offset issue with 0.14.1 on Win7, 8.1 and 10. But 0.15.0rc2 did not had the issue anymore.
< jonasschnelli>
Either its fixed in Qt5.7 or without our sources
< jonasschnelli>
It may still happen to users compiling with an older Qt version (not confirmed)
< jonasschnelli>
(like the tray icon but, etc.)
< luke-jr>
hmm
< wumpus>
yes don't get started on the tray icon... :p
< luke-jr>
can we contact the users who experienced it in RCs, and confirm their setup?
< luke-jr>
gmaxwell said he knew of at least a few
< midnightmagic>
jonasschnelli: Is there somewhere that you've more-strongly linked your GPG key to yourself? Maybe a video or something?
< wumpus>
a gpg key video? lol
< wumpus>
if it is an issue in 0.14.1 it's not a regression in 0.15 anyhow
< wumpus>
there's 0 reasons to hold the release for it, sorry
< luke-jr>
just strange that the reports came in when 0.15rc was out
< midnightmagic>
wumpus: :-) peter todd did one where he reads out the fingerprint.
< luke-jr>
midnightmagic: jonas has lots of signatures on his key :P
< meshcollider>
gmaxwell did you see instagibbs comment on #11280
< meshcollider>
there is no rescan RPC
< jonasschnelli>
midnightmagic: a video?
< jonasschnelli>
there are tons of merges and commits with my GPG signature... what would a video improve?
< jonasschnelli>
There will soon be a video from the SF bitcoin dev meetup with my key fingerprint on the slides.
< jonasschnelli>
That may help
< * luke-jr>
modifies the slides in that video /s
< wumpus>
no, there is no rescan RPC, just the command line argument
< midnightmagic>
luke-jr: yep. secondary trust is sort of meaningless to me in this context
< luke-jr>
also rescanning isn't possible for pruned nodes?
< meshcollider>
so what's gmaxwell talking about in his comment, if restarting with -rescan won't work with encrypted wallets then is there no fix?
< wumpus>
import* have a 'rescan' argument but I'm not sure that's what is meant
< luke-jr>
I think the "fix" is to unlock the wallet immediately when it starts?
< meshcollider>
nah I doubt that's what he meant, would be pretty hacky if people were required to use an import command to get the rescan going
< jonasschnelli>
with that rescans would be possible for pruned peers (if one wants to rescan not below the pruned depth)
< meshcollider>
hmm yeah that'd be good, I'll review that later too, but that means we have no fix for 0.15.0?
< meshcollider>
Should I remove that section from the notes entirely or just make a note that support for rescanning will come in a new version
< gmaxwell>
meshcollider: you can rescan from RPC.
< meshcollider>
using import commands?
< gmaxwell>
you can use yea..
< gmaxwell>
importmulti
< wumpus>
importmulti without any actual keys or so?
< wumpus>
that definitely needs to be documented, I was not aware of that
< gmaxwell>
but indeed I was forgetting that there is no freestanding 'rescan'.
< jonasschnelli>
with a dummy key/address generated in bip32.org or so
< gmaxwell>
you can scan with a dummy.
< gmaxwell>
which I guess we need to suggest. :(
< meshcollider>
importmulti [] {"rescan":true}
< meshcollider>
empty array will work or nah?
< meshcollider>
it doesnt seem to throw any errors
< jonasschnelli>
i don't think so
< gmaxwell>
It won't rescan if there is nothing to do.
< wumpus>
that kind of makes sense, though it's sad in this case
< midnightmagic>
.../lastlog jonasschnelli
< midnightmagic>
sorry
< luke-jr>
jonasschnelli: ! no:|
< jonasschnelli>
aha. :)
< luke-jr>
importing random untrusted stuff is not safe and should definitely not be advised..
< wumpus>
there are certainly some risks to that
< midnightmagic>
jonasschnelli: Yes. That SF bitcoin meetup is perfect. That's neat that peter todd stuffed a blockchain hash into his signature in a certificate notation. I wonder if I'm the only one that's actually checked that. :-)
< jonasschnelli>
Yes. Indeed. You may import a random address from another wallet to trigger a rescan
< jonasschnelli>
But that's why we need #7061
< jonasschnelli>
We are claiming rescans are not required since years... but it seems like they are
< midnightmagic>
jonasschnelli: The consistency of the signatures is not an identity verification of the guy that everyone else has met (but I have not.) :-)
< jonasschnelli>
midnightmagic: happy to drink a coffee with you somewhere in the world.
< midnightmagic>
I would be happy to have a coffee with you if we are ever in the same place together. \o
< luke-jr>
so encrypted HD backup tl;dr = no solution?
< meshcollider>
no good solution, yeah, they'd have to load another wallet, generate a dummy address, then load their encrypted one and import with rescan
< bitcoin-git>
bitcoin/master d4c18f7 Andrew Chow: Bump wallet version number to 159900
< bitcoin-git>
bitcoin/master 713a920 Andrew Chow: Remove usehd option and warn when it is used...
< bitcoin-git>
bitcoin/master c22a53c Wladimir J. van der Laan: Merge #11250: Bump wallet version to 159900 and remove the `usehd` option...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11250: Bump wallet version to 159900 and remove the `usehd` option (master...bump-wallet-version) https://github.com/bitcoin/bitcoin/pull/11250
< luke-jr>
not sure if release notes are really the place for hacky workarounds for long-standing issues
< wumpus>
meshcollider: thanks for doing 11280, seems it's more work than planned for
< wumpus>
how long-standing?
< meshcollider>
thats fine :) Yeah I'm happy to remove the rescan stuff if needed
< luke-jr>
ever since HD wallets were introduced?
< meshcollider>
Yeah ^ and it will be a hacky-fix-issue until the rescan RPC is merged I guess which means we should all go review jonas's PR asap lol
< wumpus>
well a hacky workaround is better than losing funds
< luke-jr>
wumpus: right, but it's not a new issue, so maybe it should just be a blog post or smth?
< meshcollider>
True, people can still ask for support on stackexchange or whatever though, doesn't have to be in the release notes I guess
< * luke-jr>
watches wumpus put his laptop away
< meshcollider>
Has anyone reported having issues with it so far or is it just a 'could happen'
< meshcollider>
Well, my vote is to leave it in there, having a short Notes/Known Issues section in each release notes is quite a nice idea anyway imo
< luke-jr>
meshcollider: we're all packing up and leaving, so expect a delay in response
< bitcoin-git>
[bitcoin] ajtowns opened pull request #11284: Fix invalid memory access in CScript::operator+= (master...cscript_insert) https://github.com/bitcoin/bitcoin/pull/11284
< meshcollider>
the fact that -usehd is still used in wallet.cpp#L3845 is causing all travis builds on master to fail
< meshcollider>
because contrib/devtools/check-doc.py thinks it needs documentation
< meshcollider>
so we can either remove it from wallet.cpp, or add an exclusion to check-doc.py I guess
< meshcollider>
oh wait actually theres already a list of excluded arguments in check-doc, ill just add it in there
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11285: Add -usehd to excluded args in check-doc.py (master...201709_fix_usehd_checkdocs) https://github.com/bitcoin/bitcoin/pull/11285
< meshcollider>
That should probably be reviewed quickly because all Travis builds depend on it ^
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11288: More user-friendly error message when partially signing (master...201709_partial_sign_error) https://github.com/bitcoin/bitcoin/pull/11288
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11289: Add wallet backup text to import* and add* RPCs (master...201709_add_help_text) https://github.com/bitcoin/bitcoin/pull/11289
< jtimon>
Args undocumented: 1
< jtimon>
set(['-usehd'])
< sdaftuar>
sipa: is using upper case in the human readable part of bech32 addresses not allowed? that wasn't clear to me from the bip, but it seems to result in broken behavior with eg the python implementation (if i'm doing this right)
< sdaftuar>
ie if you call encode and pass an hrp that contains an upper-case character, then the result doesn't seem to decode
< Guest9986>
sdaftuar: you have to make the whole thing uppercase or whole thing lowercase.
< sdaftuar>
Guest9986: if i understand hrp expansion correctly though, that changes the interpretation of the hrp
< sdaftuar>
implying that only lower case is allowed for hrp?
< Guest9986>
That isn't the intent, for the checksum the lowercase value is used. I think the BIP may be a big ambigious there.
< sdaftuar>
i don't think the lowercase value of the hrp is used -- just the lowercase value of the data
< sdaftuar>
so do you think hrp expansion should first convert to lowercase?
< gmaxwell>
both bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 and BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4 are accepted by the reference code for me
< sdaftuar>
right, but try encoding something with an hrp using capital letters, say "BC"
< sdaftuar>
and then try decoding
< sdaftuar>
i think that will fail
< gmaxwell>
The BIP says: "The lowercase form is used when determining a character's value for checksum purposes.", and the ref code correctly accepts upper and lowercase versions of the same string. So I think what you're saying is that the encoder doesn't convert the case, but the decoder works fine.
< gmaxwell>
So if one uses the encoder with an uppercase hrp you'll get a value that never decodes.
< sdaftuar>
yes
< gmaxwell>
seems plausable to me, sounds like an implementation bug, though not one that would be a problem for us. (not like the HRP is a user specified value)
< sdaftuar>
well i wasn't sure if it was an implementation bug or a misunderstanding in my reading of the BIP
< gmaxwell>
No misunderstanding on your part, I think: consider, since the decoder works with strings converted to uppercase, your uppercase encodes could never work, not exactly all that useful. :P
< sdaftuar>
if we are converting the hrp to lowercase when we encode, then the BIP should probably just make that clear, that hrp values are more restricted
< sdaftuar>
if the hrp expansion function treated upper case hrp's the same as lower-case hrp's, it woulnd't be a problem either i guess
< jimpo>
Would appreciate reviews on 11113 and 11116
< achow101>
seems like travis is all messed up now
< instagibbs>
achow101, ok, not just me then
< achow101>
instagibbs: apparently that's my fault. We need to merge 11285.
< achow101>
I guess this is what happens when things are merged right before leaving for dinner
< jamesob>
Have 4 hours on a plane to write some unittests. Any recommendations?