--- Day changed Mon Oct 23 2017
00:29 -!- delinquentme [~delinquen@108-235-112-153.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 258 seconds]     
00:41 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
00:47 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
01:24 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has quit [Quit: Page closed]     
01:43 -!- delinquentme [~delinquen@108-235-112-153.lightspeed.sntcca.sbcglobal.net] has joined #joinmarket     
01:46 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has joined #joinmarket     
03:21 -!- wxss [~chatzilla@109.163.234.139] has joined #joinmarket     
03:38 -!- wxss [~chatzilla@109.163.234.139] has quit [Ping timeout: 240 seconds]     
03:43 -!- wxss [~chatzilla@184.75.212.38] has joined #joinmarket     
04:26 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #joinmarket     
05:25 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
05:28 -!- quitobro_ [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #joinmarket     
05:29 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
05:29 -!- quitobro_ is now known as quitobro     
06:22 -!- pigeons_ [~quassel@94.242.209.214] has quit [Remote host closed the connection]     
06:28 < trotski2000> hi guys, how do i stop and restart a tumble schedule with joinmarket-qt? Do I just need to click abor, and then next time JM simply detects that I interrupted a schedule and askes me to continue from where I left it?
08:40 < quitobro> waxwing: so i have identified 1 transaction in my wallet history which is causing the `wallet-tool.py history` to throw an IndexError...
08:40 < quitobro> this transaction has no `ins`…
08:40 < quitobro> i think this means it thinks the tx has no unspent inputs?
08:41 < quitobro> when i query my full node using rcp `gettransaction <tx-hash>`
08:41 < quitobro> it has an amount of 0.0
08:42 < quitobro> that’s “zero point zero” or just 0
08:42 < quitobro> ha     
08:43 < quitobro> belcher: does this sound like something JM does, i.e. creating txs with amounts equal to 0? i can give u the tx hash if you want to query it, altho that may be terrible for my wallet’s privacy...
08:51 < quitobro> arubi: perhaps you can weigh in here… :)
08:57 < GithubBot5678> [joinmarket] mecampbellsoup opened pull request #763: Catch IndexError when deserializing wallet transactions (master...wallet-history-index-error) https://git.io/vdxXL
09:12 < quitobro> PSA: anyone who is working on the JM code, be sure to set your joinmarket.cfg’s `console_log_level = DEBUG`
09:12 < quitobro> lots of helpful output compared to just INFO
09:14 < Sentineo> I think there is a log file in the logs that has debug there
09:14 < Sentineo> it seems that in the console there is info, but the log has debug, I might be wrong though
09:23 < belcher> quitobro i highly doubt its amounts equal to zero, its probably the history code showing zero because it believes none of the outputs and/or inputs belong to its wallet
09:24 < quitobro> belcher: when i use the gettransaction rpc command, my node tells me `amount: 0.00000000`
09:24 < quitobro> Sentineo: yea i think that’s correct but i find it helpful to see debug output at runtime
09:24 < belcher> is that an output amount? or just a bitcoin-qt internal label
09:24 < belcher> transactions with amount=0 are non-standard and dont propagate
09:25 < quitobro> belcher: it’s the amount key in the hash returned by `gettransaction`
09:25 < belcher> maybe put the txid into a blockchain explorer?
09:25 < quitobro> hash meaning object
09:25 < arubi> do `decoderawtransaction <hex>`
09:25 < arubi> see what the amounts show there
09:25 < belcher> that works too
09:27 < quitobro> arubi: this returns a list of UTXOs? i don’t see any amount key, rather value
09:27 < quitobro> there are 2 lists, vin and vout
09:27 < arubi> yea, that vout has an amount
09:28 < arubi> well, each vout in the list
09:28 < quitobro> arubi: so those vouts’ values are non-zero indeed
09:28 < arubi> yea, the one 'gettransaction' returns is what the wallet believes you paid \ were paid
09:29 < arubi> also, remind me please if you're using a pruned node?
09:29 < quitobro> arubi: i am
09:29 < arubi> you have to do -rescan , you can't do that with a pruned node
09:29 < quitobro> why do i have to rescan?
09:30 < Sentineo> -rescan is not supported on a pruned node
09:30 < Sentineo> you have to do -reindex
09:30 < arubi> to let the wallet pick up on the transactions that happened after you replaced the wallet.dat
09:30 < quitobro> i very recently reindexed
09:30 < arubi> reindex does nothing related to wallet
09:30 < arubi> and even less on a pruned node
09:31 < quitobro> so the theory here is that my node is just unaware of what happened to this particularu transactions, hence an empty `ins` list?
09:31 < Sentineo> seems so
09:32 < Sentineo> it is not tracking that tx
09:32 < Sentineo> well you can give -rescan a try
09:32 < arubi> see `bitcoind --help | grep prune -A6`  bitcoind doesn't support txindex or rescan when pruned
09:32 < arubi> so issueing -reindex does absolutely nothing
09:32 < Sentineo> right
09:32 < Sentineo> that is not true
09:32 < arubi> also, if you didn't wait for like a day or so for reindexing, surely it didn't reindex
09:32 < Sentineo> -reindex does rescan as well
09:32 < arubi> on a pruned node
09:32 < Sentineo> yes     
09:32 < Sentineo> well it will start downloading the blockchain again :)
09:33 < Sentineo> and that is written to the wallet.dat
09:33 < arubi> that probably won't happen if prune=... is set
09:33 < Sentineo> if you copy an older wallet.dat while it is doing reindex it will ask you to do again
09:33 < Sentineo> what will not happen?
09:33 < Sentineo> I did -reindex several times
09:33 < arubi> are you setting prune=... ?
09:33 < Sentineo> it does redownload the blockchain (and prune it of course)
09:33 < Sentineo> yep     
09:34 < Sentineo> prune=550
09:34 < Sentineo> on my node at home
09:34 < arubi> why do think it's indexing anything at all?
09:34 < arubi> `bitcoind --help | grep prune -A6`
09:34 < Sentineo> cause I saw it happen? :)
09:35 < arubi> how long did it take to reindex
09:35 < arubi> ?     
09:35 < Sentineo> 5 days
09:35 < Sentineo> when syncing from a local lan 8 hours
09:35 < Sentineo> with the data dir in tmpfs, and assumevalid=<latest block hash>
09:36 < Sentineo> I have 2 pruned nodes
09:36 < arubi> so, you believe your node now holds a full txindex while being pruned?
09:36 < Sentineo> they have the same wallet.dat - I was out of sync (did not see labels)
09:36 < arubi> txindex has nothing to do with the wallet
09:36 < arubi> it's literally just an index of all transactions
09:36 < Sentineo> so I copied the wallet.dat from the 1st node (that was more than 1000 blocks ahead) and the 2nd refused to start with that wallet.dat
09:37 < Sentineo> -reindex is not txindex
09:37 < Sentineo> there are 2 separate things, right?
09:37 < arubi> reindex is what you do to reindex txindex
09:37 < Sentineo> that is true, but they are not the same
09:37 < arubi> rescan is what you do to rescan the wallet's transactions
09:38 < Sentineo> txindex is a separate db, while reindex creates block indexes as well
09:38 < Sentineo> while creating the indexes for blocks you rescan the blockchain
09:38 < Sentineo> I was asking gmaxwell when I had that issue, I recall this is what he sad
09:38 < Sentineo> I might be wrong
09:38 < arubi> again, why issue reindex if you just want to rescan?
09:38 < Sentineo> but than my wallet would not have been fixed after reindexing on a pruned node
09:38 < Sentineo> for rescan you need all blocks
09:39 < Sentineo> a pruned node does not have all blocks
09:39 < Sentineo> so it can not do rescan
09:39 < arubi> I know it can't.  but you wanted rescan, so why did you use reindex
09:39 < arubi> ?     
09:39 < arubi> (sorry my ? key is stuck)
09:39 < Sentineo> :) that is what I am saying
09:39 < Sentineo> reindex does do rescan
09:39 < Sentineo> look at the wallet.dat while reindex is happening
09:40 < Sentineo> it is changing
09:40 < arubi> magically, it can do rescan on a pruned node?
09:40 < Sentineo> perhaps if the pruned flag is done it does do scanning
09:40 < arubi> done?
09:40 < Sentineo> I ment set
09:41 < Sentineo> I do not know why I wrote done :D
09:41 < arubi> if the pruned flag is set, so that means that the node is pruned, correct?
09:41 < Sentineo> it happens sometimes I think one word, write down a completely different one :P 
09:41 < Sentineo> arubi: right
09:41 < arubi> a pruned node can not do -rescan, correct?
09:41 < Sentineo> my nodes that I am talking about had prune=550 in the config
09:41 < Sentineo> yes it can not do rescan 
09:41 < arubi> -reindex is *some thing* + -rescan, correct?
09:41 < Sentineo> yes     
09:42 < Sentineo> that is how I understand it
09:42 < arubi> so a pruned node can't do -reindex ?
09:42 < Sentineo> it can do reindex
09:42 < arubi> hmm     
09:42 < Sentineo> just not rescan
09:42 < Sentineo> cause rescan needs all blocks
09:42 < arubi> and reindex doesn't?
09:42 < Sentineo> reindex = reindex + rescan :) so you provide all blocks for rescan by reindexing (cause you start syncing from scratch)
09:43 < arubi> here's what bitcoind -help says about -rescan : "Rebuild chain state and block index from the blk*.dat files on disk"
09:43 < Sentineo> of course reindex does not
09:43 < Sentineo> reindex does create the index and blk*dat files
09:43 < Sentineo> so rescan can not work if there are blk*dat files from the genesis block
09:43 < arubi> reindex creates the block files?
09:44 < Sentineo> yes     
09:44 < quitobro> definitely
09:44 < arubi> makes 0% logic to me
09:44 < Sentineo> or better to say if it finds a block is missing it gets it from a peer
09:44 < quitobro> it reindexes the blocks in chainstate dir
09:44 < arubi> the blk* files are the files containing blocks
09:44 < arubi> but you don't have the blocks
09:44 < arubi> you are a pruned node
09:44 < quitobro> arubi: you do have blocks
09:44 < Sentineo> created blk*.dat, creates index, creates chainstate db entry, creates rev*.dat
09:44 < quitobro> just n blocks, not all of them
09:44 < Sentineo> arubi: did you run a pruned node?
09:45 < Sentineo> arubi: you have minimum 550 blocks 
09:45 < arubi> I didn't
09:45 < arubi> I know what a pruned node is
09:45 < Sentineo> so it is like a sliding window
09:45 < quitobro> Sentineo: no, you have 500MB worth of blocks :)
09:45 < quitobro> 550*
09:45 < arubi> you have 550mb of blk* files, and the complete chainstate
09:45 < Sentineo> right
09:46 < arubi> to rescan, reindex, whatever, you need the complete chain
09:46 < Sentineo> but when you do reindex it starts from block 1
09:46 < arubi> but you don't have that block
09:46 < Sentineo> and unlink all blocks
09:46 < Sentineo> and just starts over
09:46 < quitobro> arubi: reindex just wipes chainstate and starts rebuliding it afaik
09:46 < arubi> sigh
09:46 < Sentineo> quitobro: that is what reindex-chainstate does
09:47 < quitobro> i meant blocks/ dir then
09:47 < arubi> folks, indexing \ reindexing \ rescanning makes 0 sense to me on a pruned node.  reindex specifically uses the block files form disk.  if they're missing, what does it reindex?
09:47 < arubi> it doesn't rebuild them, it rebuilds the txindex from the block files
09:47 < arubi> to get the block files again you will have to download them 
09:47 < Sentineo> the blk files are built by the node, too while downloading blocks from peers
09:47 < Sentineo> right
09:47 < Sentineo> and that is what is happening
09:48 < Sentineo> when you do reindex on a pruned node
09:48 < Sentineo> it starts getting block 1,2,3 ... 
09:48 < Sentineo> building the chainstate again, scanning txes for the wallet, etc
09:48 < arubi> yea, it doesn't rebuild the block files, it downloads them from peers
09:48 < Sentineo> well nope
09:48 < Sentineo> that is what I learned today :P
09:48 < Sentineo> blk files are created by the node
09:49 < arubi> sure, the files are created on the host computer
09:49 < arubi> Sentineo, what I mean is, the data to create them is downloaded from other nodes
09:49 < Sentineo> there is no give me blk file p2p message, there is a give me a block message
09:49 < arubi> of course not
09:49 < Sentineo> arubi: yep yep
09:50 < Sentineo> so it takes a looot of time to do a "rescan" on the pruned node, as it is redownloading all blocks again (you force it to do so by doing -reindex)
09:50 < arubi> calling it a pruned node at that stage is very misleading
09:50 < Sentineo> why?
09:50 < Sentineo> it still is sliding
09:51 < Sentineo> so is pruning blocks on the go
09:51 < Sentineo> it will not keep all the blocks
09:51 < arubi> I'm not saying it's not pruning, but you might as well nuke the whole directory, and resync a pruned node
09:51 < Sentineo> right
09:51 < Sentineo> the same effect
09:51 < arubi> I don't see the value in -reindex on a pruned node
09:52 < Sentineo> well if you have only a pruned node and your wallet got somehow out of sync, but have no spare space on hdd , what would you suggest doing?
09:52 < arubi> backup the wallet, nuke the datadir, resync
09:52 < Sentineo> nuking the datadir is kind of a nightmare - as you can accidentaly delete the wallet.dat file
09:52 -!- wxss [~chatzilla@184.75.212.38] has quit [Ping timeout: 248 seconds]     
09:52 < Sentineo> well it is the same thing done you just do a bitcoind -reindex
09:53 < Sentineo> much more convenient
09:53 < Sentineo> the effect is the same of course
09:53 < arubi> alright, I'll agree to that.  quitobro, until you rescan \ resync \ reindex \ whatever, your wallet will show wrong history which will confuse jm
09:54 < quitobro> arubi: the thing is, i had *just* done a reindex…
09:54 < arubi> how long did it take?
09:54 < quitobro> i do not understand what JM is getting confused by
09:54 < quitobro> um about 2 days
09:54 < Sentineo> did you create jm before or after?
09:55 < quitobro> i created a new wallet after
09:55 < arubi> sigh
09:55 < arubi> quitobro, the first thing jm tells you after creating a wallet is..  rescan, right?
09:56 < Sentineo> would be nice if you could try it on a full node (not pruned)
09:56 < Sentineo> arubi: does it?
09:56 < arubi> yes     
09:56 < Sentineo> than yeh, you have to -reindex after creation :D
09:56 < Sentineo> soooo it is as if you did nothing quitobro ...
09:56 < Sentineo> arubi: I might have not noticed it as I am using a full node
09:57 < Sentineo> for that jm instance
09:57 < arubi> it also makes perfect sense, the core wallet can't know to look for jm watchonly addresses /before/ jm does the importwatchonly to it
09:58 -!- StopAndDecrypt__ [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #joinmarket     
09:59 < Sentineo> yeah indeed
09:59 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Ping timeout: 252 seconds]     
09:59 < arubi> sorry for sighing so much, I just got back from work.  so many hours trying to fix an old, huge, and messy git repo
09:59 < arubi> my brain is fried :)
10:00 < Sentineo> yeah I was tired too
10:00 < quitobro> arubi: can i try your previous suggestion of `getrawtransaction` or whatever that was?
10:01 < quitobro> to tell the wallet to update its info about a particular tx
10:01 < Sentineo> they got me to travel 150km to be on a stupid meeting which took 15 minutes, had to wake up at 5am for that
10:01 < Sentineo> than started reading indexd and now I feel fine :P
10:01 < arubi> haha
10:01 < arubi> quitobro, getrawtransaction is an indexing node's function
10:01 < Sentineo> it works for your txes
10:01 < arubi> quitobro, do you still have the raw hex transaction?
10:02 < quitobro> ya     
10:02 < arubi> but it isn't his, it's not in his watchonly
10:02 < Sentineo> but again core has not way of knowing your txes
10:02 < arubi> alright, take that hex and `bitcoin-cli sendrawtransaction <hex>`
10:03 < quitobro> ‘transaction already in block chain'
10:03 < arubi> nice, now do `gettransaction <hex>`
10:03 < arubi> see if the amount says something that makes sense now
10:03 < quitobro> arubi: you meant <id> not <hex> right
10:03 < arubi> yea, txid, right
10:03 < quitobro> still says 0 amount
10:04 < quitobro> fack i guess i need to reindex *again*
10:04 < quitobro> i should just not prune… do u guys run nodes on local machines or remote instances?
10:04 < arubi> local
10:04 < quitobro> how big is the blockchain these days?
10:05 < Sentineo> I have 5 nodes
10:05 < Sentineo> 2 pruned local, 3 remote
10:05 < Sentineo> but not VPS
10:05 < arubi> 150gb~
10:05 < Sentineo> my servers, just not at home :)
10:05 < quitobro> not VPS? oh ok
10:05 < quitobro> so either i should run on my laptop for the time being, or buy dedicated server...
10:05 < arubi> brb     
10:05 < Sentineo> ah and I have one unpruned local as well
10:05 < Sentineo> syncing it 1x per month
10:06 < Sentineo> just cause had to do reindex several times (I screwed some things)
10:06 < quitobro> Sentineo: why syncing once a month?
10:06 < Sentineo> cause it is an external hdd
10:06 < Sentineo> do not like having it connected to my laptop
10:06 < quitobro> so your node’s data is all stored on the external hdd?
10:06 < Sentineo> I have a backupday every month, so that days is when I attach that disk as well
10:06 < Sentineo> the blockchain only
10:07 < Sentineo> that one has no wallet 
10:07 -!- wxss [~chatzilla@184.75.212.38] has joined #joinmarket     
10:19 < arubi> anyway, the point is that -rescan is not always needed because when you create an actual new jm wallet, simply importing without rescanning is enough because there are no past transactions to find on the chain
10:20 < arubi> but for recovery it is very much needed
10:23 < arubi> waxwing, awesome presentation.  did the QA part at the end got cut off on a specific question or did you just not answer it?
10:30 < Sentineo> which presentation?
10:30 < arubi> https://www.youtube.com/watch?v=IKSSWUBqMCM
10:31 < arubi> it starts 40 minutes in
11:12 -!- delinquentme [~delinquen@108-235-112-153.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 264 seconds]     
11:48 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has quit [Quit: Page closed]     
12:55 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has joined #joinmarket     
12:59 -!- delinquentme [~delinquen@107-138-44-219.lightspeed.sntcca.sbcglobal.net] has joined #joinmarket     
13:03 < delinquentme> jm-cs and joinmarket "classic" are essentially segwit and non-segwit respectively?
13:04 < delinquentme> belcher waxwing adlai FYI the difference between segwit and non for newbies is an order of magnitude more for segwit
13:05 < delinquentme> You guys probs know this =] But yeah. thats kinda huge
13:10 < waxwing> arubi, oh i didn't watch it all, just checked the start to see if it was hearable/watchable. I'll double check the end.
13:11 < waxwing> delinquentme, i didn't quite get it. what's an order of magnitude different?
13:11 < delinquentme> 10x     
13:11 < delinquentme> the differences between segwit and non
13:11 < delinquentme> tumbling
13:11 < waxwing> 10x difference in what though?
13:12 < arubi> was a question about integrating jm into a wallet \ service from the host I believe
13:12 < arubi> it seemed like it was cut without an answer so I was interested to know :)
13:13 < waxwing> arubi, hmm yeah i just clicked to the end i hear "so thank you very much" .. that was the end right? oh yeah i vaguely remember i think there was one question unanswered, i think maybe just confusion.
13:13 < delinquentme> oh the minimum btc needed in wallets to make the tumbler run
13:13 < arubi> ah it a bit before that
13:13 < arubi> not the very end, I'll see if I can spot it
13:14 < waxwing> delinquentme, oh ok. maybe it's just a question of what kind of bots are running. maybe an interesting practical point though, could be worth investigating.
13:15 < delinquentme> can jm-cs be run a non-segwit?
13:15 < delinquentme> or should I just install joinmarket vanilla?
13:15 < waxwing> arubi, fun fact the guy doing the video recording is a joinmarket user :)
13:15 < arubi> keeping it in the family :)
13:15 < waxwing> delinquentme, yes the pre-0.3.0 version of jm-cs can be run for non-segwit but forgive me if i don't want to help out on that any more
13:16 < delinquentme> waxwing, yeah as thats outdated ... correct?
13:16 < waxwing> (in the sense that there were quite a few changes going into 0.3.0 so it's kinda not the same and a bit confusing)
13:16 < arubi> 1:26:03 is where the q from the host starts
13:17 < arubi> maybe he's asking murch, not clear
13:17 < waxwing> arubi, do you want me to answer the question? oh ok i'll take a listen
13:17 < arubi> it's like the answer is completely cut off, it's weird so I'm very curious :)
13:18 < waxwing> no, it's as it seems. he asked it and somehow someone got the mike and probably didn't listen to him, and just asked another question.
13:19 < arubi> that makes a lot more sense, the video isn't chopped or anything
13:19 < waxwing> he did ask to both but of course it was really more for me, anyway the answer's basically no although there was interest about a year ago
13:19 < trotski2000> hi guys
13:19 < arubi> very interesting
13:20 < trotski2000> how to solve the "could not find orders to complete transaction" error?
13:20 < waxwing> maybe run ob-watcher.py script locally and check the orderbook as it is right now and see if your amounts are in a range that the necessary number of bots can fulfill
13:21 < waxwing> i mean, just first thought, could be something else more weird going on
13:21 < arubi> thanks waxwing ^
13:21 < waxwing> arubi, sure. i have another weird coinjoin idea now (separate from that stuff), writing it up at the moment.
13:21 < waxwing> thinking about noninteractive coinjoin, one of our old topics :)
13:22 < arubi> good :), maybe finally it'll be solved
13:23 < trotski2000> waxwing: yes, the amounts are definitely in the offered range. i just checked
13:23 < arubi> I'm also taking some notes, recent attack threats have made on chain contracts' property of being replayable at a later time while still final in terms of signers might be useful..
13:25 < waxwing> trotski2000, hmm i would say 'check that you're connecting ok to irc', but that can't be it, since the script refuses to start if it can't connect
13:25 < trotski2000> waxwing: yeah, it connects correctlyt
13:25 < trotski2000> trying again...
13:25 < waxwing> arubi, yeah there's a whole interesting topic about joinmarket and forks (especially non-replay-protected), i only briefly thought about it
13:26 < waxwing> trotski2000, maybe there is some other error before the 'no orders' error. set console_log_level to DEBUG in joinmarket.cfg
13:27 < arubi> the gist is, some how have these tx graphs in temporary external blocks, for the duration of the attack, a bit different coinbase tx and header but same rules otherwise (maybe different pow?), and uasf into "these temporary blocks from 3 months ago now must be replayed on chain in full",  we'll see if it ends up making sense :)
13:28 < arubi> the hard part is handling fees from transactions in that case because they can't go into mainnet output, since mainnet can't contain transactions
13:29 < arubi> so maybe something like, commit to this mainnet block coinbase output, the fees in op return or something, then make replaying that same block over it paying the same miner from 3 months ago
13:30 < waxwing> arubi, maybe mention in #bitcoin-forks eh. my first impression is that asking for a soft fork is maybe too far?
13:30 < arubi> oh yea, no jm\cs related, just using the graph construction :)
13:30 < arubi> for this specific attack, did you see issue #135 on btc1 repo?
13:31 < arubi> but yea you're right, #-forks
13:32 < arubi> by graph construction I do mean the on chain contracts, only they're off chain for that time (just to be clear about it)
14:08 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
15:20 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
15:26 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 1.9.1]     
15:26 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
15:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
15:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
15:58 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Quit: (┛◉Д◉)┛┻━┻]     
16:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
17:26 -!- delinquentme [~delinquen@107-138-44-219.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 248 seconds]     
18:05 < quitobro> Sentineo: re: where to put full node, what about putting blockchain only on an external HD? is it too slow reading/writing all the time from a disc that’s separate from where the node is running?
19:38 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Quit: quitobro]     
19:38 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #joinmarket     
19:44 -!- wxss [~chatzilla@184.75.212.38] has quit [Remote host closed the connection]     
21:04 -!- proslogion [~proslogio@45.116.80.169] has joined #joinmarket     
21:48 -!- proslogion [~proslogio@45.116.80.169] has quit [Ping timeout: 240 seconds]     
22:07 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Quit: quitobro]     
22:14 -!- proslogion [~proslogio@45.116.80.169] has joined #joinmarket     
23:11 < proslogion> :)     
23:34 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket