1 2016-11-01 00:12:18	0|instagibbs|BlueMatt in not too long it will be 5 digits...
  2 2016-11-01 00:14:10	0|sipa|at which point we'll need a bot even more
  3 2016-11-01 00:33:30	0|nanotube|BlueMatt: that can be easily arranged.
  4 2016-11-01 00:43:33	0|GitHub141|[13bitcoin] 15gmaxwell opened pull request #9052: Use RelevantServices instead of node_network in AttemptToEvict. (06master...06prefer_relevant2) 02https://github.com/bitcoin/bitcoin/pull/9052
  5 2016-11-01 00:47:27	0|GitHub58|[13bitcoin] 15gmaxwell opened pull request #9053: IBD using chainwork instead of height and not using header timestamps (06master...06no_checkpoint_for_ibd) 02https://github.com/bitcoin/bitcoin/pull/9053
  6 2016-11-01 00:47:29	0|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
  7 2016-11-01 00:47:54	0|gmaxwell|haha
  8 2016-11-01 00:47:58	0|nanotube|haha well... i guess gribble should ignore github >_>
  9 2016-11-01 00:48:01	0|gmaxwell|so perhaps it should ignore gitub.
 10 2016-11-01 00:48:12	0|nanotube|:)
 11 2016-11-01 00:48:22	0|sipa|yay, consensus
 12 2016-11-01 00:48:39	0|gmaxwell|I like Red #40 dye.
 13 2016-11-01 00:48:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/40 | -rpcssl help text by dooglus · Pull Request #40 · bitcoin/bitcoin · GitHub
 14 2016-11-01 00:49:11	0|sipa|roses are #FF0000
 15 2016-11-01 00:50:09	0|nanotube|the regex just looks for #\d+
 16 2016-11-01 00:50:34	0|achow101|#10000
 17 2016-11-01 00:50:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/10000 | HTTP Error 404: Not Found
 18 2016-11-01 00:52:15	0|sipa|so what if you refer to two in one line, like how #8708 will conflict with #9039
 19 2016-11-01 00:52:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/8708 | net: have CConnman handle message sending by theuni · Pull Request #8708 · bitcoin/bitcoin · GitHub
 20 2016-11-01 00:52:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/9039 | Various serialization simplifcations and optimizations by sipa · Pull Request #9039 · bitcoin/bitcoin · GitHub
 21 2016-11-01 00:52:29	0|phantomcircuit|gmaxwell: int64_t &nOrderNextPos = nOrderNextPos in CWallet::ReorderTransactions is trying to assign a reference to itself not the member variable
 22 2016-11-01 00:52:34	0|nanotube|^ that happens :)
 23 2016-11-01 00:52:36	0|phantomcircuit|i dont get this
 24 2016-11-01 00:52:38	0|phantomcircuit|do you?
 25 2016-11-01 00:52:50	0|sipa|phantomcircuit: ha
 26 2016-11-01 00:53:07	0|sipa|phantomcircuit: yes, variables are defined during their own initializer
 27 2016-11-01 00:53:50	0|phantomcircuit|ok then i understand what was wrong with #8828
 28 2016-11-01 00:53:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/8828 | Move CWalletDB::ReorderTransactions to CWallet by pstratem · Pull Request #8828 · bitcoin/bitcoin · GitHub
 29 2016-11-01 00:54:02	0|sipa|similar to how you can call a function inside that function's body
 30 2016-11-01 01:51:13	0|sipa|should we introduce http://en.cppreference.com/w/cpp/language/user_literal for uint256?
 31 2016-11-01 01:52:56	0|gmaxwell|sipa: would there be any benefits beyond saving a few bytes of source code for each of the couple uint256 constants we have?
 32 2016-11-01 01:57:31	0|sipa|no
 33 2016-11-01 01:58:51	0|cfields_|sipa: mm, i coded that up at one point
 34 2016-11-01 01:59:40	0|cfields_|gmaxwell: it's especially nice because you can initialize on the stack more quickly (and efficiently)
 35 2016-11-01 02:00:11	0|sipa|cfields_: it's just an invocation to a conversion operator, instead of a function
 36 2016-11-01 02:00:20	0|cfields_|(you can parse a variadic of hex chars as constexpr, so the parsing is free)
 37 2016-11-01 02:00:20	0|sipa|i'm pretty sure there's no difference at runtime
 38 2016-11-01 02:00:28	0|sipa|oh!
 39 2016-11-01 02:00:39	0|sipa|well we could also make uint256S constexpr then?
 40 2016-11-01 02:00:56	0|cfields_|sipa: well, it only works for literals
 41 2016-11-01 02:01:16	0|gmaxwell|I think in all cases they get stashed in constants, so it shouldn't really make a runtime difference.
 42 2016-11-01 02:02:23	0|cfields_|yea, in reality it's negligible. I just did it to play with the variadics + user literals. But it made chainparams look prettier :)
 43 2016-11-01 02:02:28	0|cfields_|i'll see if i can dig it up
 44 2016-11-01 02:07:08	0|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
 45 2016-11-01 02:07:22	0|sipa|which you could only pass literals or other constexpr strings
 46 2016-11-01 02:07:48	0|sipa|and compared to that, a user-defined literal is purely syntactic sugar?
 47 2016-11-01 02:09:45	0|cfields_|sipa: sure, i suppose so
 48 2016-11-01 03:40:43	0|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.)
 49 2016-11-01 03:46:54	0|sipa|gmaxwell: chainActive.Tip()->nChainWork may segfault before the genesis block is loaded
 50 2016-11-01 03:47:09	0|sipa|almost all platforms fail, that doesn't look like a spurious error
 51 2016-11-01 03:48:02	0|gmaxwell|sipa: on #1 fair comment, but they're failing in test_bitcoin prevector tests.
 52 2016-11-01 03:48:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
 53 2016-11-01 03:48:12	0|gmaxwell|die
 54 2016-11-01 03:48:21	0|sipa|hahahaha
 55 2016-11-01 03:57:14	0|luke-jr|lol
 56 2016-11-01 05:40:17	0|btcdrak|#2
 57 2016-11-01 05:40:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
 58 2016-11-01 05:40:35	0|btcdrak|oh thats going to get annoying
 59 2016-11-01 05:41:09	0|gmaxwell|Perhaps we should as nano to change it to PR#xxxx
 60 2016-11-01 05:41:13	0|sipa|or we adapt
 61 2016-11-01 05:41:46	0|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.
 62 2016-11-01 05:48:28	0|TD-Linux|gmaxwell, it's not banned sadly
 63 2016-11-01 07:19:51	0|jonasschnelli|test #8977
 64 2016-11-01 07:19:53	0|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
 65 2016-11-01 07:20:31	0|jonasschnelli|I think this is useful,.. but agree maybe double-hash ##xxx would result in less noise.
 66 2016-11-01 07:23:30	0|sipa|if we want to modify it to something more strict, i'd prefer PRXXXX (without #), as that's easier to type as well
 67 2016-11-01 07:24:37	0|jonasschnelli|Yes. That would also work...
 68 2016-11-01 07:33:38	0|GitHub103|13bitcoin/06master 143333e5a 15MarcoFalke: [qt] Return useful error message on ATMP failure
 69 2016-11-01 07:33:38	0|GitHub103|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3d69ecb4edeb...273bde37d867
 70 2016-11-01 07:33:39	0|GitHub103|13bitcoin/06master 14273bde3 15Jonas Schnelli: Merge #9043: [qt] Return useful error message on ATMP failure...
 71 2016-11-01 07:33:53	0|GitHub3|[13bitcoin] 15jonasschnelli closed pull request #9043: [qt] Return useful error message on ATMP failure (06master...06Mf1611-qtATMPerror) 02https://github.com/bitcoin/bitcoin/pull/9043
 72 2016-11-01 07:46:17	0|rebroad|does gribble no longer report pull requests I open?
 73 2016-11-01 07:48:32	0|rebroad|test #9055
 74 2016-11-01 07:48:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/9055 | Skip processing of cmpctblocks we have previously downloaded. by rebroad · Pull Request #9055 · bitcoin/bitcoin · GitHub
 75 2016-11-01 07:49:02	0|rebroad|jonasschnelli, what does the test command do please?
 76 2016-11-01 07:49:18	0|jonasschnelli|rebroad: a test. :)
 77 2016-11-01 07:49:37	0|rebroad|jonasschnelli, ah, thank you. most enlightening
 78 2016-11-01 09:04:02	0|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...
 79 2016-11-01 09:04:25	0|jonasschnelli|Is there a max timeout or something similar until we release the block from the mapBlocksInFlight?
 80 2016-11-01 09:04:32	0|jonasschnelli|and re-request it from a different peer?
 81 2016-11-01 09:08:20	0|gmaxwell|jonasschnelli: yes, we will eventually hang up on the peer after 10 minutes, see BLOCK_DOWNLOAD_TIMEOUT_BASE
 82 2016-11-01 09:08:39	0|jonasschnelli|gmaxwell: thanks. Also just stumbled over state->nDownloadingSince
 83 2016-11-01 09:09:02	0|jonasschnelli|gmaxwell: for my hybrid-SPV-PR this seems to be to long...
 84 2016-11-01 09:09:26	0|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...
 85 2016-11-01 09:10:15	0|gmaxwell|why is that any different for hybrid-spv-pr than normal operation?
 86 2016-11-01 09:10:35	0|jonasschnelli|Yes. Same for normal operation.
 87 2016-11-01 09:11:12	0|jonasschnelli|If blocks are dropping in in a ~10min interval, the UX of an SPV mode is almost broken..
 88 2016-11-01 09:11:27	0|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...)
 89 2016-11-01 09:11:32	0|jonasschnelli|I guess during full-validation. people tend to be more patient.
 90 2016-11-01 09:11:50	0|gmaxwell|jonasschnelli: what?
 91 2016-11-01 09:12:12	0|gmaxwell|are you forcing in order block processing or something?
 92 2016-11-01 09:13:03	0|gmaxwell|normally during sync the timeout isn't the mechenism that deals with slow peers, the stalling mechenism is.
 93 2016-11-01 09:13:08	0|jonasschnelli|gmaxwell: I'm working on an SPV modes where the wallet can specifically request (priorize) a block-sequence
 94 2016-11-01 09:13:44	0|jonasschnelli|"Normal" IBD interrupts, FindNextBlocksToDownload prefers specific request
 95 2016-11-01 09:13:56	0|gmaxwell|And it doesn't have any tricky and failure prone hard timeouts, it punts peers that stall the transfer.
 96 2016-11-01 09:14:21	0|gmaxwell|so the good performance of other peers is the test rather than a static timeout.
 97 2016-11-01 09:16:37	0|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.
 98 2016-11-01 09:17:29	0|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.
 99 2016-11-01 09:19:23	0|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
100 2016-11-01 09:20:27	0|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)
101 2016-11-01 09:21:07	0|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.)
102 2016-11-01 09:22:01	0|jonasschnelli|Okay. Thanks.
103 2016-11-01 09:22:22	0|jonasschnelli|BIP152 doesn't helps in the SPV mode (UTXO set not ready)
104 2016-11-01 09:22:53	0|gmaxwell|UTXO set? you mean mempool.
105 2016-11-01 09:23:12	0|jonasschnelli|Yes. But no UXTO set no mempool. :)
106 2016-11-01 09:24:51	0|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?
107 2016-11-01 09:25:29	0|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.
108 2016-11-01 09:25:49	0|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.
109 2016-11-01 09:27:49	0|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
110 2016-11-01 09:27:55	0|gmaxwell|cause failure, and if the node's bandwidth goes down, it will adapt back after a couple failures.
111 2016-11-01 09:28:35	0|gmaxwell|that kind of adaptive threshold just wasn't very important so far because of the combination of other methods.
112 2016-11-01 09:45:28	0|phantomcircuit|jonasschnelli: hybrid-spv-pr?
113 2016-11-01 09:45:29	0|phantomcircuit|wat
114 2016-11-01 12:44:58	0|jl2012|sipa: I got a question from a block explorer dev. How do we want people to present bare segwit on explorers?
115 2016-11-01 12:47:18	0|jl2012|I never thought of that. Maybe using the hex?
116 2016-11-01 13:15:51	0|jonasschnelli|phantomcircuit: Yes. Will PR soon. Need to write a RPC test first,... which is non-trivial
117 2016-11-01 13:16:28	0|jonasschnelli|I guess you are familiar with the idea of SPV during IBD/sync (= hybrid SPV)
118 2016-11-01 14:54:28	0|GitHub45|[13bitcoin] 15ryanofsky opened pull request #9058: Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (06master...06fix-8842-sync-timeouts) 02https://github.com/bitcoin/bitcoin/pull/9058
119 2016-11-01 15:05:11	0|phantomcircuit|jonasschnelli: ah yeah
120 2016-11-01 15:05:15	0|phantomcircuit|for the wallet only right?
121 2016-11-01 15:07:26	0|jl2012|sipa: for block explorer, I think they should display bare segwit with P2SH addresses. Just like how they display P2PK as P2PKH address
122 2016-11-01 16:18:41	0|NicolasDorier|jl2012: nop
123 2016-11-01 16:18:47	0|NicolasDorier|it confuses new devs
124 2016-11-01 16:19:05	0|NicolasDorier|best is just to show 0 <hash>
125 2016-11-01 16:19:22	0|jl2012|or just the hex
126 2016-11-01 16:19:29	0|NicolasDorier|yeah or just the hex
127 2016-11-01 16:20:24	0|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
128 2016-11-01 17:16:36	0|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?
129 2016-11-01 17:17:09	0|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
130 2016-11-01 17:17:31	0|sipa|what does his copy-move branch do?
131 2016-11-01 17:17:38	0|gmaxwell|jl2012: showing some other address would cause loss of funds.
132 2016-11-01 17:18:02	0|morcos|theuni/bitcoin/copy-move
133 2016-11-01 17:18:30	0|gmaxwell|jl2012: people would sends funds to those addresses and because they're not the same, wallets would ignore those payments.
134 2016-11-01 17:18:53	0|jl2012|gmaxwell: yes, i think that's not a good idea. But core is still showing P2PK as P2PKH
135 2016-11-01 17:19:21	0|sipa|morcos: casting a const field to non-const is undefined behaviour
136 2016-11-01 17:19:27	0|gmaxwell|yes, legacy behavior but at least a ubiquitous one.
137 2016-11-01 17:19:27	0|morcos|sipa: if i recall cfields was thinking it wouldn't show a big speedup, but it definitely makes a noticeable difference for me.
138 2016-11-01 17:19:38	0|jl2012|ok, i told them to use raw hex directly
139 2016-11-01 17:19:45	0|sipa|morcos: we currently do it in CTransaction, but I have a PR to get rid of it
140 2016-11-01 17:19:55	0|morcos|sipa: you're referring to the move operator for CTransaction (or whatever thats called) in the 2nd commit?
141 2016-11-01 17:20:35	0|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
142 2016-11-01 17:21:00	0|morcos|i just briefly tried putting an assert(false) in there and it worked just fine...
143 2016-11-01 17:21:16	0|sipa|morcos: oh, making prevector movable is fine!
144 2016-11-01 17:21:25	0|sipa|i missed there were two commits
145 2016-11-01 17:21:53	0|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...
146 2016-11-01 17:22:12	0|morcos|pehraps the thing holding cfields_ up from actually PR'ing it is you can't use is_trivially_copyable
147 2016-11-01 17:22:34	0|morcos|and maybe he wanted some protection for that
148 2016-11-01 17:30:51	0|sipa|is_trivially_copyable is certainly fine for the current use cases
149 2016-11-01 17:31:24	0|morcos|no i mean its not supported everywhere, for instance in gcc 4.8 or whatever i have on ubuntu 14.04
150 2016-11-01 17:33:47	0|sipa|that's something you wonder about, or an issue you know?
151 2016-11-01 17:34:06	0|morcos|yeah it didn't compile for me until i commented those lines out
152 2016-11-01 17:34:06	0|sipa|afaik is_trivially_copyable is just c++11, so every compliant compiler should have it
153 2016-11-01 17:35:13	0|gmaxwell|sipa: it's libstdc++ though, not GCC itself.
154 2016-11-01 17:35:23	0|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
155 2016-11-01 17:36:53	0|morcos|ehh, type properties.. see https://gcc.gnu.org/onlinedocs/gcc-4.8.4/libstdc++/manual/manual/status.html#status.iso.2011
156 2016-11-01 17:38:59	0|sipa|i see
157 2016-11-01 17:41:18	0|sipa|well we can temporarily define our own, for just the types we use it for
158 2016-11-01 17:43:07	0|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?
159 2016-11-01 17:43:22	0|morcos|thats where i got lost in yoru conversation the other day
160 2016-11-01 17:43:55	0|sipa|right, the move constructor would be identical to the copy constructor
161 2016-11-01 17:44:40	0|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
162 2016-11-01 17:44:53	0|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
163 2016-11-01 17:44:53	0|sipa|in particular in CBlock
164 2016-11-01 17:46:15	0|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
165 2016-11-01 17:46:46	0|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)
166 2016-11-01 17:47:09	0|morcos|but what in the world do you do during startup...
167 2016-11-01 17:50:02	0|gmaxwell|oh thats cute... during startup: mempool saving. :) (later: mempool sync)
168 2016-11-01 17:51:50	0|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)
169 2016-11-01 17:52:33	0|gmaxwell|"don't do it then"
170 2016-11-01 17:53:12	0|morcos|it's sad how long HaveInputs takes in a reindex-chainstate or similar operation
171 2016-11-01 17:54:20	0|sipa|morcos: even with huge dbcache?
172 2016-11-01 17:54:40	0|sipa|because HaveInputs is what triggers the fetch from disk if an entry is not cached
173 2016-11-01 17:54:42	0|morcos|sipa: no thats what i mean.  with a reasonable sized one
174 2016-11-01 17:55:10	0|morcos|i'm wondering if when you go to flush it, you can be smart about keeping some useful stuff in there...
175 2016-11-01 18:02:54	0|sipa|perhaps we should experiment with per-output caching rather than per-tx
176 2016-11-01 18:05:08	0|morcos|sipa: i just worry that without changing the whole database it'll be hard to use that efficiently
177 2016-11-01 18:05:25	0|sipa|oh, sure, the database will need to change
178 2016-11-01 18:05:36	0|sipa|but it can be converted on startup or so
179 2016-11-01 18:05:56	0|morcos|well you could imagine a middle ground.. but yeah i agree, cleaner to just do the whole thing
180 2016-11-01 18:06:34	0|sipa|the one thing i'm not clear on is how to deal with the (few) per-tx values
181 2016-11-01 18:08:05	0|morcos|well, we should stop storing nVersion
182 2016-11-01 18:08:16	0|morcos|i think what we store for that is undefined actually
183 2016-11-01 18:09:01	0|sipa|agree, i doubt we'll need it
184 2016-11-01 18:09:03	0|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
185 2016-11-01 18:09:20	0|sipa|indeed
186 2016-11-01 18:09:29	0|morcos|there is a comment about it not properly handling negative numbers already
187 2016-11-01 18:10:14	0|sipa|so if it's just height and coinbaseness, we could perhaps have just coinbaseness stored in every utxo
188 2016-11-01 18:10:27	0|sipa|and a separate map with remembered heights of coinbase tn
189 2016-11-01 18:11:02	0|morcos|you need the height for more than coinbase though right?
190 2016-11-01 18:11:09	0|sipa|do we?
191 2016-11-01 18:11:14	0|morcos|bip68?
192 2016-11-01 18:11:19	0|sipa|oh, with bip68 we do
193 2016-11-01 18:11:20	0|sipa|ok
194 2016-11-01 18:11:34	0|sipa|maybe it's easier to not bother with deduplicating the height then
195 2016-11-01 18:12:28	0|morcos|certainly easier!
196 2016-11-01 18:13:40	0|morcos|so will the txid be duplicated on disk though for each utxo?
197 2016-11-01 18:14:25	0|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?
198 2016-11-01 18:15:58	0|sipa|i believe that leveldb efficiently represents may keys with the same prefix
199 2016-11-01 18:16:04	0|sipa|*many
200 2016-11-01 18:16:15	0|sipa|but i can't find a reference for it
201 2016-11-01 18:19:16	0|instagibbs|does the rpc tester eventually time out? It's hanging on me and I can't tell which test is triggering the timeout
202 2016-11-01 18:19:57	0|sipa|bigtable (the internal system at google that leveldb is an opensource simplified version of) certainly does that
203 2016-11-01 18:26:58	0|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
204 2016-11-01 18:27:16	0|sipa|downside: twice the number of disk seeks
205 2016-11-01 18:28:44	0|morcos|sipa: yeah i 2 disk ops is going to be worse for a lot of disks
206 2016-11-01 18:31:15	0|sipa|or we can of course leave the disk format intact
207 2016-11-01 19:21:39	0|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.
208 2016-11-01 19:22:10	0|BlueMatt|"The Alert System has been deprecated. Please upgrade your client"
209 2016-11-01 19:22:12	0|BlueMatt|?
210 2016-11-01 19:25:07	0|gmaxwell|What I wrote before checking to see the language of the current warning was "Alerts are retired and removed in current software."
211 2016-11-01 19:25:28	0|gmaxwell|BlueMatt: your suggestion suggests that alerts are the only reason to upgrade.
212 2016-11-01 19:25:31	0|achow101|How about "Upgrading is strongly recommended" instead of "Please upgrade your client"
213 2016-11-01 19:26:05	0|achow101|won't both the alert and the other message be displayed simultaneously?
214 2016-11-01 19:26:07	0|gmaxwell|It's weird to override a more serious warning with a less serious one.
215 2016-11-01 19:26:12	0|gmaxwell|achow101: no, they can't be.
216 2016-11-01 19:27:02	0|gmaxwell|achow101: the messages have a priority and the highest priority active alert is displayed.
217 2016-11-01 19:27:36	0|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.
218 2016-11-01 19:28:10	0|achow101|What about two different messages, one for those who are showing that upgrade required alert, and one not?
219 2016-11-01 19:29:23	0|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)
220 2016-11-01 19:29:43	0|BlueMatt|sipa: we're all getting emails about old releases :(
221 2016-11-01 19:29:50	0|BlueMatt|bitcoin 0.10.4 released
222 2016-11-01 19:29:58	0|sdaftuar|time to upgrade!
223 2016-11-01 19:31:31	0|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"
224 2016-11-01 19:31:35	0|sipa|BlueMatt: oops
225 2016-11-01 19:31:57	0|sipa|BlueMatt: i was just adding release notes to tags
226 2016-11-01 19:32:06	0|BlueMatt|yea, i figured
227 2016-11-01 19:32:14	0|BlueMatt|whatever, one-time cost
228 2016-11-01 19:32:18	0|sipa|as they weren't showing up on https://github.com/bitcoin/bitcoin/releases
229 2016-11-01 19:32:29	0|arubi|genuinely asking, why not recommend to run with -alerts=0 from now and that's it?
230 2016-11-01 19:32:29	0|sipa|i'm done now
231 2016-11-01 19:32:32	0|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.
232 2016-11-01 19:32:56	0|gmaxwell|arubi: uh oh. confusion detected.
233 2016-11-01 19:33:08	0|arubi|is that a different alert then?
234 2016-11-01 19:33:15	0|gmaxwell|arubi: alert=0 has been the case for many versions, and since 0.13.0 the alert system is gone entirely.
235 2016-11-01 19:33:34	0|arubi|yea but you were talking about 0.12.2
236 2016-11-01 19:33:50	0|gmaxwell|arubi: that has alert=0 by default.
237 2016-11-01 19:34:10	0|arubi|I see, "prior to"
238 2016-11-01 19:34:17	0|TD-Linux|gmaxwell, just concatenate the messages? "In addition, the alert system..."
239 2016-11-01 19:34:30	0|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
240 2016-11-01 19:35:12	0|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.
241 2016-11-01 19:36:19	0|BlueMatt|http://bitcoinfibre.org/public-network.html
242 2016-11-01 19:37:33	0|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"
243 2016-11-01 19:37:58	0|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
244 2016-11-01 19:38:10	0|achow101|maybe have a "due to soft forks" after "rules out of date"
245 2016-11-01 19:38:29	0|kanzure|high amounts of meail from recent releases on github
246 2016-11-01 19:38:32	0|kanzure|.. email.
247 2016-11-01 19:38:46	0|sipa|kanzure: i'm sorry, i didn't know it was mailing people
248 2016-11-01 19:38:51	0|kanzure|it's fine. just a heads up.
249 2016-11-01 19:38:55	0|sipa|kanzure: they're listed now on https://github.com/bitcoin/bitcoin/releases
250 2016-11-01 19:39:00	0|kanzure|ya it is nice
251 2016-11-01 19:44:00	0|achow101|gmaxwell: if the message is an issue now, what about when "Alert Key Compromised" is sent?
252 2016-11-01 19:44:16	0|gmaxwell|arubi: yes, -- the local message and alerts are handled in exactly the same way.
253 2016-11-01 19:44:40	0|gmaxwell|achow101: it's even more urgent though, and also less of an issue since we'll have months of this message being displayed.
254 2016-11-01 19:46:36	0|achow101|ok. What do you think about my other suggestion?
255 2016-11-01 19:47:20	0|arubi|thanks gmaxwell, I'll have to play around with alerts= with my own mock alert key
256 2016-11-01 19:50:27	0|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"
257 2016-11-01 19:51:12	0|achow101|sounds good to me.
258 2016-11-01 19:53:19	0|achow101|how do you even send an alert?
259 2016-11-01 19:53:56	0|gmaxwell|achow101: using software bitcoin's creator wrote which has never been publically distributed.
260 2016-11-01 19:54:00	0|gmaxwell|(AFAIK)
261 2016-11-01 19:54:57	0|achow101|does it happen to look like this: https://gist.github.com/laanwj/0e689cfa37b52bcbbb44 ?
262 2016-11-01 19:56:04	0|gmaxwell|well then.
263 2016-11-01 19:56:12	0|phantomcircuit|gmaxwell: possibly just send the same message
264 2016-11-01 19:56:25	0|phantomcircuit|iirc there are very very old versions which wont show that warning
265 2016-11-01 19:56:44	0|gmaxwell|yes, though AFAICT all of those are forked off. :)
266 2016-11-01 19:57:10	0|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.
267 2016-11-01 19:59:28	0|cfields_|sipa: https://github.com/theuni/bitcoin/commits/uint-literal
268 2016-11-01 20:05:51	0|sipa|cfields_: hmm, i would expect something that just uses return (4*(recursive call)+(new digit)) on a uint256
269 2016-11-01 20:08:35	0|cfields_|sipa: hmm?
270 2016-11-01 20:10:30	0|cfields_|sipa: ah, you mean add an initializer to base_blob that accepts uint64's?
271 2016-11-01 20:11:19	0|GitHub32|[13bitcoin] 15Vitaminmm opened pull request #9059: 0.9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/9059
272 2016-11-01 20:12:35	0|gmaxwell|oh thats from his master, if we care to replace it with folgers crystals.
273 2016-11-01 20:14:15	0|GitHub88|[13bitcoin] 15MarcoFalke closed pull request #9059: 0.9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/9059
274 2016-11-01 20:14:15	0|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
275 2016-11-01 20:14:34	0|sipa|cfields_: oh wait, uint256 no longer has operator* and operator+
276 2016-11-01 20:15:14	0|cfields_|sipa: right, just dumb bits
277 2016-11-01 20:16:31	0|sipa|cfields_: so ignore what i said
278 2016-11-01 20:17:24	0|cfields_|sipa: roger. doing it in 64bit chunks would probably be cleaner, though
279 2016-11-01 23:06:54	0|dgenr8|PR#6
280 2016-11-01 23:06:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
281 2016-11-01 23:06:58	0|dgenr8|sorry, meant for apple ][ window