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