1 2017-08-25 00:42:49 <esotericnonsense> https://i.imgur.com/gEQnRv7.png using bitcoinjs-lib and zmqpubrawblock on the backend, socket.io to chuck it out (for easier websockets),
 2 2017-08-25 03:43:20 <cluelessperson> Question, What's preventing testnet from being reset anyway?
 3 2017-08-25 03:54:15 <Emcy> nothing? They did it before
 4 2017-08-25 09:33:38 <juscamarena> I wish it was reset, too damn long/big
 5 2017-08-25 09:34:35 <waxwing> +1e100
 6 2017-08-25 09:35:08 <arubi> maybe this time with some rule that makes utxo "decay" so they become anyone-can-spend after some time unused
 7 2017-08-25 14:16:11 <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?
 8 2017-08-25 15:59:08 <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?
 9 2017-08-25 16:08:00 <arubi> coin_trader, core doesn't support recovery at all at the moment afaik
10 2017-08-25 16:08:29 <coin_trader> hmm that's what i thought, but seems kinda ... short-sighted? i figured i just was doing something wrong.....
11 2017-08-25 16:08:33 <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
12 2017-08-25 16:09:05 <coin_trader> right, i would need to run a loop for X times to addwitnessaddress(getnewaddy()) type of thing right?
13 2017-08-25 16:09:23 <coin_trader> so then the wallet "knows" all the segwit addy, and i may even need to rescan the wallet ,right?
14 2017-08-25 16:09:25 <arubi> right.  it's pretty difficulty handling recovery on bip32 wallets that aren't using public derivation
15 2017-08-25 16:09:52 <coin_trader> eh whatcha mean? i have a skeleton of that same HD wallet when it was first created
16 2017-08-25 16:10:14 <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
17 2017-08-25 16:10:20 <coin_trader> but not yet for segwit...
18 2017-08-25 16:10:33 <arubi> yea, but you had to have the wallet unlocked the whole time right?
19 2017-08-25 16:10:37 <coin_trader> sure
20 2017-08-25 16:11:04 <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?
21 2017-08-25 16:11:41 <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
22 2017-08-25 16:11:45 <arubi> (if you wouldn't use the loop)
23 2017-08-25 16:12:10 <arubi> sure sure, that's why I think it's not pretty yet
24 2017-08-25 16:12:26 <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
25 2017-08-25 16:12:41 <coin_trader> but that's cuz i have access to full data dir on servers that can talk to each other
26 2017-08-25 16:13:15 <coin_trader> do you know if 0.15 will support proper generation of segwit addy & balance from a "reloaded" HD wallet?
27 2017-08-25 16:13:57 <arubi> not sure really
28 2017-08-25 16:17:45 <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"
29 2017-08-25 16:21:28 <arubi> huh.  I never saw that happening.  what's your setup?
30 2017-08-25 16:35:09 <wallet42> bitcoind -regtest -printtoconsole -debug=bench -port=18444
31 2017-08-25 16:35:17 <wallet42> bitcoind -regtest -datadir=/tmp/3 -printtoconsole -debug=bench -listen=0 -rpcport=38332 -addnode=127.0.0.1:18444
32 2017-08-25 16:38:51 <arubi> and you've generated blocks with the first one, and the second one's debug.log is saying "ignoring headers..." ?
33 2017-08-25 16:39:09 <wallet42> jup
34 2017-08-25 16:39:32 <arubi> did you try restarting the second one?
35 2017-08-25 16:39:44 <wallet42> many times
36 2017-08-25 16:39:49 <wallet42> its weird
37 2017-08-25 16:39:59 <arubi> getpeerinfo says they're both connected?
38 2017-08-25 16:40:01 <wallet42> i created 2 complete new installations
39 2017-08-25 16:40:06 <wallet42> there it works
40 2017-08-25 16:40:10 <arubi> hm
41 2017-08-25 16:40:13 <wallet42> but i was working with 1 node regtest
42 2017-08-25 16:40:19 <wallet42> and have quite a blockchain there now
43 2017-08-25 16:40:29 <wallet42> and wanted to do bench testing on importing
44 2017-08-25 16:40:36 <wallet42> from sencond node
45 2017-08-25 16:40:53 <wallet42> but the old node is just refusing to not be in IBD mode
46 2017-08-25 16:41:34 <wallet42> anyway i guess i just recreate it all
47 2017-08-25 16:41:39 <wallet42> thanks anyway
48 2017-08-25 16:41:47 <arubi> yea I'm not sure what's wrong.  np
49 2017-08-25 16:43:35 <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
50 2017-08-25 18:50:28 <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?
51 2017-08-25 18:50:52 <coin_trader> only way would be with rawtx (which i'm looking to avoid at all costs)
52 2017-08-25 18:57:02 <CryptAxe> If you aren't sending the change to a lightning channel or something, you probably want it to be a "legacy" output
53 2017-08-25 20:37:15 <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.....