Transcript for #bitcoin-dev 2017/09/13

01:58 molz Chris_Stewart_5, kanzure does <Chris_Stewart_5> Who moderates the bitcoin dev mailing list?
02:39 ossifrage Any idea why bitcoin-msghand generates quite so much disk read traffic (vs outbound network traffic)?
02:42 ossifrage What option to I need to set to include more of the UTXO in ram vs pulling it off disk?
02:42 gmaxwell ossifrage: the disk traffic is fetching blocks to feed to other peers. All newly recieved blocks are written out and read in again (though this doesn't take that much time due to OS disk caching)
02:44 ossifrage gmaxwell, I'm currently not serving old blocks (the 24 hour limit is reached). The amount of disk read greatly exceeds the amount of network traffic
02:44 ossifrage >128MB in ~60s from bitcoin-msghand
02:46 gmaxwell ossifrage: why are you asking in here instead of #bitcoin-core-dev ?
02:46 gmaxwell (I just noticed the channel)
02:47 ossifrage gmaxwell, ok, will move... Need to collect better data first, it just seems like there is a read amplification someplace...
02:51 gmaxwell ossifrage: sure, there is, in validating blocks it can read a lot more data than the block itself.
02:51 gmaxwell and with compact blocks in use, the blocks themselves are quite small. :)
02:52 gmaxwell though 128MB in 60s is more than I expect for sure.
02:53 ossifrage No new blocks in the sampling window, just inbound txn and minimal network traffic but 100s of MB of read traffic (I assumed due to the incoming txns)
02:54 ossifrage I need to get a clean network usage plus iotop output
02:55 gmaxwell ossifrage: here on a long uptime node with a big dbcache I see 180.15kB/s read (60s average)
02:56 gmaxwell oh wait sorry that was over all uptime. actual number is 114kB/s.
02:56 gmaxwell and that is just an ordinary node plus a testnet node... so sounds like a lot less traffic than you're seeing!
02:57 ossifrage I have the default dbcache, ~16 day uptime and 86 connections...
02:59 ossifrage Since Sept 1, bitcoin-msghand has read 217G and written 2.3G (network is only 8GB rx, 65GB tx)
03:00 ossifrage QThread has read 5.33G and written 90.9G (I'm running bitcoin-qt)
12:44 Chris_Stewart_5 molz: Did you figure out who moderates the list?
12:44 molz Chris_Stewart_5, i asked btcdrak
12:45 Chris_Stewart_5 molz: Cool, thanks! Someone I am working with had their email bounced from the mailing list for some reason.
12:45 Chris_Stewart_5 and it is a high quality email -- not spam
14:27 btcdrak Chris_Steward_5: ask kanzure
15:54 kanzure bouncing is not under my control
15:54 kanzure bouncing is an email protocol problem
19:14 brianhoffman__ anyone know what the estimated release for 0.15.1 is?
19:14 brianhoffman__ it will include full bech32 support correct?
19:31 achow101 brianhoffman__: the release date is still tbd. the stuff for it is still being worked on
19:31 brianhoffman__ ok thank you
19:31 achow101 what will actually go in is also tbd
19:31 achow101 just "segwit wallet stuff"
19:35 gmaxwell This isn't a good channel to ask about bitcoin core features. #bitcoin-core-dev in the future.
19:50 brianhoffman__ oh i have to go one turtle down further from #bitcoin to #bitcoin-dev to #bitcoin-core-dev
21:25 jrick how does fundrawtransaction determine the tx fee/kB to use? (on testnet) i'm seeing it use a fee rate of 0.00020000 when the mempool relay fee is 0.00001000 and there is no user-set fee in the wallet
21:26 jrick a bit disconcerting when you see fees 20x what you expect them to be :)
22:58 iwkse hi, there's a way to log wallet.dat? For example knowing when it receives new keys
22:58 iwkse basically I'm trying to figure out when I should backup that file
23:24 StopAndDecrypt your back up is a snapshot of the wallet at the time you backed it up
23:24 StopAndDecrypt the actual file updates everytime a change is made
23:25 StopAndDecrypt how often you back up is your choice, but as long as you're using HD keys it wont matter
23:26 StopAndDecrypt which you should be if your client relatively up to date (dont know when it was added)
23:29 StopAndDecrypt
23:30 StopAndDecrypt basically as long as you have the seed or the wallet.dat, the client will "look into the future" 1000 keys to see if any of those addresses were used
23:34 iwkse StopAndDecrypt: thanks I will read on the wiki. With seed I guess you mean a paper wallet right?
23:36 StopAndDecrypt i just realized i explained it twice to the same person lol
23:37 iwkse lol
23:37 iwkse I though you wanted to move the discussion on there as it's probably OT here