Transcript for #bitcoin-dev 2017/08/25

00:42 esotericnonsense https://i.imgur.com/gEQnRv7.png using bitcoinjs-lib and zmqpubrawblock on the backend, socket.io to chuck it out (for easier websockets),
03:43 cluelessperson Question, What's preventing testnet from being reset anyway?
03:54 Emcy nothing? They did it before
09:33 juscamarena I wish it was reset, too damn long/big
09:34 waxwing +1e100
09:35 arubi maybe this time with some rule that makes utxo "decay" so they become anyone-can-spend after some time unused
14:16 e4xit I want to allow my mobile wallet (breadwallet beta) to always connect to my bitcoin core node as it has a setting to allow this, but I can't use connect=x.x.x.x.x because my IP address will change on my mobile device. Is there any workaround in the core client that I am missing?
15:59 coin_trader anyone know how to recover balance from segwit addresses on an HD core 0.14.2 wallet? must i walk the HD keypath & addwitnessaddress for every single public addy in my keypool? the "new" or "recovered" wallet seems to have no knowledge of the segwit addresses that are derived from the HD legacy addresses..... is there an easier way to get it to sync up?
16:08 arubi coin_trader, core doesn't support recovery at all at the moment afaik
16:08 coin_trader hmm that's what i thought, but seems kinda ... short-sighted? i figured i just was doing something wrong.....
16:08 arubi you do have to back up the wallet file to recover bip32 stuff. it's fine to backup once, but then you do have to manually set up scripts
16:09 coin_trader right, i would need to run a loop for X times to addwitnessaddress(getnewaddy()) type of thing right?
16:09 coin_trader so then the wallet "knows" all the segwit addy, and i may even need to rescan the wallet ,right?
16:09 arubi right. it's pretty difficulty handling recovery on bip32 wallets that aren't using public derivation
16:09 coin_trader eh whatcha mean? i have a skeleton of that same HD wallet when it was first created
16:10 coin_trader i've done it before to recreate the history just by looping a few thousand times to get new addy and walk out the keypath, since it's the same seed
16:10 coin_trader but not yet for segwit...
16:10 arubi yea, but you had to have the wallet unlocked the whole time right?
16:10 coin_trader sure
16:11 arubi so that's what I mean by it being difficult to handle. say you sync from 0, do you need to have the wallet unlocked for days?
16:11 coin_trader oh heavens no - you can sync the chain without caring about wallet -- then just rescan the HDD once it's all loaded for getting all the correct wallet history
16:11 arubi (if you wouldn't use the loop)
16:12 arubi sure sure, that's why I think it's not pretty yet
16:12 coin_trader i don't even really bother to sync new nodes anymore... i just SCP the data directory from one server to another, then it will simply "catch up" the end bits real quick
16:12 coin_trader but that's cuz i have access to full data dir on servers that can talk to each other
16:13 coin_trader do you know if 0.15 will support proper generation of segwit addy & balance from a "reloaded" HD wallet?
16:13 arubi not sure really
16:17 wallet42 i have 2 regtest nodes running, but they are not syncing from one another. in the debug log of the connecting node it says "Ignoring getheaders from peer=0 because node is in initial block download"
16:21 arubi huh. I never saw that happening. what's your setup?
16:35 wallet42 bitcoind -regtest -printtoconsole -debug=bench -port=18444
16:35 wallet42 bitcoind -regtest -datadir=/tmp/3 -printtoconsole -debug=bench -listen=0 -rpcport=38332 -addnode=127.0.0.1:18444
16:38 arubi and you've generated blocks with the first one, and the second one's debug.log is saying "ignoring headers..." ?
16:39 wallet42 jup
16:39 arubi did you try restarting the second one?
16:39 wallet42 many times
16:39 wallet42 its weird
16:39 arubi getpeerinfo says they're both connected?
16:40 wallet42 i created 2 complete new installations
16:40 wallet42 there it works
16:40 arubi hm
16:40 wallet42 but i was working with 1 node regtest
16:40 wallet42 and have quite a blockchain there now
16:40 wallet42 and wanted to do bench testing on importing
16:40 wallet42 from sencond node
16:40 wallet42 but the old node is just refusing to not be in IBD mode
16:41 wallet42 anyway i guess i just recreate it all
16:41 wallet42 thanks anyway
16:41 arubi yea I'm not sure what's wrong. np
16:43 arubi fwiw, if you bind each node's p2p and rpc interfaces to its own ip, say 127.1.0.1 for the first, 127.1.0.2 for 2nd etc.. you'll have easier time with port and -cli management
18:50 coin_trader am i correct in seeing this behavior where a bitcoind core node using RPC or CLI commands "sendmany" or "sendtoaddress" will do a segwit transaction wherein the change address is forced to go to a legacy address? Currently no way to specify change addy must be segwit, correct?
18:50 coin_trader only way would be with rawtx (which i'm looking to avoid at all costs)
18:57 CryptAxe If you aren't sending the change to a lightning channel or something, you probably want it to be a "legacy" output
20:37 coin_trader CryptAxe mmmm but the segwit transactions are much cheaper fees to send? i'd much prefer to save some loot and have change addy auto-segwit itself so that all successive tx are segwit also.... i'm seeing on average around 100-150 spb cheaper than "normal" to get confirmed... it's a nice cost savings.....