< fanquake>
Hope you had a good christmas and new years!
< jonasschnelli>
Yes! Thanks. I hope you too..
< fanquake>
Yes, it was ok. Probably time to get back to work though hah.
< fanquake>
I've just added a comment there, should we add a note that the workaround can be removed once we're > Qt5.4? Just as a reminder.
< jonasschnelli>
Yes. Adding the link to the upstream bug would be nice...
< jonasschnelli>
I guess something like #if QT_VERSION >= 0x050000 && QT_VERSION >= 0x054000 would be a overkill
< jonasschnelli>
Just keep the workaround and add a link to the upstream bug and mention that it was fixed in Qt5.4
< fanquake>
Yep, I'll push a new change.
< jonasschnelli>
Qt5.4 is relatively new, so we should keep the WA for another year or two
< fanquake>
Could you take a look at #7255 as well?
< jonasschnelli>
Yes... building right now..
< Luke-Jr>
jonasschnelli: phantomcircuit closed all his PRs saying he does not wish to contribute to Core anymore
< jonasschnelli>
Luke-Jr: does he have any reason for that?
< MarcoFalke>
Issues with the code being "misused", iirc?
< jonasschnelli>
Okay. Thanks for the info.
< Luke-Jr>
jonasschnelli: he doesn't want XT/altcoins/Gavin to benefit from his code, and gave an ultimatum of changing the license to a non-free one preventing such [ab]use
< MarcoFalke>
I guess you can look up the IRC log for the day the pulls got closed
< jonasschnelli>
Hah. I see.
< jonasschnelli>
Anyone know why CWallet has a default key (SetDefaultKey, vchDefaultKey)? Any reason for that?
< sipa>
jonasschnelli: historical reason
< sipa>
the wallet used to have an always-visible "receive address"
< jonasschnelli>
sipa: so it could be removed...
< sipa>
that automatically changed once younreceived money on it
< sipa>
eh, if nothing uses it anymore
< jonasschnelli>
a short code check told me, that it's unused.
< Luke-Jr>
be careful not to break getaccountaddress
< jonasschnelli>
Luke-Jr.... yes... this might be a point..
< Luke-Jr>
jonasschnelli: has the goal changed from new wallet to improving the current one? (not complaining, just wondering)
< jonasschnelli>
Luke-Jr: I still follow both plans... short term (0.13) I'd like to get a simple form of bip32 into the existing wallet. why: allows simple support of hardware wallets
< jonasschnelli>
But have plans to switch back focus on the new wallet...
< jonasschnelli>
Luke-Jr: right now, most(all?) hardware wallets use bip32 and do not store keys in the EPROM (just the seed). A bip32 pubkey only wallet in core would allow to use `create/fundrawtransaction`, take the hex, transmit it to the hardware wallet, get the signed hex back...
< Luke-Jr>
jonasschnelli: eh, hardware wallets shouldn't realistically need software BIP32 support.. seems like just an excuse on their part to not do it IMO
< jonasschnelli>
I really think the private keys should not be in the wallet.dat,... better on a offline computer, old android phone, hardware wallet
< Luke-Jr>
I mean, obviously the driver will need to do the deriving of the watch key, but we already have that
< Luke-Jr>
not that I object to improving the wallet
< jonasschnelli>
Luke-Jr: The write cycles and space of EPROMs are limited, ... so bip32 makes perfect sense for tiny devices.
< Luke-Jr>
certainly. I'm just saying there's nothing stopping them today
< jonasschnelli>
right...
< petertodd>
jonasschnelli: you mean EEPROMs - *electrically* erasable programmable read only memory :