1 2015-03-19 00:15:51 <gmaxwell> confirming, 0.10 binaries from bitcoin.org work on debian stable right now? right?
2 2015-03-19 00:22:37 <phantomcircuit> gmaxwell, lets find out
3 2015-03-19 00:27:31 <phantomcircuit> gmaxwell, you want to check against a full sync?
4 2015-03-19 00:29:08 <gmaxwell> just make sure it starts at all.
5 2015-03-19 00:29:16 <gmaxwell> someone on reddit claimed it was libc incompatible.
6 2015-03-19 00:29:27 <gmaxwell> I thought we fixed that a while back.
7 2015-03-19 00:29:45 <phantomcircuit> bitcoin-qt started fine
8 2015-03-19 00:29:49 <phantomcircuit> debian wheezy
9 2015-03-19 00:30:49 <phantomcircuit> libc-bin 2.13-38+deb7u8
10 2015-03-19 00:32:55 <phantomcircuit> bitcoind starts also
11 2015-03-19 00:33:34 <phantomcircuit> maybe they were trying to run 32bit binaries without multilib
12 2015-03-19 00:33:35 <gmaxwell> thanks!
13 2015-03-19 00:34:23 <phantomcircuit> actually that's probably it
14 2015-03-19 00:34:41 <phantomcircuit> trying to run the 32bit binaries i get an error related to libc 32 not being installed
15 2015-03-19 02:06:04 <fanquake> ;;blocks
16 2015-03-19 02:06:05 <gribble> 348217
17 2015-03-19 02:18:54 <cfields> gmaxwell: i believe debian oldstable was one of the ones with the busted libstdc++ problem
18 2015-03-19 02:20:46 <cfields> (manifests with the failed sanity check at startup)
19 2015-03-19 02:32:08 <morcos> Has anyone had problems installing the qt packages on Ubuntu recently? I've done it in the past without problem, but I"m trying to build a new VM now and I get dependency conflicts installing qt4 or qt5
20 2015-03-19 02:33:03 <morcos> It's a VMWare Fusion VM with Ubuntu 14.04.2, and I have installed nothing else..
21 2015-03-19 02:38:56 <morcos> I've got to run, but if anyone has any ideas, on what to change, next or should I just be using different VM software? Anyway, here is what I got: http://pastebin.com/LfEaC6vW
22 2015-03-19 02:54:39 <StephenM347> https://en.bitcoin.it/wiki/Running_Bitcoin lists -dbcache=<n> as one of the parameters. Can someone tell me what this is launch configuration is used for and/or give a little context?
23 2015-03-19 02:56:17 <phantomcircuit> StephenM347, it sets the size of the database cache in megabytes
24 2015-03-19 02:57:21 <StephenM347> phantomcircuit: Right, but what is the database cache used for? Which database and what kind of data is being cached?
25 2015-03-19 02:58:02 <phantomcircuit> StephenM347, that parameter controls a cache of the leveldb utxo state as well as txindex caching if you have that enabled
26 2015-03-19 02:59:14 <StephenM347> I do have txindex=1 enabled. So it controls how much of the UTXO set is cached to make validation faster, does that sound right?
27 2015-03-19 03:01:19 <phantomcircuit> StephenM347, yeah
28 2015-03-19 03:01:41 <phantomcircuit> it splits memory between the txindex and utxo
29 2015-03-19 03:01:51 <Luke-Jr> phantomcircuit: eh, except -dbcache=5 still OOMs on 512 MB RAM
30 2015-03-19 03:02:07 <StephenM347> phantomcircuit: Great, thanks! Do you know what the default is?
31 2015-03-19 03:02:22 <phantomcircuit> StephenM347, its on the page you linked to above...
32 2015-03-19 03:02:39 <phantomcircuit> Luke-Jr, :|
33 2015-03-19 03:03:26 <StephenM347> phantomcircuit: oic
34 2015-03-19 04:29:20 <gmaxwell> coryfields_: wtf osx.
35 2015-03-19 05:28:58 <cfields> gmaxwell: par for the course :\
36 2015-03-19 05:29:19 <cfields> gmaxwell: they add symbols in later sdks but you have to check for their presence at runtime
37 2015-03-19 05:29:31 <cfields> for high-level functionality it tends to work pretty well, but this one's nasty
38 2015-03-19 05:30:51 <gmaxwell> yea, I mean .. str* ?!?
39 2015-03-19 05:30:52 <cfields> gmaxwell: here's the more osx-y fix, but it's obvious overkill for this case: https://github.com/theuni/bitcoin/commit/e0574c3b42f05fb6a36b6acd597550a4ec1e70c1
40 2015-03-19 05:33:10 <cfields> gmaxwell: i'm hoping it's not as braindead as it would appear. Maybe it was always inlined/aliased/built-in in the osx 10.6 gcc era so they didn't bother in their libc?
41 2015-03-19 06:32:26 <wumpus> gmaxwell: it's crazy, indeed. You'd possibly expect something like this for OS APIs, but for base libc functions?!
42 2015-03-19 06:34:08 <wumpus> macosx keeps surprising me with their crazyness, even win32 is almost sane by comparison
43 2015-03-19 06:34:49 <wumpus> oh, phew, we don't need it in master
44 2015-03-19 13:58:31 <gmaxwell> https://people.xiph.org/~greg/openssl_101m.txt
45 2015-03-19 13:58:52 <gmaxwell> (sorry for the weird link, I'm apparently jumping the gun on their release by pulling the files straight off their FTP as they go up)
46 2015-03-19 13:59:53 <gmaxwell> okay the most important fix appears to be in 1.0.2 only. OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291)
47 2015-03-19 14:00:09 <gmaxwell> and thats not that interesting to us.
48 2015-03-19 14:01:09 <gmaxwell> the security advisory is up now: http://openssl.org/news/secadv_20150319.txt
49 2015-03-19 14:04:40 <gmaxwell> Gee, thank you openssl for reindenting chunks of otherwise seemingly non-updated code as part of a security update. Thats super helpful.
50 2015-03-19 14:07:36 <sipa> gmaxwell: they had apparently announced a code style cleanup in advance
51 2015-03-19 14:07:55 <sipa> i guess if you look at individual commits, it's easy to avoid; but still...
52 2015-03-19 14:08:14 <gmaxwell> I cannot review this change. NAK.
53 2015-03-19 14:08:40 <gmaxwell> grr.
54 2015-03-19 14:09:15 <Diablo-D3> https://www.openssl.org/news/secadv_20150319.txt
55 2015-03-19 14:09:44 <gmaxwell> some of what otherwise looks like style cleanup is not provably identical; indeed perhaps it'll be easier once I have the actual commits to this tree.
56 2015-03-19 14:13:29 <sipa> git diff -b 3151e328e0fe1c9233de51bfc716d2aa521a34cf..origin/OpenSSL_1_0_1-stable
57 2015-03-19 14:14:14 <timothy> is there any way to know if a multisig address if a 2of2 or a 2of3?
58 2015-03-19 14:14:26 <sipa> no
59 2015-03-19 14:14:37 <timothy> so, a web service can "scam" you easly?
60 2015-03-19 14:15:03 <timothy> they generate a 2 of 3 address, you see "3" as start of the address. but they can use your money without your key
61 2015-03-19 14:15:04 <sipa> if you're a participant, you should know the full script being sent to, so if it matters to you, no they can't
62 2015-03-19 14:16:28 <timothy> am I wrong?
63 2015-03-19 14:16:50 <sipa> there is no such thing as a multisig address; it's a p2sh address, and it is a hash of a redeemscript
64 2015-03-19 14:17:00 <sipa> if you know the redeemscript, you know what it does and who is involved
65 2015-03-19 14:17:08 <sipa> with just the hash, you don't know anything
66 2015-03-19 14:22:50 <sipa> and if you're involved, you should know the redeemscript
67 2015-03-19 14:23:10 <sipa> otherwise you wouldn't even know how to sign partially
68 2015-03-19 14:25:52 <jonasschnelli> timothy, maybe http://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions/
69 2015-03-19 14:34:38 <gmaxwell> The diff between openssl 1.0.1l and 1.0.1m is 724,896 lines long.
70 2015-03-19 14:35:37 <sipa> Moderate.
71 2015-03-19 14:37:51 <sipa> with git diff -w -b it's only 139684 lines
72 2015-03-19 14:43:22 <gmaxwell> sipa: extra fun that their code style changed to an intrensically less safe form of having lots of unbraced multi-line if statements.
73 2015-03-19 14:44:29 <sipa> git diff -w -b --word-diff OpenSSL_1_0_1l..OpenSSL_1_0_1m
74 2015-03-19 14:44:42 <sipa> even more readable
75 2015-03-19 14:46:33 <gmaxwell> hm, I'm not getting the 1_0_1m tag.
76 2015-03-19 14:47:09 <gmaxwell> indeed, thats a nice visualization.
77 2015-03-19 14:47:09 <sipa> try origin/OpenSSL_1_0_1m
78 2015-03-19 14:47:36 <gmaxwell> yea, whatever tree I'm pulling from just doesn't seem to have the tag.
79 2015-03-19 14:47:40 <gmaxwell> github I guess?
80 2015-03-19 14:47:49 <gmaxwell> it's fine I can just point to the commit.
81 2015-03-19 14:48:22 <sipa> yes, github
82 2015-03-19 14:48:37 <gmaxwell> nice that the that works on the log -p view too; git log -p -w -b --word-diff
83 2015-03-19 14:54:39 <gmaxwell> ACTION has to depart
84 2015-03-19 15:58:45 <stonecoldpat> sipa: am I right in thinking that in the sig (r,s), r is not malleable? im reading bip62 and dont see a mention if it is or not
85 2015-03-19 15:59:01 <sipa> afaik there is no known way to malleate r
86 2015-03-19 15:59:06 <stonecoldpat> (y) tty
87 2015-03-19 15:59:13 <zooko> "maul" ?
88 2015-03-19 15:59:21 <sipa> mutate
89 2015-03-19 15:59:23 <sipa> modify
90 2015-03-19 15:59:26 <sipa> mutilate
91 2015-03-19 16:27:10 <morcos> I commented last night about not being to install QT on Ubuntu 14.04.2, it looks like other people on the internet have this issue
92 2015-03-19 16:27:26 <morcos> Also I did a depends build and it build fine, but then seg faulted on running bitcoin-qt
93 2015-03-19 16:28:00 <morcos> I reinstalled my machine with 14.04.1 and don't have any problems now, and this seems like an upstream problem, but just thought people should be aware
94 2015-03-19 17:12:37 <wumpus> morcos: using latest master? a change to depends (related to xcb) went in a few days ago that should fix that
95 2015-03-19 17:13:13 <wumpus> and there should be no issues with 0.10
96 2015-03-19 17:46:46 <sipa> and block v3 is over 10%
97 2015-03-19 17:48:51 <Muis> im trying to build bitcoind x64 in mingw
98 2015-03-19 17:49:25 <Muis> and the makefile doesnt want to build because it gives 'missing seperator' for the lines starting with an 'if' statement
99 2015-03-19 17:49:46 <Muis> and if I replace all the 'if' statement with 'ifdef' for example, the whole makefile builds fine
100 2015-03-19 17:50:00 <Muis> so what could be the problems with the 'if's and mingw64?
101 2015-03-19 17:53:51 <Luke-Jr> Muis: you may be the first to attempt this :p
102 2015-03-19 17:54:24 <Luke-Jr> pastebinning the whole error and Makefile snippet may be useful
103 2015-03-19 17:55:16 <Muis> i builded all dependencies in mingw64
104 2015-03-19 17:55:31 <Muis> then I run the ./confgure with --without-gui and --disable-wallet
105 2015-03-19 17:55:37 <Muis> also ran fine
106 2015-03-19 17:55:40 <Muis> then I run make:
107 2015-03-19 17:55:50 <Muis> and I get 'No targets specified blabla'
108 2015-03-19 17:55:55 <Luke-Jr> Muis: you already said as much; please pastebin the actual logs
109 2015-03-19 17:55:57 <Muis> so I run make -f Makefile.am
110 2015-03-19 17:56:06 <Muis> and then it says 'nothing to be done for Makefile.am'
111 2015-03-19 17:56:36 <Luke-Jr> Muis: do you have a file named 'Makefile' ?
112 2015-03-19 17:56:46 <Luke-Jr> Makefile.am is NOT a makefile
113 2015-03-19 17:57:22 <Muis> if have Makefile.in and Makefile.am
114 2015-03-19 17:57:49 <Muis> but not one without extension
115 2015-03-19 17:58:51 <Muis> how should I generate it?
116 2015-03-19 18:01:27 <Muis> https://www.irccloud.com/pastebin/LPLZTd6C
117 2015-03-19 18:02:06 <Luke-Jr> configure generates it
118 2015-03-19 18:02:14 <Luke-Jr> pastebin the output of configure
119 2015-03-19 18:02:28 <Luke-Jr> ok, that pastebin is informative.
120 2015-03-19 18:02:42 <Luke-Jr> you shouldn't even *have* a configure if autgen fails..
121 2015-03-19 18:02:55 <Muis> yes but the first time autogen didnt fail
122 2015-03-19 18:03:00 <Muis> very strange that it fails now
123 2015-03-19 18:03:30 <morcos> wumpus: thanks! i wasn't on latest master, that fixed my depends build.
124 2015-03-19 18:03:33 <Muis> https://www.irccloud.com/pastebin/P1TjsRMy
125 2015-03-19 18:04:21 <wumpus> morcos: good to hear!
126 2015-03-19 18:04:26 <Luke-Jr> looks like you're missing libtool and pkg-config at least
127 2015-03-19 18:04:47 <Luke-Jr> libtool is only a dependency for building from git, not source releases; pkg-config is documented as required..
128 2015-03-19 18:05:13 <Luke-Jr> Muis: read doc/build-unix.md
129 2015-03-19 18:05:46 <Muis> im building for windows, but I will read build-unix :)
130 2015-03-19 18:06:37 <Luke-Jr> Muis: well, like I said, you may be the first to be trying to build normally on Windows
131 2015-03-19 18:06:52 <Luke-Jr> Muis: everyone else uses Linux, except for one guy who hacks up his own build stuff
132 2015-03-19 18:07:04 <Luke-Jr> (and official Windows releases are only ever built on Linux)
133 2015-03-19 18:07:19 <Luke-Jr> s/Linux/*nix/
134 2015-03-19 18:07:28 <Muis> My end-goal is to compile with Visual Studio, since it produces much smaller binaries, but I want to try the MinGW route first
135 2015-03-19 18:07:53 <ajweiss> uy, i'd just go straight for visual studio
136 2015-03-19 18:08:01 <Muis> no because if something doesnt work
137 2015-03-19 18:08:13 <Muis> I dont know if its because of Visual Studio or because of my codebase
138 2015-03-19 18:08:18 <ajweiss> i don't know how much of the work put into mingw will transfer though
139 2015-03-19 18:08:34 <Muis> I thought the official binaries were build using mingw
140 2015-03-19 18:08:39 <Muis> didnt realize they were build on linux
141 2015-03-19 18:08:42 <Muis> that explains a lot
142 2015-03-19 18:08:45 <ajweiss> also
143 2015-03-19 18:08:54 <ajweiss> there's an old pr where someone tried to do this
144 2015-03-19 18:08:54 <wumpus> they are cross compiled from linux (using depends)
145 2015-03-19 18:09:03 <ajweiss> that might have some pointers
146 2015-03-19 18:09:10 <Muis> so your advice is to skip MinGW?
147 2015-03-19 18:09:23 <wumpus> in theory it should be possible to build in mingw-w64 natively, but you need all the right packages and may need to patch up some things, as you're the first to do it
148 2015-03-19 18:09:49 <wumpus> e.g. there may be somes scripting and utility related things that are different natively
149 2015-03-19 18:09:56 <ajweiss> i would, but visual studio is a port, the mingw stuff seems like a stop that's out of the way to me
150 2015-03-19 18:10:10 <Muis> how do you mean a port?
151 2015-03-19 18:10:26 <ajweiss> it is very unlikely that it will just work
152 2015-03-19 18:10:46 <ajweiss> in other words, i suspect it would be some work
153 2015-03-19 18:10:55 <wumpus> with mingw-w64 you can be sure that the source code at least will just work, just the build system may need some changes
154 2015-03-19 18:10:57 <Muis> I read a topic from some girl on bitcointalk who compiled it in VS2013 (including QT), so if a girl can do it, I surely must can ;)
155 2015-03-19 18:11:18 <ajweiss> unless she's better than you
156 2015-03-19 18:11:22 <Muis> haha
157 2015-03-19 18:11:32 <Muis> luckily she documented it
158 2015-03-19 18:11:40 <wumpus> with VC you need to both make the build system and make some changes to the source code
159 2015-03-19 18:12:28 <Muis> if I switch to mingw32, would that be zero-effort, or is that also not garantueed to be working?
160 2015-03-19 18:12:37 <wumpus> that'd be worse
161 2015-03-19 18:12:43 <Muis> okay
162 2015-03-19 18:12:55 <wumpus> the only easy way is to use ubuntu and cross compile
163 2015-03-19 18:13:15 <ajweiss> what's your goal? or are you tinkering?
164 2015-03-19 18:13:28 <Muis> I want to build with Visual Studio C++
165 2015-03-19 18:13:32 <Muis> and compile to CLR code
166 2015-03-19 18:13:43 <Muis> so that I get a managed daemon
167 2015-03-19 18:13:47 <wumpus> if that is your goal, messing around with mingw makes little sense
168 2015-03-19 18:13:48 <Muis> instead of native x64 daemon
169 2015-03-19 18:13:55 <Luke-Jr> I would be surprised if Visual Studio was workable, it's so buggy
170 2015-03-19 18:14:15 <Muis> wumpus: i wanted to make two versions so I can compare binary-size/performance/ram-usage/etc
171 2015-03-19 18:14:31 <wumpus> Luke-Jr: it does work, it's just not worth the hassle of maintaining another build system
172 2015-03-19 18:14:40 <Muis> but theoreticly speaking my build should be automaticly more secure
173 2015-03-19 18:14:59 <Muis> because all i/o and memory access is sandboxed
174 2015-03-19 18:15:16 <Muis> just like BitcoinJ is more secure in certain ways
175 2015-03-19 18:15:38 <Muis> (and maybe less in others)
176 2015-03-19 18:15:58 <ajweiss> i don't know a whole lot about managed c++ and all that
177 2015-03-19 18:16:35 <Muis> managed c++ is just CLR code
178 2015-03-19 18:16:36 <wumpus> depends on what the threat model is, 'insecure' could also mean verifying transactions as valid that are not really valid, no kind of sandboxing will protect against that. Also, JITs and such make it harder to protect private keys in memory by e.g. keeping pages locked.
179 2015-03-19 18:16:38 <Muis> so the same as C#
180 2015-03-19 18:17:26 <wumpus> in java etc you won't have buffer overflows (unless the runtime itself has bugs! that happens!)
181 2015-03-19 18:17:31 <Muis> i saw that the native daemon already uses tricks like position-independant code, so I guess a managed JIT framework doesnt add too much value
182 2015-03-19 18:17:52 <Muis> because buffer overflows should already be prevented
183 2015-03-19 18:18:14 <Muis> but for me its a nice way to get familar with the code
184 2015-03-19 18:18:47 <ajweiss> it could be, but be prepared, i suspect a lot of rote porting and build system tweaking work would be involved
185 2015-03-19 18:18:55 <Muis> yes
186 2015-03-19 18:19:02 <Muis> but Im following the guide that I found
187 2015-03-19 18:19:13 <Muis> and hope its still up to date and works for vs2015 too
188 2015-03-19 18:19:16 <Muis> fingers crossed
189 2015-03-19 18:20:05 <Muis> https://github.com/ClaireDuSoleil/bitcoin/tree/0.8.6/MSVC
190 2015-03-19 18:20:30 <wumpus> 0.8.6? that's far from up to date
191 2015-03-19 18:20:43 <Muis> I know, but its about the build instructiuons
192 2015-03-19 18:20:46 <Muis> not the code itself
193 2015-03-19 18:22:43 <Muis> there is a new dependancy 'gmp' in 0.10, but I think thats the only change?
194 2015-03-19 18:25:32 <ajweiss> unsure, that is one of the many questions you will wrestle with in this process. honestly, i don't want to discourage you, but i think there are other tinkerings you can do to familiarize yourself with the code that will both be less frustrating and more rewarding
195 2015-03-19 18:30:12 <wumpus> gmp is not a necessary dependency, we don't have it in the gitian builds
196 2015-03-19 20:03:37 <ajweiss> "Fairly early on it was noticed that, due to some reformatting errors, we were failing to build across all branches on windows."
197 2015-03-19 20:04:28 <cfields> openssl?
198 2015-03-19 20:04:29 <ajweiss> in other words, they never checked that pre and post reformat build results were identical
199 2015-03-19 20:04:32 <ajweiss> yep
200 2015-03-19 20:04:40 <gielbier> damn
201 2015-03-19 20:04:57 <cfields> hmm, worked for our mingw builds
202 2015-03-19 20:05:03 <cfields> but yes, that's crazy
203 2015-03-19 20:05:10 <gielbier> microsoft is going crazy on github atm btw
204 2015-03-19 20:05:20 <cfields> hmm?
205 2015-03-19 20:05:58 <gielbier> http://blogs.msdn.com/b/dotnet/archive/2015/03/18/msbuild-engine-is-now-open-source-on-github.aspx
206 2015-03-19 20:06:21 <ajweiss> you guys checked that the reformat of openssl didn't result in different binaries?
207 2015-03-19 20:07:07 <ajweiss> or you mean the reformat pull of bitcoin core?
208 2015-03-19 20:07:58 <ajweiss> oh i see what you mean
209 2015-03-19 20:08:05 <ajweiss> https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
210 2015-03-19 20:08:17 <cfields> ajweiss: i meant that the win32 builds succeed. nothing about how it differs, though
211 2015-03-19 20:08:31 <cfields> it's insane to backport that code reformatting
212 2015-03-19 20:08:43 <ajweiss> right after openssl reformatted, they opened up for new changes, accepted some, but then realized they had broken builds
213 2015-03-19 20:19:10 <Muis> im building now
214 2015-03-19 20:19:18 <Muis> first problem is the PRIszu macro in printf statements
215 2015-03-19 20:19:37 <Muis> and PRI64d
216 2015-03-19 20:19:46 <Muis> i dont know what their cross-platform counterparts are
217 2015-03-19 20:20:20 <guest23423423> what generates raw tx data in test?
218 2015-03-19 20:27:52 <jonasschnelli> guest23423423, what do you mean with test?
219 2015-03-19 20:28:18 <guest23423423> src/test/data/*.json
220 2015-03-19 20:28:38 <cfields> guest23423423: see the rule in Makefile.test.include
221 2015-03-19 20:29:03 <cfields> (they're built automatically as needed)
222 2015-03-19 20:29:15 <guest23423423> by what tool>?
223 2015-03-19 20:29:28 <cfields> hexdump
224 2015-03-19 20:29:45 <guest23423423> ;-) who sets the parameters of the transactions and signs them?
225 2015-03-19 20:30:12 <cfields> hmm?
226 2015-03-19 20:30:35 <guest23423423> prev out, value, scripsig, etc...
227 2015-03-19 20:31:09 <cfields> test-cases are created by hand. I'm not sure what you're asking
228 2015-03-19 20:31:52 <wumpus> Muis: we stopped using those macros ages ago
229 2015-03-19 20:32:27 <wumpus> Muis: and use our own formatter which automatically picks the sizes in a typesafe way
230 2015-03-19 20:33:36 <guest23423423> how do you sign a prevout of 0000000000000000000000000000000000000000000000000000000000000100:0 ?
231 2015-03-19 20:33:53 <guest23423423> remeed that is
232 2015-03-19 20:33:56 <guest23423423> redeem
233 2015-03-19 20:36:39 <Muis> wumpus: i figured it out
234 2015-03-19 20:37:18 <Muis> wumpus: if I add spaces between the string and the symbol like this: " PRIszu " instead of "PRIszu" it works
235 2015-03-19 20:37:37 <wumpus> Muis: I have no clue what you're doing, but it sounds like you're using an age-old version of the source code
236 2015-03-19 20:37:44 <Muis> and it could be that it isnt use anymore, but im trying to compile 0.8.6 first, and if its working, then I compile 0.10
237 2015-03-19 20:38:20 <wumpus> Muis: that's fine, but that means a lot of the problems you're solving have necessarily already been solved
238 2015-03-19 20:38:44 <Muis> true
239 2015-03-19 20:38:58 <Muis> I forgot that I was using 0.8.6
240 2015-03-19 20:39:05 <Muis> otherwise I wouldnt have said anything
241 2015-03-19 20:39:43 <Muis> because earlier today I was compiling 0.10 for mingw, so its easy to get confused :)
242 2015-03-19 20:40:11 <wumpus> guest23423423: to redeem it you need to satisfy the scriptPubkey for that output. that doesn't look like a realistic txid though.
243 2015-03-19 20:49:38 <guest23423423> wumpus: https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_valid.json#L40
244 2015-03-19 21:12:01 <Luke-Jr> hm, so 0.10 won't start for me anymore :x bitcoin-qt.ljr20150313: main.cpp:1814: bool ConnectBlock(const CBlock&, CValidationState&, CBlockIndex*, CCoinsViewCache&, bool): Assertion `hashPrevBlock == view.GetBestBlock()' failed.
245 2015-03-19 21:13:11 <phantomcircuit> Luke-Jr, sounds like you have some loverly corruption
246 2015-03-19 21:13:20 <Luke-Jr> :<
247 2015-03-19 21:13:21 <phantomcircuit> there's a known issue with reindexing and things
248 2015-03-19 21:13:38 <Luke-Jr> I didn't reindex
249 2015-03-19 21:13:41 <phantomcircuit> if you have a partial write of a block stuff will break when you start next
250 2015-03-19 21:14:28 <Luke-Jr> pindex is the genesis block
251 2015-03-19 21:14:51 <phantomcircuit> hmm
252 2015-03-19 21:14:57 <phantomcircuit> that sounds odd
253 2015-03-19 21:14:59 <Luke-Jr> why is it trying to connect that? :/
254 2015-03-19 21:16:26 <Luke-Jr> nTargetHeight is 31, wtf
255 2015-03-19 21:18:10 <Luke-Jr> chainActive.Tip() is NULL
256 2015-03-19 21:22:05 <jonasschnelli> headers-first: is there no parallel download of headers from multiple peers?
257 2015-03-19 21:23:26 <sipa> jonasschnelli: nope
258 2015-03-19 21:23:51 <jonasschnelli> sipa, what if getheaders go to a very slow (maybe throttled) peer?
259 2015-03-19 21:26:19 <sipa> then it'll take longer :)
260 2015-03-19 21:26:35 <sipa> it's only a few mb
261 2015-03-19 21:26:49 <sipa> also, new block announcements trigger new headers fetches i think
262 2015-03-19 21:27:05 <jonasschnelli> sipa, :) yes. I'm playing with a potential SPV implementation... that's why i'm asking.
263 2015-03-19 21:28:20 <jonasschnelli> btw: i try to reuse main.cpp's logic for now... but sometime i'm not sure if it would be worth to start a spv.cpp and write the whole messaging-state-machine for spv new
264 2015-03-19 21:30:34 <sipa> jonasschnelli: i'd rather do the opposite: move the full validation out to an optional module
265 2015-03-19 21:31:41 <guest23423423> i suppose the ::100:0 inputs will have to wait for Matt.
266 2015-03-19 21:33:01 <Luke-Jr> mapBlockIndex.find(pcoinsTip->GetBestBlock()) == mapBlockIndex.end()
267 2015-03-19 21:33:45 <jonasschnelli> sipa, the validation looks after the easy part. Currently i'm fighting with getting blocks and sending them to a CValidationInterface without storing the whole chain
268 2015-03-19 21:34:20 <Luke-Jr> sipa: I suppose this means I need to nuke it and start over?
269 2015-03-19 21:34:43 <jonasschnelli> and main.cpp would need update for merkleblock and the whole filter/bip37 stuff. SPV without bloomfilters is a wast of bandwidth IMO.
270 2015-03-19 21:35:50 <Luke-Jr> jonasschnelli: the usual use case IMO would be SPV only until the full chain is validated
271 2015-03-19 21:36:02 <Luke-Jr> in which case you might as well get entire blocks since you'll want them later
272 2015-03-19 21:36:28 <phantomcircuit> sipa, as discussed yesterday that isn't strictly speaking true
273 2015-03-19 21:36:36 <phantomcircuit> nvm
274 2015-03-19 21:36:36 <phantomcircuit> oh you mentioned that
275 2015-03-19 21:39:18 <jonasschnelli> Luke-Jr, Yes. This would make sense. But i'm not sure if a standalone -spv=1 mode would also make sense.
276 2015-03-19 21:41:28 <phantomcircuit> Luke-Jr, there's a couple of knobs that should be individually tunable
277 2015-03-19 21:41:39 <phantomcircuit> total storage space
278 2015-03-19 21:41:48 <phantomcircuit> what the wallet counts as confirmed
279 2015-03-19 21:41:52 <phantomcircuit> stuff like that
280 2015-03-19 21:45:47 <Luke-Jr> jonasschnelli: a standalone SPV library would make far more sense :p
281 2015-03-19 21:46:36 <phantomcircuit> Luke-Jr, i was working on such a thing and then got busy with other things
282 2015-03-19 21:46:52 <phantomcircuit> currently it does very little
283 2015-03-19 21:47:14 <phantomcircuit> maybe i should do a prototype in python since i bet i can have something that works in a few days...
284 2015-03-19 22:03:31 <morcos> sipa: you around?
285 2015-03-19 22:18:20 <arubi> hey, for a 2-of-2 script, which format is used, "2 0x21 PUBKEY1 0x21 PUBKEY2 2 CHECKMULTISIG" or is PUSHDATA1 used before each of the 0x21 bytes?
286 2015-03-19 22:27:38 <sipa> arubi: whatever you like
287 2015-03-19 22:27:57 <sipa> both are valid, though it's cheaper to use the shoetest
288 2015-03-19 22:28:10 <arubi> the hashes for the address are also different
289 2015-03-19 22:28:22 <sipa> yes? so?
290 2015-03-19 22:28:35 <sipa> as a participant you need to know the full script anyway
291 2015-03-19 22:29:21 <arubi> right, but if each creates a script on his own end (using the same data as others) then mistakes could happen
292 2015-03-19 22:29:44 <sipa> then don't do that :)
293 2015-03-19 22:30:02 <arubi> (only on testnet :) )
294 2015-03-19 22:31:47 <arubi> sipa, actually, this question only came up because of a different thing that happened.. I'm guessing its not advisable to import bot the compressed and the uncompressed versions of a WIF, right?
295 2015-03-19 22:34:11 <arubi> I made a 2-of-2 manually that takes a compressed an uncompressed versions of a public key. I couldn't get `bitcoin-cli` or `bitcoin-tx` to sign more than 1 time on the spending transaction
296 2015-03-19 22:34:55 <arubi> a 2-of-2 of the old kind, not p2sh
297 2015-03-19 22:35:48 <arubi> finally I imported both WIF's (of the same private key) and I was able to redeem the output using `bitcoin-qt`'s input selection
298 2015-03-19 22:37:01 <arubi> then I tried the same thing only with p2sh, same thing, I couldn't sign more than once. (even when trying ALL and supplying both keys in json)
299 2015-03-19 22:38:55 <arubi> `bitcoin-qt` wasn't much help either. I had to manually copy+paste the signature that was already inside the transaction (plus increasing the size of the script)
300 2015-03-19 22:40:15 <arubi> then when I wanted to broadcast it, bitcoin gave an error : "64: non-mandatory-script-verify-flag (No error)"
301 2015-03-19 22:41:29 <arubi> I had to find the check in 'main.cpp' , disable it and recompile, and only _then_ I was able to send the transaction
302 2015-03-19 22:42:15 <arubi> anyway, sorry for spamming.. I thought its interesting.
303 2015-03-19 22:48:26 <arubi> oh, if anyone's interested, the transactions are '451fda3f44b1816d59c9bed812ba721e0c841bdc1aa46d23f792aa561703d746' and '72519286beba50478369448ffd0984556007d8b0ddfcce33caa6a2b722fd9bb6' in testnet.
304 2015-03-19 22:57:13 <Muis> I build the latest code in Visual Studio 2015, and most fixes were very straightforward
305 2015-03-19 22:57:33 <Muis> however, there are still a handfull of errors left I dont know how to fix
306 2015-03-19 22:58:00 <Muis> ironicly there are exactly 13 left :) they are:
307 2015-03-19 23:01:11 <phantomcircuit> Muis, please dont paste all 13 errors here
308 2015-03-19 23:01:30 <Muis> https://www.irccloud.com/pastebin/S2fDz2sj
309 2015-03-19 23:02:01 <Muis> actually it are only 2 errors, but at 13 locations
310 2015-03-19 23:02:18 <Muis> so if someone can help me with those 2, then I can build bitcoin in vs2015
311 2015-03-19 23:05:07 <Muis> okay, ignore the errors in interpreter.c
312 2015-03-19 23:06:03 <Muis> I added Peter Todd's CHECKLOCKTIMEVERIFY to the script-codes, so this does not happen in trunk
313 2015-03-19 23:06:11 <Muis> then there is only 1 error left
314 2015-03-19 23:18:54 <moa> any update on the OpenSSL bug announce?
315 2015-03-19 23:23:38 <phantomcircuit> moa, nothing of interest to bitcoin
316 2015-03-19 23:23:46 <phantomcircuit> http://openssl.org/news/secadv_20150319.txt