--- Log opened Sun Aug 05 00:00:31 2018
00:46 -!- windsok [~windsok@unaffiliated/windsok] has joined #bitcoin-core-dev
02:29 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
02:29 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
02:39 -!- pkx1 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev
02:50 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:51 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
02:55 -!- zivl [~zivl@2601:19a:837f:e4e1:5ca:3ef4:dd29:6706] has joined #bitcoin-core-dev
02:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
03:21 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has quit [Read error: Connection reset by peer]
03:25 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has joined #bitcoin-core-dev
03:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:52 -!- rls [~rls@192.96.205.163] has quit [Ping timeout: 256 seconds]
03:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:20 -!- pkx1 [~pkx@unaffiliated/pkx] has quit [Remote host closed the connection]
04:34 -!- var-g [~ayy@unaffiliated/var-g] has joined #bitcoin-core-dev
04:35 -!- ken2812221 [~User@180.217.182.131] has quit [Ping timeout: 268 seconds]
04:36 -!- ken2812221 [~User@180.217.138.248] has joined #bitcoin-core-dev
05:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:15 -!- zivl [~zivl@2601:19a:837f:e4e1:5ca:3ef4:dd29:6706] has quit [Ping timeout: 260 seconds]
05:19 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
05:20 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
05:33 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has quit [Read error: Connection reset by peer]
05:36 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has joined #bitcoin-core-dev
05:47 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Quit: .]
05:54 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
06:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
06:05 -!- devmob [~devmob@31.154.168.166] has joined #bitcoin-core-dev
06:05 < devmob> hi everyone
06:05 < devmob> anyone here I can talk to about bitcoin's p2p layer ?
06:06 < devmob> dns seeds, peer discovery and so on..
06:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
06:40 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
06:46 -!- lnostdal__ is now known as lnostdal
06:49 -!- michaelsdunn1 [~michaelsd@c-67-175-46-140.hsd1.il.comcast.net] has joined #bitcoin-core-dev
07:00 -!- michaelsdunn1 [~michaelsd@c-67-175-46-140.hsd1.il.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
07:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
07:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:44 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds]
07:50 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev
07:56 < grubles> ask your question :P
08:11 -!- zivl [~zivl@2601:19a:837f:e4e1:fc5b:b254:dfa8:1d54] has joined #bitcoin-core-dev
08:24 < wumpus> devmob: yes, sure, ask ahead
08:25 < wumpus> depending on how technical the question is, #bitcoin might be a better place to ask if it's about high-level concepts and not implementation
08:31 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has joined #bitcoin-core-dev
09:14 -!- devmob [~devmob@31.154.168.166] has quit [Remote host closed the connection]
09:14 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
09:15 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
09:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
09:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
09:26 -!- Amuza [~amuza@93.176.180.166] has joined #bitcoin-core-dev
09:29 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
09:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
09:42 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
09:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
09:43 -!- Arokh [~Arokh@extknot.com] has quit [Ping timeout: 256 seconds]
09:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
09:50 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
09:58 -!- str4d [~str4d@27.37.99.195.dyn.plus.net] has joined #bitcoin-core-dev
10:01 -!- str4d [~str4d@27.37.99.195.dyn.plus.net] has quit [Client Quit]
10:41 -!- Amuza [~amuza@93.176.180.166] has quit [Ping timeout: 268 seconds]
10:49 < jl2012> is it possible to return the index of a tx in a block, using getrawtransaction with -txindex?
10:50 < gmaxwell> jl2012: the interface doesn't do that, but the data is there and it could.
10:50 < gmaxwell> jl2012: the txindex tells the node what block the tx is in, it reads the whole block to give the result.
10:51 < jl2012> gmaxwell: should I look at GetTransaction() ?
10:51 < sipa> yes
10:51 < sipa> the index also has the position, i think
10:51 < gmaxwell> oh it does? hm.
10:52 < sipa> ah no, it has the byte offset w.r.t. the block position
10:52 < jl2012> CDiskTxPos postx is the byte offset?
10:53 < sipa> right
10:54 < wumpus> yes also checked, it only has the byte index
10:54 < jl2012> is it possible to turn this into the tx index?
10:54 < sipa> ?
10:55 < sipa> what do you need it for?
10:55 < jl2012> I have some txids and need to know their order in the chain
10:55 < gmaxwell> well if you only need to know their order, ... 
10:56 < wumpus> only if you'd read the entire block from disk, and parse that, you can figure out what the transaction index in the block is
10:56 < wumpus> then byte index will work just as well
10:56 < gmaxwell> well   block number || byte offset in the block    gives you the ordering of transactions.
10:57 < wumpus> yes
10:57 < jl2012> yes, that's enough for my purpose. Do you think it's a good idea to return the byte order in getrawtransaction?
10:58 < sipa> i think getrawtransaction should just return the raw transaction
10:59 < jl2012> sipa....yeah....but we could have a different name for that....
10:59 < gmaxwell> jl2012: we probably shouldn't return anything that is implementation dependant unless we have a good reason.
10:59 < jl2012> gmaxwell: yes, that's why I wonder if I could get the tx index
10:59 < gmaxwell> E.g. we shouldn't add things to our API that would get in the way of changing to a better txindex or block storage design, unless there is a clear reason.
11:00 < wumpus> at least if you do it, return the byte index relative to the block, not to the file start
11:00 < wumpus> otherwise it'll be used to directly seek into the block files, it was tried before to add block filename/offsets to getblock and rejected for the same reason
11:01 < gmaxwell> even that, for example we know that it's possible to store txn a lot more compactly than we do, and save maybe 25% of block storage. If we switch to storing blocks that way, those numbers either all change around or to keep them the same we'll have to store extra data or reseralize the block to return a result. :)
11:02 < wumpus> gmaxwell: what if we add a warning to only use it as opaque ordering token
11:02 < wumpus> don't call it byte offset
11:03 < sipa> it's also not available for mempool txn
11:03 < wumpus> unless that would reorder the transactions as well of course
11:03 < wumpus> for the mempool it certainly wouldn't make sense, what would offset into the mempool even mean
11:03 < gmaxwell> wumpus: that would be fine.  Nah, using a more efficient serialization wouldn't reorder anything.
11:04 < gmaxwell> wumpus: (uint64)txn* :P
11:04 < jl2012> gmaxwell: and the order itself is consensus-critical so you need to store it somehow
11:05 < sipa> jl2012: consensus enforcement doesn't even require storing the blocks at all :)
11:05 < sipa> let alone an index
11:06 < sipa> and more practically, it would not be outrageous i think to store the entire block by gzipping it in its entirety, at which point there is no more per-tx access possible
11:07 < sipa> (i'm not actually suggesting this; we can do much better than that without giving up the ability to access txn individually)
11:07 < wumpus> you'd still need an the offset after unzipping
11:07 < wumpus> to retrieve it
11:07 < gmaxwell> jl2012: to serve up old blocks we need to be able to recover the order, that doesn't necessarily mean that it's easily accessible at random. :)
11:07 < sipa> wumpus: well, only if we care about retaining the ability to find individual txn
11:08 < wumpus> I think some compression algorithms do allow for seeking by storing more decompressor state
11:08 < sipa> wumpus: which is really just to speed up getrawtransaction 
11:08 < wumpus> sure...
11:08 < gmaxwell> wumpus: yes, but in doing so more or less eliminates the gains from compressing things as a unit.
11:08 < sipa> sorry, too many hypotheticals here :)
11:08 < wumpus> anyhow I don't think forever API compatibility is so important for this, if we can't provide it anymore ,drop it then
11:08 < jl2012> sipa: generating SPV proof is also a consensus-critical process
11:09 < gmaxwell> jl2012: unclear what you mean by that.
11:09 < sipa> jl2012: no?
11:09 < sipa> validating of new blocks doesn't need SPV proofs
11:09 < wumpus> gmaxwell: right, and the problem is that the decompressor state can be quite big compared to just a pointer, maybe bigger than the tx itself :-)
11:09 < gmaxwell> The bitcoin protocol doesn't generate SPV proofs for arbritary transactions, it certantly isn't consensus critical to do so! :)
11:10 < gmaxwell> in any case, other than potentially bulk compressing a whole block at a time, I don't see why a "this isn't the size but it is ordered" value would get invalidated.
11:12 < wumpus> right, potentially you could still store it if you want to keep it available on the RPC API, even if you don't *need* it for the index
11:13 < gmaxwell> right, and that would be totally worth doing if there were a known usecase for the interface... :P
11:13 < wumpus> yes...
11:13 < gmaxwell> though at that point, it would probably be best to just store a plain total order number.
11:14 < jl2012> gmaxwell, sipa: maybe I'm using a wrong term.....anyway, I mean the index is critical for a full node to properly function (e.g. serving SPV proof, helping other nodes for IBD)
11:15 < sipa> no it isn't
11:15 < sipa> it's optional
11:15 < sipa> the index isn't even used when helping other nodes IBD
11:15 < sipa> (which on itself is optional)
11:16 < jl2012> sipa: when you transmit a block, you also transmit the index (implicitly)
11:16 < sipa> ah
11:17 < sipa> by index you mean transaction position
11:17 < sipa> not "the txindex database"
11:17 < sipa> sorry!
11:17 < gmaxwell> jl2012: bitcoin core doesn't even serve SPV proofs for arbritary transactions today!
11:18 < gmaxwell> jl2012: and yes, to serve out a block you must be able to recover the order, but that doesn't mean that its stored in a way that allows efficient random access to it.
11:19 < gmaxwell> E.g. we could store groups of blocks 100 at a time, gzipped. We could still serve up access for syncing peers.  But order wouldn't be efficiently accessible for a txindex.
11:20 < gmaxwell> (and any ability to serve a spv proof at all was only added in v0.8 and can be disabled with a commandline flag)
11:20 < gmaxwell> also a full node doesn't even need to have historic blocks at all.
11:21 < gmaxwell> Full node means that it autonomously enforces the consensus rules for itself without trusting third parties to validate, thats it.
11:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
11:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
11:25 < gmaxwell> in any case, all I'm trying to say is just because the data is currently there isn't a reason to expose it in an API. Doing so is a pretty severe api anti-pattern.  The purpose of an interface is to encapsulate complexity. Any time we expose an internal we make it more costly to change in the future.  There are known things people are working on that if they were adopted would change the positio
11:25 < gmaxwell> n values, though they would at least keep them ordered.
11:29 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
11:30 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has joined #bitcoin-core-dev
11:31 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has quit [Client Quit]
11:31 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has joined #bitcoin-core-dev
11:32 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has quit [Client Quit]
11:32 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has joined #bitcoin-core-dev
11:32 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:2d16:6cf7:1f8e:ce21] has quit [Client Quit]
11:37 < jl2012> gmaxwell: I understand your point........could we have some kind of "expert API" that does not guarantee to work in the future? 
11:39 < sipa> what do you need it for? perhaps there are other ways
11:43 < jl2012> sipa: I have some random ordered txids, and want to reconstruct the ledger.
11:43 < jl2012> the ledger of certain addresses
11:45 < jl2012> a dumb way is to call 'getblock' to learn the order.....
11:46 < jl2012> efficiency is not a big issue for me so that's probably good enough
11:46 < jl2012> but there is another problem: I just find that getrawtransaction doesn't return block height!
11:48 < jl2012> only block time and #of confimations.....so I need getblockchaininfo to tell me the current height....
11:48 < roasbeef> jl2012: verbose should, well returns confirmations which you can use to compute the blockheight the tx was incluided in 
11:50 < jl2012> roasbeef: yes, just need to do one more step.....
11:54 < jonasschnelli> jl2012: can't you keep a headers chain in your application and look up the blockhash there?
11:57 < jl2012> jonasschnelli: getrawtransaction provides only "number of confirmation" and "blocktime", but blocktime couldn't be a reliable block index because it is not strictly ordered and might repeat
11:59 < jl2012> jonasschnelli: oh, it also has blockhash
11:59 < jl2012> sorry
12:00 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has quit [Read error: Connection reset by peer]
12:00 < jonasschnelli> Yeah. Just dbl checked: ""  \"blockhash\" : \"hash\",   (string) the block hash\n""
12:04 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has joined #bitcoin-core-dev
12:04 -!- hex17or [~hex17or@2a02:8071:ba7:d300:7c80:1e3a:63fa:228] has joined #bitcoin-core-dev
12:08 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has quit [Ping timeout: 260 seconds]
12:09 -!- hex17or [~hex17or@2a02:8071:ba7:d300:7c80:1e3a:63fa:228] has quit [Ping timeout: 256 seconds]
12:09 < jl2012> thanks everyone......at least I find a way to do it without customized API....
12:12 -!- hex17or [~hex17or@46.5.0.0] has joined #bitcoin-core-dev
12:14 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has joined #bitcoin-core-dev
12:16 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:5406:c036:1b9:1ca0] has joined #bitcoin-core-dev
12:24 -!- Amuza [~amuza@93.176.180.166] has joined #bitcoin-core-dev
12:24 -!- hex17or [~hex17or@46.5.0.0] has quit [Read error: Connection reset by peer]
12:26 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
12:26 -!- hex17or [~hex17or@2a02:8071:ba7:d300:7c80:1e3a:63fa:228] has joined #bitcoin-core-dev
12:30 -!- hex17or [~hex17or@2a02:8071:ba7:d300:7c80:1e3a:63fa:228] has quit [Ping timeout: 256 seconds]
12:33 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
12:55 -!- justan0theruser is now known as justanotheruser
13:00 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:5406:c036:1b9:1ca0] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
13:01 -!- rls [~rls@192.96.205.163] has joined #bitcoin-core-dev
13:11 -!- str4d [~str4d@27.37.99.195.dyn.plus.net] has joined #bitcoin-core-dev
13:20 -!- str4d [~str4d@27.37.99.195.dyn.plus.net] has quit [Quit: Leaving]
13:34 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:55 -!- hex17or [~hex17or@2a02:8071:ba7:d300:7c80:1e3a:63fa:228] has joined #bitcoin-core-dev
14:56 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection]
14:57 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
14:59 -!- hex17or [~hex17or@2a02:8071:ba7:d300:7c80:1e3a:63fa:228] has quit [Ping timeout: 256 seconds]
15:09 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Ping timeout: 264 seconds]
15:09 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
15:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:22 -!- Amuza [~amuza@93.176.180.166] has quit [Ping timeout: 240 seconds]
15:27 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:21cb:cda8:9c4:40d3] has joined #bitcoin-core-dev
15:33 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
15:34 < Chris_Stewart_5> Is there a policy when RPC interfaces change for bitcoind? Does it change for minor version bumps?
15:34 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
15:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.0]
15:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:49 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:21cb:cda8:9c4:40d3] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
16:04 -!- viaj3ro [1f1076dd@gateway/web/freenode/ip.31.16.118.221] has joined #bitcoin-core-dev
16:05 < viaj3ro> have an issue with my 0.16.2 node: https://github.com/bitcoin/bitcoin/issues/13885
16:06 < viaj3ro> need help to try figure out what's causing it
16:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
16:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
16:12 < molz> viaj3ro, maybe shouldn't run the data dir on a USB stick? 
16:14 < viaj3ro> it's not a USB stick. it's my external HDD... it's not like I have a choice. my SSD is only 250GB
16:15 < viaj3ro> chainstate is on my main SSD - so it shouldn't be that much of an issue
16:15 < viaj3ro> it synced within 35 hours on my 10 year old laptop
16:16 < viaj3ro> with those settings
16:17 < viaj3ro> it's known to run fine on a raspberry pi - should be running fine on my hardware...
16:34 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection]
16:34 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
16:36 < viaj3ro> going offline. any help via github is very much appreciated!
16:48 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:06 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
17:13 -!- viaj3ro [1f1076dd@gateway/web/freenode/ip.31.16.118.221] has quit [Quit: Page closed]
17:21 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
17:36 -!- rls [~rls@192.96.205.163] has quit [Ping timeout: 244 seconds]
18:00 -!- var-g [~ayy@unaffiliated/var-g] has quit [Read error: No route to host]
18:00 -!- var-g [~ayy@unaffiliated/var-g] has joined #bitcoin-core-dev
18:07 -!- rls [~rls@192.96.205.163] has joined #bitcoin-core-dev
18:35 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Read error: Connection reset by peer]
18:38 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev
18:38 -!- Krellan [~Krellan@2601:640:4000:9258:8ccd:178:a61d:33ff] has quit [Read error: Connection reset by peer]
18:39 -!- Krellan [~Krellan@2601:640:4000:9258:70af:fd9e:f740:bbce] has joined #bitcoin-core-dev
18:40 -!- instagibbs [~instagibb@pool-100-15-122-172.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]
18:41 -!- instagibbs [~instagibb@pool-100-15-122-172.washdc.fios.verizon.net] has joined #bitcoin-core-dev
18:46 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-nzpvmtgqwchwouny] has joined #bitcoin-core-dev
19:04 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
19:54 < BlueMatt> lol, I appreciate how the freenode spam went from random madeup nonsense to actually-true comments about how freenode was acquired by some incredibly-sketchy folks who are pushing the latest in Dumb ICO (tm)
20:19 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
20:20 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
20:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
20:26 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev
20:27 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
20:50 -!- Krellan [~Krellan@2601:640:4000:9258:70af:fd9e:f740:bbce] has quit [Read error: Connection reset by peer]
20:51 -!- Krellan [~Krellan@2601:640:4000:9258:70af:fd9e:f740:bbce] has joined #bitcoin-core-dev
20:55 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-nzpvmtgqwchwouny] has quit [Quit: Connection closed for inactivity]
21:34 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
21:34 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
21:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
21:46 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
22:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
22:46 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
23:01 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
23:04 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
--- Log closed Mon Aug 06 00:00:32 2018