1 2013-10-15 01:08:15 <shamoon> trying to build
2 2013-10-15 01:08:19 <shamoon> g++: internal compiler error: Killed (program cc1plus)
3 2013-10-15 01:08:19 <shamoon> P=0 -DUSE_IPV6=1 -I/home/ubuntu/bitcoin/src/leveldb/include -I/home/ubuntu/bitcoin/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2 -MMD -MF obj/bitcoinrpc.d -o obj/bitcoinrpc.o bitcoinrpc.cpp
4 2013-10-15 01:08:24 <shamoon> Luke-Jr: you around?
5 2013-10-15 01:08:29 <Luke-Jr> ?
6 2013-10-15 01:08:58 <Luke-Jr> shamoon: out of memory
7 2013-10-15 01:09:02 <shamoon> blast
8 2013-10-15 01:09:24 <shamoon> so a micro AWS instance won't cut it, eh?
9 2013-10-15 01:09:37 <shamoon> how much memory do i need?
10 2013-10-15 01:09:51 <Luke-Jr> dunno, 16 GB seems to work
11 2013-10-15 01:10:51 <shamoon> damn, the 16GB instances are pricey
12 2013-10-15 01:12:21 <maaku> shamoon: you can *run* bitcoind on a micro instance (not recommended for other reasons)
13 2013-10-15 01:12:41 <shamoon> but not for development, i guess
14 2013-10-15 01:12:44 <maaku> just compile it on your own vm
15 2013-10-15 01:12:54 <gmaxwell> Compiling it takes more memory than running it.
16 2013-10-15 01:13:09 <shamoon> okay, so i'll set up a VM on my mac
17 2013-10-15 01:13:10 <shamoon> and use that
18 2013-10-15 01:13:12 <maaku> yeah should have started with that ^^
19 2013-10-15 01:13:28 <Luke-Jr> hmm, I bet 4 GB is sufficient for compiling - or else it wouldn't build on x86 :D
20 2013-10-15 01:16:53 <maaku> I've compiled on a 1GB instance, but that may have been pushing it
21 2013-10-15 01:16:59 <shamoon> so once i compile on my VM, i just move bitcoind to my aws instance?
22 2013-10-15 01:17:02 <maaku> depends very much on what else you have running
23 2013-10-15 01:17:07 <shamoon> and if all the deps are there, it should run?
24 2013-10-15 01:17:29 <maaku> shamoon: yes, but you can also enable static linking so it will not require the deps
25 2013-10-15 01:17:40 <shamoon> maaku: how does one do such a thing?
26 2013-10-15 01:17:53 <maaku> not sure about the new autotools, but usually --enable-static
27 2013-10-15 01:18:09 <maaku> in the old v0.8.5 look for the RELEASE=1 make flag
28 2013-10-15 01:18:59 <shamoon> and then i just copy the one bitcoind file over?
29 2013-10-15 01:19:06 <Luke-Jr> FYI: static linking uses more memory and is a bad practice in general
30 2013-10-15 01:19:57 <gmaxwell> yea, static is not a good call for your own usage. We use it to build binaries that will run reliably on radically different systems, but generally you should avoid it.
31 2013-10-15 01:20:31 <maaku> it only adds ~10 mb right?
32 2013-10-15 01:20:49 <maaku> less if you consider that some of these deps aren't present
33 2013-10-15 01:22:11 <shamoon> what's the min HD space i need?
34 2013-10-15 01:23:13 <gmaxwell> maaku: also, on a lot of more recent distributions you can't simply just make static builds because static versions of libraries are not installed by default (or don't even exist, e.g. libz when maintainers got tired of the 1001st rebuild the whole distro security event)
35 2013-10-15 01:24:00 <maaku> shamoon: 15+GB for bitcoin data alone
36 2013-10-15 01:24:08 <shamoon> so 24GB should do it?
37 2013-10-15 01:24:13 <gjs278> lol no
38 2013-10-15 01:24:16 <gjs278> because eventually
39 2013-10-15 01:24:18 <gjs278> 24gb won't be enough
40 2013-10-15 01:24:24 <Luke-Jr> ACTION intentionally sets up his libraries to refuse to make static versions
41 2013-10-15 01:24:28 <maaku> shamoon: you're using a VM right? make it dynamically sizable
42 2013-10-15 01:24:56 <maaku> it will only take up actual disk used
43 2013-10-15 01:24:57 <gjs278> just add more swap and compile it
44 2013-10-15 01:25:02 <shamoon> parallels
45 2013-10-15 01:33:48 <olalonde> i have a question regarding mining. once a miner has begun incrementing the nonce, what is his incentive for including new transactions and resetting the nonce to 0?
46 2013-10-15 01:34:33 <olalonde> also, does the nonce have a maximum size?
47 2013-10-15 01:38:10 <olalonde> i understand there is a transaction fee but at the same time, if you've been trying to solve your block for a while, it kind of sucks starting again
48 2013-10-15 01:38:16 <olalonde> anyone understands what i mean?
49 2013-10-15 01:46:14 <shamoon> SO much faster with more ram!
50 2013-10-15 01:46:33 <shamoon> olalonde: as far as i understand it...
51 2013-10-15 01:46:40 <shamoon> incrementing the nonce
52 2013-10-15 01:46:46 <shamoon> has the same effect as adding a new TX
53 2013-10-15 01:46:55 <shamoon> the new TX with an old nonce might solv the block
54 2013-10-15 01:47:02 <shamoon> so there is no "starting again"
55 2013-10-15 01:47:09 <olalonde> right
56 2013-10-15 01:47:14 <shamoon> db.h:14:20: fatal error: db_cxx.h: No such file or directory
57 2013-10-15 01:47:14 <shamoon> Luke-Jr: almost there,
58 2013-10-15 01:47:30 <olalonde> but _theoritcally_ what if you incremented the nonce to 10^20
59 2013-10-15 01:47:44 <olalonde> aren't you more likely to find a solution sooner?
60 2013-10-15 01:47:55 <shamoon> why?
61 2013-10-15 01:48:10 <olalonde> I guess my question really is⦠what is the maximum nonce that guarantees a solution will be found
62 2013-10-15 01:48:25 <shamoon> there is none
63 2013-10-15 01:48:36 <shamoon> i think if you go through aLL The nonces and STILL no solution, it starts to change some header stuff
64 2013-10-15 01:48:38 <shamoon> i think
65 2013-10-15 01:48:45 <olalonde> i see
66 2013-10-15 01:49:01 <shamoon> olalonde: http://bitcoin.stackexchange.com/questions/12956/what-happens-when-the-nonce-field-overflows
67 2013-10-15 01:49:13 <olalonde> would it be theoretically possible for a block to be "unsolvable" ?
68 2013-10-15 01:49:17 <olalonde> ok thanks, will read that
69 2013-10-15 01:49:57 <shamoon> i guess theoretically, a block could be unsolveable
70 2013-10-15 01:50:00 <shamoon> but a new transaction
71 2013-10-15 01:50:02 <shamoon> will change that
72 2013-10-15 01:50:03 <shamoon> or a new time
73 2013-10-15 01:50:17 <shamoon> and the fact that every miner has a different coinbase transaction
74 2013-10-15 01:50:57 <olalonde> right
75 2013-10-15 01:51:04 <shamoon> so more realistically.. i suppose that it's possible that RIGHT NOW, it's possible for YOU to have an unsolveable block
76 2013-10-15 01:51:09 <shamoon> but changing the time changes that
77 2013-10-15 01:51:28 <shamoon> maaku: make -f makefile.unix
78 2013-10-15 01:51:32 <shamoon> how can i static link that?
79 2013-10-15 01:51:34 <shamoon> as you were saying?
80 2013-10-15 01:51:35 <olalonde> makes some sense :)
81 2013-10-15 01:53:20 <olalonde> so to answer my question, since it is possible that you have an unsolveable block, it doesn't really change anything to your likelihood of solving the block to add a new transaction
82 2013-10-15 01:53:28 <shamoon> correct
83 2013-10-15 01:55:12 <shamoon> where in the code does it start the peer discovery process?
84 2013-10-15 02:00:32 <olalonde> found good explanation here http://bitcoin.stackexchange.com/questions/9933/is-it-possible-for-the-network-to-stop-finding-valid-blocks
85 2013-10-15 02:03:31 <olalonde> probably somewhere in main.cpp haha
86 2013-10-15 02:04:25 <shamoon> lol
87 2013-10-15 02:04:35 <shamoon> i'm looking
88 2013-10-15 02:06:48 <shamoon> nothing
89 2013-10-15 02:07:08 <shamoon> from what i understand, there are some default IP's or nodes hardcoded
90 2013-10-15 02:07:09 <shamoon> somewhere
91 2013-10-15 02:07:14 <shamoon> got it
92 2013-10-15 02:08:58 <shamoon> all the printf's - does that go to a log file somewhere?
93 2013-10-15 02:12:21 <olalonde> most of the code seems to be in net.cpp
94 2013-10-15 02:15:30 <olalonde> this might help https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery
95 2013-10-15 02:35:39 <jgarzik> sipa, gmaxwell gavinandresen wumpus: ACK troll https://github.com/bitcoin/bitcoin/pull/2844 - Add unauthenticated HTTP REST interface
96 2013-10-15 04:45:14 <Luke-Jr> fwiw, apparently some n00bs look to donate to bfgminer with google, and come up on blockchain.info pages showing me sending funds to others, and then assume the recipient is my donation address :/
97 2013-10-15 04:45:29 <Luke-Jr> that is, someone just donated to me using the address I sent some of my previous donations to :|
98 2013-10-15 04:47:46 <MC1984> dont complain about free money
99 2013-10-15 04:48:18 <gmaxwell> MC1984: read that again.
100 2013-10-15 04:49:24 <MC1984> how do you know sometimes tried to shoot you money and missed then
101 2013-10-15 04:49:27 <MC1984> if you didnt get it
102 2013-10-15 04:49:28 <gmaxwell> Luke-Jr: I see how: bc.i actually hides the "bfgminer donation" address and replaces it with that text.
103 2013-10-15 04:57:34 <Luke-Jr> MC1984: in this particular case, the recipient was my Coinbase account
104 2013-10-15 04:57:43 <Luke-Jr> I asked how he managed to find that address
105 2013-10-15 06:17:19 <sipa> gavinandresen: any problem with the merge script?
106 2013-10-15 06:17:50 <gavinandresen> sipa: I had to tweak it a bit to work on OSX⦠mktemp difference
107 2013-10-15 06:19:58 <sipa> oh blast
108 2013-10-15 06:20:39 <gavinandresen> sipa: TMPDIR="$(mktemp -d -t GHM)"
109 2013-10-15 06:21:20 <gavinandresen> sipa: I also tweaked the git diff (personal preference): git diff -b --patience pull/"$PULL"/base..pull/"$PULL"/merge
110 2013-10-15 06:22:28 <gmaxwell> gavinandresen: git config --global diff.algorithm patience
111 2013-10-15 06:22:34 <gavinandresen> sipa: ⦠and I'm contemplating the "sign merges" functionality. I don't like to decrypt my protects-the-world gpg key very often.
112 2013-10-15 06:22:40 <gavinandresen> gmaxwell: cool, thanks.
113 2013-10-15 06:22:48 <gmaxwell> gavinandresen: make another subkey for that.
114 2013-10-15 06:23:29 <gmaxwell> you can have any number of subkeys under your main key, and it's possible to e.g. have just one of the subkeys online. and revoke it if it gets compromised or whatever.
115 2013-10-15 06:23:34 <gavinandresen> gmaxwell: yeah, but another subkey means publishing that somewhere and dealing with questions of "Is this the right key? Not the one you used to sign blah blah blah"
116 2013-10-15 06:24:01 <gmaxwell> gavinandresen: If its an actual subkey it's authenticated by your normal primary key.
117 2013-10-15 06:24:26 <gavinandresen> gmaxwell: okey dokey. That means I need to learn about pgp subkeys, and my brain is full.....
118 2013-10-15 06:24:36 <gmaxwell> I know the feeling, I do not blame you.
119 2013-10-15 06:24:48 <sipa> well, that was sort of the reason for writing the script
120 2013-10-15 06:24:59 <gmaxwell> other approach is to use another key, ignore the complaints... still better than no signature at all.
121 2013-10-15 06:25:09 <sipa> right now github could do all sorts of strange things with our repository :)
122 2013-10-15 06:25:17 <gmaxwell> Other people aren't likely to complain. (I guess it would be good news if they were!)
123 2013-10-15 06:25:51 <sipa> though i like not needing to rely on webinterfaces too
124 2013-10-15 06:26:26 <gavinandresen> sipa: in any case, my first experiment with the signing feature seemed to pick my oldest, 1024-bit key to sign with. I didn't look at how it decides which key to use.
125 2013-10-15 06:27:08 <sipa> ah, you need to use --gpg-sign=key to change it
126 2013-10-15 06:27:25 <sipa> didn't have that problem here, as all old keys i have are revoked
127 2013-10-15 06:27:29 <sipa> btw:
128 2013-10-15 06:27:31 <sipa> pw@vps7135:~$ mktemp -d -t GHM
129 2013-10-15 06:27:34 <sipa> mktemp: too few X's in template `GHM'
130 2013-10-15 06:28:02 <warren> gavinandresen: .gnupg/gpg.conf add "default-key YOURKEYID"
131 2013-10-15 06:28:08 <gavinandresen> on osx: -t prefix Generate a template (using the supplied prefix and TMPDIR if set) to create a filename template.
132 2013-10-15 06:29:08 <gavinandresen> warren: I've already got a default-key set, and it works for other gpg operations.
133 2013-10-15 06:29:08 <gmaxwell> [if you revoke your old key, it won't use it anymore (and anyone who gets the revoked key won't use it anymore either). Or you can set some gpg config option default-key I think. :P]
134 2013-10-15 06:29:13 <warren> hm
135 2013-10-15 06:29:46 <warren> cert-digest-algo SHA256
136 2013-10-15 06:29:46 <warren> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
137 2013-10-15 06:29:46 <warren> other good things for gpg.conf:
138 2013-10-15 06:29:46 <warren> personal-digest-preferences SHA256
139 2013-10-15 06:29:53 <warren> unless you enjoy SHA1
140 2013-10-15 06:30:43 <gavinandresen> messing around with gpg options is so far down on my todo list, it won't ever get done.
141 2013-10-15 06:31:09 <sipa> gavinandresen: not sure how git invokes gpg, but it may pass the commiter email to gpg, overriding the default
142 2013-10-15 06:31:27 <sipa> i'll make some modifications
143 2013-10-15 08:22:21 <thermoman> sipa: will investigate if this occures again
144 2013-10-15 09:36:56 <wumpus> https://github.com/bitcoin/bitcoin/issues/3090 CodeBug : should compare return value from memcmp with zero.
145 2013-10-15 09:37:03 <wumpus> that looks like quite a sneaky bug
146 2013-10-15 09:37:32 <wumpus> I would like to check if we're using that function anywhere, but just a grep won't do :P
147 2013-10-15 09:37:57 <sipa> wumpus: oh wow
148 2013-10-15 09:38:18 <wumpus> let's comment it out and try to compile.. yep, first usage candidate on key.h line 292
149 2013-10-15 09:38:21 <sipa> wumpus: i saw the bug and thought he was referring to the fact that we shouldn't use the implicit comparis
150 2013-10-15 09:39:31 <sipa> wumpus: is that all?
151 2013-10-15 09:39:39 <sipa> because CExtKey isn't used yet
152 2013-10-15 09:40:13 <wumpus> will know that in a moment, commenting out that one too
153 2013-10-15 09:40:47 <sipa> i may have added that in the pre-bip32 pullreq
154 2013-10-15 09:41:07 <wumpus> everything seems to compile fine now
155 2013-10-15 09:41:42 <wumpus> so the functions are unused, at least by the core code
156 2013-10-15 09:42:05 <sipa> and by tests?
157 2013-10-15 09:43:37 <wumpus> not by qt or the tests either
158 2013-10-15 09:45:29 <wumpus> hmm ouch, though compiling is not enough I suppose, it will use the default == operator if none is defined :-/
159 2013-10-15 09:45:46 <wumpus> should make it private
160 2013-10-15 09:45:47 <sipa> mark it privare
161 2013-10-15 09:45:52 <sipa> !hi5 wumpus
162 2013-10-15 09:45:53 <gribble> Error: "hi5" is not a valid command.
163 2013-10-15 09:46:13 <michagogo> cloud|I'm pretty sure git commit's -S flag takes an argument for "which key?"
164 2013-10-15 09:46:18 <warren> hmm, github can be configured to broadcast new pull request updates in IRC
165 2013-10-15 09:46:21 <warren> would that be too annoying?
166 2013-10-15 09:46:52 <sipa> i believe it did at some point
167 2013-10-15 09:46:59 <sipa> and was moved to #bitcoin-commits or something
168 2013-10-15 09:47:05 <warren> ooh
169 2013-10-15 09:47:08 <michagogo> cloud|(Re: 3 hours ago)
170 2013-10-15 09:47:14 <sipa> because people couldn't agree on which projects were interesting enough to be irc-logged
171 2013-10-15 09:47:28 <sipa> so all were added, and that became too spammy :)
172 2013-10-15 09:47:54 <warren> perfect is enemy of good, and so bad.
173 2013-10-15 09:47:59 <warren> and so is bad.
174 2013-10-15 09:48:22 <warren> err, certainly 'master' is interesting enough?
175 2013-10-15 09:48:38 <wumpus> yes, I think so
176 2013-10-15 09:48:48 <sipa> yes but the channel shouldn't be about just the reference client, blah blah
177 2013-10-15 09:49:00 <sipa> (was the reasoning)
178 2013-10-15 09:49:02 <warren> call it like it is
179 2013-10-15 09:49:30 <michagogo> cloud|sipa: well, from the perspective of freenode, it is
180 2013-10-15 09:50:29 <sipa> anyway, no objection from me, but i'm certainly biased
181 2013-10-15 09:50:34 <wumpus> #bitcoin-commits does show the commits now? (just joined it) or has it been abandoned too?
182 2013-10-15 09:51:35 <wumpus> ok, everything still compiles with the functions made private
183 2013-10-15 09:51:37 <sipa> it was long ago, i'm sure things broke :)
184 2013-10-15 09:51:42 <warren> see #litecoin-dev for an example
185 2013-10-15 09:56:03 <wumpus> I'd still prefer it here and not in a seperate channel, but I can see how it would make some people complain that their project should be included too, and that would indeed get too spammy
186 2013-10-15 09:58:09 <warren> master commits are kind of rare
187 2013-10-15 10:00:47 <michagogo> cloud|They tend to happen I. Concentrated batches, too
188 2013-10-15 10:00:53 <michagogo> cloud|in c*
189 2013-10-15 10:22:14 <wumpus> warren: agreed, the problem is getting people to agree to only show bitcoin/bitcoin master commits, and not the zillion other clients and frontends
190 2013-10-15 10:23:44 <warren> wumpus: some of those other illion others have hteir own channel
191 2013-10-15 10:23:54 <wumpus> yes :)
192 2013-10-15 10:23:58 <wumpus> maybe it's not an issue anymore
193 2013-10-15 10:55:09 <Goonie> Can anyone tell me how to build bitcoin-qt from master on Ubuntu? "make" has stopped working for me. readme-qt.md is missing actual build instructions (despite the section name).
194 2013-10-15 10:58:01 <sipa> Goonie: ./autogen.sh && configure && make
195 2013-10-15 10:58:20 <Goonie> sipa: thanks. I think this should be documented somewhere.
196 2013-10-15 10:58:27 <sipa> Goonie: it definitely should
197 2013-10-15 10:58:52 <sipa> (and i'm sure it will before release)
198 2013-10-15 10:59:14 <Goonie> ./autogen.sh: line 1: autoreconf: command not found
199 2013-10-15 10:59:25 <Goonie> looks like the dependencies also needs some overhaul
200 2013-10-15 10:59:26 <sipa> you'll need to install autotools
201 2013-10-15 10:59:39 <sipa> yeah, the documentation isn't updated for the autotools changeover
202 2013-10-15 11:01:45 <Goonie> the package to install for ubuntu is called "autoconf"
203 2013-10-15 11:02:53 <Goonie> hmmm which package contains "configure"?
204 2013-10-15 11:03:47 <wumpus> Goonie: autogen.sh creates it
205 2013-10-15 11:04:33 <Goonie> thanks. so in sipas command line it needs to say ./configure
206 2013-10-15 11:04:37 <wumpus> yes
207 2013-10-15 11:06:03 <wumpus> this is the standard way of building 90% of open source software, so it's worth to remember it by heart
208 2013-10-15 11:08:11 <wumpus> readme-qt.md should probably go
209 2013-10-15 11:08:36 <wumpus> the required packages can be integrated into the normal build instructions, and for the rest there's nothing different anymore for building the gui
210 2013-10-15 11:09:06 <Goonie> well I build 99% of open source software with maven (-:
211 2013-10-15 11:10:13 <Goonie> bitcoin is the second project I build using make. the first one was lpmud, back in the 80's.
212 2013-10-15 11:12:01 <Goonie> anyway, I'd be happy to proofread and test new build instructions, if there are any.
213 2013-10-15 11:29:13 <wumpus> maven? I don't think I've ever seen that used
214 2013-10-15 11:40:13 <TD> wumpus: it's java vs the c/c++ world
215 2013-10-15 11:40:20 <TD> Goonie: autotools is the standard for native UNIX software
216 2013-10-15 11:40:30 <TD> Goonie: basically it's always ./configure && make && sudo make install
217 2013-10-15 11:40:43 <TD> Goonie: where configure has flags that can be used to control how the software is compiled/toggle features on or off
218 2013-10-15 11:40:57 <wumpus> TD: back in the day I used java it was mostly 'ant', AFAIK
219 2013-10-15 11:41:07 <TD> Goonie: if configure doesn't exist then it's generated by the autogen.sh script, which in turn needs autotools to be installed.
220 2013-10-15 11:41:39 <TD> wumpus: yeah, back in my day it was too. the first version of bitcoinj used ant. there are actually a bunch of different build systems in use in the java world, fortunately they all share the same dependency repository format
221 2013-10-15 11:42:11 <wumpus> yes, good to have some consistency
222 2013-10-15 11:42:55 <michagogo> cloud|Hmm, why does autotools use a .sh like that?
223 2013-10-15 11:43:22 <michagogo> cloud|Why not a .at or something like that, which doesn't look like something you can run on its own?
224 2013-10-15 11:43:41 <wumpus> which sh? you mean the configure script?
225 2013-10-15 11:44:09 <wumpus> it generates a shell file for portibility to systems that don't have autotools package installed but do have a shell and a c compiler
226 2013-10-15 11:44:54 <wumpus> (if you package the configure script in your tarball...)
227 2013-10-15 11:44:58 <michagogo> cloud| Goonie: if configure doesn't exist then it's generated by the autogen.sh script, which in turn needs autotools to be installed.
228 2013-10-15 11:45:06 <michagogo> cloud|(quote)
229 2013-10-15 11:45:11 <TD> autogen.sh is a script
230 2013-10-15 11:45:13 <TD> so is configure
231 2013-10-15 11:45:18 <michagogo> cloud|right...
232 2013-10-15 11:45:28 <michagogo> cloud|nvm
233 2013-10-15 11:46:09 <michagogo> cloud|Oh, I see -- autogen.sh is one line
234 2013-10-15 11:46:24 <michagogo> cloud|(erm, why bother putting it in a shell script, then?)
235 2013-10-15 11:47:29 <wumpus> why not? it makes things slightly easier for developers
236 2013-10-15 11:48:32 <sipa> it's not just one line for every project
237 2013-10-15 11:48:47 <wumpus> the exact contents of autogen.sh differ from project to project, but if there is a autogen.sh you know you can run it to generate the configure script
238 2013-10-15 11:50:04 <wumpus> there used to be a time that projects usually didn't package an autogen.sh, so you'd need some time to figure out the right flags and automake/conf commands to generate it
239 2013-10-15 11:57:30 <sipa> wumpus: afaict, autogen.sh's output is supposed to be packaged
240 2013-10-15 11:57:47 <sipa> so you don't run it in case you're using released source
241 2013-10-15 11:57:52 <wumpus> sipa: sorry, I mean 'checked in'
242 2013-10-15 11:57:59 <sipa> ah, right
243 2013-10-15 11:58:09 <wumpus> for packaged source the configure script and other generated stuff should be included
244 2013-10-15 11:58:15 <sipa> right
245 2013-10-15 12:10:36 <olalonde> the solution to a block is finding a hash that begins with X numbers of 0 right?
246 2013-10-15 12:11:08 <olalonde> I'm trying to understand how difficulty plays a role in the solution to a block
247 2013-10-15 12:13:00 <michagogo> cloud|olalonde: The difficulty defines how low the hash needs to be
248 2013-10-15 12:14:10 <michagogo> cloud|That is, how many zero bits are required at the start
249 2013-10-15 12:14:40 <olalonde> right now the difficulty is 189,281,249⦠does that mean the solution requires 189,281,249 zero bits at the start?
250 2013-10-15 12:14:53 <olalonde> i guess not lol
251 2013-10-15 12:15:25 <kinlo> the difficulty doesn't define how many zeroes at the start - it defines how low the value must be
252 2013-10-15 12:16:07 <kinlo> a low value implies a certain number of zeroes at start, so the confusion is quickly made
253 2013-10-15 12:17:18 <olalonde> ok so a valid solution requires X zeros and needs to be smaller then difficulty??
254 2013-10-15 12:17:58 <kinlo> just requires to be smaller then the difficulty
255 2013-10-15 12:18:13 <CodeShark> the number of leading zeros is a result of it being smaller than the target
256 2013-10-15 12:18:49 <CodeShark> all bitcoin cares about is whether hash < target
257 2013-10-15 12:18:57 <olalonde> ah
258 2013-10-15 12:19:23 <olalonde> got it (i think)
259 2013-10-15 12:19:42 <olalonde> so there could be 2 hashes with the same amount of leading zeroes but only one of them is valid?
260 2013-10-15 12:21:56 <CodeShark> to use small numbers in decimal (the base is irrelevant), consider 0015 to be the target
261 2013-10-15 12:22:08 <CodeShark> then 0000 - 0014 are valid
262 2013-10-15 12:22:14 <CodeShark> 0015 - 9999 are invalifd
263 2013-10-15 12:23:17 <CodeShark> in the case of bitcoin, the leading zeros are due to sha256 having a 256 bit output
264 2013-10-15 12:23:34 <CodeShark> but the numbers are compared as integers
265 2013-10-15 12:23:43 <CodeShark> with leading zeros ignored
266 2013-10-15 12:23:50 <olalonde> so if target is 0010, 0011 would be invalid right
267 2013-10-15 12:23:55 <CodeShark> right
268 2013-10-15 12:24:10 <olalonde> but how come is the difficulty increasing?
269 2013-10-15 12:24:17 <olalonde> doesn't it make it easier to find valid hashes?
270 2013-10-15 12:24:32 <CodeShark> higher difficulty means smaller target
271 2013-10-15 12:25:07 <CodeShark> they are in a reciprocal relationship
272 2013-10-15 12:25:08 <olalonde> what is the formula? target = 1/difficulty ?
273 2013-10-15 12:25:18 <CodeShark> roughly, yes
274 2013-10-15 12:25:26 <CodeShark> up to some constants
275 2013-10-15 12:25:53 <olalonde> ok
276 2013-10-15 12:26:01 <tcatm> Actually, difficulty is derived from the target...
277 2013-10-15 12:26:36 <CodeShark> difficulty is a normalized measure to make comparisons sensible to us
278 2013-10-15 12:26:44 <CodeShark> but bitcoin really cares about target and work
279 2013-10-15 12:26:48 <olalonde> isn't difficulty based on how many hashes found in past 2 weeks?
280 2013-10-15 12:27:12 <olalonde> ok
281 2013-10-15 12:32:04 <tcatm> difficulty is based on the current target. the target is adjusted every 2016 blocks.
282 2013-10-15 12:32:45 <CodeShark> which parameter is the one that's adjusted is mathematically arbitrary
283 2013-10-15 12:32:52 <CodeShark> it depends on which way you write the equations
284 2013-10-15 12:33:06 <CodeShark> you could just as easily define the rule either way
285 2013-10-15 12:33:35 <CodeShark> point is *target* is what is used by bitcoin to validate a block - and *work* is what is used to select the best chain
286 2013-10-15 12:34:00 <CodeShark> and difficulty is normalized work
287 2013-10-15 12:34:35 <olalonde> ok
288 2013-10-15 12:36:08 <CodeShark> work is directly additive
289 2013-10-15 12:36:20 <CodeShark> so you just compute the cumulative work for the chain
290 2013-10-15 12:36:23 <olalonde> whats the exact formula to derive target from difficulty?
291 2013-10-15 12:36:48 <olalonde> I'm not sure what you mean by "work". never really heard that term in that context before
292 2013-10-15 12:37:11 <CodeShark> difficulty = maximum target / actual target
293 2013-10-15 12:37:29 <CodeShark> maximum target = 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
294 2013-10-15 12:37:40 <olalonde> thanks
295 2013-10-15 12:37:53 <tcatm> maximum target = 0x00000000FFFF0000000000000000000000000000000000000000000000000000
296 2013-10-15 12:38:01 <CodeShark> oh, right
297 2013-10-15 12:38:02 <CodeShark> :p
298 2013-10-15 12:38:06 <tcatm> it's stored in packed format
299 2013-10-15 12:38:40 <wumpus> Goonie: https://github.com/bitcoin/bitcoin/pull/3092/files
300 2013-10-15 12:41:17 <CodeShark> work = 2^256 / (target + 1)
301 2013-10-15 12:41:45 <CodeShark> integer division
302 2013-10-15 12:42:09 <CodeShark> this is what bitcoin actually uses to compare different chains. difficulty is an approximate value that gets truncated
303 2013-10-15 12:42:52 <CodeShark> difficulty is only intended for human consumption - it plays no direct role in the bitcoin validation algorithms
304 2013-10-15 12:44:28 <CodeShark> in fact, the choice of 1 as the mimumum difficulty is purely arbitrary
305 2013-10-15 12:51:39 <Goonie> wumpus: thanks, I have a look at it now
306 2013-10-15 12:51:53 <CodeShark> Wt = total work, Ti = target of block with height i (T0 is the target of the genesis block). then Wt ~ 2^256 [1/(t0 + 1) + 1/(t1 + 1) + 1/(t2 + 1) + ⦠+ 1/(tn + 1)]
307 2013-10-15 12:52:55 <CodeShark> but in order to avoid floating point arithmetic and rounding issues, we say Wt = 2^256\(t0+1) + 2^256\(t1+1) + ...
308 2013-10-15 14:08:47 <Goonie> CXXLD bitcoind
309 2013-10-15 14:08:47 <Goonie> Hmmm, get this error when compiling bitcoin from master:
310 2013-10-15 14:08:48 <Goonie> leveldb/libleveldb.a: could not read symbols: Bad value
311 2013-10-15 14:09:28 <Goonie> irc is crap
312 2013-10-15 14:09:40 <wumpus> Goonie: remove that file and restart the build
313 2013-10-15 14:09:44 <Goonie> does not want to let me paste the most important line
314 2013-10-15 14:10:33 <wumpus> it's a known issue when doing a automake build for the first time and the source directory is not cleaned after the last make build
315 2013-10-15 14:12:35 <sipa> may also make sense to mention in documentation :)
316 2013-10-15 14:12:49 <Belxjander> are any bitcoin source projects that compile available with a straight makefile only build or directly available without autotools/cmake ?
317 2013-10-15 14:13:21 <sipa> you could generate the makefile and package that :)
318 2013-10-15 14:14:17 <Belxjander> sipa: to me "autotools" and "cmake" pre-suppose access to a Linux system or CygWin32 overlay for Windows...
319 2013-10-15 14:14:27 <wumpus> Belxjander: eh yes, current releases of bitcoin stil use a makefile-only build
320 2013-10-15 14:14:29 <Belxjander> I am not using a Linux/Windows/Mac OS choice...
321 2013-10-15 14:14:40 <sipa> what are you using?
322 2013-10-15 14:14:43 <wumpus> the autoconf stuff is only in master
323 2013-10-15 14:14:53 <Belxjander> wumpus: bitcoin-qt is something I already grabbed and it refuses to build and link at the moment
324 2013-10-15 14:15:08 <Belxjander> wumpus: I've just tried to "build" picocoin as well
325 2013-10-15 14:15:21 <sipa> what platform are you on?
326 2013-10-15 14:15:37 <Belxjander> sipa: AmigaOS
327 2013-10-15 14:15:39 <wumpus> depending on the platform, the build system may be least of your worries
328 2013-10-15 14:15:55 <Belxjander> I have GCC and Make along with a couple of other basic tools but autotools and cmake are not present at all
329 2013-10-15 14:16:06 <wumpus> for example on big-endian architectures the bitcoin client doesn't work at all at the moment
330 2013-10-15 14:16:36 <Belxjander> how about a Chip that defaults BigEndian but allows for Big+Little Endian operations mixed?
331 2013-10-15 14:16:56 <Belxjander> I can hard-read LE format into BE format for 16bit and 32bit memory reads
332 2013-10-15 14:17:05 <wumpus> not supported
333 2013-10-15 14:17:09 <Belxjander> thats an ISA feature
334 2013-10-15 14:18:57 <Belxjander> right... so I will need to walk through step by step and impliment a packet handler that is LE "on the wire" but allows for BE in-memory?
335 2013-10-15 14:19:14 <sipa> much more than that
336 2013-10-15 14:19:33 <Belxjander> sipa: yeah I get that part...
337 2013-10-15 14:19:39 <sipa> it's probably not actually hard to make the source BE-compatible
338 2013-10-15 14:19:48 <sipa> and i'm sure patchrs would be welcome
339 2013-10-15 14:20:00 <sipa> but finding all places where it is necessary may be tricky
340 2013-10-15 14:20:07 <sipa> i know luke tried at some point
341 2013-10-15 14:20:09 <Belxjander> Well before I patch anything I have to get it compiling and functionaly usable no?
342 2013-10-15 14:20:30 <sipa> it won't be usable before you fix BE issues
343 2013-10-15 14:20:44 <sipa> and as said, you can generate the makedile elsewhere
344 2013-10-15 14:21:00 <sipa> though you may need to fix library locations e.a. manually
345 2013-10-15 14:21:35 <Belxjander> right... so generate a makefile on a Linux box and watch it go comepletely awol nuts when transferred to an AmigaOS system because tis non-posix as a starting point...
346 2013-10-15 14:21:39 <Belxjander> right
347 2013-10-15 14:21:52 <sipa> yup
348 2013-10-15 14:21:56 <Belxjander> libraries are not fixed-path based on AmigaOS
349 2013-10-15 14:22:17 <sipa> well, that's what you choose when using an obscure OS :)
350 2013-10-15 14:23:10 <Belxjander> and here I just wanted to be able to get an idea of what the essential basics are and work "up the stack"
351 2013-10-15 14:27:29 <sipa> well, if you're just interested in getting to the point where you can compile things
352 2013-10-15 14:27:44 <sipa> it shouldn't be too hard to construct a single-line gcc command
353 2013-10-15 14:28:38 <sipa> g++ -o bitcoind -O2 main.cpp netbase.cpp util.cpp hash.cpp .... -lboost-something -lcrypto -l...
354 2013-10-15 14:29:17 <Belxjander> sipa: assuming that everything is "just there"?
355 2013-10-15 14:29:28 <sipa> well you need all dependencies of course
356 2013-10-15 14:29:47 <sipa> bdb, boost, c++ stl, openssl
357 2013-10-15 14:32:00 <Belxjander> so no chance in hell of finding a C only version of sources that work as a client?
358 2013-10-15 14:32:13 <sipa> C only client? i doubt that
359 2013-10-15 14:32:18 <Belxjander> it is pretty much C++ or Java and a headache of hidden code?
360 2013-10-15 14:32:21 <sipa> someone started on that, but never got far afaik
361 2013-10-15 14:35:24 <michagogo> cloud|What does boost actually do?
362 2013-10-15 14:36:16 <Ry4an> makes C++ a language worth coding in... ;)
363 2013-10-15 14:36:34 <michagogo> cloud|Ry4an: hmm?
364 2013-10-15 14:37:55 <Ry4an> https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries)
365 2013-10-15 14:45:14 <wumpus> it provides many useful algorithms, datastructures and platform-independent support functions, like a standard library on steroids
366 2013-10-15 14:47:14 <HM2> splendid
367 2013-10-15 14:47:24 <Belxjander> well I need to sort out gettnig boost on AmigaOS then
368 2013-10-15 14:47:29 <Belxjander> since it is not present that I know about
369 2013-10-15 14:47:32 <HM2> I've been unlazy enough to recover my nick after about 15 weeks
370 2013-10-15 14:48:14 <wumpus> if boost has been ported to amigaos at all
371 2013-10-15 14:48:24 <t7> soon most of boost will be standard and we can bin it :3
372 2013-10-15 14:48:32 <HM2> doubtful
373 2013-10-15 14:48:45 <wumpus> maybe by 2050, at least in MSVC :)
374 2013-10-15 14:49:09 <HM2> besides, standard implementations aren't always up to snuff and the standardisation process is always a compromise
375 2013-10-15 14:49:10 <wumpus> c++50
376 2013-10-15 14:49:32 <HM2> for instance, std::async uses a thread pool on MS C++ but GNU is unbound
377 2013-10-15 14:50:43 <wumpus> and I doubt more specific libraries such as boost::spirit (parsing) will ever be part of the standard library
378 2013-10-15 14:52:20 <t7> wumpus is it good or template hell?
379 2013-10-15 14:52:35 <wumpus> it's good and template hell
380 2013-10-15 14:53:13 <wumpus> bitcoin uses it for json parsing
381 2013-10-15 14:53:46 <Belxjander> and multi-threading
382 2013-10-15 14:54:13 <Belxjander> or was I misreading how it tried to build with the multi-threaded boost libraries?
383 2013-10-15 14:54:43 <wumpus> I was talking about spirit specifically, but sure, we use boost for many things like network and threading as well
384 2013-10-15 14:56:11 <t7> why write a json parser, rather than use an existing one?
385 2013-10-15 14:56:22 <t7> like the reference cpp one?
386 2013-10-15 14:57:20 <HM2> it is an existing one, json Spirit
387 2013-10-15 14:57:33 <HM2> http://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-JSON-Parser-Generator-Implemented
388 2013-10-15 14:59:15 <t7> aha
389 2013-10-15 15:04:03 <HM2> I'm counting 61 distinct boost headers used in Bitcoin git HEAD
390 2013-10-15 15:04:34 <HM2> my sed skills may be sloppy though
391 2013-10-15 15:05:23 <HM2> http://pastebin.com/YAHcDKAQ
392 2013-10-15 15:05:50 <HM2> pretty mundane stuff
393 2013-10-15 15:08:20 <HM2> JSON Spirit actually uses the classic 'Spirit' api
394 2013-10-15 15:08:56 <HM2> Hopefully Spirit X3 will make it out of the sandbox sometime soon
395 2013-10-15 15:09:16 <HM2> it makes writing parsers much more pleasant
396 2013-10-15 15:13:07 <wumpus> HM2: not sure why json spirit was chosen, probably a mysterious satoshi decision :)
397 2013-10-15 15:13:42 <sipa> did satoshi even write the rpc stuff?
398 2013-10-15 15:14:39 <sipa> apparently yes
399 2013-10-15 15:15:09 <sipa> btw, json-spirit becomes a lot more usable if you use mvalue rathen than value
400 2013-10-15 15:15:33 <sipa> which uses std::map for objects rather than std::vector<std::pair<...> >
401 2013-10-15 15:18:51 <HM2> sipa, i think the idea behind vector<pair> is you can dump it in to any associative container that you like
402 2013-10-15 15:19:02 <HM2> or at least anyone that supports std::pair insertions, which is wise
403 2013-10-15 15:19:16 <sipa> HM2: json-spirit supports any container you like
404 2013-10-15 15:19:18 <sipa> for anything
405 2013-10-15 15:19:24 <HM2> it does?
406 2013-10-15 15:19:39 <sipa> there are just 2 predefined configurations, one that uses vectors for objects, and one that uses maps
407 2013-10-15 15:19:52 <sipa> the former has the advantage that it preserves order
408 2013-10-15 15:19:55 <wumpus> std<vector> is ordered
409 2013-10-15 15:19:56 <wumpus> right
410 2013-10-15 15:20:03 <sipa> the latter has to advantage that it is key-addressable
411 2013-10-15 15:20:33 <HM2> right
412 2013-10-15 15:20:39 <sipa> but you can write your own configuration class, and modify the datatype for strings, for arrays and for objects
413 2013-10-15 15:20:57 <sipa> there are also predefined configurations for using wstring instead of string
414 2013-10-15 15:21:19 <sipa> i guess the idea is that you can map directory into your application data classes
415 2013-10-15 15:21:27 <sipa> instead of converting all the time
416 2013-10-15 15:22:16 <HM2> indeed
417 2013-10-15 15:22:34 <HM2> I've been meaning to investigate using Boost Fusion to make JSON serialisation easier
418 2013-10-15 15:22:38 <wumpus> that's the big advantage of template metaprogramming
419 2013-10-15 15:23:12 <HM2> Fusions adapted structs make iterating over structs and serialising them nice and lazy
420 2013-10-15 15:23:23 <sipa> the disadvantage is huge compiler memory requirements, and unreadable compiler messages
421 2013-10-15 15:24:05 <HM2> as far as I got though is writing some type inferring wrappers around Json spirit like load_value(T&, Object, key) where the type of T automatically does the right thing
422 2013-10-15 15:24:10 <sipa> though c++14 should improve upon that considerably
423 2013-10-15 15:25:23 <wumpus> c++14, heh, I haven't even grown accustomed to c++11 yet
424 2013-10-15 15:25:46 <HM2> Bitcoin doesn't yet depend on c++11 does it?
425 2013-10-15 15:25:49 <sipa> nope
426 2013-10-15 15:25:53 <sipa> i want c++11 though :(
427 2013-10-15 15:26:11 <wumpus> no, it doesn't, but it may in the near future as gitian environments are being updated
428 2013-10-15 15:26:15 <HM2> I write exclusively in C++11 now
429 2013-10-15 15:26:51 <HM2> At one point i was trying to ifdef in backward support for '98
430 2013-10-15 15:26:52 <sipa> no need for hacks with swap or passing mutable references to return some complex datastructure efficiently
431 2013-10-15 15:26:56 <HM2> that is a nightmare and not worth doing
432 2013-10-15 15:28:10 <Goonie> Hmm bitcoin-qt still has this bug that the menu is sometimes not appearing.
433 2013-10-15 15:28:26 <wumpus> Goonie: that's an ubuntu bug, not a bitcoin-qt one
434 2013-10-15 15:28:43 <Goonie> wumpus: But I never saw it with any other app.
435 2013-10-15 15:29:00 <Goonie> wumpus: Is there a ticket on launchpad?
436 2013-10-15 15:29:03 <wumpus> I've never seen it with bitcoin-qt either
437 2013-10-15 15:29:59 <wumpus> it's rumored to happen on slower systems, but I don't think anyone ever reproduced it reliably
438 2013-10-15 15:30:09 <wumpus> which ubuntu are you using?
439 2013-10-15 15:30:35 <wumpus> and how are you launching it?
440 2013-10-15 15:30:50 <wumpus> from a terminal or directly through the menu?
441 2013-10-15 15:31:09 <Goonie> started from the terminal, 0.8.5 beta (current master), ubuntu 13.04
442 2013-10-15 15:31:33 <Goonie> but I had it with all previous ubuntu and bitcoin-qt versions
443 2013-10-15 15:31:39 <wumpus> you haven't messed with the dbus environment settings?
444 2013-10-15 15:32:02 <Goonie> no, I'm a "use as many defaults as possible" guy
445 2013-10-15 15:32:37 <wumpus> it's really strange, I've never had it, not with 12.04, not with earlier versions, not with 13.04
446 2013-10-15 15:33:14 <wumpus> but there is some very ugly hack where ubuntu plugs into qt to intercept the menu, and I guess that sometimes fails
447 2013-10-15 15:33:23 <Goonie> how can I go to the network traffic chart? its not in the debug window.
448 2013-10-15 15:33:32 <wumpus> it is in the debug window
449 2013-10-15 15:33:41 <wumpus> third tab IIRC
450 2013-10-15 15:34:34 <Goonie> damn, just noticed that I was running the old version
451 2013-10-15 15:34:50 <Goonie> where does "make" build bitcoin-qt to?
452 2013-10-15 15:34:54 <wumpus> src/qt
453 2013-10-15 15:35:33 <Goonie> I would not expect build targets to be located in src.
454 2013-10-15 15:36:22 <Goonie> I guess this should be documented as well.
455 2013-10-15 15:36:36 <wumpus> I found it surprising too
456 2013-10-15 15:37:33 <wumpus> but it's more consistent than before
457 2013-10-15 15:37:53 <Goonie> I see the network traffic chart now.
458 2013-10-15 15:37:53 <wumpus> before, bitcoind was built in src, and bitcoin-qt in the project root
459 2013-10-15 15:38:02 <Goonie> When I zoom in or out, it clears its data.
460 2013-10-15 15:38:09 <wumpus> yes, it does that
461 2013-10-15 15:38:15 <Goonie> Would expect not to do.
462 2013-10-15 15:38:26 <wumpus> feel free to fix that
463 2013-10-15 15:38:32 <Goonie> ok
464 2013-10-15 15:42:37 <wumpus> seems to be because the sampling rate depends on the scaling
465 2013-10-15 16:24:34 <gmaxwell> https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108
466 2013-10-15 16:28:51 <TD> ye gods
467 2013-10-15 16:28:58 <TD> only took them 6 years
468 2013-10-15 16:29:57 <TD> sipa: you can return complicated data structures efficiently in c++98
469 2013-10-15 16:30:20 <TD> sipa: just return them as normal and let the compiler do the nrv optimisation
470 2013-10-15 16:30:42 <gmaxwell> TD: [random] Any idea why in bitcoinj the varint encode function calls a function called encodeBE?
471 2013-10-15 16:31:10 <TD> sounds like a naming bug
472 2013-10-15 16:31:13 <TD> let me take a look
473 2013-10-15 16:32:25 <TD> i guess the real question is, why are varints even objects at all :)
474 2013-10-15 16:32:55 <TD> anyway, no, i don't know. if i wrote that code, it was years ago. if it was changed by a subsequent patch, which is quite possible, then i don't remember it
475 2013-10-15 16:32:58 <TD> ACTION fixes
476 2013-10-15 16:33:43 <sipa> TD: not across objects, afaik
477 2013-10-15 16:34:30 <TD> how do you mean, across objects?
478 2013-10-15 16:35:22 <TD> gmaxwell: how comes you were looking? some malleability thing?
479 2013-10-15 16:38:39 <gmaxwell> TD: someone was complaining that multibit's signmessage and bitcoinqt's were incompatible. It sounded like it might be a failure to use varint encoding of the length (as other implementations have made that mistake) but if that was the cause I must have been confused by the code, since it appears to be using varint encoding.
480 2013-10-15 16:38:43 <TD> huh
481 2013-10-15 16:38:44 <TD> odd
482 2013-10-15 16:39:00 <gmaxwell> (some things don't varint encode the length and then fail for longer messages)
483 2013-10-15 16:39:02 <TD> i mean, if it's incompatible, it must be some change jim made? there is a unit test that verifies messages signed by bicoin-qt
484 2013-10-15 16:39:16 <TD> maybe something to do with ascii armouring
485 2013-10-15 16:39:25 <TD> there was a bug where it didn't count UTF-8 sizes properly. i fixed that recently.
486 2013-10-15 16:39:34 <TD> but that caused a crash. perhaps it was also possible for it to cause corruption
487 2013-10-15 16:39:53 <gmaxwell> I didn't look at jim's code though, I kinda got lost in a twisty maze of java. Sorry, I was also only looking at this while talking to someone on IRC.
488 2013-10-15 16:40:37 <TD> there was a schoolboy error where it used num of chars rather than num bytes. it's fixed in git master, but multibit hasn't shipped that fix yet
489 2013-10-15 16:40:45 <TD> so i suspect some variant of that issue
490 2013-10-15 16:48:53 <jgarzik> random,
491 2013-10-15 16:49:27 <jgarzik> it is tempting to add a sequence of binary headers, testnet or mainnet, to the git repo, and then code unit tests using that dataset.
492 2013-10-15 16:49:46 <jgarzik> this came in handy with picocoin, and it's just a handful of megabytes.
493 2013-10-15 16:50:43 <Goonie> wumpus: I think "make clean" should explicitely remove the old binary to clear out confusion. What do you think?
494 2013-10-15 16:52:35 <wumpus> Goonie: yes, which works if you run make clean *before* you upgrade to a version that uses autotools :)
495 2013-10-15 16:53:11 <Goonie> wumpus: Not possible to explicitely add a command to the Makefile?
496 2013-10-15 16:53:18 <wumpus> I don't know
497 2013-10-15 16:53:31 <Goonie> I don't know anything about this strange build system, sorry.
498 2013-10-15 16:53:43 <wumpus> in a normal makefile, sure, but with autotools I don't know
499 2013-10-15 16:54:04 <Goonie> ok
500 2013-10-15 16:54:18 <Goonie> is payment requests already merged and testable?
501 2013-10-15 16:54:30 <wumpus> yes
502 2013-10-15 16:55:09 <Goonie> I don't see it in the UI nor the console. Is there some doc about it?
503 2013-10-15 16:57:08 <Goonie> Is it perhaps only in bitcoind?
504 2013-10-15 17:16:47 <michagogo> Goonie: Well, you wouldn't see it in the UI until you clicked on a link
505 2013-10-15 17:18:02 <michagogo> Goonie: see https://bitcoincore.org/~gavin/createpaymentrequest.php
506 2013-10-15 17:19:30 <michagogo> Goonie
507 2013-10-15 17:19:44 <michagogo> Goonie: For example, if you felt like giving me a bitcent, you'd go to bitcoin:14FdeJBWiAjERjtj2oyyguLiDQHxLyut7H?request=https%3A%2F%2Fbitcoincore.org%2F%7Egavin%2Ff.php%3Fh%3Dbe54fa094f22b66f15550057681ac059&amount=0.01
508 2013-10-15 17:20:25 <Goonie> Ah, so I cannot create requests with the UI?
509 2013-10-15 17:20:38 <Goonie> (I would expect that in the receive tab)
510 2013-10-15 17:21:02 <michagogo> No[e
511 2013-10-15 17:21:04 <michagogo> Nope*
512 2013-10-15 17:21:21 <michagogo> At the moment, support in the client is only for receiving and paying requests
513 2013-10-15 17:21:35 <Goonie> How unfortunate.
514 2013-10-15 17:22:23 <Goonie> Can I enter the URL you gave me somewhere into the client? My browser isn't associated with bitcoin-qt, so it just says "The address wasn't understood".
515 2013-10-15 17:37:42 <sipa> TD: across compilation units, i meant
516 2013-10-15 17:38:26 <michagogo> Goonie: I think you can invoke the executable with the URL as an argument
517 2013-10-15 18:59:10 <helo> Goonie: if the client can make payment requests, then it also has to make them available via a web server, which needs a domain, and a ssl cert, etc :/
518 2013-10-15 19:00:32 <helo> wow, that conversation was old -.-
519 2013-10-15 19:01:11 <jouke> helo: or transfer the complete paymentrequest via qr-code
520 2013-10-15 19:04:14 <helo> still needs (well, really should use) a domain and ssl cert
521 2013-10-15 19:05:04 <helo> it could be pretty neat with something like a trezor
522 2013-10-15 19:06:29 <jouke> Why does it still need a domain? it doesn't need to send the tx back
523 2013-10-15 19:07:02 <helo> doesn't it use x.509 to sign the request?
524 2013-10-15 19:07:35 <jouke> Ah right.
525 2013-10-15 19:08:13 <helo> optionally, but going through the trouble to implement it without the security of signed requests seems like a waste of time
526 2013-10-15 19:17:26 <sipa> helo: heh?
527 2013-10-15 19:17:32 <sipa> helo: oh, requests, yes
528 2013-10-15 19:17:57 <jouke> Can't you get a certificate without a domain?
529 2013-10-15 19:18:12 <helo> hmm... yeah i think you can
530 2013-10-15 19:21:23 <michagogo> http://www.instantssl.com/ssl-certificate-products/free-email-certificate.html
531 2013-10-15 20:51:20 <gavinandresen> "patches welcome" for Bitcoin-Qt support to create payment requests. Extra bonus points if you can figure out how to automatically interact with instantssl (or whoever) to generate a certificate for the user automagically.
532 2013-10-15 20:54:59 <Luke-Jr> gavinandresen: does the payment protocol not allow for sending a payment request by email? :/
533 2013-10-15 20:55:08 <Luke-Jr> ie, without an interactive server
534 2013-10-15 20:55:20 <gavinandresen> Luke-Jr: Yes, it does.
535 2013-10-15 20:55:47 <Luke-Jr> not sure how SSL comes into that then?
536 2013-10-15 20:56:55 <gavinandresen> Luke-Jr: unsigned, insecure payment requests are really no better than a plain old bitcoin address, so I don't see the point of them
537 2013-10-15 20:57:41 <Luke-Jr> email would be PGP though
538 2013-10-15 20:57:44 <sipa> i think they are infinitely better
539 2013-10-15 20:57:45 <gavinandresen> Might as well just send a bitcoin: link in your email, rather than an unsigned payment request as attachment
540 2013-10-15 20:58:06 <gavinandresen> sipa: infinitely? Wow! That's a lot!
541 2013-10-15 20:58:13 <sipa> you get negotiation, guarantee that the address is alive, messages, guaranteed receival
542 2013-10-15 20:58:19 <sipa> (is receival a word?)
543 2013-10-15 20:58:26 <gmaxwell> Luke-Jr: Payment request signing is internal to the payment request. (SSL fetching doesn't provide non-repudiation)
544 2013-10-15 20:58:27 <sipa> reception?
545 2013-10-15 20:58:44 <gavinandresen> you don't get negotiation if there is no payment_url set, and Luke said there was no interactive server
546 2013-10-15 20:59:03 <Luke-Jr> gmaxwell: hm
547 2013-10-15 20:59:06 <sipa> well if you pay a payment request that just arrives as a file, the result should be signed file
548 2013-10-15 20:59:09 <gavinandresen> afk for a while, Foundation board meeting this morning....
549 2013-10-15 20:59:30 <sipa> perhaps a file: dummy URL as payment_url
550 2013-10-15 21:01:27 <Luke-Jr> sipa: if that works, I'd say it's a security hole
551 2013-10-15 21:01:39 <sipa> how so?
552 2013-10-15 21:01:41 <Luke-Jr> foreign data shouldn't be able to do anything with file: URIs
553 2013-10-15 21:02:47 <sipa> right, that's why i called it a dummy url
554 2013-10-15 21:02:48 <sipa> if that's NFC, return via NFC
555 2013-10-15 21:02:48 <sipa> imho, the intent should always be to return the payment via the same medium as you received the request
556 2013-10-15 21:02:48 <sipa> the client should probably ask where to save the result or something
557 2013-10-15 21:02:50 <sipa> if that's HTTPS, return via HTTPS
558 2013-10-15 21:02:55 <sipa> if that's a file, return a file
559 2013-10-15 21:03:10 <Luke-Jr> mailto: URI would make sense then?
560 2013-10-15 21:03:19 <sipa> perhaps, yes
561 2013-10-15 21:04:36 <sipa> and only when explicitly requested, broadcast via P2P
562 2013-10-15 21:22:18 <sipa> wow
563 2013-10-15 21:22:32 <sipa> iterating all CBlockIndex entries in memory takes 20ms here
564 2013-10-15 21:23:33 <sipa> terrible memory locality, i guess
565 2013-10-15 21:52:36 <HM2> sipa, it's a big structure
566 2013-10-15 21:54:18 <HM2> sipa, is it basically a linked list?
567 2013-10-15 21:55:46 <HM2> hmmm
568 2013-10-15 21:55:54 <HM2> i don't remember main.h being this tidy
569 2013-10-15 21:56:19 <gribble> 263946
570 2013-10-15 21:56:19 <sipa> ;;blocks
571 2013-10-15 21:56:32 <HM2> oh you refactoring in to CChain
572 2013-10-15 21:56:37 <HM2> refactored
573 2013-10-15 21:56:50 <sipa> it's 170 cpu cycler per CBlockIndex entry
574 2013-10-15 21:56:54 <sipa> *cycles
575 2013-10-15 21:57:40 <HM2> to do what? just follow the pointers?
576 2013-10-15 21:57:52 <sipa> yes
577 2013-10-15 21:58:19 <HM2> hmm
578 2013-10-15 21:58:53 <sipa> actually, every entry is around 128 bytes
579 2013-10-15 21:59:05 <HM2> 2 cache lines then
580 2013-10-15 21:59:14 <sipa> assuming the pointer and the data being read are in different 64-byte segments
581 2013-10-15 21:59:20 <sipa> then you must pretty much read it all
582 2013-10-15 21:59:40 <sipa> ;;calc 128*[blocks]/0.02*8
583 2013-10-15 21:59:41 <gribble> 13514035200
584 2013-10-15 21:59:48 <HM2> intrusive pointer linked list probably isn't the best idea then?
585 2013-10-15 22:00:02 <sipa> that's still 13 Gbit/s RAM bandwidth
586 2013-10-15 22:00:07 <sipa> assuming it can't stay in cache
587 2013-10-15 22:00:31 <gmaxwell> thats really slow.
588 2013-10-15 22:00:34 <HM2> I can't tell whether you're now happy with 20ms or not
589 2013-10-15 22:00:40 <sipa> absolutely not
590 2013-10-15 22:01:04 <sipa> gmaxwell: it's latency-constrained, not bandwidth constrained of course
591 2013-10-15 22:01:15 <gmaxwell> yes, I understand.
592 2013-10-15 22:02:06 <sipa> i'm sure that if it was a contiguous memory block, it would be significantly faster
593 2013-10-15 22:02:20 <gmaxwell> sipa: though if the stride is usually constant the prefetcher would work, but I guess its not.
594 2013-10-15 22:02:40 <sipa> well it's a linked list of individually-allocated heap objects
595 2013-10-15 22:02:47 <sipa> i don't think there is a constant stride :)
596 2013-10-15 22:04:57 <gmaxwell> sipa: might be interesting to try to reallocate it in once piece.
597 2013-10-15 22:05:08 <sipa> HM2: see #3083
598 2013-10-15 22:05:31 <HM2> CBlockIndex looks a bit like a heap, each parent node is lower (earlier) than it's children, but siblings aren't ordered with respect to one another
599 2013-10-15 22:06:05 <HM2> how do you traverse up the tree? pprev = parent pointer right?
600 2013-10-15 22:06:09 <sipa> yes
601 2013-10-15 22:06:32 <sipa> the code currently relies strongly on the fact that CBlockIndex pointers are constant
602 2013-10-15 22:06:43 <sipa> so CBlockIndex* is used as a block identifier in the code
603 2013-10-15 22:07:08 <sipa> that can be changed of course, use an int as identifier, and assign sequentially-increasing indices to blocks
604 2013-10-15 22:07:14 <sipa> and allocate them in a vector
605 2013-10-15 22:07:37 <HM2> right, so basically you have CBlockIndex pointers everywhere, jump in to arbitrary nodes and can then down to the root / genesis
606 2013-10-15 22:08:05 <sipa> well CChain now encapsulates a vector with CBlockIndex* pointers, indexed by height
607 2013-10-15 22:08:27 <sipa> so for pretty much every operations that needed to iterate through it all, we can just jump to the right ones immediately
608 2013-10-15 22:08:39 <HM2> indexed by height?
609 2013-10-15 22:08:46 <sipa> that's a common operation
610 2013-10-15 22:08:52 <sipa> looking up a block by height
611 2013-10-15 22:09:00 <sipa> in the main chain
612 2013-10-15 22:09:17 <HM2> hmm
613 2013-10-15 22:09:26 <sipa> i was just surprised by how slow iterating it all really takes
614 2013-10-15 22:09:31 <HM2> but aren't there multiple CBlockIndex's for each height?
615 2013-10-15 22:09:38 <sipa> not within one chain
616 2013-10-15 22:10:00 <sipa> we have the entire block tree loaded of course, but a CChain just embodies one chain in it
617 2013-10-15 22:10:12 <HM2> right
618 2013-10-15 22:10:31 <HM2> with you now. so it's like vein going from one leaf down to the genesis
619 2013-10-15 22:10:43 <sipa> yes
620 2013-10-15 22:20:13 <HM2> ah i see now
621 2013-10-15 22:22:49 <HM2> at one point i knew how CPartialMerkletree worked
622 2013-10-15 22:22:55 <HM2> I need to paper it out again
623 2013-10-15 22:44:18 <Goonie> sipa: returning payment requests via nfc does not make sense. it would mean you need to touch multiple times. horrible ux.
624 2013-10-15 22:46:10 <sipa> Goonie: you mentioned that before; agree
625 2013-10-15 22:46:33 <sipa> you can't really consider it bidirectional
626 2013-10-15 22:46:42 <gmaxwell> Goonie: wait, NFC only works one way? so all nfc payment devices have to have a working internet connection?
627 2013-10-15 22:47:06 <sipa> no, it bidirectional, but you need the connection at distinct points in time
628 2013-10-15 22:47:18 <gmaxwell> ugh. an extra point of failure. :(
629 2013-10-15 22:47:37 <sipa> fetch payment request, ask user for confirmations, send payment
630 2013-10-15 22:47:46 <gmaxwell> I see.
631 2013-10-15 22:47:49 <gmaxwell> (now you have to have two working internet connections, and a working NFC channel)
632 2013-10-15 22:48:15 <sipa> maybe by the time NFC gets used, it becomes better
633 2013-10-15 22:48:24 <sipa> (as in: much easier to link)
634 2013-10-15 22:49:38 <gmaxwell> kind of a bummer.
635 2013-10-15 22:50:38 <Goonie> I think we should design payment requests in a way that with the first request a channel is built. and the medium of the channel is independent of the medium of the first request
636 2013-10-15 22:51:14 <sipa> well you have that with URI's
637 2013-10-15 22:51:40 <Goonie> Scanning QR codes is even more problematic, would you want to continue scanning qr codes of each others phone until the protocol is completed?
638 2013-10-15 22:51:58 <sipa> it's just once in each direction
639 2013-10-15 22:52:05 <sipa> (which may still be too much, but ok)
640 2013-10-15 22:52:20 <Goonie> I thought its three steps. request -> payment -> confirm
641 2013-10-15 22:52:35 <sipa> oh right!
642 2013-10-15 22:53:26 <sipa> QR is really only useful for the request
643 2013-10-15 22:53:33 <Goonie> right
644 2013-10-15 23:09:25 <michagogo> cloud|IIRC, there was a solution for the NFC problem: make the NFC tap cause the devices to exchange Bluetooth MAC addresses (or whatever the equivalent is for bt)
645 2013-10-15 23:09:44 <michagogo> cloud|And then use that to complete the exchange
646 2013-10-15 23:09:58 <HM2> why not just use bluetooth to begin with then?
647 2013-10-15 23:10:24 <michagogo> cloud|That basically uses NFC to make the initial handshake
648 2013-10-15 23:10:42 <michagogo> cloud|With bt, you'd need to search, pair, etc
649 2013-10-15 23:10:57 <michagogo> cloud|Having an NFC exchange skips all that
650 2013-10-15 23:11:38 <HM2> Heh, i wouldn't know. the only use i've ever found for NFC on my phone is scanning my passport
651 2013-10-15 23:12:07 <HM2> the idea of 'tapping' my delicate glass backed Nexus 4 makes me whince
652 2013-10-15 23:13:58 <michagogo> cloud|Your passport?
653 2013-10-15 23:14:06 <michagogo> cloud|How does that work?
654 2013-10-15 23:14:35 <michagogo> cloud|Does it have you take a photo of the MRZ?
655 2013-10-15 23:15:56 <sipa> mrz?
656 2013-10-15 23:16:09 <sipa> nfc chips can read rfid
657 2013-10-15 23:16:56 <michagogo> cloud|sipa: IIRC you need information from the MRZ to get past BAC
658 2013-10-15 23:18:16 <sipa> wth is mrz or bac?
659 2013-10-15 23:19:17 <sipa> i love how acronymed thos conversation is: nfc, rfid, iirc, wth, mrz, bac
660 2013-10-15 23:20:22 <HM2> michagogo|cloud, you type in a few details first
661 2013-10-15 23:20:32 <HM2> date of birth, passport number
662 2013-10-15 23:20:33 <michagogo> cloud|Ah, that'll be it then
663 2013-10-15 23:21:01 <michagogo> cloud|Yeah, that's the information that you need for BAC, which is normally pulled from the MRZ
664 2013-10-15 23:21:37 <sipa> bac
665 2013-10-15 23:21:39 <michagogo> cloud|sipa: BAC == Basic Access Control, where the information is protected by a key derived from details about the passport
666 2013-10-15 23:21:47 <sipa> ok
667 2013-10-15 23:22:16 <HM2> yeah it's presumably to stop casual scans
668 2013-10-15 23:22:25 <michagogo> cloud|Exactly
669 2013-10-15 23:22:33 <HM2> michagogo|cloud, is it just encrypted or is it actually an active auth process?
670 2013-10-15 23:22:36 <michagogo> cloud|You need to be able to read the passport details
671 2013-10-15 23:22:46 <michagogo> cloud|I *think* it's auth
672 2013-10-15 23:23:03 <HM2> it must be, it'd be weak ass if it was just encrypted
673 2013-10-15 23:23:44 <michagogo> cloud|Usually, epassport readers are the full-page type, where the passport is placed on a scanner glass, allowing the details to be read from the MRZ (machine-readable zone, the 2 lines of OCR-friendly characters at the bottom of the passport) and then used to read the chip
674 2013-10-15 23:40:42 <petertodd> c2t@z1
675 2013-10-15 23:44:55 <petertodd> lol, better change my bitcoin RPC password... good thing I have a firewall!
676 2013-10-15 23:47:15 <gmaxwell> yours is that short?
677 2013-10-15 23:48:11 <michagogo> cloud|petertodd: you have RPC allowed from *?
678 2013-10-15 23:48:30 <petertodd> gmaxwell: yeah, I set it ages ago and didn't use the auto-create functionality back then
679 2013-10-15 23:48:37 <petertodd> michagogo|cloud: very likely not!
680 2013-10-15 23:49:30 <petertodd> michagogo|cloud: it's also not on the machine I'm logged into on IRC fortunately :P silly cut-n-paste error
681 2013-10-15 23:49:33 <michagogo> cloud|I think I went to a bunch of different random data sites (random.org, etc), took several strings from each, and concatenated them for my RPC username and password
682 2013-10-15 23:49:54 <gmaxwell> michagogo|cloud: it will helpfully suggest a good one for you. :)
683 2013-10-15 23:50:18 <michagogo> cloud|Bitcoin-Qt will?
684 2013-10-15 23:50:21 <petertodd> michagogo|cloud: I used hunter2, but then all my BTC vanished :P
685 2013-10-15 23:50:34 <petertodd> michagogo|cloud: yeah, start it with no rpc password and try to use rpc
686 2013-10-15 23:50:49 <michagogo> cloud|Hmm, pretty sure I've never seen that
687 2013-10-15 23:51:56 <michagogo> cloud|(Maybe I knew before the first time that I used -server that a password was needed?)
688 2013-10-15 23:52:18 <gmaxwell> michagogo|cloud: likely.