12016-11-01T00:12:17  <instagibbs> BlueMatt in not too long it will be 5 digits...
  22016-11-01T00:14:09  <sipa> at which point we'll need a bot even more
  32016-11-01T00:17:09  *** echonaut3 has joined #bitcoin-core-dev
  42016-11-01T00:18:53  *** echonaut has quit IRC
  52016-11-01T00:21:40  *** blkdb has quit IRC
  62016-11-01T00:21:47  *** blkdb has joined #bitcoin-core-dev
  72016-11-01T00:33:30  <nanotube> BlueMatt: that can be easily arranged.
  82016-11-01T00:43:23  *** Chris_Stewart_5 has quit IRC
  92016-11-01T00:43:32  <GitHub141> [bitcoin] gmaxwell opened pull request #9052: Use RelevantServices instead of node_network in AttemptToEvict. (master...prefer_relevant2) https://github.com/bitcoin/bitcoin/pull/9052
 102016-11-01T00:43:41  *** davec has quit IRC
 112016-11-01T00:44:25  *** davec has joined #bitcoin-core-dev
 122016-11-01T00:45:32  *** binns has quit IRC
 132016-11-01T00:45:42  *** binns has joined #bitcoin-core-dev
 142016-11-01T00:47:26  <GitHub58> [bitcoin] gmaxwell opened pull request #9053: IBD using chainwork instead of height and not using header timestamps (master...no_checkpoint_for_ibd) https://github.com/bitcoin/bitcoin/pull/9053
 152016-11-01T00:47:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9053 | IBD using chainwork instead of height and not using header timestamps by gmaxwell · Pull Request #9053 · bitcoin/bitcoin · GitHub
 162016-11-01T00:47:54  <gmaxwell> haha
 172016-11-01T00:47:55  *** binns is now known as wbnns
 182016-11-01T00:47:57  <nanotube> haha well... i guess gribble should ignore github >_>
 192016-11-01T00:48:00  <gmaxwell> so perhaps it should ignore gitub.
 202016-11-01T00:48:12  <nanotube> :)
 212016-11-01T00:48:22  <sipa> yay, consensus
 222016-11-01T00:48:38  <gmaxwell> I like Red #40 dye.
 232016-11-01T00:48:39  <gribble> https://github.com/bitcoin/bitcoin/issues/40 | -rpcssl help text by dooglus · Pull Request #40 · bitcoin/bitcoin · GitHub
 242016-11-01T00:49:11  <sipa> roses are #FF0000
 252016-11-01T00:50:09  <nanotube> the regex just looks for #\d+
 262016-11-01T00:50:34  <achow101> #10000
 272016-11-01T00:50:35  <gribble> https://github.com/bitcoin/bitcoin/issues/10000 | HTTP Error 404: Not Found
 282016-11-01T00:52:14  <sipa> so what if you refer to two in one line, like how #8708 will conflict with #9039
 292016-11-01T00:52:16  <gribble> https://github.com/bitcoin/bitcoin/issues/8708 | net: have CConnman handle message sending by theuni · Pull Request #8708 · bitcoin/bitcoin · GitHub
 302016-11-01T00:52:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9039 | Various serialization simplifcations and optimizations by sipa · Pull Request #9039 · bitcoin/bitcoin · GitHub
 312016-11-01T00:52:28  <phantomcircuit> gmaxwell: int64_t &nOrderNextPos = nOrderNextPos in CWallet::ReorderTransactions is trying to assign a reference to itself not the member variable
 322016-11-01T00:52:34  <nanotube> ^ that happens :)
 332016-11-01T00:52:36  <phantomcircuit> i dont get this
 342016-11-01T00:52:37  <phantomcircuit> do you?
 352016-11-01T00:52:50  <sipa> phantomcircuit: ha
 362016-11-01T00:53:06  <sipa> phantomcircuit: yes, variables are defined during their own initializer
 372016-11-01T00:53:49  <phantomcircuit> ok then i understand what was wrong with #8828
 382016-11-01T00:53:51  <gribble> https://github.com/bitcoin/bitcoin/issues/8828 | Move CWalletDB::ReorderTransactions to CWallet by pstratem · Pull Request #8828 · bitcoin/bitcoin · GitHub
 392016-11-01T00:54:02  <sipa> similar to how you can call a function inside that function's body
 402016-11-01T00:59:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 412016-11-01T01:47:52  *** btcdrak has quit IRC
 422016-11-01T01:51:13  <sipa> should we introduce http://en.cppreference.com/w/cpp/language/user_literal for uint256?
 432016-11-01T01:52:56  <gmaxwell> sipa: would there be any benefits beyond saving a few bytes of source code for each of the couple uint256 constants we have?
 442016-11-01T01:57:31  <sipa> no
 452016-11-01T01:58:50  <cfields_> sipa: mm, i coded that up at one point
 462016-11-01T01:59:40  <cfields_> gmaxwell: it's especially nice because you can initialize on the stack more quickly (and efficiently)
 472016-11-01T02:00:10  <sipa> cfields_: it's just an invocation to a conversion operator, instead of a function
 482016-11-01T02:00:20  <cfields_> (you can parse a variadic of hex chars as constexpr, so the parsing is free)
 492016-11-01T02:00:20  <sipa> i'm pretty sure there's no difference at runtime
 502016-11-01T02:00:28  <sipa> oh!
 512016-11-01T02:00:39  <sipa> well we could also make uint256S constexpr then?
 522016-11-01T02:00:56  <cfields_> sipa: well, it only works for literals
 532016-11-01T02:01:15  <gmaxwell> I think in all cases they get stashed in constants, so it shouldn't really make a runtime difference.
 542016-11-01T02:02:23  <cfields_> yea, in reality it's negligible. I just did it to play with the variadics + user literals. But it made chainparams look prettier :)
 552016-11-01T02:02:28  <cfields_> i'll see if i can dig it up
 562016-11-01T02:07:08  <sipa> cfields_: right, but i guess you could at least have a uint256constS function, which is constexpr and does the same thing as the normal uint256S function
 572016-11-01T02:07:22  <sipa> which you could only pass literals or other constexpr strings
 582016-11-01T02:07:48  <sipa> and compared to that, a user-defined literal is purely syntactic sugar?
 592016-11-01T02:09:45  <cfields_> sipa: sure, i suppose so
 602016-11-01T02:11:55  *** notmike has joined #bitcoin-core-dev
 612016-11-01T02:28:15  *** notmike has quit IRC
 622016-11-01T02:35:29  *** notmike has joined #bitcoin-core-dev
 632016-11-01T02:37:48  *** Chris_Stewart_5 has quit IRC
 642016-11-01T02:39:31  *** echonaut3 has quit IRC
 652016-11-01T02:39:48  *** echonaut has joined #bitcoin-core-dev
 662016-11-01T02:48:13  *** notmike is now known as notnick
 672016-11-01T02:48:30  *** notnick is now known as notmike
 682016-11-01T03:17:53  *** btcdrak has joined #bitcoin-core-dev
 692016-11-01T03:40:43  <gmaxwell> https://github.com/bitcoin/bitcoin/pull/9053 < can someone trigger a rerun here? I'm pretty sure this change couldn't make test_bitcoin fail (and it passes locally.)
 702016-11-01T03:46:53  <sipa> gmaxwell: chainActive.Tip()->nChainWork may segfault before the genesis block is loaded
 712016-11-01T03:47:09  <sipa> almost all platforms fail, that doesn't look like a spurious error
 722016-11-01T03:48:01  <gmaxwell> sipa: on #1 fair comment, but they're failing in test_bitcoin prevector tests.
 732016-11-01T03:48:03  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
 742016-11-01T03:48:11  <gmaxwell> die
 752016-11-01T03:48:21  <sipa> hahahaha
 762016-11-01T03:57:13  <luke-jr> lol
 772016-11-01T04:10:23  *** PaulCapestany has quit IRC
 782016-11-01T04:11:35  *** PaulCapestany has joined #bitcoin-core-dev
 792016-11-01T04:16:04  *** dstadulis has joined #bitcoin-core-dev
 802016-11-01T04:16:29  *** PaulCapestany has quit IRC
 812016-11-01T04:18:44  *** PaulCapestany has joined #bitcoin-core-dev
 822016-11-01T04:23:58  *** fengling has joined #bitcoin-core-dev
 832016-11-01T05:08:48  *** dstadulis has quit IRC
 842016-11-01T05:40:17  <btcdrak> #2
 852016-11-01T05:40:19  <gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
 862016-11-01T05:40:35  <btcdrak> oh thats going to get annoying
 872016-11-01T05:41:08  <gmaxwell> Perhaps we should as nano to change it to PR#xxxx
 882016-11-01T05:41:13  <sipa> or we adapt
 892016-11-01T05:41:45  <gmaxwell> FWIW, there is a bot that does this in #xiph run by someone no one knows, that just spends all its time banned. esp because it links to some trac instance thats hardly used.
 902016-11-01T05:42:15  *** rebroad has joined #bitcoin-core-dev
 912016-11-01T05:44:45  *** DigiByteDev has joined #bitcoin-core-dev
 922016-11-01T05:48:28  <TD-Linux> gmaxwell, it's not banned sadly
 932016-11-01T05:52:14  *** notmike has quit IRC
 942016-11-01T06:08:52  *** rebroad has quit IRC
 952016-11-01T06:36:14  *** servkolhapur has joined #bitcoin-core-dev
 962016-11-01T06:36:58  *** notmike has joined #bitcoin-core-dev
 972016-11-01T06:42:06  *** notmike has quit IRC
 982016-11-01T06:59:07  *** paveljanik has quit IRC
 992016-11-01T07:09:54  *** Evel-Knievel has quit IRC
1002016-11-01T07:14:00  *** rebroad has joined #bitcoin-core-dev
1012016-11-01T07:19:51  <jonasschnelli> test #8977
1022016-11-01T07:19:52  <gribble> https://github.com/bitcoin/bitcoin/issues/8977 | [Wallet] Refactor wallet/init interaction (Reaccept wtx, flush thread) by jonasschnelli · Pull Request #8977 · bitcoin/bitcoin · GitHub
1032016-11-01T07:20:30  <jonasschnelli> I think this is useful,.. but agree maybe double-hash ##xxx would result in less noise.
1042016-11-01T07:23:30  <sipa> if we want to modify it to something more strict, i'd prefer PRXXXX (without #), as that's easier to type as well
1052016-11-01T07:24:37  <jonasschnelli> Yes. That would also work...
1062016-11-01T07:32:37  *** Evel-Knievel has joined #bitcoin-core-dev
1072016-11-01T07:33:38  <GitHub103> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3d69ecb4edeb...273bde37d867
1082016-11-01T07:33:38  <GitHub103> bitcoin/master 3333e5a MarcoFalke: [qt] Return useful error message on ATMP failure
1092016-11-01T07:33:39  <GitHub103> bitcoin/master 273bde3 Jonas Schnelli: Merge #9043: [qt] Return useful error message on ATMP failure...
1102016-11-01T07:33:53  <GitHub3> [bitcoin] jonasschnelli closed pull request #9043: [qt] Return useful error message on ATMP failure (master...Mf1611-qtATMPerror) https://github.com/bitcoin/bitcoin/pull/9043
1112016-11-01T07:39:29  *** echonaut has quit IRC
1122016-11-01T07:39:30  *** echonaut4 has joined #bitcoin-core-dev
1132016-11-01T07:46:17  <rebroad> does gribble no longer report pull requests I open?
1142016-11-01T07:48:31  <rebroad> test #9055
1152016-11-01T07:48:33  <gribble> https://github.com/bitcoin/bitcoin/issues/9055 | Skip processing of cmpctblocks we have previously downloaded. by rebroad · Pull Request #9055 · bitcoin/bitcoin · GitHub
1162016-11-01T07:49:02  <rebroad> jonasschnelli, what does the test command do please?
1172016-11-01T07:49:17  <jonasschnelli> rebroad: a test. :)
1182016-11-01T07:49:36  <rebroad> jonasschnelli, ah, thank you. most enlightening
1192016-11-01T07:58:38  *** arubi has quit IRC
1202016-11-01T07:59:20  *** kadoban has quit IRC
1212016-11-01T08:07:52  *** btcdrak has quit IRC
1222016-11-01T08:12:30  *** wasi has joined #bitcoin-core-dev
1232016-11-01T08:18:39  *** molz has joined #bitcoin-core-dev
1242016-11-01T08:22:20  *** mol has quit IRC
1252016-11-01T08:27:37  *** btcdrak has joined #bitcoin-core-dev
1262016-11-01T08:37:49  *** DigiByteDev has quit IRC
1272016-11-01T08:38:41  *** DigiByteDev has joined #bitcoin-core-dev
1282016-11-01T08:51:22  *** notmike has joined #bitcoin-core-dev
1292016-11-01T08:59:34  *** notmike has quit IRC
1302016-11-01T09:04:02  <jonasschnelli> sipa: how do we detect nodes delaying (or even not sending) requested blocks? Currently I'm debugging a case where I have a couple of blocks "inflight" but the peer is responding extremely slow...
1312016-11-01T09:04:24  <jonasschnelli> Is there a max timeout or something similar until we release the block from the mapBlocksInFlight?
1322016-11-01T09:04:32  <jonasschnelli> and re-request it from a different peer?
1332016-11-01T09:08:20  <gmaxwell> jonasschnelli: yes, we will eventually hang up on the peer after 10 minutes, see BLOCK_DOWNLOAD_TIMEOUT_BASE
1342016-11-01T09:08:39  <jonasschnelli> gmaxwell: thanks. Also just stumbled over state->nDownloadingSince
1352016-11-01T09:09:02  <jonasschnelli> gmaxwell: for my hybrid-SPV-PR this seems to be to long...
1362016-11-01T09:09:14  *** DigiByteDev has quit IRC
1372016-11-01T09:09:26  <jonasschnelli> I guess there are no other full-block SPV wallets out there... so hard to say what would be best in a such case...
1382016-11-01T09:10:14  <gmaxwell> why is that any different for hybrid-spv-pr than normal operation?
1392016-11-01T09:10:35  <jonasschnelli> Yes. Same for normal operation.
1402016-11-01T09:11:12  <jonasschnelli> If blocks are dropping in in a ~10min interval, the UX of an SPV mode is almost broken..
1412016-11-01T09:11:27  <gmaxwell> It should be made adaptive. It cannot just be made shorter without making the software dysfunctional for hosts with a slow connection. (as it will get 95% through transfering, then abort, and start over, ... but even slower because the prior transfer left some incoming traffic...)
1422016-11-01T09:11:32  <jonasschnelli> I guess during full-validation. people tend to be more patient.
1432016-11-01T09:11:50  <gmaxwell> jonasschnelli: what?
1442016-11-01T09:12:12  <gmaxwell> are you forcing in order block processing or something?
1452016-11-01T09:13:02  <gmaxwell> normally during sync the timeout isn't the mechenism that deals with slow peers, the stalling mechenism is.
1462016-11-01T09:13:08  <jonasschnelli> gmaxwell: I'm working on an SPV modes where the wallet can specifically request (priorize) a block-sequence
1472016-11-01T09:13:44  <jonasschnelli> "Normal" IBD interrupts, FindNextBlocksToDownload prefers specific request
1482016-11-01T09:13:56  <gmaxwell> And it doesn't have any tricky and failure prone hard timeouts, it punts peers that stall the transfer.
1492016-11-01T09:14:21  <gmaxwell> so the good performance of other peers is the test rather than a static timeout.
1502016-11-01T09:16:36  <jonasschnelli> The SPV modes works mostly okay, but sometimes I encountered that I have connected to extremely slow peers (block response take up to 5mins), which makes the user-experience really inconvenient.
1512016-11-01T09:17:29  <gmaxwell> this is handled by the initial block download logic. It fetches blocks out of order, and when a peer is slower than all the others thus stalling things, it gets kicked off.
1522016-11-01T09:19:22  <jonasschnelli> Haven't fully analyzed "nNow > state.nDownloadingSince + consensusParams.nPowTargetSpacing * (BLOCK_DOWNLOAD_TIMEOUT_BASE + BLOCK_DOWNLOAD_TIMEOUT_PER_PEER * nOtherPeersWithValidatedDownloads)"... but it seems to not trigger a 5 min delayed block around the tip
1532016-11-01T09:20:26  <gmaxwell> the timeout is 10 minutes. (at the tip, normally we expect things to be transfered via BIP152 high bandwidth mode, which can't stall)
1542016-11-01T09:21:07  <gmaxwell> (well my recollection is 10 minutes, and if it is set statically less then 10 minutes you will have hosts with enough bandwidth to successfully use the system constant dos attacking themselves.)
1552016-11-01T09:22:01  <jonasschnelli> Okay. Thanks.
1562016-11-01T09:22:22  <jonasschnelli> BIP152 doesn't helps in the SPV mode (UTXO set not ready)
1572016-11-01T09:22:53  <gmaxwell> UTXO set? you mean mempool.
1582016-11-01T09:23:12  <jonasschnelli> Yes. But no UXTO set no mempool. :)
1592016-11-01T09:23:39  *** notmike has joined #bitcoin-core-dev
1602016-11-01T09:24:51  <jonasschnelli> Also not sure, but could it be, that the parallel block download during the time, when we initially sync the headers could slow down the header sync?
1612016-11-01T09:25:29  <jonasschnelli> As soon as we have the first header batch, we start download those blocks (which is fine in normal operation), but in SPV, I'd prefer to get the headers with priority.
1622016-11-01T09:25:38  *** rebroad has quit IRC
1632016-11-01T09:25:49  <gmaxwell> the header sync is very fast, and we do not use much bandwidth early in the sync due to the many round trips needed due to small batches. So I doubt it does.
1642016-11-01T09:26:47  *** DigiByteDev has joined #bitcoin-core-dev
1652016-11-01T09:27:49  <gmaxwell> in any case, as I said before... the timeout can be made dynamic. It just needs to start at a safe number like ten minutes, and then when a block transfers faster than 10 minutes, it can be reduced to e.g. 2 sec + 2*(block_time*1m/block_size) or such, and any time it kicks off a peer due to a failure, double again with a max of 10 minutes. This way it will not have a timeout so slow that it will
1662016-11-01T09:27:55  <gmaxwell>  cause failure, and if the node's bandwidth goes down, it will adapt back after a couple failures.
1672016-11-01T09:28:35  <gmaxwell> that kind of adaptive threshold just wasn't very important so far because of the combination of other methods.
1682016-11-01T09:28:48  *** notmike has quit IRC
1692016-11-01T09:35:29  *** jannes has joined #bitcoin-core-dev
1702016-11-01T09:45:28  <phantomcircuit> jonasschnelli: hybrid-spv-pr?
1712016-11-01T09:45:29  <phantomcircuit> wat
1722016-11-01T10:04:40  *** rebroad has joined #bitcoin-core-dev
1732016-11-01T10:06:37  *** rebroad has quit IRC
1742016-11-01T10:10:19  *** fengling has quit IRC
1752016-11-01T10:12:58  *** Victorsueca has quit IRC
1762016-11-01T10:21:29  *** rebroad has joined #bitcoin-core-dev
1772016-11-01T10:24:26  *** murch has joined #bitcoin-core-dev
1782016-11-01T10:26:37  *** notmike has joined #bitcoin-core-dev
1792016-11-01T10:31:45  *** notmike has quit IRC
1802016-11-01T10:37:00  *** rebroad has quit IRC
1812016-11-01T10:49:55  *** fengling has joined #bitcoin-core-dev
1822016-11-01T10:54:43  *** fengling has quit IRC
1832016-11-01T11:12:14  *** Guyver2 has joined #bitcoin-core-dev
1842016-11-01T11:16:37  *** cryptapus has joined #bitcoin-core-dev
1852016-11-01T11:16:37  *** cryptapus has joined #bitcoin-core-dev
1862016-11-01T11:50:56  *** fengling has joined #bitcoin-core-dev
1872016-11-01T11:55:46  *** fengling has quit IRC
1882016-11-01T11:57:56  *** rebroad has joined #bitcoin-core-dev
1892016-11-01T12:15:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1902016-11-01T12:18:49  *** wasi has quit IRC
1912016-11-01T12:20:17  *** Chris_Stewart_5 has quit IRC
1922016-11-01T12:20:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1932016-11-01T12:24:27  *** dermoth_ has joined #bitcoin-core-dev
1942016-11-01T12:24:53  *** dermoth has quit IRC
1952016-11-01T12:24:55  *** dermoth_ is now known as dermoth
1962016-11-01T12:37:51  *** wasi has joined #bitcoin-core-dev
1972016-11-01T12:44:58  <jl2012> sipa: I got a question from a block explorer dev. How do we want people to present bare segwit on explorers?
1982016-11-01T12:47:18  <jl2012> I never thought of that. Maybe using the hex?
1992016-11-01T12:47:49  *** DigiByteDev has quit IRC
2002016-11-01T12:51:58  *** fengling has joined #bitcoin-core-dev
2012016-11-01T12:56:49  *** fengling has quit IRC
2022016-11-01T13:03:26  *** ClockCat has joined #bitcoin-core-dev
2032016-11-01T13:15:51  <jonasschnelli> phantomcircuit: Yes. Will PR soon. Need to write a RPC test first,... which is non-trivial
2042016-11-01T13:16:28  <jonasschnelli> I guess you are familiar with the idea of SPV during IBD/sync (= hybrid SPV)
2052016-11-01T13:20:36  *** laurentmt has joined #bitcoin-core-dev
2062016-11-01T13:20:42  *** laurentmt has quit IRC
2072016-11-01T13:37:33  *** Guyver2 has quit IRC
2082016-11-01T13:40:53  *** Guyver2 has joined #bitcoin-core-dev
2092016-11-01T13:50:24  *** cryptapus has quit IRC
2102016-11-01T13:51:16  *** Chris_Stewart_5 has quit IRC
2112016-11-01T13:53:00  *** fengling has joined #bitcoin-core-dev
2122016-11-01T13:57:52  *** fengling has quit IRC
2132016-11-01T14:03:02  *** Guyver2 has quit IRC
2142016-11-01T14:04:08  *** Guyver2 has joined #bitcoin-core-dev
2152016-11-01T14:05:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2162016-11-01T14:19:01  *** aalex has quit IRC
2172016-11-01T14:20:37  *** DigiByteDev has joined #bitcoin-core-dev
2182016-11-01T14:21:43  *** rebroad has quit IRC
2192016-11-01T14:27:53  *** DigiByteDev has quit IRC
2202016-11-01T14:53:59  *** fengling has joined #bitcoin-core-dev
2212016-11-01T14:54:28  <GitHub45> [bitcoin] ryanofsky opened pull request #9058: Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (master...fix-8842-sync-timeouts) https://github.com/bitcoin/bitcoin/pull/9058
2222016-11-01T14:58:55  *** fengling has quit IRC
2232016-11-01T15:05:11  <phantomcircuit> jonasschnelli: ah yeah
2242016-11-01T15:05:15  <phantomcircuit> for the wallet only right?
2252016-11-01T15:07:26  <jl2012> sipa: for block explorer, I think they should display bare segwit with P2SH addresses. Just like how they display P2PK as P2PKH address
2262016-11-01T15:10:48  *** kadoban has joined #bitcoin-core-dev
2272016-11-01T15:18:06  *** vdefeo has joined #bitcoin-core-dev
2282016-11-01T15:27:25  *** cryptapus has joined #bitcoin-core-dev
2292016-11-01T15:32:14  *** notmike has joined #bitcoin-core-dev
2302016-11-01T15:33:28  *** vdefeo has quit IRC
2312016-11-01T15:36:38  *** sanada has quit IRC
2322016-11-01T15:54:47  *** fengling has joined #bitcoin-core-dev
2332016-11-01T15:55:12  *** ClockCat has quit IRC
2342016-11-01T15:58:18  *** aalex has joined #bitcoin-core-dev
2352016-11-01T15:59:58  *** fengling has quit IRC
2362016-11-01T16:00:08  *** Ylbam has quit IRC
2372016-11-01T16:08:26  *** PaulCape_ has joined #bitcoin-core-dev
2382016-11-01T16:08:53  *** wallet42 has quit IRC
2392016-11-01T16:10:14  *** wallet42 has joined #bitcoin-core-dev
2402016-11-01T16:10:45  *** PaulCapestany has quit IRC
2412016-11-01T16:18:41  <NicolasDorier> jl2012: nop
2422016-11-01T16:18:46  <NicolasDorier> it confuses new devs
2432016-11-01T16:19:05  <NicolasDorier> best is just to show 0 <hash>
2442016-11-01T16:19:22  <jl2012> or just the hex
2452016-11-01T16:19:29  <NicolasDorier> yeah or just the hex
2462016-11-01T16:20:24  <NicolasDorier> lost quite a lot of time explaining to noob why the address of the genesis output was not generating the same ScriptPubKey than inside the block
2472016-11-01T16:38:47  *** sanada has joined #bitcoin-core-dev
2482016-11-01T16:44:50  *** abpa has joined #bitcoin-core-dev
2492016-11-01T16:55:59  *** fengling has joined #bitcoin-core-dev
2502016-11-01T17:01:01  *** fengling has quit IRC
2512016-11-01T17:16:36  <morcos> cfields_: I got a bit lost trying to follow you, BlueMatt and sipa discussing moving and const members, but I don't think any of that discussion changes the gains I was seeing from your copy-move branch?
2522016-11-01T17:17:09  <morcos> What do you think about actually PR'ing that.  I've been using it for so long now for all my benching, I'd like to make sure I'm not building my work on a house of cards
2532016-11-01T17:17:31  <sipa> what does his copy-move branch do?
2542016-11-01T17:17:38  <gmaxwell> jl2012: showing some other address would cause loss of funds.
2552016-11-01T17:18:02  <morcos> theuni/bitcoin/copy-move
2562016-11-01T17:18:30  <gmaxwell> jl2012: people would sends funds to those addresses and because they're not the same, wallets would ignore those payments.
2572016-11-01T17:18:53  <jl2012> gmaxwell: yes, i think that's not a good idea. But core is still showing P2PK as P2PKH
2582016-11-01T17:19:21  <sipa> morcos: casting a const field to non-const is undefined behaviour
2592016-11-01T17:19:27  <gmaxwell> yes, legacy behavior but at least a ubiquitous one.
2602016-11-01T17:19:27  <morcos> sipa: if i recall cfields was thinking it wouldn't show a big speedup, but it definitely makes a noticeable difference for me.
2612016-11-01T17:19:38  <jl2012> ok, i told them to use raw hex directly
2622016-11-01T17:19:45  <sipa> morcos: we currently do it in CTransaction, but I have a PR to get rid of it
2632016-11-01T17:19:55  <morcos> sipa: you're referring to the move operator for CTransaction (or whatever thats called) in the 2nd commit?
2642016-11-01T17:20:35  <morcos> i don't think I'm using that though anywhere in the code right.  i didn't make any changes to explicitly use that.  i'm assuming its the other changes that are causing the speedup, so i don't need that part
2652016-11-01T17:20:59  <morcos> i just briefly tried putting an assert(false) in there and it worked just fine...
2662016-11-01T17:21:16  <sipa> morcos: oh, making prevector movable is fine!
2672016-11-01T17:21:25  <sipa> i missed there were two commits
2682016-11-01T17:21:53  <morcos> it wasn't clear to me if any of the other minor changes in the 2nd commit mattered, i didn't bother trying to track down what was important...
2692016-11-01T17:22:12  <morcos> pehraps the thing holding cfields_ up from actually PR'ing it is you can't use is_trivially_copyable
2702016-11-01T17:22:34  <morcos> and maybe he wanted some protection for that
2712016-11-01T17:25:23  *** Ylbam has joined #bitcoin-core-dev
2722016-11-01T17:30:51  <sipa> is_trivially_copyable is certainly fine for the current use cases
2732016-11-01T17:31:23  <morcos> no i mean its not supported everywhere, for instance in gcc 4.8 or whatever i have on ubuntu 14.04
2742016-11-01T17:32:01  *** notmike has quit IRC
2752016-11-01T17:33:47  <sipa> that's something you wonder about, or an issue you know?
2762016-11-01T17:34:05  <morcos> yeah it didn't compile for me until i commented those lines out
2772016-11-01T17:34:06  <sipa> afaik is_trivially_copyable is just c++11, so every compliant compiler should have it
2782016-11-01T17:34:39  *** justanotheruser has quit IRC
2792016-11-01T17:35:13  <gmaxwell> sipa: it's libstdc++ though, not GCC itself.
2802016-11-01T17:35:22  <morcos> what are those called? traits or attributes or whatever, are the one part of c++11 that gcc 4.8 didn't fully support
2812016-11-01T17:36:52  <morcos> ehh, type properties.. see https://gcc.gnu.org/onlinedocs/gcc-4.8.4/libstdc++/manual/manual/status.html#status.iso.2011
2822016-11-01T17:38:59  <sipa> i see
2832016-11-01T17:41:17  <sipa> well we can temporarily define our own, for just the types we use it for
2842016-11-01T17:43:07  <morcos> so in your PR to fix CTransaction, you don't define a move constructor right?  would it be benfecial to have one?  or is it useless since the CTransaction it's moving from has all members const?
2852016-11-01T17:43:22  <morcos> thats where i got lost in yoru conversation the other day
2862016-11-01T17:43:55  <sipa> right, the move constructor would be identical to the copy constructor
2872016-11-01T17:44:39  <sipa> and my suggestion is that we solve it at a higher level: if a ctransaction needs to be movable, use a std::unique_ptr or std::shared_ptr around it
2882016-11-01T17:44:53  <morcos> which is inefficient though huh, since isn't the whole point of the move that you're not going to use the source object any more
2892016-11-01T17:44:53  <sipa> in particular in CBlock
2902016-11-01T17:45:12  *** atroxes has quit IRC
2912016-11-01T17:46:15  <morcos> btw, if you have any brilliant ideas, i've been spending a lot of time trying to figure out how to flush pcoinstip but keep it warm
2922016-11-01T17:46:30  *** atroxes has joined #bitcoin-core-dev
2932016-11-01T17:46:46  <morcos> you can do something semi-smart in regular operation by constructing fake blocks (although usually there isn't enough of a mempool backlog for this to be too helpful)
2942016-11-01T17:47:09  <morcos> but what in the world do you do during startup...
2952016-11-01T17:50:02  <gmaxwell> oh thats cute... during startup: mempool saving. :) (later: mempool sync)
2962016-11-01T17:50:42  *** DigiByteDev has joined #bitcoin-core-dev
2972016-11-01T17:51:50  <morcos> gmaxwell: no i mean when you're in IBD or something (so its not that you don't have a mempool, its that you're connecting blocks from long ago)
2982016-11-01T17:52:33  <gmaxwell> "don't do it then"
2992016-11-01T17:53:12  <morcos> it's sad how long HaveInputs takes in a reindex-chainstate or similar operation
3002016-11-01T17:54:19  <sipa> morcos: even with huge dbcache?
3012016-11-01T17:54:40  <sipa> because HaveInputs is what triggers the fetch from disk if an entry is not cached
3022016-11-01T17:54:41  <morcos> sipa: no thats what i mean.  with a reasonable sized one
3032016-11-01T17:55:09  <morcos> i'm wondering if when you go to flush it, you can be smart about keeping some useful stuff in there...
3042016-11-01T17:56:11  *** arubi has joined #bitcoin-core-dev
3052016-11-01T17:56:56  *** fengling has joined #bitcoin-core-dev
3062016-11-01T18:02:04  *** fengling has quit IRC
3072016-11-01T18:02:54  <sipa> perhaps we should experiment with per-output caching rather than per-tx
3082016-11-01T18:05:08  <morcos> sipa: i just worry that without changing the whole database it'll be hard to use that efficiently
3092016-11-01T18:05:25  <sipa> oh, sure, the database will need to change
3102016-11-01T18:05:35  <sipa> but it can be converted on startup or so
3112016-11-01T18:05:56  <morcos> well you could imagine a middle ground.. but yeah i agree, cleaner to just do the whole thing
3122016-11-01T18:06:34  <sipa> the one thing i'm not clear on is how to deal with the (few) per-tx values
3132016-11-01T18:08:05  <morcos> well, we should stop storing nVersion
3142016-11-01T18:08:15  <morcos> i think what we store for that is undefined actually
3152016-11-01T18:09:01  <sipa> agree, i doubt we'll need it
3162016-11-01T18:09:02  <morcos> i was trying to trace it yesterday, it looks like we right shift a signed int to store it as a CVarInt which I belive is implementation dependent
3172016-11-01T18:09:19  <sipa> indeed
3182016-11-01T18:09:29  <morcos> there is a comment about it not properly handling negative numbers already
3192016-11-01T18:10:14  <sipa> so if it's just height and coinbaseness, we could perhaps have just coinbaseness stored in every utxo
3202016-11-01T18:10:27  <sipa> and a separate map with remembered heights of coinbase tn
3212016-11-01T18:11:01  <morcos> you need the height for more than coinbase though right?
3222016-11-01T18:11:09  <sipa> do we?
3232016-11-01T18:11:14  <morcos> bip68?
3242016-11-01T18:11:19  <sipa> oh, with bip68 we do
3252016-11-01T18:11:20  <sipa> ok
3262016-11-01T18:11:34  <sipa> maybe it's easier to not bother with deduplicating the height then
3272016-11-01T18:12:28  <morcos> certainly easier!
3282016-11-01T18:13:40  <morcos> so will the txid be duplicated on disk though for each utxo?
3292016-11-01T18:14:24  <morcos> i assume its easy enough to skip that in memory, but not sure how leveldb works, that can we have two levels of keys?
3302016-11-01T18:15:58  <sipa> i believe that leveldb efficiently represents may keys with the same prefix
3312016-11-01T18:16:03  <sipa> *many
3322016-11-01T18:16:15  <sipa> but i can't find a reference for it
3332016-11-01T18:19:16  <instagibbs> does the rpc tester eventually time out? It's hanging on me and I can't tell which test is triggering the timeout
3342016-11-01T18:19:57  <sipa> bigtable (the internal system at google that leveldb is an opensource simplified version of) certainly does that
3352016-11-01T18:25:06  *** Chris_Stewart_5 has quit IRC
3362016-11-01T18:26:58  <sipa> morcos: an alternative is two tabbles, where one maps txid to (coinbase,height,id), and id is a 64-bit sequentially incrementing value, which is used in a (id,nout) to (scriptPubkey, amoubt) map
3372016-11-01T18:27:16  <sipa> downside: twice the number of disk seeks
3382016-11-01T18:28:44  <morcos> sipa: yeah i 2 disk ops is going to be worse for a lot of disks
3392016-11-01T18:30:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3402016-11-01T18:30:28  *** molz has quit IRC
3412016-11-01T18:31:15  <sipa> or we can of course leave the disk format intact
3422016-11-01T18:33:06  *** paveljanik has joined #bitcoin-core-dev
3432016-11-01T18:41:25  *** DigiByteDev has quit IRC
3442016-11-01T18:57:46  *** fengling has joined #bitcoin-core-dev
3452016-11-01T19:03:07  *** fengling has quit IRC
3462016-11-01T19:12:39  *** BashCo has joined #bitcoin-core-dev
3472016-11-01T19:21:39  <gmaxwell> So, re. prefinal alert, right now all those old nodes are displaying "Warning: This version is obsolete, upgrade required!".  It would be a bit odd to override that message with something merely saying the alert system is going away.
3482016-11-01T19:22:10  <BlueMatt> "The Alert System has been deprecated. Please upgrade your client"
3492016-11-01T19:22:11  <BlueMatt> ?
3502016-11-01T19:25:07  <gmaxwell> What I wrote before checking to see the language of the current warning was "Alerts are retired and removed in current software."
3512016-11-01T19:25:27  <gmaxwell> BlueMatt: your suggestion suggests that alerts are the only reason to upgrade.
3522016-11-01T19:25:29  *** Chris_Stewart_5 has quit IRC
3532016-11-01T19:25:30  <achow101> How about "Upgrading is strongly recommended" instead of "Please upgrade your client"
3542016-11-01T19:26:04  <achow101> won't both the alert and the other message be displayed simultaneously?
3552016-11-01T19:26:07  <gmaxwell> It's weird to override a more serious warning with a less serious one.
3562016-11-01T19:26:12  <gmaxwell> achow101: no, they can't be.
3572016-11-01T19:27:02  <gmaxwell> achow101: the messages have a priority and the highest priority active alert is displayed.
3582016-11-01T19:27:35  <gmaxwell> if this is sent at low priority (which was what I was originally intending before I thought about it) then it just won't be seen by anyone because it would be masked by that upgrade required alert.
3592016-11-01T19:28:10  <achow101> What about two different messages, one for those who are showing that upgrade required alert, and one not?
3602016-11-01T19:28:36  *** moli has joined #bitcoin-core-dev
3612016-11-01T19:29:23  <gmaxwell> AFAIK, there aren't any nodes which display alerts which aren't showing upgrade required. Anything prior to 0.12.2 is displaying upgrade required right now. (and once segwit signaling starts, all 0.13 will also start displaying an upgrade notice)
3622016-11-01T19:29:42  <BlueMatt> sipa: we're all getting emails about old releases :(
3632016-11-01T19:29:50  <BlueMatt> bitcoin 0.10.4 released
3642016-11-01T19:29:58  <sdaftuar> time to upgrade!
3652016-11-01T19:31:30  <achow101> gmaxwell: so just make the message "Warning: This version is obsolete. The Alert System has been deprecated. Upgrade is strongly recommended. See: https://bitcoin.org/alert-retirement"
3662016-11-01T19:31:34  <sipa> BlueMatt: oops
3672016-11-01T19:31:57  <sipa> BlueMatt: i was just adding release notes to tags
3682016-11-01T19:32:05  <BlueMatt> yea, i figured
3692016-11-01T19:32:14  <BlueMatt> whatever, one-time cost
3702016-11-01T19:32:18  <sipa> as they weren't showing up on https://github.com/bitcoin/bitcoin/releases
3712016-11-01T19:32:29  <arubi> genuinely asking, why not recommend to run with -alerts=0 from now and that's it?
3722016-11-01T19:32:29  <sipa> i'm done now
3732016-11-01T19:32:31  <gmaxwell> achow101: makes it sound like the alert system is the only issue, but it's not-- the reason they're saying upgrade required is that they're not current with the current network rules.
3742016-11-01T19:32:55  <gmaxwell> arubi: uh oh. confusion detected.
3752016-11-01T19:33:07  <arubi> is that a different alert then?
3762016-11-01T19:33:15  <gmaxwell> arubi: alert=0 has been the case for many versions, and since 0.13.0 the alert system is gone entirely.
3772016-11-01T19:33:33  <arubi> yea but you were talking about 0.12.2
3782016-11-01T19:33:50  <gmaxwell> arubi: that has alert=0 by default.
3792016-11-01T19:34:09  <arubi> I see, "prior to"
3802016-11-01T19:34:16  <TD-Linux> gmaxwell, just concatenate the messages? "In addition, the alert system..."
3812016-11-01T19:34:29  <achow101> how long can the message be? You could make it more explicit that the software is both out of date with consensus rules and that the alert system is deprecated
3822016-11-01T19:35:11  <gmaxwell> achow101: I think it'll get cut off in the tray of the application in older versions if it's too long. But otherwise there isn't a meaningful limit.
3832016-11-01T19:36:18  <BlueMatt> http://bitcoinfibre.org/public-network.html
3842016-11-01T19:37:33  <achow101> so, how about "Warning: Network rules in this version are out of date. Additionally the Alert System has been deprecated. Upgrade is strongly recommended. See https://bitcoin.org/alert-retirement"
3852016-11-01T19:37:57  <arubi> gmaxwell, to be sure, "upgrade required" is a message invoked locally when rule changes are detected, and "alerts" are simply the messages that come in signed by the alert key?  sorry for getting in the way here
3862016-11-01T19:38:10  <achow101> maybe have a "due to soft forks" after "rules out of date"
3872016-11-01T19:38:29  <kanzure> high amounts of meail from recent releases on github
3882016-11-01T19:38:32  <kanzure> .. email.
3892016-11-01T19:38:46  <sipa> kanzure: i'm sorry, i didn't know it was mailing people
3902016-11-01T19:38:51  <kanzure> it's fine. just a heads up.
3912016-11-01T19:38:55  <sipa> kanzure: they're listed now on https://github.com/bitcoin/bitcoin/releases
3922016-11-01T19:39:00  <kanzure> ya it is nice
3932016-11-01T19:44:00  <achow101> gmaxwell: if the message is an issue now, what about when "Alert Key Compromised" is sent?
3942016-11-01T19:44:15  <gmaxwell> arubi: yes, -- the local message and alerts are handled in exactly the same way.
3952016-11-01T19:44:39  <gmaxwell> achow101: it's even more urgent though, and also less of an issue since we'll have months of this message being displayed.
3962016-11-01T19:46:36  <achow101> ok. What do you think about my other suggestion?
3972016-11-01T19:47:20  <arubi> thanks gmaxwell, I'll have to play around with alerts= with my own mock alert key
3982016-11-01T19:50:27  <gmaxwell> achow101: sounds fine to me more or less..  Perhaps "Warning: This is outdated and network-inconsistent software. Also, the alert system has been deprecated. Upgrade is strongly recommended. See https://bitcoin.org/alert-retirement"
3992016-11-01T19:51:11  <achow101> sounds good to me.
4002016-11-01T19:53:19  <achow101> how do you even send an alert?
4012016-11-01T19:53:56  <gmaxwell> achow101: using software bitcoin's creator wrote which has never been publically distributed.
4022016-11-01T19:54:00  <gmaxwell> (AFAIK)
4032016-11-01T19:54:57  <achow101> does it happen to look like this: https://gist.github.com/laanwj/0e689cfa37b52bcbbb44 ?
4042016-11-01T19:56:04  <gmaxwell> well then.
4052016-11-01T19:56:11  <phantomcircuit> gmaxwell: possibly just send the same message
4062016-11-01T19:56:24  <phantomcircuit> iirc there are very very old versions which wont show that warning
4072016-11-01T19:56:43  <gmaxwell> yes, though AFAICT all of those are forked off. :)
4082016-11-01T19:57:10  <gmaxwell> we want to mention the alert system specifically, so that when the alert system compromised message shows up it might be a little less alarming.
4092016-11-01T19:58:58  *** fengling has joined #bitcoin-core-dev
4102016-11-01T19:59:28  <cfields_> sipa: https://github.com/theuni/bitcoin/commits/uint-literal
4112016-11-01T20:04:10  *** fengling has quit IRC
4122016-11-01T20:04:44  *** cryptapus has quit IRC
4132016-11-01T20:05:51  <sipa> cfields_: hmm, i would expect something that just uses return (4*(recursive call)+(new digit)) on a uint256
4142016-11-01T20:08:35  <cfields_> sipa: hmm?
4152016-11-01T20:10:30  <cfields_> sipa: ah, you mean add an initializer to base_blob that accepts uint64's?
4162016-11-01T20:11:18  <GitHub32> [bitcoin] Vitaminmm opened pull request #9059: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/9059
4172016-11-01T20:12:34  <gmaxwell> oh thats from his master, if we care to replace it with folgers crystals.
4182016-11-01T20:14:15  <GitHub88> [bitcoin] MarcoFalke closed pull request #9059: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/9059
4192016-11-01T20:14:15  <sipa> cfields_: no, have a constexpr function that takes a hex string... if the string has length 0, return 0. if not, call recursively, multiply by 16 and add the new hex digit
4202016-11-01T20:14:34  <sipa> cfields_: oh wait, uint256 no longer has operator* and operator+
4212016-11-01T20:15:14  <cfields_> sipa: right, just dumb bits
4222016-11-01T20:16:31  <sipa> cfields_: so ignore what i said
4232016-11-01T20:17:23  <cfields_> sipa: roger. doing it in 64bit chunks would probably be cleaner, though
4242016-11-01T20:56:36  *** Victorsueca has joined #bitcoin-core-dev
4252016-11-01T20:59:58  *** fengling has joined #bitcoin-core-dev
4262016-11-01T21:01:16  *** molz has joined #bitcoin-core-dev
4272016-11-01T21:04:34  *** moli has quit IRC
4282016-11-01T21:05:13  *** fengling has quit IRC
4292016-11-01T21:29:21  *** molz has quit IRC
4302016-11-01T21:29:33  *** moli has joined #bitcoin-core-dev
4312016-11-01T21:57:20  *** justanotheruser has joined #bitcoin-core-dev
4322016-11-01T22:01:00  *** fengling has joined #bitcoin-core-dev
4332016-11-01T22:06:16  *** fengling has quit IRC
4342016-11-01T22:26:17  *** justanotheruser has quit IRC
4352016-11-01T22:27:16  *** justanotheruser has joined #bitcoin-core-dev
4362016-11-01T22:28:42  *** Guyver2 has quit IRC
4372016-11-01T22:48:04  *** Alina-malina has quit IRC
4382016-11-01T23:02:00  *** fengling has joined #bitcoin-core-dev
4392016-11-01T23:06:54  <dgenr8> PR#6
4402016-11-01T23:06:55  <gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
4412016-11-01T23:06:58  <dgenr8> sorry, meant for apple ][ window
4422016-11-01T23:07:19  *** fengling has quit IRC
4432016-11-01T23:12:54  * btcdrak stabs gribble
4442016-11-01T23:17:54  * achow101 calls an ambulance for gribble
4452016-11-01T23:27:52  *** owowo has quit IRC
4462016-11-01T23:33:39  *** owowo has joined #bitcoin-core-dev
4472016-11-01T23:40:16  *** owowo has quit IRC
4482016-11-01T23:45:04  *** owowo has joined #bitcoin-core-dev
4492016-11-01T23:45:05  *** owowo has joined #bitcoin-core-dev
4502016-11-01T23:45:05  *** owowo has joined #bitcoin-core-dev
4512016-11-01T23:46:29  *** murch has quit IRC
4522016-11-01T23:48:18  *** notmike has joined #bitcoin-core-dev
4532016-11-01T23:59:40  *** notmike has quit IRC