< bitcoin-git>
[bitcoin] sipa opened pull request #15751: Speed up deriveaddresses for large ranges (master...201904_fasterderiveaddresses) https://github.com/bitcoin/bitcoin/pull/15751
< bitcoin-git>
[bitcoin] jnewbery opened pull request #15750: [rpc] Remove the addresses field from the getaddressinfo return object (master...2019_04_remove_address_from_getaddressinfo) https://github.com/bitcoin/bitcoin/pull/15750
< bitcoin-git>
[bitcoin] sipa opened pull request #15749: Fix: importmulti only imports origin info for PKH outputs (master...201904_importallorigins) https://github.com/bitcoin/bitcoin/pull/15749
< achow101>
supay: can you try `bitcoin-cli listaddressgroupings` and see if your address is in there?
< gwillen>
if you are trying to import the master privkey, that is your problem -- bitcoin core does not know about bip 44, and won't try to derive the child keys automatically
< supay>
gmaxwell: i've done: bitcoin-cli importprivkey the_key "" true -- and i wait about 25 mins or so for the rescan, and when i run bitcoin-cli getwalletinfo, the balances are still 0
< supay>
i lost access to my bitcoin and scrubbed my system for any data i could find. found some bip32/44 paths. trying to import private keys into bitcoin core using importprivkey, but that isn't working. there aren't any errors either. any help?
< gmaxwell>
jl2012: there isn't a chinese version of bitcoin.org or something that only shows old links? I'm just at a loss as to what would be causing people to start new nodes using old code.
< wumpus>
fanquake: thanks for keeping an eye on changes to the release notes-if this keeps up we'll have to restrict edits to people in the bitcoin-core org (I'd prefer not to as this loses some potential documentation-only contributors), but this may well be accidental and they fixed it
< gmaxwell>
$ ./bitcoin-cli getblocktemplate
< gmaxwell>
I'm just ./bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.transactions | .[] | select(.hash != .txid)' |less and hitting / and pasting in the txid.
< gmaxwell>
I did: $ ./bitcoin-cli prioritisetransaction 35611cbad11967731aa122136bf90bd63c5224296c45c10a26885c3bb3fff6f6 0 100000
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15721: validation: Check absence of locks at compile-time (LOCKS_EXCLUDED) in addition to the current run-time checking (AssertLockNotHeld) (master...negative-locking-annotations) https://github.com/bitcoin/bitcoin/pull/15721
< bitcoin-git>
[bitcoin] scravy closed pull request #15715: Better support for mainframes and EBCDIC users in general (master...cater-mainframes-and-ebcdic-users) https://github.com/bitcoin/bitcoin/pull/15715
< bitcoin-git>
[bitcoin] scravy opened pull request #15715: Better support for mainframes and EBCDIC users in general (master...cater-mainframes-and-ebcdic-users) https://github.com/bitcoin/bitcoin/pull/15715
< wumpus>
(there's nothing wrong with asking that question on twitter on your own personal accord, but having it come from "bitcoin core" is going to cause lots of noise)
< bitcoin-git>
[bitcoin] luke-jr opened pull request #15704: Move Win32 defines to configure.ac to ensure they are globally defined (master...win32_defines_globally) https://github.com/bitcoin/bitcoin/pull/15704
< sipa>
yeah, so your bitcoin core wallet will correspond to a union of several things that are (possibly) compatible with an electrum wallet individually
< bitcoin-git>
[bitcoin] dongcarl opened pull request #15689: netaddress: Update CNetAddr for ORCHIDv2 (master...2019-03-account-for-orchidv2) https://github.com/bitcoin/bitcoin/pull/15689
< gmaxwell>
I've always made a point of CCing other people (usually wumpus and sipa) anytime I communicated something 'for bitcoin core project', even dumb stuff like lame whining at people for idiotic tweets. ... just so if I drop off the face of the earth someone has context.
< gmaxwell>
I'm concerned that we're erroring a little too strongly towards total compatiblity, which is causing industry participants to make an economically rational decision to ignore updating their bitcoin support in favor of supporting more altcoins.
< moneyball>
we have 1 proposed topic! topic proposed by gmaxwell: Bech32 support shipped first in Bitcoin Core in Feb 2018, more than a year ago. We should consider making an announcement that Bitcoin Core intends to change the default addresstype from p2sh-segwit to bech32 in 0.19 or 0.20.
< bitcoin-git>
[bitcoin] jonatack opened pull request #15687: test: tool wallet test coverage for unexpected writes to wallet (master...tool-wallet-tests-for-unexpected-writes-to-wallet-file) https://github.com/bitcoin/bitcoin/pull/15687
< bitcoin-git>
[bitcoin] instagibbs closed pull request #15547: Switch wallet default to reject too-long transaction chains for mempool (master...walletreject_true) https://github.com/bitcoin/bitcoin/pull/15547
< bitcoin-git>
[bitcoin] murrayn closed pull request #15500: Support for a bitcoind 'ready' file to indicate startup is complete. (master...ready_file) https://github.com/bitcoin/bitcoin/pull/15500
< bitcoin-git>
bitcoin/0.18 09a05e8 Wladimir J. van der Laan: qt: Translations update pre-rc3
< bitcoin-git>
bitcoin/0.18 f14a0aa Wladimir J. van der Laan: build: Bump to rc3
< wumpus>
running bitcoin on an unupdated w7 ouch :)
< bitcoin-git>
[bitcoin] theuni opened pull request #15682: release: Update the Windows Codesigning certificate (master...new-win-cert) https://github.com/bitcoin/bitcoin/pull/15682
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #15681: [mempool] Allow one extra single-ancestor transaction per package (master...2019-03-lightning-policy) https://github.com/bitcoin/bitcoin/pull/15681