< 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
< bitcoin-git>
bitcoin/master e16b6a7 Miguel Herranz: rpc: Rename size to vsize in mempool related calls
< bitcoin-git>
bitcoin/master e14cd04 MarcoFalke: Merge #15637: rpc: Rename size to vsize in mempool related calls
< bitcoin-git>
[bitcoin] torkelrogstad opened pull request #15669: rpc: Fix help text for signtransactionwithXXX (master...signrawtx-rpc-help) https://github.com/bitcoin/bitcoin/pull/15669
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15668: p2p: Slightly more private initial tx relay (master...1903-p2pSlightlyPrivateTxRelay) https://github.com/bitcoin/bitcoin/pull/15668
< BostX>
sipa: maybe some warnings would be helpful. Like "You're signing a TX w/ no inputs". Or maybe a better message in the `bitcoin-cli help signrawtransactionwithwallet`
< BostX>
sipa: Uhm... I'd like to sign my TX on an offline computer where I don't want to install anything other than bitcoin-core.
< sipa>
BostX: perhaps you should head to bitcoin.stackexchange.com
< BostX>
sipa: I created: bitcoin-cli createrawtransaction '[]' '{"unused-new-address": <number>}'
< bitcoin-git>
[bitcoin] instagibbs opened pull request #15664: change default Python block serialization to witness, test round-trip (master...default_wit_block) https://github.com/bitcoin/bitcoin/pull/15664
< midnightmagic>
Just a hackish informational thing that means I don't have to use bitcoin-iterate
< gmaxwell>
It gets used by things like custom wallet software to make bitcoin core track data needed for spending. I assume electrum personal server uses it. Joinmarket uses it.
< harding>
echeveria: yes, but (as I mentioned) Bitcoin Core trickles txes. That is, it doesn't send to each of its peers immediately but separates all of its peers into buckets of peers and maintains a queue of transactions for each bucket, sending to all the peers in the bucket on some schedule. This means a transaction may be propagated to a non-spy node, relayed through the network, and then heard about by the spy node from some other
< harding>
echeveria: encryption by itself, if we assume no mitm and no eclipse, improves own-transaction relay privacy in combination with Bitcoin Core's existing tx trickling code. Right now when you send your own transaction, spy nodes can't be sure whether you originated a transaction or just relayed it. However, your ISP can see that you never received the tx over clearnet before sending it, so unless your node is also on Tor or
< echeveria>
I couldn't work that out. its pretty clear what is running bitcoin, from the traffic or the port number.
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #14050: Add chacha20/poly1305 and chacha20poly1305_AEAD from openssh (master...2018/08/bip151_chachapoly1305) https://github.com/bitcoin/bitcoin/pull/14050
< echeveria>
harding: the only other one I was thinking of was Parity Bitcoin, and they seemed to have only been funded to create that for a very short period.
< harding>
echeveria: not that I'm aware of at the moment. I was thinking about 2015-17 contention between Bitcoin Core and some of the stuff Unlimited was doing. Also XT had BIP64 support and a different protocol version.
< echeveria>
is there any actually used implementation of a bitcoin node other than btcd and bitcoin core?
< bitcoin-git>
[bitcoin] promag opened pull request #15652: wallet: Update transactions with current mempool after load (master...2019-03-fix-15591) https://github.com/bitcoin/bitcoin/pull/15652
< gribble>
https://github.com/bitcoin/bitcoin/issues/15647 | [rpc] Remove deprecated functionality message from validateaddress help by jnewbery · Pull Request #15647 · bitcoin/bitcoin · GitHub
< gmaxwell>
#proposedmeetingtopic 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] luke-jr opened pull request #15651: torcontrol: Use the default/standard network port for Tor hidden services, even if the internal port is set differently (master...tor_standard_port) https://github.com/bitcoin/bitcoin/pull/15651
< bitcoin-git>
[bitcoin] lucayepa opened pull request #15650: Handle the result of posix_fallocate system call (master...handle-posix-fallocate) https://github.com/bitcoin/bitcoin/pull/15650