1 2014-12-23 01:50:06 <ers35> Should "privatekeys" be "prevtxs"? https://github.com/bitcoin/bitcoin/blob/master/src/bitcoin-tx.cpp#L371
2 2014-12-23 01:50:55 <bsm117532> betchayes
3 2014-12-23 01:51:24 <sipa> ers35: looks like it
4 2014-12-23 01:51:45 <sipa> patches welcome (and unit tests that would have caught this too)
5 2014-12-23 01:51:49 <ers35> I'll submit a pull
6 2014-12-23 01:52:20 <sipa> thanks!
7 2014-12-23 02:27:44 <ers35> https://github.com/bitcoin/bitcoin/pull/5528
8 2014-12-23 06:12:22 <Luke-Jr> bah, not even uptime 48 hours and already Linux BUGs on me. I miss when Linux was reliable :/
9 2014-12-23 06:19:31 <fenn> switch to stable
10 2014-12-23 06:21:14 <Luke-Jr> maybe. I guess there should be a stable kernel that works with my hardware by now
11 2014-12-23 08:23:06 <jonasschnelli> gitian and apt-cacher-ng: do i have to config somehow apt-cacher-ng? When accessing 'http://127.0.0.1:3142/archive.ubuntu.com/ubuntu' i get a 403?
12 2014-12-23 08:24:39 <wumpus> I never needed to
13 2014-12-23 08:30:29 <Luke-Jr> I think I needed to. But it's been a while.
14 2014-12-23 08:31:27 <jonasschnelli> i just changed the make-base-vm script to direct urls to avoid the usage of apt-cacher-ng
15 2014-12-23 08:31:32 <jonasschnelli> now it looks better
16 2014-12-23 08:33:47 <jonasschnelli> im looking forward to a non-vm/non-gitian deterministic toolchain. :)
17 2014-12-23 08:34:09 <jonasschnelli> s/detemrninistic/detemrninistic build/
18 2014-12-23 08:34:39 <Luke-Jr> meh, having our own package manager is essentially no better than gitian IMO
19 2014-12-23 08:37:30 <wumpus> if it avoids having to set up a VM, or even a VM-in-a-VM, it'd be a great improvement over the current state though
20 2014-12-23 08:37:35 <jonasschnelli> gitian looks not so good maintained. Non-trivial and a time-eating-black-hole (while configuring). Lot's of dependencies.
21 2014-12-23 08:37:59 <wumpus> depends works really well, but I suppose you only appreciate it if you cross-compile a lot
22 2014-12-23 08:38:38 <jonasschnelli> or it would be cool to have a shell / python script who downloads and configure a VirtualBox ubuntu with gitian build and everything.
23 2014-12-23 08:38:41 <wumpus> and for a gitian replacement, cross-compile is a given, so I don't see how we'd do it without something like depends
24 2014-12-23 08:38:58 <wumpus> jonasschnelli: that's just inception another level
25 2014-12-23 08:39:25 <wumpus> jonasschnelli: you can keep building scripts that build vms that build scripts that build software etc etc :P we're trying to escape from that
26 2014-12-23 08:39:35 <jonasschnelli> not the build depends... i mean gitian depends..., no flexible configuration, tied to ubuntu, fix apt-cacher-ng,
27 2014-12-23 08:39:53 <maaku> jonasschnelli: I had a makefile once that setup a VirtualBox based gitian builder. i haven't keept it up to date
28 2014-12-23 08:40:00 <maaku> feel free to write one
29 2014-12-23 08:40:09 <midnightmagic> can an lxc spawn a sub-lxc? huh. so it can. https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-basic-usage (nesting)
30 2014-12-23 08:40:11 <maaku> there just hasn't been enough need ...
31 2014-12-23 08:40:12 <jonasschnelli> yes. that's probably the issue. Keep it up to date. :)
32 2014-12-23 08:40:24 <wumpus> I wouldn't bother, if you're going to spend time on it work with cfields on a gitian replacement involing a cross toolchain
33 2014-12-23 08:41:02 <jonasschnelli> wumpus: i set my goals this night: new wallet/flexible backend, SPV mode in bitcoind (*duck*)
34 2014-12-23 08:41:02 <wumpus> midnightmagic: yes, lxc can spawn a sub lxc, a nested world of fun
35 2014-12-23 08:41:25 <wumpus> jonasschnelli: so what do you think about my newwallet branch idea?
36 2014-12-23 08:41:33 <maaku> that's a lot to accomplish in one night
37 2014-12-23 08:41:35 <wumpus> jonasschnelli: it is the same way bitcoin-qt was developed
38 2014-12-23 08:41:36 <Luke-Jr> wumpus: well, I cross-compile a lot - but I suspect depends won't make use of the cross-compiled libs I have already ;p
39 2014-12-23 08:41:54 <jonasschnelli> wumpus: yes i read that. Could be a good idea. But i'm not sure if the changeset is that huge.
40 2014-12-23 08:41:56 <maaku> jonasschnelli: those are both welcome goals, don't know why you're ducking
41 2014-12-23 08:42:00 <cfields> wumpus: i played with it a good bit today. seems very reasonable
42 2014-12-23 08:42:08 <wumpus> jonasschnelli: old GUI code was (effectively) frozen, I forked bitcoin repository, worked on the new UI until it was somehow ready, then merged it for a major release when ready
43 2014-12-23 08:42:43 <Luke-Jr> (don't do your fork/merge the way wumpus did though, use normal git practices :P)
44 2014-12-23 08:42:55 <Luke-Jr> (for some reason we ended up with the entire RPC code being deleted and re-added)
45 2014-12-23 08:43:04 <wumpus> jonasschnelli: there is no capacity for reviewing incremental improvements to the wallet, so it has to be in one go
46 2014-12-23 08:43:13 <wumpus> Luke-Jr: yes, I screwed up there
47 2014-12-23 08:43:27 <wumpus> Luke-Jr: but that doesn't change anything to the underlying point
48 2014-12-23 08:43:31 <Luke-Jr> right
49 2014-12-23 08:43:51 <jonasschnelli> wumpus: so you think creating a replacement (same interface) for CWalletDB would need a new branch?
50 2014-12-23 08:44:27 <wumpus> jonasschnelli: you can make *any* change there, like implement SPV, implement determinitic keys, implement a new on-disk format, remove the acccount system, and on and on
51 2014-12-23 08:44:56 <wumpus> jonasschnelli: everything that's been neglected to do for the legacy wallet
52 2014-12-23 08:44:57 <jonasschnelli> wumpus: how about review and collaboration work?
53 2014-12-23 08:45:08 <wumpus> jonasschnelli: you'd have to organize your own, maybe with sipa's help
54 2014-12-23 08:45:19 <cfields> jonasschnelli: as for the question above, there are no more gitian depends. gitian now uses the depends/ as its base (in case you weren't already aware)
55 2014-12-23 08:45:20 <wumpus> and cozz?
56 2014-12-23 08:45:33 <wumpus> probably there are some other people interested in it too once it gets going
57 2014-12-23 08:46:11 <wumpus> if this had been a year ago, CodeShark, but he started on his completely independent wallet project so I don't think he'll collaborate now
58 2014-12-23 08:46:30 <jonasschnelli> Okay. Sounds good.
59 2014-12-23 08:46:49 <jonasschnelli> No promises that i will succeed... but at least i can try.
60 2014-12-23 08:47:16 <wumpus> no promises necessary
61 2014-12-23 08:47:33 <wumpus> that's why you work on a separate fork, if it goes nowhwere, well it's a pity but noone gets hurt either
62 2014-12-23 08:47:54 <jonasschnelli> Yes. That is right...
63 2014-12-23 08:48:02 <Luke-Jr> I'm not un-interested, but whether I'll have time is another matter
64 2014-12-23 08:48:36 <jonasschnelli> Time is constraint. It's more a priority thing...
65 2014-12-23 08:48:57 <wumpus> and I'll review the new wallet code in detail once it lands, but I won't be able to review all incremental changes
66 2014-12-23 08:49:03 <jonasschnelli> I think i can spend some good hours in implementing and testing. But i need review and advices because my lack of c++ knowledge.
67 2014-12-23 08:49:30 <Luke-Jr> C++ is pretty easy once you get the hang of it
68 2014-12-23 08:49:35 <Luke-Jr> docs online are good
69 2014-12-23 08:49:43 <jonasschnelli> For separate branch review i go knock on sipas door because he live around the corner i recently discovered. :)
70 2014-12-23 08:51:38 <jonasschnelli> s/live/lives
71 2014-12-23 08:51:50 <Luke-Jr> sipa lives!
72 2014-12-23 08:55:19 <jonasschnelli> cfields: yes. right. Maybe i meant more that gitian is non-trivial to setup and it seems not so flexible in case of host os selection...
73 2014-12-23 08:55:58 <cfields> jonasschnelli: yes, ideally we can look towards killing it off.
74 2014-12-23 08:57:31 <wumpus> cfields: how I imagine the ideal end result would be to pass in a host tuple and get a working, deterministic, static bitcoind for that target :-)
75 2014-12-23 08:58:06 <cfields> wumpus: ack. that was my hope about 1.5 years ago :)
76 2014-12-23 08:58:10 <cfields> baby steps i suppose :)
77 2014-12-23 08:58:37 <wumpus> cfields: sure, we're getting there
78 2014-12-23 08:59:37 <wumpus> I think gitian's main problem is that it is trying too much (ie, support too many configurations of VMs, for example), and too little maintained to afford that
79 2014-12-23 08:59:40 <cfields> wumpus: i thought about it a good bit today. there are still going to be hurdles. stupid incompatibilities between native awk/sed/etc... stupid little things that are hard to anticipate
80 2014-12-23 08:59:45 <cfields> but it's very doable still.
81 2014-12-23 08:59:46 <wumpus> we'll just do one thing and it will work (TM)
82 2014-12-23 09:00:09 <wumpus> cfields: yes, can't avoid those
83 2014-12-23 09:00:36 <wumpus> cfields: worst-case we can build those for the host, as ccache
84 2014-12-23 09:01:32 <cfields> wumpus: yes. thing is, i'm hesitant to diverge from travis. i really like the fact that travis builds exactly as gitian does. we'll either need to diverge to avoid building 30 things on travis, or improve on our caching strategy significatly
85 2014-12-23 09:01:46 <cfields> i'm hacking on some experiments atm
86 2014-12-23 09:01:53 <wumpus> cfields: on travis all of those tools exist and work
87 2014-12-23 09:02:20 <wumpus> cfields: you'd have to build them only if the platform's one is not compatible
88 2014-12-23 09:02:21 <cfields> wumpus: sure, as long as the results are deterministic, no need to build ourselves
89 2014-12-23 09:02:45 <wumpus> or sucks in another way making it unusable (e.g., the nightmare of building from mingw...)
90 2014-12-23 09:03:45 <cfields> yea. a chain-reaction is what i'm afraid of. I'm hoping we get lucking and don't have to drill down too low.
91 2014-12-23 09:03:48 <cfields> *lucky
92 2014-12-23 09:03:49 <wumpus> then again, supporting build from linux is enough for the initial stage, other platforms could still use one-level-of VM
93 2014-12-23 09:04:02 <wumpus> or linux+macosx sounds doable
94 2014-12-23 09:04:08 <wumpus> both sufficiently unixy
95 2014-12-23 09:04:47 <Luke-Jr> can we support Amiga?
96 2014-12-23 09:04:49 <Luke-Jr> ACTION hides
97 2014-12-23 09:04:58 <wumpus> no.
98 2014-12-23 09:07:20 <cfields> wumpus: i think we're very much on the same page. i'm working on getting crosstool working so that we can build from any toolchain it creates. from there, we'll just have to see where the problems crop up.
99 2014-12-23 09:07:37 <Luke-Jr> cfields: can I use crossdev instead of crosstool?
100 2014-12-23 09:07:50 <wumpus> Luke-Jr: no - we'll support one set of tools
101 2014-12-23 09:07:59 <Luke-Jr> :<
102 2014-12-23 09:08:05 <wumpus> whether that is crosstool or crossdev I don't care though
103 2014-12-23 09:08:21 <Luke-Jr> crossdev is kinda Gentoo-specific, and crosstool isn't packaged for Gentoo
104 2014-12-23 09:08:23 <wumpus> but there will be no forest of configurability, too much too maintain
105 2014-12-23 09:08:27 <cfields> Luke-Jr: i've not worked with crossdev before. is there anything in particular that sets it apart?
106 2014-12-23 09:08:36 <Luke-Jr> cfields: it's integrated with the OS basically
107 2014-12-23 09:08:37 <wumpus> Luke-Jr: I'm sure cfields will build crosstoo-ng for you from source
108 2014-12-23 09:09:13 <wumpus> I'm also building mine from source in manual testing, there is no ubuntu package for it either
109 2014-12-23 09:09:15 <cfields> Luke-Jr: well that's a minus, as far as i'm concerned
110 2014-12-23 09:09:28 <cfields> Luke-Jr: rather, distro-agnostic is a plus
111 2014-12-23 09:09:45 <Luke-Jr> cfields: I agree, which is why it should be neutral to what cross-builder is used ;)
112 2014-12-23 09:09:45 <wumpus> crosstool-ng is easy to build from source, has no dependencies apart from a basic compiler+toolchain, and runs from its build directory
113 2014-12-23 09:10:10 <wumpus> Luke-Jr: no, it should just pick a fixed version of one and build with it, to have a deterministic result!
114 2014-12-23 09:10:42 <cfields> Luke-Jr: that's kinda a null argument. the cross-builder that's used is the cross-builder that we pick
115 2014-12-23 09:10:47 <Luke-Jr> wumpus: hm, I guess that's a point; I was thinking just use x-y-z-gcc regardless of where it came from, but that might get Gentoo-specific patches for crossdev :\
116 2014-12-23 09:11:20 <wumpus> Luke-Jr: yeah - distro-specific patches to the build env is exactly what we're trying to avoid by buildng our own sanitized one
117 2014-12-23 09:11:47 <cfields> Luke-Jr: i do agree with that somewhat, though. I'd like to be able to continue to use a host toolchain of your choice, even if only for local tests/use
118 2014-12-23 09:11:48 <Luke-Jr> I suppose I can always do a KVM instance with whatever in it
119 2014-12-23 09:12:04 <wumpus> cfields: sure, for non-release use
120 2014-12-23 09:12:19 <wumpus> cfields: we only need the toolchain dance for releases
121 2014-12-23 09:12:30 <cfields> wumpus: yes, exactly. your mips/aarch64 hacking is a good example of where that comes in handy
122 2014-12-23 09:12:46 <wumpus> for non-releases you can A) use the current depends system B) just install the dependencies yourself
123 2014-12-23 09:12:50 <wumpus> cfields: yup
124 2014-12-23 09:12:56 <cfields> (though i suppose crosstool probably handled that just fine as well)
125 2014-12-23 09:15:07 <cfields> ok, looks like there's a reasonably clear objective here for once. will put together a POC.
126 2014-12-23 09:15:51 <wumpus> but let's first get 0.10 out of the door, we'll have to bite the bullet with gitian for now
127 2014-12-23 09:16:21 <Luke-Jr> +2
128 2014-12-23 09:16:22 <cfields> of course
129 2014-12-23 09:16:28 <jonasschnelli> gitian: now it continues: after successful creating the base images for amd/i386 i tried gbuild and get "lxc-start: lxc_start.c: main: 337 The container failed to start.". Any ideas?
130 2014-12-23 09:17:58 <cfields> jonasschnelli: i realize this is a non-answer, but gitian+lxc was a never-ending time-sink for me. kvm pretty much works as intended.
131 2014-12-23 09:19:19 <jonasschnelli> does kvm works when having hw/host[osx]->VirtualBoxVM[ubuntu]->GitianKVM?
132 2014-12-23 09:20:15 <cfields> jonasschnelli: ouch. that depends on several variables that i'm not qualified to discuss.
133 2014-12-23 09:20:25 <jonasschnelli> okay.. let me try.
134 2014-12-23 09:23:34 <cfields> jonasschnelli: i'll start first thing tomorrow with a similar build, though. for the sake of fixing up the docs
135 2014-12-23 09:24:18 <cfields> i always do gitian builds from linux, but i'll try one from scratch tomorrow from my macbook via vbox and document the process
136 2014-12-23 09:24:19 <jonasschnelli> cfields: yes. would be nice. Maybe i have some inputs (whenever my gitian vm works).
137 2014-12-23 09:25:26 <cfields> i'm not really sure what's changed in that regard since 0.9.x, though?
138 2014-12-23 09:32:24 <cfields> nnite
139 2014-12-23 09:49:58 <michagogo> jonasschnelli: as of last time I tried, KVM inside VBox didn't work
140 2014-12-23 09:51:06 <michagogo> 11:25:38 <cfields> i'm not really sure what's changed in that regard since 0.9.x, though?
141 2014-12-23 09:51:16 <michagogo> We're just using one precise-amd64 VM now, right?
142 2014-12-23 09:51:34 <michagogo> I think we were still using precise-{amd64,i386} in 0.9?
143 2014-12-23 09:51:50 <jonasschnelli> michagogo IMO it can't work. But i give it a try now...
144 2014-12-23 09:52:10 <michagogo> jonasschnelli: Yeah, pretty sure VBox doesn't do nesting
145 2014-12-23 09:52:23 <michagogo> I think at one point I installed VMWare Player, and KVM worked inside that
146 2014-12-23 09:52:34 <michagogo> But then OpenSSL failed to build, something about asm
147 2014-12-23 09:52:47 <jonasschnelli> aha... i could try in vmware.. right
148 2014-12-23 09:53:08 <michagogo> What's wrong with lxc?
149 2014-12-23 09:53:19 <michagogo> ACTION hasn't really has much trouble with it
150 2014-12-23 09:53:31 <jonasschnelli> getting one error after another... seems a time-eating-thing
151 2014-12-23 09:53:49 <jonasschnelli> was giving up when i got ""lxc-start: lxc_start.c: main: 337 The container failed to start."" while gbuild-ing
152 2014-12-23 09:54:14 <jonasschnelli> michagogo precies base vm was okay
153 2014-12-23 09:55:26 <michagogo> jonasschnelli: what about the sanity-check mentioned in Gitian's readme?
154 2014-12-23 09:55:43 <michagogo> Also, what's your environment? Which Ubuntu, following which steps?
155 2014-12-23 09:56:50 <jonasschnelli> hardware host: OSX 10.10 / VirtualBox with Ubuntu 14.10 as Gitian Host
156 2014-12-23 09:57:04 <jonasschnelli> followed wumpus tutorial
157 2014-12-23 09:57:11 <jonasschnelli> (more or less)
158 2014-12-23 09:58:39 <michagogo> Hm, not familiar with 14.10
159 2014-12-23 09:58:46 <michagogo> I think my setup is on 12.04
160 2014-12-23 09:58:57 <michagogo> Maybe I should consider going to 14.04
161 2014-12-23 09:59:42 <jonasschnelli> or maybe i should go to 12.04...
162 2014-12-23 10:03:19 <michagogo> jonasschnelli: It's supported until 17.04
163 2014-12-23 10:04:01 <jonasschnelli> michagogo: okay. i try now in VMWare... from the scratch
164 2014-12-23 10:04:21 <michagogo> jonasschnelli: also, I didn't really follow any specific tutorial, I just looked at the gitian readme
165 2014-12-23 10:04:26 <michagogo> and our release-process.md
166 2014-12-23 10:04:32 <michagogo> (and descriptors, I think)
167 2014-12-23 10:27:04 <wumpus> I'm going to write the release notes for 0.10 today, my goal is to merge the last open pulls for 0.10 and tag the rc1 after that
168 2014-12-23 10:29:47 <gmaxwell> wumpus: Do I owe any work on the two fee related pulls I have open for 0.10?
169 2014-12-23 10:31:47 <wumpus> gmaxwell: doesn't look like that
170 2014-12-23 10:35:12 <wumpus> gmaxwell: don't know if you still want to test https://github.com/bitcoin/bitcoin/pull/5459, I tested it but sipa mentioned you
171 2014-12-23 10:35:26 <wumpus> oh you acked it
172 2014-12-23 10:35:50 <gmaxwell> I've tested it. yea, your mentioned of 0.10 caused me to go check testing results.
173 2014-12-23 10:37:12 <jonasschnelli> whats stored in the <datadir>/database? Is that kind of disk working environment for the wallet?
174 2014-12-23 10:37:31 <gmaxwell> jonasschnelli: correct.
175 2014-12-23 10:38:59 <jonasschnelli> a complete in memory handling for the wallet would be possible, regarding of potential wallet size and assume that bdb was replaced?
176 2014-12-23 10:39:27 <wumpus> jonasschnelli: a 'journal' IIRC
177 2014-12-23 10:39:50 <wumpus> jonasschnelli: it would be possible
178 2014-12-23 10:40:30 <gmaxwell> jonasschnelli: ", regarding of potential wallet size" ?
179 2014-12-23 10:40:37 <wumpus> jonasschnelli: although keeping all historical transactions in memory likely isn't useful
180 2014-12-23 10:40:45 <gmaxwell> wumpus: the data there is only created by bdb, not bitcoin core code.
181 2014-12-23 10:40:55 <wumpus> gmaxwell: yes
182 2014-12-23 10:41:12 <gmaxwell> oops that was supposted to be directed at jonasschnelli
183 2014-12-23 10:41:15 <jonasschnelli> gmaxwell i have no experience how big a wallet might get.
184 2014-12-23 10:41:23 <wumpus> jonasschnelli: you should ask Jouke
185 2014-12-23 10:41:28 <wumpus> hehe
186 2014-12-23 10:41:33 <jonasschnelli> Joke? big wallet user?
187 2014-12-23 10:41:43 <gmaxwell> I don't know why a in memory only wallet might be considered desirable, just would seem to artificially limit scalability.
188 2014-12-23 10:41:44 <jonasschnelli> s/Joke/Jouke
189 2014-12-23 10:41:47 <Jouke> We recently stopped using our old wallet
190 2014-12-23 10:42:07 <Jouke> It was two and a half years old, with around 150k addresses
191 2014-12-23 10:42:36 <wumpus> gmaxwell: agreed, and you need to sync to disk anyhow to make sure you lose nothing on crashes
192 2014-12-23 10:42:39 <gmaxwell> the growth should be different now, because we no longer stick prev in transactions into the wallet. This caused a lot of crazy growth.
193 2014-12-23 10:43:16 <Jouke> Is there an easy way to see how many transactions it stored?
194 2014-12-23 10:43:38 <jonasschnelli> Joke probably with pywallet?
195 2014-12-23 10:43:42 <maaku> jonasschnelli: any new wallet should be using an append-only structure for safety
196 2014-12-23 10:43:45 <wumpus> without starting bitcoin core? well, you could get the total number of records using bdb tools
197 2014-12-23 10:44:00 <wumpus> that would be 2*addresses + transactions roughly
198 2014-12-23 10:44:13 <Jouke> wumpus: well, we still have it running.
199 2014-12-23 10:44:45 <wumpus> let's see
200 2014-12-23 10:44:51 <gmaxwell> wumpus: i think jouke might like to know how much smaller it would be if it was all written with current code.
201 2014-12-23 10:44:53 <Jouke> people sending bitcoins to very old adresses and such
202 2014-12-23 10:46:10 <wumpus> no, I don't think there is a call to get the number of transactions without querying them
203 2014-12-23 10:46:41 <Jouke> The wallet also gathered some invalid transactions that it kept broadcasting over the years.
204 2014-12-23 10:47:20 <wumpus> gmaxwell: well at least two times smaller I suppose? depending on the average size of the transactions and the number of inputs
205 2014-12-23 10:47:45 <wumpus> Jouke: the empty vins? should be fixed with 0.9.3
206 2014-12-23 10:47:51 <gmaxwell> wumpus: yea, I suspect greater.
207 2014-12-23 10:48:03 <gmaxwell> (I mean a greater than 2x reduction)
208 2014-12-23 10:49:04 <wumpus> Jouke: if there are other invalid transactions being broadcasted please open an issue
209 2014-12-23 10:49:41 <Jouke> It was about the empty vins indeed
210 2014-12-23 10:50:03 <wumpus> Jouke: ok, do you need the commit id# that stops that for cherry picking?
211 2014-12-23 10:50:24 <Jouke> Nah, as I said, we stopped using that wallet in production.
212 2014-12-23 10:51:07 <wumpus> ok, it's just that those transactions get your node banned
213 2014-12-23 10:51:27 <Jouke> I know, but it was not directly connected to outside nodes anyway.
214 2014-12-23 10:51:37 <wumpus> good
215 2014-12-23 10:52:53 <wumpus> jonasschnelli: anyhow, yes, the current implementation with all its faults (such as keeping everything in memory) does support huge wallets
216 2014-12-23 10:53:46 <jonasschnelli> Yes. i see.
217 2014-12-23 10:54:47 <Jouke> Transactions in that old wallet: Move: 188460, Send: 94272, Received: 152926
218 2014-12-23 10:54:52 <wumpus> the UI has some problems there that bitcoind doesn't really have (also because people expect more snappyness when directly interacting)
219 2014-12-23 10:55:29 <wumpus> Jouke: thanks
220 2014-12-23 10:56:11 <jonasschnelli> thanks.
221 2014-12-23 10:59:57 <fanquake> jonasschnelli For how long have you been seeing the new toolbar when running master?
222 2014-12-23 11:01:04 <jonasschnelli> the std::map mapWallet does the in memory mapping? I assume key won't kept in memory because of security.
223 2014-12-23 11:01:31 <wumpus> jonasschnelli: keys are kept in memory, though encrypted if you use encrypted wallet
224 2014-12-23 11:02:21 <jonasschnelli> fanquake what do you mean exactly? The new toolbar = new icons? What do you mean "for how long"?
225 2014-12-23 11:03:00 <wumpus> and for non-encrypted keys, keeping them only on disk isn't exactly a security win either
226 2014-12-23 11:03:18 <fanquake> sorry, bad wording. I meant to say the progress bar. Iâve noticed in your screenshots its looked different to what Iâve been seeing for a while.
227 2014-12-23 11:04:17 <jonasschnelli> fanquake: you mean the clear flat blue progress bar? Do you run osx10.10?
228 2014-12-23 11:04:19 <wumpus> progress bar is qt's, not ours
229 2014-12-23 11:04:47 <fanquake> jonasschnelli Yes. I was wondering if it was just because you were running 10.10.
230 2014-12-23 11:05:06 <jonasschnelli> yes. Qt uses OS X framework which change in gfx-style from 10.9 to 10.10
231 2014-12-23 11:05:18 <jonasschnelli> everything flat now.
232 2014-12-23 11:05:30 <fanquake> Ah ok, which Qt have you been building with recently?
233 2014-12-23 11:05:35 <fanquake> Iâve just moved to 5.4
234 2014-12-23 11:06:11 <jonasschnelli> fanquake: 5.3.1
235 2014-12-23 11:06:42 <fanquake> Ok. Liking the new icons btw
236 2014-12-23 11:07:48 <jonasschnelli> I also think they look more clean now. Luke-Jr color change make it even look better on linux
237 2014-12-23 11:08:07 <wumpus> yes i like the 80's revival
238 2014-12-23 11:08:11 <wumpus> everything in two colors
239 2014-12-23 11:08:35 <wumpus> :D
240 2014-12-23 11:08:45 <fanquake> wumpus Any plans on releasing that christmas qt you were playing around with? :p
241 2014-12-23 11:08:48 <wumpus> especially with luke-jr's patch
242 2014-12-23 11:09:28 <wumpus> fanquake: hahaha could do that as an easter egg, as VLC does with its icon around christmas
243 2014-12-23 11:10:04 <jonasschnelli> Yes. i recently detected the santa-clause-cap on VLC! pretty cool that they release such stuff...
244 2014-12-23 11:10:05 <fanquake> wumpus Speaking of VLC, I just noticed the little christmas hat this morning heh
245 2014-12-23 11:10:28 <jonasschnelli> (pretty cool that they find time for such things)
246 2014-12-23 11:11:29 <fanquake> jonasschelli Did you see the April fools BIP that sipa and a few other wrote up?
247 2014-12-23 11:11:40 <jonasschnelli> no
248 2014-12-23 11:12:13 <Luke-Jr> fanquake: that was totally serious!
249 2014-12-23 11:12:16 <afk11> It was merged.
250 2014-12-23 11:12:20 <jonasschnelli> Is there no pre-work (mental or implementation) for multiple wallet support as is is in Multibit?
251 2014-12-23 11:12:24 <Luke-Jr> unless it kept the part about PHP
252 2014-12-23 11:13:06 <fanquake> Luke-Jr heh. Iâll have to go an track it down then.
253 2014-12-23 11:13:39 <afk11> Its in the change logs, meaning, a core fundamental of bitcoin was changed without many peoples knowledge :p
254 2014-12-23 11:15:06 <wumpus> jonasschnelli: you can create multiple wallet objects, it's just that the RPC interface would have to be redesigned
255 2014-12-23 11:15:41 <jonasschnelli> wumpus: so switching pwalletMain under the hood works?
256 2014-12-23 11:15:47 <wumpus> afk11: well a core fundamental was platform dependent, which would imply a fork somewhere far in the future, so yes the underlying idea was serious just not how it was presented
257 2014-12-23 11:15:59 <wumpus> jonasschnelli: no no no
258 2014-12-23 11:16:13 <Luke-Jr> fanquake: basically, the original consensus algorithm had an infinite number of bitcoins, not the widely claimed 21 million BTC. so that BIP you're thinking of hardforked it to the widely-believed limit
259 2014-12-23 11:16:23 <Luke-Jr> softforked*
260 2014-12-23 11:16:37 <wumpus> jonasschnelli: it doesn't work, and anything supporting multiwallet would get rid of pwalletmain
261 2014-12-23 11:17:00 <jonasschnelli> okay.
262 2014-12-23 11:17:02 <Luke-Jr> fanquake: the original algorithm was after ~256 years, the subsidy began over at 50 BTC
263 2014-12-23 11:17:20 <wumpus> jonasschnelli: it's just that the base ideas are there, you'd need serious changes to the RPC interface as well as initialization/shutdown to make it really work
264 2014-12-23 11:17:50 <wumpus> jonasschnelli: note that the UI only uses pwalletmain at startup, apart from that it's multi-wallet-agnostic
265 2014-12-23 11:17:51 <fanquake> Luke-Jr heh. Well remind me when Iâm 260 or so.
266 2014-12-23 11:18:03 <Luke-Jr> fanquake: too late, the softfork is live :P
267 2014-12-23 11:18:15 <wumpus> jonasschnelli: multiple wallet views, multiple walletmodels, it should work (but is ofcourse entirely untested)
268 2014-12-23 11:18:24 <fanquake> Well damn, guess I can make sure I donât worry about it any more.
269 2014-12-23 11:18:27 <Luke-Jr> fanquake: also, it was implemented with undefined behaviour, so easily broken when/if the CPU or compiler changed
270 2014-12-23 11:19:09 <fanquake> ACTION wonders what our CPUs will be like in 200 years time
271 2014-12-23 11:19:14 <wumpus> Luke-Jr: yes, that was a serious issue, there is no guarantee that shifts will behave in that way
272 2014-12-23 11:19:15 <jonasschnelli> wumpus: okay. Thats good to know. But does the RPC could not live with a "switchwallet" command?
273 2014-12-23 11:19:31 <wumpus> jonasschnelli: no statefulness
274 2014-12-23 11:19:37 <wumpus> jonasschnelli: really, don't do that
275 2014-12-23 11:20:08 <Luke-Jr> +1000 for breaking RPC interface
276 2014-12-23 11:20:21 <wumpus> think of the poor people running more than one client concurrently, for example
277 2014-12-23 11:20:47 <wumpus> there are lots of reasons to redesign the wallet RPC interface, and multiwallet is one of them
278 2014-12-23 11:21:02 <jonasschnelli> Okay. Yes. Thats an issue.
279 2014-12-23 11:21:25 <Luke-Jr> (outside of the much-needed RPC API change, multiwallet could easily be done with multiple usernames)
280 2014-12-23 11:21:40 <wumpus> in the most obvious design change the RPC wallet calls would just gain an initial wallet ID argument
281 2014-12-23 11:22:05 <wumpus> Luke-Jr: that's also an ugly workaround ,but not as ugly as statefulness
282 2014-12-23 11:22:33 <fanquake> wumpus How far into the future do you want multi-wallet support to be?
283 2014-12-23 11:22:33 <Luke-Jr> only slightly ugly IMO, but as long as we want an API break anyway, might as well not use the username trick I agree
284 2014-12-23 11:22:35 <jonasschnelli> Remove states. The initial wallet ID sounds good and stable.
285 2014-12-23 11:22:54 <wumpus> fanquake: depending on whether someone will work on it, everything from one week to 20 years :P
286 2014-12-23 11:23:07 <Luke-Jr> well, it's too late for 0.10 at least :p
287 2014-12-23 11:23:12 <wumpus> oh yes, much too late
288 2014-12-23 11:23:21 <fanquake> one week? Time to jam it into 0.10 :p
289 2014-12-23 11:23:33 <Luke-Jr> maybe a year ago, someone had a patch for the multi-username trick, actually
290 2014-12-23 11:23:43 <wumpus> yes
291 2014-12-23 11:23:53 <jonasschnelli> is that useable in some ways?
292 2014-12-23 11:24:04 <Luke-Jr> I'm sure we've shuffled the code too much since then
293 2014-12-23 11:24:05 <wumpus> but as usual, do to the almost absent interest in wallet changes, it went out of date
294 2014-12-23 11:24:15 <Luke-Jr> it was fairly simple IIRC
295 2014-12-23 11:24:28 <Luke-Jr> I mean, most of the stuff is already abstracted for it
296 2014-12-23 11:24:36 <wumpus> yes it was fairly simple
297 2014-12-23 11:24:45 <wumpus> as I said, initialization ,shutdown, RPC interface, that's it
298 2014-12-23 11:24:59 <wumpus> make sure noone uses pwalletmain anymore
299 2014-12-23 11:25:14 <Luke-Jr> the downside to this way, is that all wallets "need" to be loaded all the time, or you have to rescan
300 2014-12-23 11:25:16 <jonasschnelli> but long-term-wise i first see a rewrite of the current wallet-backend-implementation. Nothing against BDB, but a tiny append-only-format would make things more easy.
301 2014-12-23 11:25:35 <wumpus> Luke-Jr: oh yes dynamic loading and unloading wallets would be a future step then
302 2014-12-23 11:25:59 <wumpus> Luke-Jr: but you'll have to fight bdb... hard
303 2014-12-23 11:26:19 <Luke-Jr> hopefully bdb is gone soon <.<
304 2014-12-23 11:26:19 <wumpus> another thing that would be easier with a one-file database format
305 2014-12-23 11:27:26 <wumpus> so all of these wallet changes really hinge on each other
306 2014-12-23 11:31:01 <midnightmagic> ACTION stabs bdb
307 2014-12-23 11:46:03 <wumpus> it just won't die
308 2014-12-23 11:47:31 <fanquake> Think Iâve broken VirtualBox
309 2014-12-23 11:53:42 <wumpus> whoa, 1122 commits in v0.9.3..0.10 after removing what was cherry-picked into 0.9...
310 2014-12-23 11:56:19 <fanquake> thatâs alot of code review/testing
311 2014-12-23 11:56:35 <gmaxwell> averages out to only a couple per day though.
312 2014-12-23 11:56:40 <fanquake> although, how long since 0.9.3 came out now?
313 2014-12-23 11:57:41 <wumpus> fanquake: a few months, would be more realistic to start counting from 0.9's forking point
314 2014-12-23 11:59:28 <fanquake> quick look on github suggests that 0.9 is ~1800 commits behind master
315 2014-12-23 11:59:58 <wumpus> yes - as said, my count excludes merge commits as well as commits that have in some fashion ended up in 0.9 already
316 2014-12-23 12:00:59 <fanquake> Yea. Iâve noticed that fixes are still being pushed to the 0.9 branch
317 2014-12-23 12:01:11 <wumpus> going to go through them and remove the really trivial ones, then maybe sort them into boxes, though I may not bother
318 2014-12-23 12:02:36 <fanquake> sort them into boxes? As sorted by serverity or something?
319 2014-12-23 12:02:47 <wumpus> no, by aspect, as in earlier changelogs
320 2014-12-23 12:03:01 <fanquake> ah ok
321 2014-12-23 12:05:46 <wumpus> e.g., and changes that fix regressions that were introduced on the way to 0.10 aren't interesting for the release notes either
322 2014-12-23 12:06:47 <fanquake> Yep. Like the inflight dos fixed just merged.
323 2014-12-23 12:07:08 <wumpus> but I like that commit title so much :(
324 2014-12-23 12:07:10 <wumpus> you're right htough
325 2014-12-23 12:07:47 <fanquake> Iâm sure no one would object to itâs inclusion in the release notes
326 2014-12-23 12:07:50 <firelegend> What is the maximum size of a script used in an output?
327 2014-12-23 12:07:56 <wumpus> sounds like a techno-triller its own right
328 2014-12-23 12:09:28 <wumpus> firelegend: very large, although the transaction will be non-standard so you'll have trouble getting it mined
329 2014-12-23 12:16:48 <wumpus> if anyone of you happens to have a qt bug tracker account, please click vote for my issue https://bugreports.qt-project.org/browse/QTBUG-43168 for more secure payment requests fetching
330 2014-12-23 12:19:51 <wumpus> (or help fix the issue, even better of course)
331 2014-12-23 12:26:48 <midnightmagic> what's the status of the qt lib anyway? there's been a significant number of open "security vulnerabilities" listed in the netbsd pkgsrc for a number of years
332 2014-12-23 12:29:12 <wumpus> it probably needs help, like any open source project
333 2014-12-23 12:30:00 <midnightmagic> it feels as though the upstream is no longer developing it. has it effectively been abandoned? the distribution sites are a little muddled these days
334 2014-12-23 12:30:16 <wumpus> lots of companies using qt, not so many contributing back, it's a general theme
335 2014-12-23 12:30:26 <michagogo> Hm, why is BIP42 still a Draft?
336 2014-12-23 12:30:26 <midnightmagic> true enough
337 2014-12-23 12:30:32 <michagogo> (gmaxwell: ^)
338 2014-12-23 12:32:15 <wumpus> midnightmagic: it is still actively developed, though they had a shift in focus toward QML, 'widgets' is more and more considered legacy code
339 2014-12-23 12:32:30 <wumpus> midnightmagic: which is a pity, I like widgets.
340 2014-12-23 12:32:53 <wumpus> anyhow, the network code should still be actively maintained
341 2014-12-23 12:33:08 <midnightmagic> hrmm
342 2014-12-23 12:35:27 <wumpus> hopefully when this mobile/web draw-your-own-UI hype is over, the pendulum will return to sane, standard, reusable, accessibility-friendly widgets
343 2014-12-23 12:36:21 <sipa> wumpus: we should probably disable autodetecting/using gmp in libsecp in bitcoin 0.10, or you may end up with an unintended bitcoin dependency
344 2014-12-23 12:36:39 <wumpus> sipa: ACK
345 2014-12-23 12:37:15 <sipa> do you want an update to master, or just a hotfix?
346 2014-12-23 12:37:52 <wumpus> a hotfix for just 0.10 is fine in this case, for master it will be part of the regular secp256k1 update I suppose
347 2014-12-23 12:38:58 <sipa> ok, sounds good
348 2014-12-23 12:41:42 <jonasschnelli> sipa: regarding a possible new wallet format: did you also had in mind a append-only key/value store, reverse read-in?
349 2014-12-23 12:42:11 <jonasschnelli> (and a optional compact write to reorganize and optimize the store)
350 2014-12-23 12:48:22 <sipa> jonasschnelli: yes, but forward read :)
351 2014-12-23 12:48:50 <sipa> just replace items.in your memory map while reading
352 2014-12-23 12:49:00 <sipa> so the last write counts
353 2014-12-23 12:49:19 <jonasschnelli> Why not reverse read and skip already read keys?
354 2014-12-23 12:50:05 <jonasschnelli> (keys means key/value keys)
355 2014-12-23 12:54:21 <wumpus> my primary requirement for the wallet format would be that the new format, once introduced, is designed to be both forwards and backwards compatible
356 2014-12-23 12:57:35 <jonasschnelli> wumpus: Yes. Thats a good idea.
357 2014-12-23 12:58:25 <jonasschnelli> But brings in the question of a ideal serialization format.
358 2014-12-23 12:58:30 <wumpus> (the only other sane way would be to make the wallet format incrediblely version-dependent, then make sure the upgrader exports in a portable format and re-imports, but it sounds much more fickle...)
359 2014-12-23 12:58:59 <wumpus> so only backups would be in a portable format
360 2014-12-23 13:00:18 <wumpus> jonasschnelli: as it is bound to the block chain our own serialization format is extremely stable, if bitcoin still exists in 100 years, it's bound to have changed little
361 2014-12-23 13:00:43 <jonasschnelli> Yes. It's good. But can it be read reverse?
362 2014-12-23 13:00:59 <wumpus> as sipa says, I wouldn't bother with reading reverse
363 2014-12-23 13:01:12 <wumpus> of course you could, with appropriate framing
364 2014-12-23 13:01:29 <jonasschnelli> add a header envelope.
365 2014-12-23 13:02:12 <jonasschnelli> I mean take Jouke >200'000 tx wallet... backward reading would make sense there..
366 2014-12-23 13:02:31 <wumpus> why? you still need to read through all of it
367 2014-12-23 13:02:46 <wumpus> and if you have to read through the entire file, reading forward is much faster
368 2014-12-23 13:02:47 <jonasschnelli> yes. But you can skip a lot of things.
369 2014-12-23 13:03:13 <jonasschnelli> if might end up fseek the most part
370 2014-12-23 13:03:17 <gmaxwell> You may have a mistaken impression about how big a typical wallet is?
371 2014-12-23 13:03:36 <gmaxwell> feesking backworks skipping only a few kb at a time is not going to be hugely fast.
372 2014-12-23 13:04:18 <jonasschnelli> Thats true. But when we have to change of writing a new format...
373 2014-12-23 13:04:28 <jonasschnelli> But yes. Maybe a simple forward read is okay.
374 2014-12-23 13:04:30 <wumpus> I'd recommend against premature optimization
375 2014-12-23 13:07:50 <wumpus> the overarching goal would still be to have a stable, straightforward, secure, reference implmentation of a wallet, not the fastest possible one
376 2014-12-23 13:09:23 <sipa> jonasschnelli: what benefit does skipping already read keys offer? you still need to skip them; likely you need exactly the same sectors from disk, and forward sequential reads are far faster than seeks
377 2014-12-23 13:09:39 <sipa> you still need to go through the entire file in any case
378 2014-12-23 13:09:57 <jonasschnelli> sipa: yes. for memory mapping yes.
379 2014-12-23 13:10:39 <sipa> i'm still unclear what benefit you think it would have :)
380 2014-12-23 13:10:41 <wumpus> if the goal is pure speed, using one of the existing database solution is preferable to NIH'ing it,but we don't want that as we want a stable straightforward format
381 2014-12-23 13:11:19 <sipa> how about using ASN.1? *ducks*
382 2014-12-23 13:11:32 <wumpus> hehe
383 2014-12-23 13:11:55 <sipa> or JSONx
384 2014-12-23 13:13:22 <jonasschnelli> Truly. In our case backward reading makes not that much sense. It would make sense if we would append-overwrite keys in the store and lookup records from disk.
385 2014-12-23 13:13:47 <sipa> ok
386 2014-12-23 13:14:23 <sipa> jonasschnelli: i have a >2 year old branch here: https://github.com/sipa/bitcoin/commits/logdb
387 2014-12-23 13:18:08 <jonasschnelli> sipa... hmm.. nice.
388 2014-12-23 13:19:18 <bedeho> can OP_CHECKMULTISIG be used with all signature types? (ALL, NONE, SINGLE, ANYONECANPAY)
389 2014-12-23 13:19:31 <jonasschnelli> sipa: so you checksum everything with SHA256 there?
390 2014-12-23 13:19:35 <sipa> jonasschnelli: yes
391 2014-12-23 13:20:11 <jonasschnelli> sipa: makes more sense then crc32
392 2014-12-23 13:21:07 <sipa> it's truncated sha256, but it's computed over _all_ data in the file, with checkpoints after every write
393 2014-12-23 13:21:36 <wumpus> nice approach
394 2014-12-23 13:22:15 <jonasschnelli> sipa: and how do you serialize?
395 2014-12-23 13:22:28 <sipa> jonasschnelli: bitcoin does the serialization
396 2014-12-23 13:22:39 <sipa> logdb just writes byte-array key-value pairs
397 2014-12-23 13:23:40 <jonasschnelli> so, CLogDBFile::Flush_() does the persistent file store?
398 2014-12-23 13:23:51 <sipa> ehhhh i'd have to look at the file :)
399 2014-12-23 13:24:13 <sipa> wumpus: i don't think i ever submitted a PR for a non-master branch
400 2014-12-23 13:24:19 <sipa> #5531 is
401 2014-12-23 13:24:23 <jonasschnelli> sipa: yes. sorry for questioning you... :)
402 2014-12-23 13:24:24 <wumpus> sipa: thanks
403 2014-12-23 13:24:35 <sipa> jonasschnelli: heh, i'd be glad if someone picks it up
404 2014-12-23 13:25:07 <jonasschnelli> i try to shift in your commits and extend it....
405 2014-12-23 13:25:33 <sipa> it needs error recovery etc
406 2014-12-23 13:25:39 <jonasschnelli> whats basically missing is the optional switch between a bdb and logdb wallet
407 2014-12-23 13:25:47 <sipa> i wouldn't have such a switch
408 2014-12-23 13:25:55 <sipa> just an external tool that can convert between them
409 2014-12-23 13:26:10 <jonasschnelli> but what if people like to stick to bdb?
410 2014-12-23 13:26:18 <sipa> then they're pretty crazy
411 2014-12-23 13:26:30 <jonasschnelli> i would go the depracate in V0.11, remove in V0.12 approach
412 2014-12-23 13:26:31 <sipa> sorry just joking; sure, maybe for some time support both
413 2014-12-23 13:26:45 <wumpus> I would really not like to support both
414 2014-12-23 13:26:50 <sipa> but i would really prefer rewriting the wallet from scratch
415 2014-12-23 13:26:51 <jonasschnelli> (don't take the version numbers serious!)
416 2014-12-23 13:27:05 <sipa> and do things sanely from the start
417 2014-12-23 13:27:10 <jonasschnelli> no fears of breaking user wallets
418 2014-12-23 13:27:11 <jonasschnelli> ?
419 2014-12-23 13:27:50 <wumpus> jonasschnelli: as said, I'd just do a clean break, ie freeze the current wallet code (not much needed for that), make a newwallet branch and merge it when the whole thing is ready
420 2014-12-23 13:28:23 <sipa> maybe someone (not us) wants to maintain a branch with the old wallet code around
421 2014-12-23 13:28:31 <wumpus> exactly
422 2014-12-23 13:28:55 <sipa> and breaking user wallets... well, it's probably near impossible to make the external interface 100% identical
423 2014-12-23 13:29:22 <wumpus> there will of course need to be a conversion tool distributed with the release, and some wizard to call it automatically for UI users
424 2014-12-23 13:29:43 <wumpus> sipa: yup
425 2014-12-23 13:29:55 <jonasschnelli> sipa: so you say the CWallet should also be written from the scratch?
426 2014-12-23 13:30:04 <sipa> yes
427 2014-12-23 13:30:18 <sipa> (says the person who introduced the CWallet class to begin with...)
428 2014-12-23 13:30:54 <wumpus> you could start from scratch, or at least do a big reorganization, don't know what approach is preferable
429 2014-12-23 13:31:09 <sipa> well... there will be significant parts of reusable code
430 2014-12-23 13:31:12 <sipa> like the coin selection
431 2014-12-23 13:31:31 <wumpus> it's fine to delete the account system, change the RPC interface
432 2014-12-23 13:32:10 <wumpus> there will be a lot of code that just works where it makes no sense to rewrite
433 2014-12-23 13:32:33 <jonasschnelli> many parts of CWallet looks fine to me
434 2014-12-23 13:32:36 <wumpus> if anything, rewriting too enthousiastically just introduces bugs
435 2014-12-23 13:33:08 <sipa> well those who don't know history are doomed to repeat it; and most commonly the reason for wanting to rewrite code is because you don't understand the reasons why the original was so complex to begin with
436 2014-12-23 13:33:13 <jonasschnelli> - acount system, + multiple wallet
437 2014-12-23 13:33:17 <sipa> + spv
438 2014-12-23 13:33:23 <sipa> - bdb
439 2014-12-23 13:33:33 <wumpus> sounds like a good aim
440 2014-12-23 13:33:47 <jonasschnelli> yes. spv could be my 2nd goal for 2015...
441 2014-12-23 13:34:07 <sipa> *challenge accepted*
442 2014-12-23 13:34:11 <sipa> (make spv work in 2014 :p)
443 2014-12-23 13:34:19 <jonasschnelli> ha
444 2014-12-23 13:34:25 <jonasschnelli> where's your branch? :)
445 2014-12-23 13:34:31 <sipa> I HAVE A WEKK
446 2014-12-23 13:35:07 <fanquake> sipa Youâd have less time if you were here :P
447 2014-12-23 13:35:27 <sipa> you mean the christman and newyear thing?
448 2014-12-23 13:36:12 <fanquake> nah, Iâm pretty sure weâre just ahead (time wise) of everyone else
449 2014-12-23 13:37:26 <sipa> australia?
450 2014-12-23 13:38:09 <fanquake> Gâday
451 2014-12-23 13:38:43 <sipa> damn stray aliens
452 2014-12-23 13:39:42 <fanquake> Itâs to hot to worry about christmas here, you should be happy to just survive dec/jan/feb
453 2014-12-23 13:39:54 <gmaxwell> sipa: headers first was a really significant part of that work in any case.
454 2014-12-23 13:39:59 <sipa> gmaxwell: yes :)
455 2014-12-23 13:40:22 <gmaxwell> it kinda works, in fact already because of that. :P
456 2014-12-23 14:42:18 <sipa> wumpus: no more 0.10 milestones?
457 2014-12-23 14:43:19 <wumpus> sipa: nope, will tag 0.10rc1 after I finish writing the release notes
458 2014-12-23 14:43:30 <sipa> want me to review them?
459 2014-12-23 14:43:50 <wumpus> sure, will pass them here first
460 2014-12-23 14:44:13 <wumpus> still ~400 commits to go through
461 2014-12-23 14:44:17 <sipa> wow
462 2014-12-23 14:50:23 <michagogo> wumpus: do you think 0.9.4 will happen?
463 2014-12-23 14:50:32 <michagogo> (should I keep the 0.9 deps?)
464 2014-12-23 14:50:58 <wumpus> michagogo: that's impossible to say, in general if an important fix is needed it will happen
465 2014-12-23 14:51:23 <michagogo> I guess we're just at the start of the 0.10 release cycle
466 2014-12-23 14:51:36 <michagogo> I guess I'll keep it around... pretty sure I have the space
467 2014-12-23 14:51:36 <sipa> i'd say we'll need a successor to 0.9.3 in any case if we want to do BIP62/CTLV/..., as those will need backports
468 2014-12-23 14:52:51 <michagogo> It annoys me that each time Ubuntu updates Linux, the vbox guest additions need to be reinstalled again
469 2014-12-23 14:53:10 <wumpus> well, BIP62/CTLV needs to be happen in 0.11
470 2014-12-23 14:53:20 <wumpus> so I'd indeed say yes then
471 2014-12-23 15:19:59 <michagogo> wumpus: Is there a way to gbuild just the deps?
472 2014-12-23 15:22:06 <michagogo> oh, can I just comment out the actual build in the descriptor?
473 2014-12-23 15:39:20 <wumpus> sure
474 2014-12-23 15:41:02 <wumpus> phew, 0.10 preliminary release notes: https://gist.github.com/laanwj/c94f5222aadb3fc8fe1a
475 2014-12-23 15:41:04 <wumpus> @sipa
476 2014-12-23 15:46:06 <sipa> wumpus: oh, update the builtin seeds now?
477 2014-12-23 16:11:22 <michagogo> Ooh, getwork's dead?
478 2014-12-23 16:11:32 <michagogo> About time...
479 2014-12-23 16:13:07 <michagogo> Heh, I remember https://github.com/bitcoin/bitcoin/commit/6c37f7f
480 2014-12-23 16:13:22 <michagogo> (I think I may have been that user, actually?)
481 2014-12-23 16:14:31 <michagogo> wumpus: 6b407e4 -datadir is now allowed in config files
482 2014-12-23 16:14:41 <michagogo> That's not a command-line option change
483 2014-12-23 16:14:54 <michagogo> It's just an update to the debian doc
484 2014-12-23 16:17:04 <michagogo> Um, why is "45a4baf Add testnet DNS seed of Andreas Schildbach" in "Block and transaction handling:"?
485 2014-12-23 16:17:21 <michagogo> While "c30329a Add testnet DNS seed of Alex Kotenko" is in "P2P protocol and network code:"
486 2014-12-23 16:18:21 <michagogo> And I don't think "9765a50 Implement BIP 23 Block Proposal" belongs in there, that's RPC, not P2P
487 2014-12-23 16:19:32 <wumpus> sipa: makes sense
488 2014-12-23 16:20:24 <wumpus> BIP 23 is network not RPC
489 2014-12-23 16:20:41 <michagogo> wumpus: hm? Isn't it a mining rpc?
490 2014-12-23 16:20:41 <wumpus> you're right that the seed updates belong under P2P though
491 2014-12-23 16:20:53 <michagogo> (the file edited is rpcmining.cpp...)
492 2014-12-23 16:21:10 <wumpus> michagogo: oh, than I'm confused
493 2014-12-23 16:21:38 <michagogo> Also, is the osx detached signing being done in 0.10.0? Don't see it under build
494 2014-12-23 16:21:40 <wumpus> I generally consider BIP == network level, but mining is special here
495 2014-12-23 16:22:06 <wumpus> michagogo: what commit?
496 2014-12-23 16:22:14 <michagogo> ACTION looks
497 2014-12-23 16:23:01 <wumpus> michagogo: you may have to ask cfields there, I don't follow macosx that closely
498 2014-12-23 16:23:43 <michagogo> https://github.com/bitcoin/bitcoin/commit/914868a05dfcae0f766283e0065aa36762cc5abe
499 2014-12-23 16:24:17 <michagogo> Hm, says it's just in master
500 2014-12-23 16:24:29 <wumpus> ok
501 2014-12-23 16:24:35 <michagogo> Wait, when did 0.10 branch off?
502 2014-12-23 16:24:40 <michagogo> More than a month ago?
503 2014-12-23 16:25:04 <wumpus> you can easily ask that to git instead of to us
504 2014-12-23 16:26:04 <gribble> How to determine when a Git branch was created? - Stack Overflow: <http://stackoverflow.com/questions/2255416/how-to-determine-when-a-git-branch-was-created>; find out when a git branch was created (not the first commit to that ...: <http://stackoverflow.com/questions/18277841/find-out-when-a-git-branch-was-created-not-the-first-commit-to-that-branch>; What is the easiest/fastest way (1 more message)
505 2014-12-23 16:26:04 <michagogo> ;;google git find out when a branch was created
506 2014-12-23 16:28:01 <michagogo> Thu Dec 11 13:17:34 2014 +0100
507 2014-12-23 16:28:11 <michagogo> So yes, the deterministic build should be in
508 2014-12-23 16:28:24 <michagogo> erm
509 2014-12-23 16:28:31 <michagogo> s/build/signing/
510 2014-12-23 16:28:55 <michagogo> Which is supported by release-process and the descriptors dir... which I should have checked in the first place...
511 2014-12-23 16:28:58 <sipa> wumpus: i'll send a PR for updating the seeds in 10 min (that's when dnsseeder dumps again... seems i overwrote the previous one)
512 2014-12-23 16:29:17 <michagogo> wumpus: so that also needs to get added
513 2014-12-23 16:29:31 <wumpus> michagogo: git branch --contains
514 2014-12-23 16:29:43 <wumpus> michagogo: and yes, it's in there
515 2014-12-23 16:30:01 <michagogo> Ah, good to know
516 2014-12-23 16:30:26 <wumpus> sipa: great!
517 2014-12-23 16:32:41 <wumpus> michagogo: ok, updated, thanks for the comments
518 2014-12-23 16:34:23 <michagogo> Still reading, haven't refreshed yet, but some of the misc things could be elsewhere, I think.
519 2014-12-23 16:34:33 <michagogo> For example, "f9de17e Add warning comment to getinfo" could probably be rpc?
520 2014-12-23 16:34:56 <michagogo> Oh, it's just comment
521 2014-12-23 16:35:00 <michagogo> +a
522 2014-12-23 16:35:37 <wumpus> yeah, some are in a grey area
523 2014-12-23 16:35:39 <michagogo> "76ec867 Use actually valid transactions for script tests" and "c8589bf Add actual signature tests" should probably be under tests, though
524 2014-12-23 16:35:50 <wumpus> I don't really want arguments about what belongs there unless it's clear-cut wrong
525 2014-12-23 16:36:08 <wumpus> what belongs where*
526 2014-12-23 16:37:21 <michagogo> I'd argue that those two (and maybe "219a147 script: check ScriptError values in script tests", in validation atm, as well?) are pretty clear-cut
527 2014-12-23 16:37:35 <michagogo> They update/improve the tests
528 2014-12-23 16:37:47 <michagogo> And we have a Tests category
529 2014-12-23 16:38:05 <michagogo> Anyway, just finished reading it, looks pretty good
530 2014-12-23 16:38:17 <michagogo> Though I didn't go through in-depth, just skimmed it
531 2014-12-23 16:39:26 <michagogo> Hm, only question I have is are there any other features that we want to mention in the written notes, and not just the commit list
532 2014-12-23 16:39:31 <michagogo> For example, watch-only
533 2014-12-23 16:39:42 <sipa> watch-only addresses may be worth a section of its own
534 2014-12-23 16:40:02 <michagogo> sipa: right, that's what I mean
535 2014-12-23 16:40:10 <wumpus> michagogo:yes, good idea, feel free to write a section about it
536 2014-12-23 16:40:26 <wumpus> although watch-only is still experimental
537 2014-12-23 16:40:31 <michagogo> I don't know enough about it
538 2014-12-23 16:40:34 <wumpus> ie, it hasn't been added to the GUI on purpose
539 2014-12-23 16:40:37 <michagogo> (also I'm a terrible writer)
540 2014-12-23 16:42:13 <wumpus> libbitcoinconsensus probably needs a section of its own too
541 2014-12-23 16:42:23 <michagogo> Maybe also bitcoin-tx
542 2014-12-23 16:42:33 <michagogo> (maybe not)
543 2014-12-23 16:42:34 <wumpus> yes
544 2014-12-23 16:42:36 <wumpus> ping @jgarzik
545 2014-12-23 16:44:35 <jgarzik> wumpus, ?
546 2014-12-23 16:44:50 <wumpus> jgarzik: mind writing something about bitcoin-tx for the 0.10 release notes?
547 2014-12-23 16:45:02 <sipa> i can write something about watch-only addresses
548 2014-12-23 16:45:09 <jgarzik> wumpus, sure
549 2014-12-23 16:45:42 <michagogo> D'you think anything should be said about getwork? (i.e. is anyone anywhere still using it, and would need to know it's out?)
550 2014-12-23 16:45:45 <wumpus> sipa: ok, that'd be nice, the seed update is more urgent though :)
551 2014-12-23 16:46:02 <sipa> wumpus: #5532
552 2014-12-23 16:48:24 <wumpus> michagogo: it's mentioned under RPC changes, I think that's enough
553 2014-12-23 16:48:33 <michagogo> wumpus: yeah, probably
554 2014-12-23 16:49:48 <michagogo> Erm, I think I found a bug with the cache
555 2014-12-23 16:49:59 <michagogo> idk if it's a bug in gitian or in our descriptors
556 2014-12-23 16:52:44 <sipa> wumpus: can you maybe just commit the release notes to the 0.10 repository, so there can be PRs suggested etc for it, and it won't get out of sync with the tree if we do changes in rcs?
557 2014-12-23 16:52:59 <michagogo> http://paste.ubuntu.com/9604904/
558 2014-12-23 16:54:00 <michagogo> I created gitian-builder/cache and gitian-builder/cache/common, and put all the deps' tarballs (that I had, at least) into the latter
559 2014-12-23 16:54:32 <michagogo> gitian-builder/cache/bitcoin-linux-0.10 was created, but is empty
560 2014-12-23 16:54:43 <wumpus> sipa: yes
561 2014-12-23 16:55:50 <wumpus> sipa: I intend to do that, but first wanted to fix initial commits on IRC, so that the commit log doesn't become a mess of small updates to the changelog
562 2014-12-23 16:56:04 <sipa> right, sure
563 2014-12-23 16:56:43 <michagogo> gitian-builder/cache/cache is created, inside it there's common, which is a copy of cache/common, and bitcoin-linux-0.10 which does have all our built deps
564 2014-12-23 17:00:42 <wumpus> michagogo: weird
565 2014-12-23 17:11:18 <gavinandresen> wumpus: release notes look good to me after a quick read-through
566 2014-12-23 17:11:39 <sipa> wumpus: https://gist.github.com/sipa/df19edb59e96853754bb
567 2014-12-23 17:11:54 <sipa> and of course, s/not/now/ in the first sentence...
568 2014-12-23 17:13:23 <gavinandresen> Even better: âThe wallet can now trackâ¦.â
569 2014-12-23 17:14:22 <sipa> gavinandresen: done
570 2014-12-23 17:14:26 <gavinandresen> ⦠because it is possible to write in a more active voiceâ¦.
571 2014-12-23 17:14:46 <wumpus> sipa: thanks, looks good to me, will add
572 2014-12-23 17:15:21 <wumpus> I think you can leave out the word 'relevant' before private keys without change of meaning
573 2014-12-23 17:15:33 <sipa> go ahead and remove it when copyin
574 2014-12-23 17:15:43 <wumpus> ok
575 2014-12-23 17:20:51 <wumpus> https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md
576 2014-12-23 17:23:06 <hearn> have there been any 0.10 rcs yet?
577 2014-12-23 17:23:37 <sipa> no
578 2014-12-23 17:23:42 <sipa> verrrrry soon
579 2014-12-23 17:24:11 <sipa> wumpus: i'd like a section about libconsensus too
580 2014-12-23 17:25:18 <wumpus> sipa: yes, working on that
581 2014-12-23 17:25:24 <sipa> ah cool, thanks
582 2014-12-23 17:25:40 <wumpus> Luke-Jr: did you perhaps already write a blorb about libbitcoinconsensus? I see you've made an ebuild
583 2014-12-23 17:30:22 <sipa> wumpus: do we want a list of all new command-line flags/rpcs?
584 2014-12-23 17:30:47 <wumpus> sipa: I've tried to do that in the RPC and command line sections, though I may have missed some
585 2014-12-23 17:31:17 <wumpus> (ie, if they're not mentioned in commit messages)
586 2014-12-23 17:31:49 <wumpus> feel free to add ones, but I wouldn't recommend adding another section for it, to avoid duplication
587 2014-12-23 17:31:56 <sipa> ok, agree
588 2014-12-23 17:31:59 <sipa> i'll compare the code
589 2014-12-23 17:37:46 <sipa> wumpus: since 0.9.0 or 0.9.3 (though i doubt much changed in between)
590 2014-12-23 17:38:16 <wumpus> 0.9.3 is the reference point
591 2014-12-23 17:38:53 <wumpus> after all, if it is already in a 0.9 release it's not new
592 2014-12-23 17:39:14 <michagogo> ACTION wonders why people call them command-line flags when mostly they're config flags that can also be specified on the command line
593 2014-12-23 17:40:31 <hearn> where is CTransaction declared these days?
594 2014-12-23 17:40:43 <sipa> primitives/transaction.h
595 2014-12-23 17:40:57 <hearn> thanks
596 2014-12-23 17:42:04 <wumpus> michagogo: because they're described as command line flags (ie, with the - before them), it is also possible to specify them in bitcoin.conf, but that's not relevant to the release notes
597 2014-12-23 17:43:08 <wumpus> michagogo: although strictly spoken the config file options are a subset of command line options, as -conf cannot be specified in the configuration file :-)
598 2014-12-23 17:44:16 <sipa> wumpus: quite a few!
599 2014-12-23 17:57:49 <sipa> wumpus: i think we also need to mention -disablewallet?
600 2014-12-23 17:57:54 <sipa> or was that in 0.9 already?
601 2014-12-23 17:58:35 <wumpus> yes, that's old hat
602 2014-12-23 18:00:00 <wumpus> re: consensus libarary http://www.hastebin.com/raranivami.md
603 2014-12-23 18:01:28 <petertodd> wumpus: should mention the P2SH IsStandard() relaxation briefly
604 2014-12-23 18:01:52 <sipa> yup
605 2014-12-23 18:01:56 <sipa> and -rest