--- Day changed Tue Nov 01 2016 00:09 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [] 00:13 -!- rebroad [~rebroad@175.145.183.164] has joined #bitcoin-core-dev 00:19 < jonasschnelli> test #8977 00:19 < 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 00:20 < jonasschnelli> I think this is useful,.. but agree maybe double-hash ##xxx would result in less noise. 00:23 < sipa> if we want to modify it to something more strict, i'd prefer PRXXXX (without #), as that's easier to type as well 00:24 < jonasschnelli> Yes. That would also work... 00:32 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 00:33 < GitHub103> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3d69ecb4edeb...273bde37d867 00:33 < GitHub103> bitcoin/master 3333e5a MarcoFalke: [qt] Return useful error message on ATMP failure 00:33 < GitHub103> bitcoin/master 273bde3 Jonas Schnelli: Merge #9043: [qt] Return useful error message on ATMP failure... 00:33 < 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 00:39 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 00:39 -!- echonaut4 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 00:46 < rebroad> does gribble no longer report pull requests I open? 00:48 < rebroad> test #9055 00:48 < gribble> https://github.com/bitcoin/bitcoin/issues/9055 | Skip processing of cmpctblocks we have previously downloaded. by rebroad · Pull Request #9055 · bitcoin/bitcoin · GitHub 00:49 < rebroad> jonasschnelli, what does the test command do please? 00:49 < jonasschnelli> rebroad: a test. :) 00:49 < rebroad> jonasschnelli, ah, thank you. most enlightening 00:58 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds] 00:59 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 01:07 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jcjjnzchuwelkupo] has quit [Quit: Connection closed for inactivity] 01:12 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has joined #bitcoin-core-dev 01:18 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 01:22 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 01:27 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vtytyaptrocncytq] has joined #bitcoin-core-dev 01:37 -!- DigiByteDev [~JT2@218.250.11.174] has quit [Ping timeout: 260 seconds] 01:38 -!- DigiByteDev [~JT2@69.167.31.229] has joined #bitcoin-core-dev 01:51 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev 01:59 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep] 02:04 < 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... 02:04 < jonasschnelli> Is there a max timeout or something similar until we release the block from the mapBlocksInFlight? 02:04 < jonasschnelli> and re-request it from a different peer? 02:08 < gmaxwell> jonasschnelli: yes, we will eventually hang up on the peer after 10 minutes, see BLOCK_DOWNLOAD_TIMEOUT_BASE 02:08 < jonasschnelli> gmaxwell: thanks. Also just stumbled over state->nDownloadingSince 02:09 < jonasschnelli> gmaxwell: for my hybrid-SPV-PR this seems to be to long... 02:09 -!- DigiByteDev [~JT2@69.167.31.229] has quit [Quit: DigiByteDev] 02:09 < 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... 02:10 < gmaxwell> why is that any different for hybrid-spv-pr than normal operation? 02:10 < jonasschnelli> Yes. Same for normal operation. 02:11 < jonasschnelli> If blocks are dropping in in a ~10min interval, the UX of an SPV mode is almost broken.. 02:11 < 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...) 02:11 < jonasschnelli> I guess during full-validation. people tend to be more patient. 02:11 < gmaxwell> jonasschnelli: what? 02:12 < gmaxwell> are you forcing in order block processing or something? 02:13 < gmaxwell> normally during sync the timeout isn't the mechenism that deals with slow peers, the stalling mechenism is. 02:13 < jonasschnelli> gmaxwell: I'm working on an SPV modes where the wallet can specifically request (priorize) a block-sequence 02:13 < jonasschnelli> "Normal" IBD interrupts, FindNextBlocksToDownload prefers specific request 02:13 < gmaxwell> And it doesn't have any tricky and failure prone hard timeouts, it punts peers that stall the transfer. 02:14 < gmaxwell> so the good performance of other peers is the test rather than a static timeout. 02:16 < 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. 02:17 < 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. 02:19 < 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 02:20 < 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) 02:21 < 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.) 02:22 < jonasschnelli> Okay. Thanks. 02:22 < jonasschnelli> BIP152 doesn't helps in the SPV mode (UTXO set not ready) 02:22 < gmaxwell> UTXO set? you mean mempool. 02:23 < jonasschnelli> Yes. But no UXTO set no mempool. :) 02:23 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev 02:24 < 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? 02:25 < 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. 02:25 -!- rebroad [~rebroad@175.145.183.164] has quit [Ping timeout: 250 seconds] 02:25 < 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. 02:26 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev 02:27 < 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 02:27 < gmaxwell> cause failure, and if the node's bandwidth goes down, it will adapt back after a couple failures. 02:28 < gmaxwell> that kind of adaptive threshold just wasn't very important so far because of the combination of other methods. 02:28 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep] 02:35 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 02:45 < phantomcircuit> jonasschnelli: hybrid-spv-pr? 02:45 < phantomcircuit> wat 03:04 -!- rebroad [~rebroad@175.144.3.177] has joined #bitcoin-core-dev 03:06 -!- rebroad [~rebroad@175.144.3.177] has quit [Read error: Connection reset by peer] 03:10 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 03:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:21 -!- rebroad [~rebroad@175.144.3.177] has joined #bitcoin-core-dev 03:24 -!- murch [~murch@p4FE38220.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 03:26 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev 03:31 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep] 03:37 -!- rebroad [~rebroad@175.144.3.177] has quit [Ping timeout: 244 seconds] 03:49 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 03:54 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 04:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 04:16 -!- cryptapus [~cryptapus@87.254.202.233] has joined #bitcoin-core-dev 04:16 -!- cryptapus [~cryptapus@87.254.202.233] has quit [Changing host] 04:16 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:50 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 04:55 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 04:57 -!- rebroad [~rebroad@2001:e68:4434:9aaf:c96c:6344:2c24:7d3e] has joined #bitcoin-core-dev 05:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:18 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has quit [Ping timeout: 260 seconds] 05:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 05:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:24 -!- dermoth_ [~thomas@dial-216-221-46-134.mtl.aei.ca] has joined #bitcoin-core-dev 05:24 -!- dermoth [~thomas@dsl-216-221-32-179.mtl.aei.ca] has quit [Disconnected by services] 05:24 -!- dermoth_ is now known as dermoth 05:37 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev 05:44 < jl2012> sipa: I got a question from a block explorer dev. How do we want people to present bare segwit on explorers? 05:47 < jl2012> I never thought of that. Maybe using the hex? 05:47 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev] 05:51 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 05:56 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 06:03 -!- ClockCat [~CattieCat@75-109-228-219.stjocmtk01.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 06:15 < jonasschnelli> phantomcircuit: Yes. Will PR soon. Need to write a RPC test first,... which is non-trivial 06:16 < jonasschnelli> I guess you are familiar with the idea of SPV during IBD/sync (= hybrid SPV) 06:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 06:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 06:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 06:40 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds] 06:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 06:53 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 06:57 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 07:03 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 07:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 07:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:19 -!- aalex [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer] 07:20 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 07:21 -!- rebroad [~rebroad@2001:e68:4434:9aaf:c96c:6344:2c24:7d3e] has quit [Ping timeout: 245 seconds] 07:27 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev] 07:53 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 07:54 < 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 07:58 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 08:05 < phantomcircuit> jonasschnelli: ah yeah 08:05 < phantomcircuit> for the wallet only right? 08:07 < jl2012> sipa: for block explorer, I think they should display bare segwit with P2SH addresses. Just like how they display P2PK as P2PKH address 08:10 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 08:18 -!- vdefeo [~vdefeo@37.189.90.239] has joined #bitcoin-core-dev 08:27 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 08:32 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev 08:33 -!- vdefeo [~vdefeo@37.189.90.239] has quit [] 08:36 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer] 08:54 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 08:56 -!- ClockCat [~CattieCat@75-109-228-219.stjocmtk01.res.dyn.suddenlink.net] has quit [Quit: Leaving] 08:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:59 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 09:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lmnydpgbvazstyka] has quit [Quit: Connection closed for inactivity] 09:08 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:690f:de64:957d:87df] has joined #bitcoin-core-dev 09:08 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-deyaewtponxupkoo] has quit [Ping timeout: 260 seconds] 09:10 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-ejmuztsevtenzywj] has joined #bitcoin-core-dev 09:10 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:c183:298d:e344:642d] has quit [Ping timeout: 260 seconds] 09:18 < NicolasDorier> jl2012: nop 09:18 < NicolasDorier> it confuses new devs 09:19 < NicolasDorier> best is just to show 0 09:19 < jl2012> or just the hex 09:19 < NicolasDorier> yeah or just the hex 09:20 < 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 09:38 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev 09:44 -!- abpa [~textual@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:55 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 10:01 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 10:16 < 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? 10:17 < 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 10:17 < sipa> what does his copy-move branch do? 10:17 < gmaxwell> jl2012: showing some other address would cause loss of funds. 10:18 < morcos> theuni/bitcoin/copy-move 10:18 < gmaxwell> jl2012: people would sends funds to those addresses and because they're not the same, wallets would ignore those payments. 10:18 < jl2012> gmaxwell: yes, i think that's not a good idea. But core is still showing P2PK as P2PKH 10:19 < sipa> morcos: casting a const field to non-const is undefined behaviour 10:19 < gmaxwell> yes, legacy behavior but at least a ubiquitous one. 10:19 < morcos> sipa: if i recall cfields was thinking it wouldn't show a big speedup, but it definitely makes a noticeable difference for me. 10:19 < jl2012> ok, i told them to use raw hex directly 10:19 < sipa> morcos: we currently do it in CTransaction, but I have a PR to get rid of it 10:19 < morcos> sipa: you're referring to the move operator for CTransaction (or whatever thats called) in the 2nd commit? 10:20 < 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 10:20 < morcos> i just briefly tried putting an assert(false) in there and it worked just fine... 10:21 < sipa> morcos: oh, making prevector movable is fine! 10:21 < sipa> i missed there were two commits 10:21 < 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... 10:22 < morcos> pehraps the thing holding cfields_ up from actually PR'ing it is you can't use is_trivially_copyable 10:22 < morcos> and maybe he wanted some protection for that 10:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ugscqcqjdbrlsjeb] has joined #bitcoin-core-dev 10:30 < sipa> is_trivially_copyable is certainly fine for the current use cases 10:31 < morcos> no i mean its not supported everywhere, for instance in gcc 4.8 or whatever i have on ubuntu 14.04 10:32 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep] 10:33 < sipa> that's something you wonder about, or an issue you know? 10:34 < morcos> yeah it didn't compile for me until i commented those lines out 10:34 < sipa> afaik is_trivially_copyable is just c++11, so every compliant compiler should have it 10:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] 10:35 < gmaxwell> sipa: it's libstdc++ though, not GCC itself. 10:35 < 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 10:36 < morcos> ehh, type properties.. see https://gcc.gnu.org/onlinedocs/gcc-4.8.4/libstdc++/manual/manual/status.html#status.iso.2011 10:38 < sipa> i see 10:41 < sipa> well we can temporarily define our own, for just the types we use it for 10:43 < 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? 10:43 < morcos> thats where i got lost in yoru conversation the other day 10:43 < sipa> right, the move constructor would be identical to the copy constructor 10:44 < 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 10:44 < 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 10:44 < sipa> in particular in CBlock 10:45 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye] 10:46 < 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 10:46 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 10: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) 10:47 < morcos> but what in the world do you do during startup... 10:50 < gmaxwell> oh thats cute... during startup: mempool saving. :) (later: mempool sync) 10:50 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 10:51 < 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) 10:52 < gmaxwell> "don't do it then" 10:53 < morcos> it's sad how long HaveInputs takes in a reindex-chainstate or similar operation 10:54 < sipa> morcos: even with huge dbcache? 10:54 < sipa> because HaveInputs is what triggers the fetch from disk if an entry is not cached 10:54 < morcos> sipa: no thats what i mean. with a reasonable sized one 10:55 < morcos> i'm wondering if when you go to flush it, you can be smart about keeping some useful stuff in there... 10:56 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 10:56 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 11:02 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 11:02 < sipa> perhaps we should experiment with per-output caching rather than per-tx 11:05 < morcos> sipa: i just worry that without changing the whole database it'll be hard to use that efficiently 11:05 < sipa> oh, sure, the database will need to change 11:05 < sipa> but it can be converted on startup or so 11:05 < morcos> well you could imagine a middle ground.. but yeah i agree, cleaner to just do the whole thing 11:06 < sipa> the one thing i'm not clear on is how to deal with the (few) per-tx values 11:08 < morcos> well, we should stop storing nVersion 11:08 < morcos> i think what we store for that is undefined actually 11:09 < sipa> agree, i doubt we'll need it 11:09 < 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 11:09 < sipa> indeed 11:09 < morcos> there is a comment about it not properly handling negative numbers already 11:10 < sipa> so if it's just height and coinbaseness, we could perhaps have just coinbaseness stored in every utxo 11:10 < sipa> and a separate map with remembered heights of coinbase tn 11:11 < morcos> you need the height for more than coinbase though right? 11:11 < sipa> do we? 11:11 < morcos> bip68? 11:11 < sipa> oh, with bip68 we do 11:11 < sipa> ok 11:11 < sipa> maybe it's easier to not bother with deduplicating the height then 11:12 < morcos> certainly easier! 11:13 < morcos> so will the txid be duplicated on disk though for each utxo? 11:14 < 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? 11:15 < sipa> i believe that leveldb efficiently represents may keys with the same prefix 11:16 < sipa> *many 11:16 < sipa> but i can't find a reference for it 11:19 < instagibbs> does the rpc tester eventually time out? It's hanging on me and I can't tell which test is triggering the timeout 11:19 < sipa> bigtable (the internal system at google that leveldb is an opensource simplified version of) certainly does that 11:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 11:26 < 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 11:27 < sipa> downside: twice the number of disk seeks 11:28 < morcos> sipa: yeah i 2 disk ops is going to be worse for a lot of disks 11:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:30 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 245 seconds] 11:31 < sipa> or we can of course leave the disk format intact 11:33 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 11:41 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev] 11:57 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 12:03 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 12:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 12:21 < 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. 12:22 < BlueMatt> "The Alert System has been deprecated. Please upgrade your client" 12:22 < BlueMatt> ? 12:25 < gmaxwell> What I wrote before checking to see the language of the current warning was "Alerts are retired and removed in current software." 12:25 < gmaxwell> BlueMatt: your suggestion suggests that alerts are the only reason to upgrade. 12:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 12:25 < achow101> How about "Upgrading is strongly recommended" instead of "Please upgrade your client" 12:26 < achow101> won't both the alert and the other message be displayed simultaneously? 12:26 < gmaxwell> It's weird to override a more serious warning with a less serious one. 12:26 < gmaxwell> achow101: no, they can't be. 12:27 < gmaxwell> achow101: the messages have a priority and the highest priority active alert is displayed. 12:27 < 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. 12:28 < achow101> What about two different messages, one for those who are showing that upgrade required alert, and one not? 12:28 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 12:29 < 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) 12:29 < BlueMatt> sipa: we're all getting emails about old releases :( 12:29 < BlueMatt> bitcoin 0.10.4 released 12:29 < sdaftuar> time to upgrade! 12:31 < 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" 12:31 < sipa> BlueMatt: oops 12:31 < sipa> BlueMatt: i was just adding release notes to tags 12:32 < BlueMatt> yea, i figured 12:32 < BlueMatt> whatever, one-time cost 12:32 < sipa> as they weren't showing up on https://github.com/bitcoin/bitcoin/releases 12:32 < sipa> i'm done now 12:32 < arubi> genuinely asking, why not recommend to run with -alerts=0 from now and that's it? 12:32 < 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. 12:32 < gmaxwell> arubi: uh oh. confusion detected. 12:33 < arubi> is that a different alert then? 12:33 < gmaxwell> arubi: alert=0 has been the case for many versions, and since 0.13.0 the alert system is gone entirely. 12:33 < arubi> yea but you were talking about 0.12.2 12:33 < gmaxwell> arubi: that has alert=0 by default. 12:34 < arubi> I see, "prior to" 12:34 < TD-Linux> gmaxwell, just concatenate the messages? "In addition, the alert system..." 12:34 < 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 12:35 < 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. 12:36 < BlueMatt> http://bitcoinfibre.org/public-network.html 12:37 < 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" 12:37 < 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 12:38 < achow101> maybe have a "due to soft forks" after "rules out of date" 12:38 < kanzure> high amounts of meail from recent releases on github 12:38 < kanzure> .. email. 12:38 < sipa> kanzure: i'm sorry, i didn't know it was mailing people 12:38 < kanzure> it's fine. just a heads up. 12:38 < sipa> kanzure: they're listed now on https://github.com/bitcoin/bitcoin/releases 12:39 < kanzure> ya it is nice 12:44 < achow101> gmaxwell: if the message is an issue now, what about when "Alert Key Compromised" is sent? 12:44 < gmaxwell> arubi: yes, -- the local message and alerts are handled in exactly the same way. 12:44 < gmaxwell> achow101: it's even more urgent though, and also less of an issue since we'll have months of this message being displayed. 12:46 < achow101> ok. What do you think about my other suggestion? 12:47 < arubi> thanks gmaxwell, I'll have to play around with alerts= with my own mock alert key 12:50 < 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" 12:51 < achow101> sounds good to me. 12:53 < achow101> how do you even send an alert? 12:53 < gmaxwell> achow101: using software bitcoin's creator wrote which has never been publically distributed. 12:54 < gmaxwell> (AFAIK) 12:54 < achow101> does it happen to look like this: https://gist.github.com/laanwj/0e689cfa37b52bcbbb44 ? 12:56 < gmaxwell> well then. 12:56 < phantomcircuit> gmaxwell: possibly just send the same message 12:56 < phantomcircuit> iirc there are very very old versions which wont show that warning 12:56 < gmaxwell> yes, though AFAICT all of those are forked off. :) 12:57 < 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. 12:58 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 12:59 < cfields_> sipa: https://github.com/theuni/bitcoin/commits/uint-literal 13:04 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 13:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds] 13:05 < sipa> cfields_: hmm, i would expect something that just uses return (4*(recursive call)+(new digit)) on a uint256 13:08 < cfields_> sipa: hmm? 13:10 < cfields_> sipa: ah, you mean add an initializer to base_blob that accepts uint64's? 13:11 < GitHub32> [bitcoin] Vitaminmm opened pull request #9059: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/9059 13:12 < gmaxwell> oh thats from his master, if we care to replace it with folgers crystals. 13:14 < GitHub88> [bitcoin] MarcoFalke closed pull request #9059: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/9059 13:14 < 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 13:14 < sipa> cfields_: oh wait, uint256 no longer has operator* and operator+ 13:15 < cfields_> sipa: right, just dumb bits 13:16 < sipa> cfields_: so ignore what i said 13:17 < cfields_> sipa: roger. doing it in 64bit chunks would probably be cleaner, though 13:56 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 13:56 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 13:59 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 14:01 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 14:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 14:05 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 14:29 -!- molz [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 14:29 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 14:57 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:01 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 15:06 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 15:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.5] 15:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:48 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 260 seconds] 16:02 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 16:06 < dgenr8> PR#6 16:06 < gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub 16:06 < dgenr8> sorry, meant for apple ][ window 16:07 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 16:12 * btcdrak stabs gribble 16:17 * achow101 calls an ambulance for gribble 16:27 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 244 seconds] 16:33 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 16:40 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 244 seconds] 16:45 -!- owowo [ovovo@gateway/vpn/mullvad/x-fxzjytlupubuqbba] has joined #bitcoin-core-dev 16:45 -!- owowo [ovovo@gateway/vpn/mullvad/x-fxzjytlupubuqbba] has quit [Changing host] 16:45 -!- owowo [ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 16:45 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host] 16:45 -!- owowo [ovovo@gateway/vpn/mullvad/x-fxzjytlupubuqbba] has joined #bitcoin-core-dev 16:46 -!- murch [~murch@p4FE38220.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 16:48 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev 16:59 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep] 17:02 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 17:07 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 17:24 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 17:35 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev 17:53 -!- abpa [~textual@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:00 -!- echonaut4 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 18:00 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 18:02 -!- harrymm [~wayne@104.222.140.123] has quit [Quit: Leaving.] 18:03 -!- harrymm [~wayne@104.222.140.92] has joined #bitcoin-core-dev 18:04 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 18:08 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds] 18:12 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 18:13 < GitHub120> [bitcoin] robmcl4 opened pull request #9060: trivial: fix bloom filter init to isEmpty = true (master...fix-bloom-filter-empty-init) https://github.com/bitcoin/bitcoin/pull/9060 18:27 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vtytyaptrocncytq] has quit [Quit: Connection closed for inactivity] 18:29 < TD-Linux> dgenr8, time to upgrade to an autostart rom 18:40 -!- Tiraspol [~Tiraspol@unaffiliated/tiraspol] has joined #bitcoin-core-dev 18:48 -!- ill [~ill@32.210.34.9] has quit [Ping timeout: 252 seconds] 18:48 -!- ill [~ill@32.210.34.9] has joined #bitcoin-core-dev 19:02 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 19:14 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 19:14 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit] 19:15 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 19:34 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 19:35 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 19:48 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 19:55 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev] 19:58 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 250 seconds] 20:13 -!- justanotheruser is now known as justanother|CHI 20:24 -!- justanother|CHI is now known as justanother|LBS 20:26 -!- justanother|LBS is now known as justanother\_ub 20:35 < GitHub31> [bitcoin] rebroad opened pull request #9061: Ignore getheaders prior to passing all checkpoints. (master...FixGetheadersResponseWhenSyncing) https://github.com/bitcoin/bitcoin/pull/9061 20:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:55 -!- justanother\_ub [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] 21:01 < gmaxwell> rebroad: Ignoring getheaders tends to dos attack peers. 21:15 -!- abpa [~abpa@2604:5500:16:6:ece9:d971:d9f4:c713] has joined #bitcoin-core-dev 21:39 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep] 21:58 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev 22:01 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host] 22:01 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 22:49 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 22:52 -!- juscamarena [~jus@47.148.176.74] has joined #bitcoin-core-dev 23:00 -!- dermoth [~thomas@dial-216-221-46-134.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:00 -!- dermoth [~thomas@dial-216-221-46-134.mtl.aei.ca] has joined #bitcoin-core-dev 23:08 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-aeyyjswbshpotbut] has joined #bitcoin-core-dev 23:41 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has joined #bitcoin-core-dev