1 2015-03-05 04:32:33 <jonasschnelli> hmm... my gitian builds fail and my build.log tells me "multiple definition of 'std::out_of_range:"? Any ideas?
  2 2015-03-05 07:31:47 <Luke-Jr> harding: re https://github.com/bitcoin/bitcoin.org/issues/277#issuecomment-77240412 , IMO either they can participate/contribute on github or be ignored.
  3 2015-03-05 07:32:01 <Luke-Jr> (specifically the [1])
  4 2015-03-05 07:32:54 <Luke-Jr> makes it easier to avoid confusing trolls for real people, at least IMO
  5 2015-03-05 09:10:34 <sipa> jonasschnelli: i see you're alive again
  6 2015-03-05 09:10:45 <sipa> interested in meeting up in zurich?
  7 2015-03-05 09:10:58 <jonasschnelli> sipa, yeah. Back from the beach...
  8 2015-03-05 09:11:31 <jonasschnelli> sipa, Meeting. Yes. At the next bitcoin meeting?
  9 2015-03-05 09:23:34 <wumpus> <jonasschnelli> hmm... my gitian builds fail and my build.log tells me "multiple definition of 'std::out_of_range:"? Any ideas? <- no, never seen that, where are the definitions?
 10 2015-03-05 09:24:26 <jonasschnelli> wumpus, you can look at this nights build log: https://builds.jonasschnelli.ch/nightlybuilds/2015-03-05/build-linux.log
 11 2015-03-05 09:24:30 <jonasschnelli> wumpus, only linux is affected...
 12 2015-03-05 09:24:46 <jonasschnelli> wumpus, was a clean master with `make depends`
 13 2015-03-05 09:25:40 <wumpus> out_of_range does not appear in that log
 14 2015-03-05 09:25:43 <jonasschnelli> wumpus, build command is more or less something like './bin/gbuild -j 5 -m 10000 --url bitcoin=git://github.com/robvanmieghem/bitcoin.git  --commit bitcoin=dc3eb7702877c193ce3f5e776c1e311385a03e2d ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml'
 15 2015-03-05 09:26:19 <jonasschnelli> wumpus, oops. Right. Nightly build worked! hmmm... let me check again
 16 2015-03-05 09:26:49 <jonasschnelli> wumpus: here we have it: https://builds.jonasschnelli.ch/pulls/5831/build-linux.log
 17 2015-03-05 09:26:54 <wumpus> my guess would be a stale tree of some kind, mind that we removed glibcxx compatibility
 18 2015-03-05 09:27:03 <wumpus> (as that's going to be linked statically)
 19 2015-03-05 09:27:47 <jonasschnelli> yes. I think it's a misconfiguration on my side. Probably my pull build script...
 20 2015-03-05 09:27:57 <wumpus> (eh, that reads wrong, we removed the backwards-forwards compatibility code, not compatibility for glibcxx :-)
 21 2015-03-05 09:28:34 <jonasschnelli> wumpus, yes. i saw that.
 22 2015-03-05 09:31:42 <moa> and static linked qt5
 23 2015-03-05 09:32:24 <wumpus> yes - static linking of glibcxx implies static linking of all c++ libraries, dynamically linking qt was no longer possible
 24 2015-03-05 09:33:38 <moa> my qt depends builds seg fault on launch now on older linux
 25 2015-03-05 09:33:54 <sipa> oom?
 26 2015-03-05 09:34:33 <wumpus> strange. if anything, this should have improved compatibility with older and newer linux, as it no longer assumes anything about the intalled version of qt
 27 2015-03-05 09:34:44 <wumpus> where does it segfault
 28 2015-03-05 09:34:54 <moa> yeah that's what I would have thought
 29 2015-03-05 09:35:52 <jonasschnelli> wumpus, but linux will still be compiled with Qt 4.8?
 30 2015-03-05 09:35:54 <wumpus> the resulting executable depends on libX11 libX11_xcb but those should be very stable, so try to figure out where it segfaults maybe that tells us anything
 31 2015-03-05 09:36:09 <wumpus> jonaschnelli: no, static qt5 as moa says
 32 2015-03-05 09:36:18 <moa> ok ... I think the only err message I saw was xcb related ...
 33 2015-03-05 09:36:28 <jonasschnelli> ah. Oversaw that.
 34 2015-03-05 09:38:27 <wumpus> moa: try to find more information (e.g. what distro, what versions of libraries, what errors, where exactly it segfaults), and open an issue
 35 2015-03-05 09:39:20 <moa> mint 13 and fedora 15
 36 2015-03-05 09:39:46 <moa> but I can build without depends and runs ok
 37 2015-03-05 09:40:04 <moa> QXcbConnection::atomName: bad Atom 277996912
 38 2015-03-05 09:40:04 <moa> QXcbConnection::atomName: bad Atom 32706
 39 2015-03-05 09:40:14 <moa> Segmentation fault
 40 2015-03-05 09:40:32 <wumpus> better put it into an issue, it will get lost here
 41 2015-03-05 09:40:38 <moa> I'll look into in a bit but that's all i got so far
 42 2015-03-05 09:40:42 <moa> ok
 43 2015-03-05 09:41:16 <wumpus> looks to me that it's linking againt a more recent version of libxcb, expecting new features absent from your x server
 44 2015-03-05 09:41:40 <moa> sounds about right
 45 2015-03-05 09:41:54 <wumpus> but that's just a guess, I know nothing about low-level X
 46 2015-03-05 09:42:49 <moa> well it is some sub-lib (or fuctionality therein) that qt5 is expecting that qt4 subs don't provide
 47 2015-03-05 09:43:27 <moa> and isn't in depends
 48 2015-03-05 09:43:49 <wumpus> any kind of cross-distro compatibility on linux seems a lost cause
 49 2015-03-05 09:44:04 <wumpus> at least with regard to GUIs
 50 2015-03-05 09:44:21 <moa> its diverse
 51 2015-03-05 09:44:26 <Luke-Jr> might be easier to just figure out a way to do deterministic deb/rpm for major binary distros
 52 2015-03-05 09:44:29 <wumpus> one thing win32 did better.
 53 2015-03-05 09:44:44 <moa> but win32 is a monoculture, and that has downsides
 54 2015-03-05 09:45:07 <Luke-Jr> well, it works on win32 because they ship an ancient stdlib that everyone links to ;)
 55 2015-03-05 09:45:27 <Luke-Jr> (for C at least)
 56 2015-03-05 09:48:19 <wumpus> don't get me wrong, win32 is a terrible api, but it has graphics/user input as first-class calls, not something that has to be implemented in lots of different libraries and incompatible ways
 57 2015-03-05 09:48:44 <wumpus> maybe something nice will grow out of generic linux application sandboxing (like https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/), at least if they manage to standardize user input/graphics APIs too.
 58 2015-03-05 09:49:10 <Luke-Jr> Qt has standardised input/gfx APIs :P
 59 2015-03-05 09:50:47 <wumpus> Luke-Jr: remember, using qt as a base line API for the UI was what we *tried* to do, but versions are drifting apart too much :(
 60 2015-03-05 09:51:08 <wumpus> a year ago I'd have called people crazy for even proposing statically linked qt
 61 2015-03-05 09:51:16 <Luke-Jr> API != ABI
 62 2015-03-05 09:51:31 <Luke-Jr> I think it's somewhat intentional that ABI breakages happen a lot in *nix
 63 2015-03-05 09:51:48 <Luke-Jr> (free software people don't want people distributing binaries)
 64 2015-03-05 09:52:19 <wumpus> and with the C++ ABI changing it's moot anyhow
 65 2015-03-05 09:52:40 <Luke-Jr> I'm surprised newer libxcb makes problems with older X though
 66 2015-03-05 09:53:25 <Luke-Jr> that seems rather contrary to the design of X
 67 2015-03-05 09:55:20 <wumpus> yes it's unexpected at the least
 68 2015-03-05 09:55:30 <moa> can I turn up the verbosity for terminal output? (it doesn't leave anything in the debug/log
 69 2015-03-05 09:55:38 <wumpus> Luke-Jr: could that be because we don't link libxcb statically?
 70 2015-03-05 09:55:59 <moa> yes
 71 2015-03-05 09:56:00 <Luke-Jr> we don't? if we're going to static link libstdc++, we should just do everything
 72 2015-03-05 09:56:04 <moa> yes
 73 2015-03-05 09:56:29 <wumpus> Luke-Jr: apart from libc/libgcc then.
 74 2015-03-05 09:57:02 <moa> i'll try that
 75 2015-03-05 09:57:58 <wumpus> @cfields see above, may have to link libxcb/libX11 statically too :/
 76 2015-03-05 10:03:58 <wumpus> Luke-Jr: but the many different APIs for gfx/input on Linux are not just hampering binary compatibility between distros; it also gives lots of headaches when an application wants to embed GUI from another (for example in audio application racks where plugin synths have their own UI)
 77 2015-03-05 10:04:49 <Luke-Jr> wumpus: well, GTK vs Qt, yes, but if everyone stuck to just Qt that'd go away with a compile
 78 2015-03-05 10:05:17 <wumpus> there are some extremely scary hacks in that direction to embed e.g. a gtk UI in qt4. But it gets even scarier with similar but different APIs, eg when you want to embed qt4 GUI in qt5.
 79 2015-03-05 10:05:53 <wumpus> Luke-Jr: if only they had sticked with qt4 that'd be true. Qt5 does need some work to port over thing, unfortunately...
 80 2015-03-05 10:06:47 <moa> what's the difference between xcp_proto and libxcb ... or how are they related?
 81 2015-03-05 10:06:48 <Luke-Jr> yes, but we're past that at least
 82 2015-03-05 10:07:07 <wumpus> moa: I don't think this is the right channel to ask that :)
 83 2015-03-05 10:07:16 <moa> :)
 84 2015-03-05 10:12:13 <wumpus> as I've always understood it the _protos just provide headers with the low-level protocol, and no implementation
 85 2015-03-05 10:17:55 <gdm85> Luke-Jr: I think that intentional ABI breakage in FOSS is more because of the idea of dropping legacy earlier rather than later.
 86 2015-03-05 10:18:29 <Luke-Jr> gdm85: s/later/ever/ ☺
 87 2015-03-05 10:22:06 <wumpus> gdm85: which is understandable because there is so much of it, lots of different APIs to do one thing means lots of tomorrow's legacy APIs too
 88 2015-03-05 10:24:04 <gdm85> yeah indeed. I think originally it was a reaction to early software companies' policy with legacy in software. We know the famous names (MSFT, ORCL etc)
 89 2015-03-05 10:35:30 <wumpus> gdm85: what would help already is if there was a straightforward way to set the target API/ABI lower than that of the libraries on the build machine
 90 2015-03-05 10:36:39 <gdm85> wumpus: android has the correct approach for that, for the little I have seen about it.
 91 2015-03-05 10:37:04 <wumpus> gdm85: yes - that's the part of sandboxing it gets right
 92 2015-03-05 10:37:29 <gdm85> what would help is an injection of new blood in Linux kernel development :P
 93 2015-03-05 10:37:44 <wumpus> maybe, though most of the problems are not at the kernel level
 94 2015-03-05 10:38:15 <wumpus> the kernel supports a lot of neat stuff that is not even used by most OSes on top of it
 95 2015-03-05 10:38:38 <gdm85> true.
 96 2015-03-05 10:38:45 <gdm85> I remember modprobe allows to ignore the version and force loading, I am somewhat still surprised it has to be that rough these days
 97 2015-03-05 12:33:29 <Luke-Jr> why do the RPC tests use XBT while everything else uses BTC? is XBT even a well-defined value yet? O.o
 98 2015-03-05 12:33:53 <Luke-Jr> (I seem to recall debate over whether it should be BTC, mBTC, or uBTC)
 99 2015-03-05 12:35:40 <wumpus> probably because they have different authors
100 2015-03-05 12:36:04 <sipa> yup
101 2015-03-05 12:38:25 <wumpus> I suppose that is limited to the comments, as the test code itself shouldn't depend on what unit is dealt in
102 2015-03-05 12:40:26 <Luke-Jr> wumpus: the deprecated RPC is send*from*
103 2015-03-05 12:40:47 <Luke-Jr> oh, missed jonasschnelli's comment
104 2015-03-05 12:41:45 <wumpus> Luke-Jr: yes
105 2015-03-05 12:43:39 <Luke-Jr> a new "send" RPC that takes a parameter object would be nice perhaps, but probably not worth holding up a PR on
106 2015-03-05 12:43:48 <jonasschnelli> Luke-Jr, wumpus regarding #5831 we probably should take sendfrom and sendmany as they are now in the PR. For deprecated methods i think it's not worth discussion about objects/arrays, etc.
107 2015-03-05 12:44:20 <wumpus> Luke-Jr: there are too many send methods, let's add one more! (I agree in principle though :-)
108 2015-03-05 12:44:28 <jonasschnelli> ;)
109 2015-03-05 12:44:51 <jonasschnelli> Let's remove the accounting stuff for 0.11... *duck*
110 2015-03-05 12:45:44 <Luke-Jr> adding more is the only way RPC is going to get a makeover without breaking compatibility, since nobody wants a compatibility layer :p
111 2015-03-05 12:45:45 <wumpus> anyhow, unless there are critical problems with the current #5831 interface I'd prefer to merge it as-is
112 2015-03-05 12:46:07 <Luke-Jr> jonasschnelli: sendmany isn't deprecated, only sendfrom. no point adding this feature to sendfrom
113 2015-03-05 12:46:37 <Luke-Jr> wumpus: eh, as-is gets the Object with all values "true"
114 2015-03-05 12:46:42 <Luke-Jr> that's just ugly
115 2015-03-05 12:46:58 <wumpus> it wasn't my intention to be long-term maintainer of this pull, I just wanted to get it into a state where it could be merged
116 2015-03-05 12:47:11 <wumpus> feel free to take it over and improve it though
117 2015-03-05 12:47:15 <jonasschnelli> Luke-Jr, right. Only the account parameter in sandmany is deprecated. I'm wondering how we would handle removing the parameter there...
118 2015-03-05 12:47:22 <Luke-Jr> oh, is this a PR-fork?
119 2015-03-05 12:47:39 <Luke-Jr> jonasschnelli: I assume replace it with label perhaps
120 2015-03-05 12:47:48 <wumpus> yes, replace it with label makes sense
121 2015-03-05 12:48:08 <jonasschnelli> yes. would make sense.
122 2015-03-05 12:48:25 <wumpus> although; *what* would it label?
123 2015-03-05 12:48:46 <Luke-Jr> wumpus: the transaction(s)?
124 2015-03-05 12:48:52 <wumpus> would it label the recipients addresses?
125 2015-03-05 12:49:09 <wumpus> in that case a label per recipient would make more sense
126 2015-03-05 12:49:37 <wumpus> transactions don't have labels, addresses do
127 2015-03-05 12:49:53 <Luke-Jr> addresses are unconfirmed transactions ;)
128 2015-03-05 12:50:15 <wumpus> not with sendmany, which allowes creating lots of outputs to different addresses at the same time
129 2015-03-05 12:50:36 <Luke-Jr> wumpus: remember low-level transactions in bitcoind are distinct from high-level
130 2015-03-05 12:50:36 <wumpus> the idea of a 'send from' label doesn't make sense, hence, replacing the account argument on sendmany with 'label' doesn't make sense
131 2015-03-05 12:50:45 <Luke-Jr> we present every output as its own tx
132 2015-03-05 12:51:31 <wumpus> *confused*
133 2015-03-05 12:51:39 <Luke-Jr> sendmany to 2 addresses results in 2 transactions as seen on RPC
134 2015-03-05 12:51:54 <wumpus> I know we do that, but how does that change the above at all
135 2015-03-05 12:52:00 <wumpus> yes, so it would need two labels.
136 2015-03-05 12:52:20 <wumpus> hence, it would need to be passed a label per recipient
137 2015-03-05 12:52:54 <wumpus> (it's the same as the form in the UI)
138 2015-03-05 12:53:39 <Luke-Jr> ideally, yes - but in terms of compatibility, if it's a String, assigning it as a label to all the transactions seems okay
139 2015-03-05 12:54:14 <wumpus> that doesn't get you any compatibility, would be better to just ignore it
140 2015-03-05 12:54:23 <Luke-Jr> ok
141 2015-03-05 12:54:36 <Luke-Jr> ignoring it sounds fine too
142 2015-03-05 12:54:38 <jonasschnelli> we could detect if it's a string or a json-structure and assign the label to all, etc.?
143 2015-03-05 12:55:00 <wumpus> I'd rather not
144 2015-03-05 12:55:08 <Luke-Jr> wumpus: so if I want to clean this PR up, shall I just replace the Object with an Array, or make a parameter-object?
145 2015-03-05 12:55:37 <wumpus> Luke-Jr: the added RPC test also isn't even testing sendmany
146 2015-03-05 12:56:35 <wumpus> Luke-Jr: I think it's fine
147 2015-03-05 12:56:50 <wumpus> replacing it with an Array wouldn't make it better
148 2015-03-05 12:57:29 <wumpus> it is a map from address to boolean now, so you can pass it a boolean for each recipient, with an address you'd have to wonder what the ordering is
149 2015-03-05 12:57:43 <wumpus> s/with an address/with an Array
150 2015-03-05 12:58:35 <Luke-Jr> wumpus: I mean an array of addresses
151 2015-03-05 12:58:53 <Luke-Jr> not an array of booleans :p
152 2015-03-05 12:59:20 <Luke-Jr> there is no case with the current PR that you would ever want to pass anything other than "true" as the value
153 2015-03-05 12:59:20 <wumpus> I agree a single array [{'address':'1Akjafs','amount':1234,'subtractfee':true},{'address':'...'},...] would have been better, for the new wallet API such a send call would make more sense
154 2015-03-05 12:59:39 <wumpus> oh, right
155 2015-03-05 13:00:32 <Luke-Jr> hm, we *could* change the address Object from 'addr':BTC to 'addr':{'amount':N, …} (while retaining backward compatibility) if that is desirable
156 2015-03-05 13:00:35 <wumpus> indeed, you'd never do 'addresss': false because that's the default
157 2015-03-05 13:00:42 <wumpus> no, let's not do that
158 2015-03-05 13:00:45 <Luke-Jr> k
159 2015-03-05 13:01:15 <wumpus> I'd like to either overhaul it completely or keep it as-is with small incremental changes, not a complex circus of both
160 2015-03-05 13:01:54 <wumpus> if we start making decisions based on what type is passed and such... crazyness lies that way
161 2015-03-05 13:02:02 <Luke-Jr> well, if that's the concern, we could just merge this one as-is and PR a revision
162 2015-03-05 13:02:11 <Luke-Jr> oh, RPC
163 2015-03-05 13:02:30 <Luke-Jr> well, just an Object->Array change then?
164 2015-03-05 13:02:33 <wumpus> I'd really like a clean-slate redesign of the RPC API for the wallet
165 2015-03-05 13:02:37 <wumpus> but later, not now
166 2015-03-05 13:02:55 <Luke-Jr> (for the new parameter only)
167 2015-03-05 13:02:58 <wumpus> right now I simply want #5831 merged :-)
168 2015-03-05 13:03:02 <wumpus> yes, fine w/ me
169 2015-03-05 13:06:32 <wumpus> are you going to do it? if so, are you going to add a test for sendmany's extra argument too?
170 2015-03-05 13:08:22 <Luke-Jr> yes, might as well; sure
171 2015-03-05 13:08:33 <Luke-Jr> can I drop the change for deprecated sendfrom while I'm at it? ;)
172 2015-03-05 13:09:02 <wumpus> yes
173 2015-03-05 13:15:50 <Luke-Jr> wumpus: should I open a new PR or just have you pull/push it to yours?
174 2015-03-05 13:21:30 <wumpus> I can just pull it if you give me the branch, no problem
175 2015-03-05 13:47:39 <Luke-Jr> bleh, qa tests using system bitcoind.. how to get it to use the built ones again? :/
176 2015-03-05 13:48:15 <Luke-Jr> got it, export BITCOIND
177 2015-03-05 13:50:45 <wumpus> yes
178 2015-03-05 13:58:52 <Luke-Jr> wumpus: ok, it's on my github as subtractfee
179 2015-03-05 14:50:54 <jtimon> so Luke-Jr cfields, did you see my comment on #5749 ? Thoughts?
180 2015-03-05 14:52:24 <Luke-Jr> jtimon: IMO better to just return them from policy as pairs or some similar type, so they can be changed from GUI nicely
181 2015-03-05 14:53:29 <jtimon> ok, so you still don't like GetPolicyUsageStr() even if it's calling HelpMessageGroup and HelpMessageOpt directly
182 2015-03-05 14:53:37 <jtimon> ?
183 2015-03-05 14:54:16 <Luke-Jr> jtimon: that'd be okay, but clumsy to try to make a GUI for
184 2015-03-05 14:55:31 <jtimon> so that gui still doesn't exist for any other param, right? couldn't you just write whatever you need for the gui within HelpMessageGroup and HelpMessageOpt ?
185 2015-03-05 14:55:43 <Luke-Jr> there is GUI for lots of params
186 2015-03-05 14:56:07 <jtimon> can you point me to an example in the code?
187 2015-03-05 14:56:51 <Luke-Jr> src/qt/optionsmodel.cpp but it's all hardcoded
188 2015-03-05 14:59:09 <wumpus> Luke-Jr: thanks, pushed
189 2015-03-05 15:04:36 <jtimon> thanks, so that would could be generic and used for all options, right?
190 2015-03-05 15:23:25 <wumpus> Luke-Jr: you forgot to remove the sendfrom parameter from vRPCConvertParams, no problem I'll do it
191 2015-03-05 15:23:38 <Luke-Jr> oops, right
192 2015-03-05 15:37:56 <jonasschnelli> needs mac label: https://github.com/bitcoin/bitcoin/issues/5797
193 2015-03-05 15:38:48 <jonasschnelli> needs "improvement" label: https://github.com/bitcoin/bitcoin/issues/5844
194 2015-03-05 15:41:25 <jonasschnelli> i'm still unsure how to proper gitian-build a pull request. I assumes it should be "git reset origin/master" (origin=bitcoin main repo). "git pull <pullrequest>", then gbuild with --url pointing to the local repository holding the just pulled PR. Am i wrong?
195 2015-03-05 15:41:41 <wumpus> jonasschnelli: I've added the REST and Feature for the latter instead
196 2015-03-05 15:42:14 <kanzure> hmm i am not sure if git reset is required there. why are you pulling? i think you want a fetch.
197 2015-03-05 15:42:15 <jonasschnelli> wumpus, ah. Right. Better
198 2015-03-05 15:42:17 <wumpus> I label only pulls 'improvement', generally if they don't fit in any other category
199 2015-03-05 15:42:32 <wumpus> but thanks for letting me know they were unlabeled
200 2015-03-05 15:42:44 <jonasschnelli> kanzure, the git reset is just the make sure we have a clean master.
201 2015-03-05 15:43:15 <jonasschnelli> i mean the other way would be to build a PR directly from the PR's git repository instead of pulling the changes into bitcoin/master
202 2015-03-05 15:43:34 <jonasschnelli> but i would prefer a bitcoin/master with the PR's commit(s) on top
203 2015-03-05 15:43:45 <jonasschnelli> but gbuild don't like that!
204 2015-03-05 15:44:18 <jonasschnelli> the -url and -commit parameter did create a strange git state on my build server
205 2015-03-05 15:45:31 <jonasschnelli> wumpus, https://github.com/bitcoin/bitcoin/issues/5761 could also use a "wallet" label
206 2015-03-05 16:04:22 <gavinandresen> cfields: I’m lost in a maze of twisty Makefile.am’s, all alike.  I want to have ‘make check’ run the unit tests in random order (test_bitcoin -random=1)… what line of what file would I change to do that?
207 2015-03-05 16:16:32 <wumpus> jonasschnelli: maybe you could use parts from github-merge.sh, it merges a pull into master and gives you a shell
208 2015-03-05 16:16:36 <wumpus> gavinandresen: good idea
209 2015-03-05 16:17:34 <wumpus> although, thinking about it, that makes it harder to reproduce a  failed run
210 2015-03-05 16:19:33 <wumpus> or does it log a random seed?
211 2015-03-05 16:30:20 <gavinandresen> wumpus: -random=1 uses current time as seed.  -random=<something else> uses <something else> as the seed. Pull-tester should probably use… I dunno, maybe the pull number.
212 2015-03-05 16:32:36 <gavinandresen> … or maybe pull number plus which-run-in-the-test-matrix, so each pull is tested with several different, deterministic seeds.
213 2015-03-05 16:32:37 <gmaxwell> Using the time and logging it so you can reproduce should it fail, doesn't sound bad.
214 2015-03-05 16:33:03 <sipa> i doubt that boost test supports logging it?
215 2015-03-05 16:33:16 <gmaxwell> ah. well that would be a problem then.
216 2015-03-05 16:34:13 <wumpus> maybe travis has some convenient number available, e.g. the job number. Pull number will be unavailable when building a branch.
217 2015-03-05 16:34:45 <wumpus> gmaxwell: yes, that would be preferable, if possible
218 2015-03-05 16:35:23 <wumpus> maybe the seed can be set in code, and logged
219 2015-03-05 16:35:43 <wumpus> (instead of passed on the command line)
220 2015-03-05 16:35:50 <wumpus> that'd also solve the 'how do I pass this' problem
221 2015-03-05 16:36:36 <sipa> $TRAVIS_JOB_ID
222 2015-03-05 16:37:05 <gavinandresen> boost unit test runtime params are documented here: http://www.boost.org/doc/libs/1_43_0/libs/test/doc/html/utf/user-guide/runtime-config/reference.html
223 2015-03-05 16:37:51 <gavinandresen> … so setting BOOST_TEST_RANDOM env var to $TRAVIS_JOB_ID should work.
224 2015-03-05 16:38:14 <sipa> i think so
225 2015-03-05 16:38:30 <sipa> but i'm not sure we want travis to be randomized?
226 2015-03-05 16:38:41 <sipa> that may make it hard to find the cause of problems
227 2015-03-05 16:38:58 <sipa> if they seem nondeterministic
228 2015-03-05 16:39:15 <wumpus> that's true; problems may go away with a re-trigger
229 2015-03-05 16:39:23 <gmaxwell> We don't want randomization that isn't logged and reproducable at least. We don't want any coverage tests randomized (though we have none of those now).
230 2015-03-05 16:39:41 <sipa> yes, agree... reproducibility is a requirement
231 2015-03-05 16:39:45 <gmaxwell> I think if there is a case where a particular randomization causes failures; its worth the extra time wasted tracking it down, otherwise we'd not see the failure.
232 2015-03-05 16:39:58 <sipa> but even if reproducible, i'm not convinved about introducing randomness at all
233 2015-03-05 16:40:21 <gavinandresen> sipa: why not?  Unit tests should be independent, if they’re not that is a bug.
234 2015-03-05 16:40:44 <sipa> gavinandresen: so run them twice, with a different but fixed seed
235 2015-03-05 16:41:00 <sipa> my worry is that it hides thr problem
236 2015-03-05 16:41:20 <gmaxwell> takes a lot more than two runs to get all cases of X before Y and Y before X if drawing at random.
237 2015-03-05 16:41:49 <sipa> if a problem only triggers for 1 in 10 runs, it will be very hard to distinguish from general travis flakiness
238 2015-03-05 16:42:03 <gmaxwell> though in two runs they could be called one way and the reverse, which does satisify that.
239 2015-03-05 16:42:21 <wumpus> sipa: OTOH, the test_bitcoin tests are not flakey at the moment
240 2015-03-05 16:42:30 <sipa> wumpus: fair enough
241 2015-03-05 16:42:31 <wumpus> all the flaking happens in the comparison tool, and RPC tests
242 2015-03-05 16:42:37 <sipa> anyway, i'm not objecting
243 2015-03-05 16:42:42 <wumpus> (though I agree with you somewhat that introducing randomness is a risk)
244 2015-03-05 16:43:33 <sipa> just not convinced this is the way to go
245 2015-03-05 16:43:42 <gavinandresen> I’m gonna set BOOST_TEST_RANDOM=1 in my environment, so I’ll eventually catch any errors introduced.  Seems like it wouldn’t hurt to have travis run with BOOST_TEST_RANDOM=2 / 3 / 4/ 5 / etc for each test matrix run
246 2015-03-05 16:43:58 <gmaxwell> just means any time travis fails .. hm. well so we don't have an exact replication of the travis enviroment, which is a bit annoying.
247 2015-03-05 16:44:02 <gavinandresen> Not perfect, things could still slip through, but bette rthan what we have now.
248 2015-03-05 16:44:14 <sipa> gavinandresen: that sounds fine
249 2015-03-05 16:44:16 <gmaxwell> so if it fails maybe it flaked, maybe there is an order dependence that only shows up on travis.
250 2015-03-05 16:44:32 <gmaxwell> yea, k.
251 2015-03-05 16:59:27 <rfree_prox> hi. can we do (e.g. for speedup) verification of downloaded blocks by just saving expected hashes of blocks blobs and just checking that instead doing actual verification (of signatures, hashes and validity of transactions etc)?
252 2015-03-05 16:59:53 <rfree_prox> of course this has trust verifications, if the list of expected hashes if bad then you will trust the bad blocks with possibly totally bogus transactions
253 2015-03-05 16:59:59 <rfree_prox> *trust problem
254 2015-03-05 17:00:12 <Luke-Jr> rfree_prox: Bitcoin Core already does that (hopefully not for much longer)
255 2015-03-05 17:00:54 <rfree_prox> Luke-Jr, we store hashes for each of 340,000 blocks? (or some groups like each 100 of them)? in code?
256 2015-03-05 17:01:29 <Luke-Jr> rfree_prox: don't need to store that much, just the last block hash
257 2015-03-05 17:01:55 <Luke-Jr> each block vouches for its previous blocks, so that's enough
258 2015-03-05 17:02:39 <wumpus> see src/checkpoints.cpp
259 2015-03-05 17:02:50 <rfree_prox> and we download in reverse order from last block then?
260 2015-03-05 17:03:31 <wumpus> oh, the actual data is in chainparams.cpp, consists of a map of (height,hash) tuples
261 2015-03-05 17:03:57 <Luke-Jr> rfree_prox: no, you can't do that
262 2015-03-05 17:04:10 <Luke-Jr> rfree_prox: you have to download everything, and process it in sequential order
263 2015-03-05 17:04:11 <rfree_prox> wumpus, sure this are just the normal checkpoints
264 2015-03-05 17:04:12 <Luke-Jr> even if you trust the data
265 2015-03-05 17:04:19 <wumpus> Luke-Jr: why couldn't you? with headers first you could download it in any order (not that it makes sense)
266 2015-03-05 17:04:21 <rfree_prox> I mean to instead checksum each block
267 2015-03-05 17:04:31 <wumpus> rfree_prox: what you are proposing *are* normal checkpoints
268 2015-03-05 17:04:38 <Luke-Jr> wumpus: well, downloading the last first is least efficient considering processing order
269 2015-03-05 17:04:47 <wumpus> Luke-Jr: oh yes, it's inefficient
270 2015-03-05 17:04:49 <Luke-Jr> rfree_prox: what wumpus said
271 2015-03-05 17:05:14 <rfree_prox> that map is with heights:  11111 33333 74000 ....
272 2015-03-05 17:05:20 <Luke-Jr> rfree_prox: and block hashes
273 2015-03-05 17:06:04 <wumpus> but yes you still need to download all the data and process it to keep the running utxo state
274 2015-03-05 17:06:12 <gmaxwell> rfree_prox: Please take some time to understand bitcoin a bit better before proposing improvements. What you're likely missing there is that a later block hash commits to all prior ones, due to the hashes being changed.
275 2015-03-05 17:06:17 <gmaxwell> er chained*
276 2015-03-05 17:06:59 <rfree_prox> gmaxwell, lol I know that for years
277 2015-03-05 17:08:13 <rfree_prox> but I'm not sure how much is already optimized about this in bitcoind.  Do we download blocks 0 to first checkpoint, not trusting them yet, and when first checkpoint is reached then we trust them all?  so we do not do any logical/signatures check of each block (other then to see if they connect in a chain to reach checkpoint)?
278 2015-03-05 17:08:19 <wumpus> rfree_prox: if you'rer willing to cheat the fastest way to get started is to copy the entire .bitcoin directory from one of your other nodes, don't do this with other people's data as you can't trust that they won't give you an invalid utxo set
279 2015-03-05 17:08:41 <gavinandresen> rfree_prox: see https://blog.bitcoinfoundation.org/a-scalability-roadmap/  for current optimization roadmap.
280 2015-03-05 17:09:40 <Luke-Jr> gavinandresen: speaking of the BCF, who is responsible for https://bitcoinfoundation.org/bitcoincore/ ? it appears to be giving a LOT of people the Foundation controls Bitcoin Core
281 2015-03-05 17:10:16 <rfree_prox> wumpus, yeap, the idea is to have that kind of speed in bitcoin core
282 2015-03-05 17:10:21 <Luke-Jr> might be good to find a way to clarify the purpose of that blog
283 2015-03-05 17:10:43 <gmaxwell> gavinandresen: "The longest reorganization ever experienced on the main network was 24 blocks during the infamous" is not correct. There was a reorg from 74691 to 74638.
284 2015-03-05 17:10:44 <gavinandresen> Luke-Jr: Patrick asked Cory to write those updates, the purpose is to let Foundation members know how their donations are being spent on “core stuff"
285 2015-03-05 17:10:44 <Luke-Jr> rfree_prox: Bitcoin isn't merely downloading/trusting blocks. It has to build a database from them too.
286 2015-03-05 17:11:24 <Luke-Jr> sorry, skipped a word above "giving a LOT of people the impression*"
287 2015-03-05 17:11:27 <wumpus> rfree_prox: I'm sure there is room for optimization, but all the low-hanging fruit has been thought of
288 2015-03-05 17:11:40 <gavinandresen> gmaxwell: thanks, I’ll fix. I think you told me that was wrong before.....
289 2015-03-05 17:11:56 <gmaxwell> gavinandresen: hah. I'm glad that I'm sufficiently determinstic. :)
290 2015-03-05 17:12:03 <rfree_prox> wumpus, so basically I was thinking of "headers-first", except, to encode them in source code. And to not bloat the code by 25 mb in .exe/.bin - to checksum groups of 1000 files
291 2015-03-05 17:12:25 <sipa> rfree_prox: in general we want to get rid of the source code committing to the state of the network
292 2015-03-05 17:12:31 <wumpus> rfree_prox: doesn't make sense, downloading the headers from the network works just as well
293 2015-03-05 17:12:59 <sipa> rfree_prox: what problem are you trying to solve?
294 2015-03-05 17:13:09 <rfree_prox> sipa, cpu load limiting initial download speed
295 2015-03-05 17:13:22 <sipa> the headers download takes 3 minutes
296 2015-03-05 17:13:23 <rfree_prox> or rather: cpu load + hdd seeks load for that
297 2015-03-05 17:13:27 <wumpus> for a full node it wouldn't give any advantage to hardcode the headers
298 2015-03-05 17:13:40 <Luke-Jr> HD seeks is writing the database, you can't avoid that without distributing the database (insecure and pretty big)
299 2015-03-05 17:13:53 <sipa> rfree_prox: most of the cpu and disk is due to block validation, which you can't avoid
300 2015-03-05 17:14:04 <sipa> not unless you want to give up the zero-trust design
301 2015-03-05 17:14:51 <wumpus> and if you do want to give that up, just copy someones utxo state, as I mentioned
302 2015-03-05 17:15:06 <rfree_prox> sipa, I mean if you are ok to fully trust the source code and it's checkpoints. Then you do not need to validate blocks other then to check block.previous_hash from trusted checkpoint back
303 2015-03-05 17:15:40 <Luke-Jr> rfree_prox: you still need to build the UTXO database
304 2015-03-05 17:15:43 <sipa> rfree_prox: you still need the database that results from the old blovks
305 2015-03-05 17:15:53 <sipa> if you're not going to process them
306 2015-03-05 17:16:15 <wumpus> rfree_prox: we're trying to *reduce* the amount of trusted data in the source code, not increase it
307 2015-03-05 17:16:23 <rfree_prox> sipa, of course I still need to process the blocks to know transactions (ballances).  How ever, at least the network code can go on and download more blocks, while we could unpack transactions in background
308 2015-03-05 17:16:49 <sipa> rfree_prox: if you still habe to process them, you gain nothing
309 2015-03-05 17:16:51 <rfree_prox> which fork/branch demonstrates the fastest initial download (assuming I'm ok with any kind of checkpoints/lower trust)?
310 2015-03-05 17:17:09 <gmaxwell> rfree_prox: it already is not checking things in the past since 0.6-ish.
311 2015-03-05 17:17:16 <Luke-Jr> rfree_prox: we can be a SPV node until the blocks are processed. it's just not an overnight change
312 2015-03-05 17:17:18 <gmaxwell> so you're barking up the wrong tree.
313 2015-03-05 17:18:05 <sipa> and there is no "unpacking" to speak of
314 2015-03-05 17:18:16 <wumpus> we're wasting time here.
315 2015-03-05 17:18:20 <gmaxwell> (and also irritating people because in your misunderstanding of what it already does you're effectively pushing for more centeralization, which most of us consider intolerable)
316 2015-03-05 18:09:27 <paveljanik> hmm, force push on master?
317 2015-03-05 18:15:05 <Luke-Jr> paveljanik: ?
318 2015-03-05 18:17:32 <paveljanik> Luke-Jr,  <GitHub172> [bitcoin] gavinandresen force-pushed master from 1fc000d to 84a05b8: https://github.com/bitcoin/bitcoin/commits/master
319 2015-03-05 18:19:16 <Luke-Jr> hmm
320 2015-03-05 18:19:28 <Luke-Jr> looks like that was just a revert
321 2015-03-05 18:19:36 <Luke-Jr> at least it was a fast-forward from my perspective
322 2015-03-05 18:19:46 <sipa> it was a revert of a REMOVEME commit
323 2015-03-05 18:19:54 <paveljanik> yes, I verified it.
324 2015-03-05 18:20:20 <paveljanik> this should be done on regular PRs IMO.
325 2015-03-05 18:20:34 <sipa> agree
326 2015-03-05 18:21:07 <Luke-Jr> agree, but maybe it had to be on master, although a warning would be nice first in that case
327 2015-03-05 19:44:40 <morcos> sipa: Another question re: autoprune. I understand your comment now about nTx>0.  But why is BLOCK_VALID_TRANSACTIONS not a sufficient test for that?
328 2015-03-05 19:45:20 <morcos> In LoadBlockIndexDB, we can't check for HAVE_DATA any more to build up the chains, you had suggested on #4701 to check for VALID_TX and nTx != 0, why both?
329 2015-03-05 19:45:45 <morcos> Also it seems like if we dont' HAVE_DATA then we shouldn't be inserting into mapBlocksUnlinked
330 2015-03-05 19:46:09 <sipa> morcos: good point
331 2015-03-05 19:46:49 <sipa> i guess the difference is that valid_transactions implies they're validated; but at this point we don't store data on disk without validation, so they're equivalent (and i think that's very unlikely to change)
332 2015-03-05 19:52:03 <morcos> sipa: ok and i'm right mapBlocksUnlinked should still have the HAVE_DATA test?
333 2015-03-05 19:57:52 <sipa> morcos: right, the invariant for mapBlocksUnlinked is that the blocks in have known transactions (as in: HAVE_DATA), while their parent does not
334 2015-03-05 19:58:32 <sipa> morcos: what do you think needs to change?
335 2015-03-05 19:59:32 <morcos> right now in LoadBlockIndexDB, the calculation of chainWork and inserting into mapBlocksUnlinked were protected by the same check to HAVE_DATA, so they have to be split out now
336 2015-03-05 19:59:52 <sipa> morcos: hmm, this is annoying
337 2015-03-05 19:59:52 <sipa> we do not actually have a way of expressing "this pblock, and all its parents, have block data currently available"
338 2015-03-05 20:00:13 <sipa> or even "this block, and all its non-active parents, have block data available"
339 2015-03-05 20:01:08 <morcos> well... i would think that we cna't depend on all the parents having block data available if you want to stop and restart a pruned node right?
340 2015-03-05 20:02:39 <sipa> no, but having all non-active blocks available is a requirement before you can consider activating a chain
341 2015-03-05 20:02:46 <morcos> yeah..
342 2015-03-05 20:03:26 <sipa> previously, nChainTx ! 0 was used as a conditions for that
343 2015-03-05 20:03:42 <sipa> but that only means we at some point had the block data for all those blocks
344 2015-03-05 20:03:46 <sipa> not whether we still do
345 2015-03-05 20:04:25 <sdaftuar> is this actually a problem though?  if we have a header that is further along than our tip, we just need to make sure we try to download all the blocks along the way right?
346 2015-03-05 20:04:32 <sdaftuar> if we don't have them now
347 2015-03-05 20:04:37 <Kireji> I'm confused about the transaction fee change in 0.10 - written up here https://bitcoin.org/en/release/v0.10.0 and the #bitcoin room is not responding;  when it says "New command line options for transaction fee changes" are those command line options for bitcoind [when starting server] or for bitcoin-cli [when issueing a transaction] ?
348 2015-03-05 20:05:10 <sipa> so thre invariant for setBlockIndexCandidates needs to change
349 2015-03-05 20:05:47 <sipa> sdaftuar: "not actually a problem"; sure, everything is possible
350 2015-03-05 20:06:00 <morcos> Kireji: bitcoind
351 2015-03-05 20:06:08 <sipa> sdaftuar: but currently the decision whether we need to download something, and the decision for what the best chain should be are independent
352 2015-03-05 20:06:15 <Kireji> morcos: thanks
353 2015-03-05 20:06:31 <sipa> sdaftuar: it would be nice to keep it that way
354 2015-03-05 20:06:59 <morcos> Kireji: the new rpc commands are for bitcoin-cli
355 2015-03-05 20:07:11 <sipa> sdaftuar: if some header chain is further ahead than the best one, we will download blocks for it, already
356 2015-03-05 20:07:15 <sipa> what i mean is that the activation code shouldn't cconsider that chain until those blocks are actually all there
357 2015-03-05 20:07:24 <sdaftuar> right
358 2015-03-05 20:07:34 <Luke-Jr> hm, isn't the default of -txconfirmtarget=1 a bit.. extreme?
359 2015-03-05 20:07:40 <sdaftuar> so as long as we exclude it from setBlockIndexCandidates, i think this will work?
360 2015-03-05 20:07:55 <sdaftuar> (i'm actually unclear on how we'd re-download a block we've previously downloaded and then pruned)
361 2015-03-05 20:08:02 <sipa> sdaftuar: which is why i just said that the invariant for setBlockIndexCandidates needs to change
362 2015-03-05 20:08:28 <sdaftuar> right
363 2015-03-05 20:08:31 <morcos> Luke-Jr: yes i think so....   but gavinandresen didn't agree, and I decided to save my arguments for when 5159 (currently being reworked) gets pulled, as then it'll be even more important to change it
364 2015-03-05 20:09:26 <sipa> sdaftuar: this may have weird implications if the chain you need to reorg to has more blocks non in common with the main chain than fit in the pruned size
365 2015-03-05 20:09:32 <sipa> which i guess we knew
366 2015-03-05 20:10:41 <sdaftuar> ok and i answered my own question about re-downloading a block, looks like that should just work as is
367 2015-03-05 20:13:50 <sipa> that would be pretty cool to test
368 2015-03-05 20:13:58 <sipa> maybe a hidden RPC to force prune a block
369 2015-03-05 20:14:06 <sipa> (just mark its data as unavailable)
370 2015-03-05 20:14:22 <sipa> and then have a test that deletes some blocks, and reorgs away and back
371 2015-03-05 20:15:56 <sdaftuar> yeah sounds good
372 2015-03-05 20:16:24 <sdaftuar> so to be clear regarding the invariant -- we're adding the condition that entries in setBlockIndexCandidates are HAVE_DATA as well?
373 2015-03-05 20:16:51 <sipa> and all their non-active parents too
374 2015-03-05 20:17:17 <sdaftuar> ah yes.
375 2015-03-05 20:19:00 <sipa> Luke-Jr: extreme in which direction?
376 2015-03-05 20:19:25 <Luke-Jr> sipa: I would think if everyone is trying to get in the next block, fees will shoot up fast
377 2015-03-05 20:19:37 <Luke-Jr> especially when we get near full blocks
378 2015-03-05 20:19:46 <sipa> yup
379 2015-03-05 20:24:31 <morcos> sipa: hmm, that invariant isn't so easy because we might autoprune away parents of blocks that made it into setBlockIndexCandidates
380 2015-03-05 20:25:01 <sipa> morcos: right, which would require forward removal
381 2015-03-05 20:25:39 <sipa> morcos: but i guess the rule could be that HAVE_DATA is not a requirement, but checked at reorg time
382 2015-03-05 20:26:04 <sipa> and if it isn't satisfied, we remove the tip from setBlockIndexCandidates
383 2015-03-05 20:26:13 <sipa> ugh
384 2015-03-05 20:26:25 <sdaftuar> i was thinking we could update PruneBlockIndexCandidates to do the removal
385 2015-03-05 20:26:34 <sdaftuar> and call it after removing a file
386 2015-03-05 20:26:38 <sipa> that also requires adding the parent of X potentially to setBlockIndexCandidates, when X is being pruned
387 2015-03-05 20:27:14 <sdaftuar> oh, the parent of X wouldn't just be in there already?
388 2015-03-05 20:27:25 <sipa> no, it only contains tips afaik
389 2015-03-05 20:28:00 <sipa> oh no
390 2015-03-05 20:28:22 <morcos> yeah we thought they were all in there
391 2015-03-05 20:28:30 <sipa> seems they are; i misrememberdd
392 2015-03-05 20:28:49 <sipa> that simplifies things
393 2015-03-05 20:29:30 <sdaftuar> ok, so then i think we can just iterate setBlockIndexCandidates in PruneBlockIndexCandidates and remove anything that fails the new invariant.  is that a reasonable algorithm, are there cases when that set is very large?
394 2015-03-05 20:30:36 <sipa> i would do the pruning in Find
395 2015-03-05 20:30:40 <sipa> i would do the pruning in FindMostWorkChain
396 2015-03-05 20:30:49 <sipa> detecting invalid blocks is also done there
397 2015-03-05 20:30:57 <sipa> so it would be trivial to add another condition
398 2015-03-05 20:31:04 <sdaftuar> ah ok
399 2015-03-05 20:31:19 <sdaftuar> makes sense, so we're only checking that condition on demand
400 2015-03-05 20:31:28 <sipa> yup
401 2015-03-05 20:33:24 <sdaftuar> thanks!
402 2015-03-05 20:36:27 <sipa> sdaftuar: in fact, the loop there already goes to exactly where it needs to
403 2015-03-05 20:36:35 <morcos> we just saw that
404 2015-03-05 20:36:38 <morcos> :)
405 2015-03-05 20:38:20 <sipa> great
406 2015-03-05 23:19:00 <maaku> bikeshedding straw poll: if creating a new 224-bit hash type, should it be called uint224 or blob224/something else?
407 2015-03-05 23:23:51 <adlai> maaku: definitely should have a name that's not been used before to describe similar functions, to avoid confusion
408 2015-03-05 23:24:10 <denisx> 4150 tx/h, does that sound reasonable for the bitcoin network right now?
409 2015-03-05 23:27:21 <Luke-Jr> denisx: depends on if you're counting all tx, or just on-blockchain ones, as well as other factors, but this kind of topic is more suited to #bitcoin
410 2015-03-05 23:27:35 <Luke-Jr> maaku: IMO blob224 makes sense
411 2015-03-05 23:28:18 <Luke-Jr> maaku: … but it feels like we're implementing the same things, that you ask this :p
412 2015-03-05 23:36:42 <phantomcircuit> ha
413 2015-03-05 23:36:52 <phantomcircuit> renice on bitcoind doesn't effect the signature checking threads
414 2015-03-05 23:43:06 <maaku> Luke-Jr: maybe we are. i'm updating my hashmap branch, adding the new test vectors to it
415 2015-03-05 23:43:18 <maaku> Luke-Jr: are you doing a strictly C implementation?
416 2015-03-05 23:43:24 <Luke-Jr> maaku: yes
417 2015-03-05 23:44:01 <gmaxwell> phantomcircuit: yea, thats what renice does. :)
418 2015-03-05 23:45:33 <phantomcircuit> gmaxwell, possibly the sig check threads should be low priority by default
419 2015-03-05 23:45:40 <phantomcircuit> at least by 1
420 2015-03-05 23:45:47 <maaku> Luke-Jr: what's your plan? are you rolling your own in-memory tree, or reusing the C equiv of std::map?
421 2015-03-05 23:46:04 <maaku> phantomcircuit: that would be nice
422 2015-03-05 23:46:15 <phantomcircuit> some other thread is 2 by default
423 2015-03-05 23:46:17 <Luke-Jr> maaku: there is no C equiv..?
424 2015-03-05 23:49:13 <maaku> Luke-Jr: well there's plenty of associative containers written in C
425 2015-03-05 23:49:37 <gmaxwell> maaku: no standard ones, unless you want to count glib.
426 2015-03-05 23:49:55 <Luke-Jr> 
ACTION wouldn't even want to use software depending on glib :P

427 2015-03-05 23:50:09 <maaku> my question was whether you are doing an explicit in-memory binary tree, or doing the trick of storing nodes of the tree in an associative container keyed by prefix
428 2015-03-05 23:50:47 <maaku> (i should have said "a C equiv of std::map".)
429 2015-03-05 23:51:31 <Luke-Jr> maaku: basically same as the trie structure described in the BIP draft
430 2015-03-05 23:51:49 <Luke-Jr> (except pointers instead of hashes ofc)
431 2015-03-05 23:51:57 <maaku> ok
432 2015-03-05 23:52:39 <Luke-Jr> 
ACTION ponders if the alternative might work better

433 2015-03-05 23:53:00 <Luke-Jr> mm, a std::map-like basis would fail if the trie was incomplete
434 2015-03-05 23:53:35 <hearn> phantomcircuit: why do you want to change the thread priorities?
435 2015-03-05 23:54:11 <maaku> Luke-Jr: you would need the ability to iterate / scan ranges
436 2015-03-05 23:57:31 <maaku> starting from the index where the node you're looking for would be, you scan backwards until you find the nearest inner node along the path up to root
437 2015-03-05 23:58:51 <maaku> Luke-Jr: it is certainly not faster to use an associative backing store for in-memory work, but it is probably the most straight-forward way to implement it over an external storage, like LevelDB
438 2015-03-05 23:59:05 <maaku> presumably a UTXO prefix tree would be stored that way