12018-08-05T00:14:54  *** justanotheruser has quit IRC
  22018-08-05T00:15:52  *** justan0theruser has joined #bitcoin-core-dev
  32018-08-05T00:27:18  *** fanquake has joined #bitcoin-core-dev
  42018-08-05T00:31:35  *** fanquake has quit IRC
  52018-08-05T01:11:10  *** d9b4bef9 has joined #bitcoin-core-dev
  62018-08-05T01:26:27  *** CodeShark has joined #bitcoin-core-dev
  72018-08-05T01:37:02  *** d9b4bef9 has quit IRC
  82018-08-05T01:44:17  *** d9b4bef9 has joined #bitcoin-core-dev
  92018-08-05T01:44:41  *** Krellan has quit IRC
 102018-08-05T01:45:34  *** Krellan has joined #bitcoin-core-dev
 112018-08-05T01:56:55  *** michaelsdunn1 has joined #bitcoin-core-dev
 122018-08-05T02:47:14  *** michaelsdunn1 has quit IRC
 132018-08-05T03:21:10  *** cncr04s has quit IRC
 142018-08-05T03:24:14  *** cncr04s has joined #bitcoin-core-dev
 152018-08-05T03:33:07  *** zivl has quit IRC
 162018-08-05T03:52:27  *** fanquake has joined #bitcoin-core-dev
 172018-08-05T03:54:36  *** Krellan has quit IRC
 182018-08-05T03:54:49  *** fanquake has quit IRC
 192018-08-05T03:55:23  *** Krellan has joined #bitcoin-core-dev
 202018-08-05T04:03:16  *** pkx1 has quit IRC
 212018-08-05T04:12:02  *** achow101 has quit IRC
 222018-08-05T04:23:48  *** achow101 has joined #bitcoin-core-dev
 232018-08-05T05:45:02  *** d9b4bef9 has quit IRC
 242018-08-05T05:46:17  *** d9b4bef9 has joined #bitcoin-core-dev
 252018-08-05T06:04:49  *** Krellan has quit IRC
 262018-08-05T06:05:44  *** Krellan has joined #bitcoin-core-dev
 272018-08-05T06:17:50  *** vicenteH has quit IRC
 282018-08-05T06:18:21  *** vicenteH has joined #bitcoin-core-dev
 292018-08-05T07:46:46  *** windsok has joined #bitcoin-core-dev
 302018-08-05T09:29:15  *** vicenteH has quit IRC
 312018-08-05T09:29:44  *** vicenteH has joined #bitcoin-core-dev
 322018-08-05T09:39:13  *** pkx1 has joined #bitcoin-core-dev
 332018-08-05T09:50:31  *** SopaXorzTaker has joined #bitcoin-core-dev
 342018-08-05T09:51:46  *** SopaXorzTaker has quit IRC
 352018-08-05T09:55:50  *** zivl has joined #bitcoin-core-dev
 362018-08-05T09:56:33  *** SopaXorzTaker has joined #bitcoin-core-dev
 372018-08-05T10:21:15  *** Krellan has quit IRC
 382018-08-05T10:25:45  *** Krellan has joined #bitcoin-core-dev
 392018-08-05T10:45:05  *** AaronvanW has joined #bitcoin-core-dev
 402018-08-05T10:52:08  *** rls has quit IRC
 412018-08-05T10:53:58  *** AaronvanW has quit IRC
 422018-08-05T11:07:47  *** AaronvanW has joined #bitcoin-core-dev
 432018-08-05T11:20:42  *** pkx1 has quit IRC
 442018-08-05T11:34:53  *** var-g has joined #bitcoin-core-dev
 452018-08-05T11:35:57  *** ken2812221 has quit IRC
 462018-08-05T11:36:50  *** ken2812221 has joined #bitcoin-core-dev
 472018-08-05T12:08:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 482018-08-05T12:15:30  *** zivl has quit IRC
 492018-08-05T12:19:01  *** d9b4bef9 has quit IRC
 502018-08-05T12:20:14  *** d9b4bef9 has joined #bitcoin-core-dev
 512018-08-05T12:33:41  *** Krellan has quit IRC
 522018-08-05T12:36:06  *** Krellan has joined #bitcoin-core-dev
 532018-08-05T12:47:43  *** Sentineo has quit IRC
 542018-08-05T12:54:33  *** Guyver2 has joined #bitcoin-core-dev
 552018-08-05T13:01:03  *** Victorsueca has quit IRC
 562018-08-05T13:02:15  *** Victorsueca has joined #bitcoin-core-dev
 572018-08-05T13:05:20  *** devmob has joined #bitcoin-core-dev
 582018-08-05T13:05:30  <devmob> hi everyone
 592018-08-05T13:05:41  <devmob> anyone here I can talk to about bitcoin's p2p layer ?
 602018-08-05T13:06:05  <devmob> dns seeds, peer discovery and so on..
 612018-08-05T13:39:20  *** promag has joined #bitcoin-core-dev
 622018-08-05T13:40:19  *** promag has quit IRC
 632018-08-05T13:46:14  *** lnostdal__ is now known as lnostdal
 642018-08-05T13:49:00  *** michaelsdunn1 has joined #bitcoin-core-dev
 652018-08-05T14:00:27  *** michaelsdunn1 has quit IRC
 662018-08-05T14:28:57  *** Chris_Stewart_5 has quit IRC
 672018-08-05T14:30:02  *** AaronvanW has quit IRC
 682018-08-05T14:37:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 692018-08-05T14:44:05  *** nullptr| has quit IRC
 702018-08-05T14:50:20  *** nullptr| has joined #bitcoin-core-dev
 712018-08-05T14:56:20  <grubles> ask your question :P
 722018-08-05T15:11:47  *** zivl has joined #bitcoin-core-dev
 732018-08-05T15:24:37  <wumpus> devmob: yes, sure, ask ahead
 742018-08-05T15:25:21  <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
 752018-08-05T15:31:30  *** michaelsdunn1 has joined #bitcoin-core-dev
 762018-08-05T16:14:31  *** devmob has quit IRC
 772018-08-05T16:14:52  *** vicenteH has quit IRC
 782018-08-05T16:15:29  *** vicenteH has joined #bitcoin-core-dev
 792018-08-05T16:17:27  *** Chris_Stewart_5 has quit IRC
 802018-08-05T16:21:02  *** d9b4bef9 has quit IRC
 812018-08-05T16:26:24  *** Amuza has joined #bitcoin-core-dev
 822018-08-05T16:29:36  *** Victorsueca has quit IRC
 832018-08-05T16:30:46  *** Victorsueca has joined #bitcoin-core-dev
 842018-08-05T16:42:35  *** vicenteH has quit IRC
 852018-08-05T16:42:35  *** Victorsueca has quit IRC
 862018-08-05T16:43:02  *** Arokh has quit IRC
 872018-08-05T16:43:51  *** Victorsueca has joined #bitcoin-core-dev
 882018-08-05T16:50:28  *** vicenteH has joined #bitcoin-core-dev
 892018-08-05T16:58:22  *** str4d has joined #bitcoin-core-dev
 902018-08-05T17:01:04  *** str4d has quit IRC
 912018-08-05T17:41:38  *** Amuza has quit IRC
 922018-08-05T17:49:17  <jl2012> is it possible to return the index of a tx in a block, using getrawtransaction with -txindex?
 932018-08-05T17:50:23  <gmaxwell> jl2012: the interface doesn't do that, but the data is there and it could.
 942018-08-05T17:50:44  <gmaxwell> jl2012: the txindex tells the node what block the tx is in, it reads the whole block to give the result.
 952018-08-05T17:51:11  <jl2012> gmaxwell: should I look at GetTransaction() ?
 962018-08-05T17:51:16  <sipa> yes
 972018-08-05T17:51:29  <sipa> the index also has the position, i think
 982018-08-05T17:51:36  <gmaxwell> oh it does? hm.
 992018-08-05T17:52:37  <sipa> ah no, it has the byte offset w.r.t. the block position
1002018-08-05T17:52:53  <jl2012> CDiskTxPos postx is the byte offset?
1012018-08-05T17:53:13  <sipa> right
1022018-08-05T17:54:07  <wumpus> yes also checked, it only has the byte index
1032018-08-05T17:54:18  <jl2012> is it possible to turn this into the tx index?
1042018-08-05T17:54:46  <sipa> ?
1052018-08-05T17:55:06  <sipa> what do you need it for?
1062018-08-05T17:55:36  <jl2012> I have some txids and need to know their order in the chain
1072018-08-05T17:55:56  <gmaxwell> well if you only need to know their order, ...
1082018-08-05T17:56:01  <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
1092018-08-05T17:56:14  <wumpus> then byte index will work just as well
1102018-08-05T17:56:53  <gmaxwell> well   block number || byte offset in the block    gives you the ordering of transactions.
1112018-08-05T17:57:31  <wumpus> yes
1122018-08-05T17:57:52  <jl2012> yes, that's enough for my purpose. Do you think it's a good idea to return the byte order in getrawtransaction?
1132018-08-05T17:58:23  <sipa> i think getrawtransaction should just return the raw transaction
1142018-08-05T17:59:00  <jl2012> sipa....yeah....but we could have a different name for that....
1152018-08-05T17:59:02  <gmaxwell> jl2012: we probably shouldn't return anything that is implementation dependant unless we have a good reason.
1162018-08-05T17:59:30  <jl2012> gmaxwell: yes, that's why I wonder if I could get the tx index
1172018-08-05T17:59:56  <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.
1182018-08-05T18:00:09  <wumpus> at least if you do it, return the byte index relative to the block, not to the file start
1192018-08-05T18:00:52  <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
1202018-08-05T18:01:48  <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. :)
1212018-08-05T18:02:30  <wumpus> gmaxwell: what if we add a warning to only use it as opaque ordering token
1222018-08-05T18:02:37  <wumpus> don't call it byte offset
1232018-08-05T18:03:01  <sipa> it's also not available for mempool txn
1242018-08-05T18:03:05  <wumpus> unless that would reorder the transactions as well of course
1252018-08-05T18:03:34  <wumpus> for the mempool it certainly wouldn't make sense, what would offset into the mempool even mean
1262018-08-05T18:03:42  <gmaxwell> wumpus: that would be fine.  Nah, using a more efficient serialization wouldn't reorder anything.
1272018-08-05T18:04:04  <gmaxwell> wumpus: (uint64)txn* :P
1282018-08-05T18:04:34  <jl2012> gmaxwell: and the order itself is consensus-critical so you need to store it somehow
1292018-08-05T18:05:25  <sipa> jl2012: consensus enforcement doesn't even require storing the blocks at all :)
1302018-08-05T18:05:28  <sipa> let alone an index
1312018-08-05T18:06:47  <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
1322018-08-05T18:07:06  <sipa> (i'm not actually suggesting this; we can do much better than that without giving up the ability to access txn individually)
1332018-08-05T18:07:12  <wumpus> you'd still need an the offset after unzipping
1342018-08-05T18:07:17  <wumpus> to retrieve it
1352018-08-05T18:07:29  <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. :)
1362018-08-05T18:07:55  <sipa> wumpus: well, only if we care about retaining the ability to find individual txn
1372018-08-05T18:08:03  <wumpus> I think some compression algorithms do allow for seeking by storing more decompressor state
1382018-08-05T18:08:08  <sipa> wumpus: which is really just to speed up getrawtransaction
1392018-08-05T18:08:13  <wumpus> sure...
1402018-08-05T18:08:24  <gmaxwell> wumpus: yes, but in doing so more or less eliminates the gains from compressing things as a unit.
1412018-08-05T18:08:25  <sipa> sorry, too many hypotheticals here :)
1422018-08-05T18:08:28  <wumpus> anyhow I don't think forever API compatibility is so important for this, if we can't provide it anymore ,drop it then
1432018-08-05T18:08:44  <jl2012> sipa: generating SPV proof is also a consensus-critical process
1442018-08-05T18:09:00  <gmaxwell> jl2012: unclear what you mean by that.
1452018-08-05T18:09:02  <sipa> jl2012: no?
1462018-08-05T18:09:16  <sipa> validating of new blocks doesn't need SPV proofs
1472018-08-05T18:09:35  <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 :-)
1482018-08-05T18:09:35  <gmaxwell> The bitcoin protocol doesn't generate SPV proofs for arbritary transactions, it certantly isn't consensus critical to do so! :)
1492018-08-05T18:10:39  <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.
1502018-08-05T18:12:35  <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
1512018-08-05T18:13:18  <gmaxwell> right, and that would be totally worth doing if there were a known usecase for the interface... :P
1522018-08-05T18:13:40  <wumpus> yes...
1532018-08-05T18:13:51  <gmaxwell> though at that point, it would probably be best to just store a plain total order number.
1542018-08-05T18:14:22  <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)
1552018-08-05T18:15:14  <sipa> no it isn't
1562018-08-05T18:15:22  <sipa> it's optional
1572018-08-05T18:15:44  <sipa> the index isn't even used when helping other nodes IBD
1582018-08-05T18:15:50  <sipa> (which on itself is optional)
1592018-08-05T18:16:50  <jl2012> sipa: when you transmit a block, you also transmit the index (implicitly)
1602018-08-05T18:16:58  <sipa> ah
1612018-08-05T18:17:06  <sipa> by index you mean transaction position
1622018-08-05T18:17:12  <sipa> not "the txindex database"
1632018-08-05T18:17:14  <sipa> sorry!
1642018-08-05T18:17:38  <gmaxwell> jl2012: bitcoin core doesn't even serve SPV proofs for arbritary transactions today!
1652018-08-05T18:18:13  <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.
1662018-08-05T18:19:03  <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.
1672018-08-05T18:20:06  <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)
1682018-08-05T18:20:26  <gmaxwell> also a full node doesn't even need to have historic blocks at all.
1692018-08-05T18:21:23  <gmaxwell> Full node means that it autonomously enforces the consensus rules for itself without trusting third parties to validate, thats it.
1702018-08-05T18:22:23  *** Victorsueca has quit IRC
1712018-08-05T18:23:50  *** Victorsueca has joined #bitcoin-core-dev
1722018-08-05T18:25:58  <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
1732018-08-05T18:25:58  <gmaxwell> n values, though they would at least keep them ordered.
1742018-08-05T18:29:35  *** michaelsdunn1 has quit IRC
1752018-08-05T18:30:57  *** michaelsdunn1 has joined #bitcoin-core-dev
1762018-08-05T18:31:14  *** michaelsdunn1 has quit IRC
1772018-08-05T18:31:55  *** michaelsdunn1 has joined #bitcoin-core-dev
1782018-08-05T18:32:02  *** michaelsdunn1 has quit IRC
1792018-08-05T18:32:42  *** michaelsdunn1 has joined #bitcoin-core-dev
1802018-08-05T18:32:49  *** michaelsdunn1 has quit IRC
1812018-08-05T18:37:06  <jl2012> gmaxwell: I understand your point........could we have some kind of "expert API" that does not guarantee to work in the future?
1822018-08-05T18:39:28  <sipa> what do you need it for? perhaps there are other ways
1832018-08-05T18:43:13  <jl2012> sipa: I have some random ordered txids, and want to reconstruct the ledger.
1842018-08-05T18:43:59  <jl2012> the ledger of certain addresses
1852018-08-05T18:45:29  <jl2012> a dumb way is to call 'getblock' to learn the order.....
1862018-08-05T18:46:04  <jl2012> efficiency is not a big issue for me so that's probably good enough
1872018-08-05T18:46:36  <jl2012> but there is another problem: I just find that getrawtransaction doesn't return block height!
1882018-08-05T18:48:30  <jl2012> only block time and #of confimations.....so I need getblockchaininfo to tell me the current height....
1892018-08-05T18:48:34  <roasbeef> jl2012: verbose should, well returns confirmations which you can use to compute the blockheight the tx was incluided in
1902018-08-05T18:50:15  <jl2012> roasbeef: yes, just need to do one more step.....
1912018-08-05T18:54:52  <jonasschnelli> jl2012: can't you keep a headers chain in your application and look up the blockhash there?
1922018-08-05T18:57:12  <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
1932018-08-05T18:59:53  <jl2012> jonasschnelli: oh, it also has blockhash
1942018-08-05T18:59:56  <jl2012> sorry
1952018-08-05T19:00:12  *** Krellan has quit IRC
1962018-08-05T19:00:18  <jonasschnelli> Yeah. Just dbl checked: ""  \"blockhash\" : \"hash\",   (string) the block hash\n""
1972018-08-05T19:04:07  *** Krellan has joined #bitcoin-core-dev
1982018-08-05T19:04:26  *** hex17or has joined #bitcoin-core-dev
1992018-08-05T19:08:30  *** Krellan has quit IRC
2002018-08-05T19:09:06  *** hex17or has quit IRC
2012018-08-05T19:09:14  <jl2012> thanks everyone......at least I find a way to do it without customized API....
2022018-08-05T19:12:28  *** hex17or has joined #bitcoin-core-dev
2032018-08-05T19:14:10  *** Krellan has joined #bitcoin-core-dev
2042018-08-05T19:16:08  *** michaelsdunn1 has joined #bitcoin-core-dev
2052018-08-05T19:24:18  *** Amuza has joined #bitcoin-core-dev
2062018-08-05T19:24:53  *** hex17or has quit IRC
2072018-08-05T19:26:17  *** SopaXorzTaker has quit IRC
2082018-08-05T19:26:21  *** hex17or has joined #bitcoin-core-dev
2092018-08-05T19:30:38  *** hex17or has quit IRC
2102018-08-05T19:33:08  *** d9b4bef9 has joined #bitcoin-core-dev
2112018-08-05T19:55:40  *** justan0theruser is now known as justanotheruser
2122018-08-05T20:00:56  *** michaelsdunn1 has quit IRC
2132018-08-05T20:01:52  *** rls has joined #bitcoin-core-dev
2142018-08-05T20:11:49  *** str4d has joined #bitcoin-core-dev
2152018-08-05T20:20:39  *** str4d has quit IRC
2162018-08-05T20:34:44  *** Guyver2 has quit IRC
2172018-08-05T21:55:26  *** hex17or has joined #bitcoin-core-dev
2182018-08-05T21:56:50  *** no_input_found has quit IRC
2192018-08-05T21:57:13  *** no_input_found has joined #bitcoin-core-dev
2202018-08-05T21:59:40  *** hex17or has quit IRC
2212018-08-05T22:09:22  *** no_input_found has quit IRC
2222018-08-05T22:09:55  *** no_input_found has joined #bitcoin-core-dev
2232018-08-05T22:19:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2242018-08-05T22:22:35  *** Amuza has quit IRC
2252018-08-05T22:27:01  *** michaelsdunn1 has joined #bitcoin-core-dev
2262018-08-05T22:33:43  *** vicenteH has quit IRC
2272018-08-05T22:34:12  <Chris_Stewart_5> Is there a policy when RPC interfaces change for bitcoind? Does it change for minor version bumps?
2282018-08-05T22:34:17  *** vicenteH has joined #bitcoin-core-dev
2292018-08-05T22:39:05  *** justanotheruser has quit IRC
2302018-08-05T22:39:24  *** justanotheruser has joined #bitcoin-core-dev
2312018-08-05T22:49:08  *** michaelsdunn1 has quit IRC
2322018-08-05T23:04:54  *** viaj3ro has joined #bitcoin-core-dev
2332018-08-05T23:05:44  <viaj3ro> have an issue with my 0.16.2 node: https://github.com/bitcoin/bitcoin/issues/13885
2342018-08-05T23:06:21  <viaj3ro> need help to try figure out what's causing it
2352018-08-05T23:10:17  *** Victorsueca has quit IRC
2362018-08-05T23:11:31  *** Victorsueca has joined #bitcoin-core-dev
2372018-08-05T23:12:51  <molz> viaj3ro, maybe shouldn't run the data dir on a USB stick?
2382018-08-05T23:14:18  <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
2392018-08-05T23:15:26  <viaj3ro> chainstate is on my main SSD - so it shouldn't be that much of an issue
2402018-08-05T23:15:49  <viaj3ro> it synced within 35 hours on my 10 year old laptop
2412018-08-05T23:16:01  <viaj3ro> with those settings
2422018-08-05T23:17:55  <viaj3ro> it's known to run fine on a raspberry pi - should be running fine on my hardware...
2432018-08-05T23:34:07  *** no_input_found has quit IRC
2442018-08-05T23:34:27  *** no_input_found has joined #bitcoin-core-dev
2452018-08-05T23:36:52  <viaj3ro> going offline. any help via github is very much appreciated!
2462018-08-05T23:48:01  *** d9b4bef9 has quit IRC