1 2015-05-21 00:01:57 <TD-Linux> b..but 45k of wasted disk space!
  2 2015-05-21 00:52:48 <cfields> is that all?
  3 2015-05-21 00:53:07 <cfields> i was under the impression it'd be hundreds of kb
  4 2015-05-21 01:07:08 <TD-Linux> cfields, it's much larger for verification
  5 2015-05-21 01:08:15 <TD-Linux> is bitcoin-core still using openssl ec functions?
  6 2015-05-21 01:17:09 <gmaxwell> TD-Linux: for verification yes.
  7 2015-05-21 01:17:59 <gmaxwell> cfields: _signing_ is 65536 bytes of data.
  8 2015-05-21 01:18:05 <gmaxwell> Verify is about 1.3MB.
  9 2015-05-21 01:19:05 <cfields> gmaxwell: ah ok, that's more like what i was remembering from sipa
 10 2015-05-21 01:24:47 <gmaxwell> really verify should be compile time and maybe runtime configurable as the optimal size depends on the hardware. It's kinda compile time configurable now, .. there is a define.
 11 2015-05-21 01:25:03 <gmaxwell> Something that doesn't have 2MB of L2/L3 cache may well be faster with a smaller verify table.
 12 2015-05-21 08:49:56 <wumpus> * [new tag]         v0.9.5rc2 -> v0.9.5rc2  (MacOSX should be deterministic now, thanks cfields)
 13 2015-05-21 08:51:56 <fanquake> wumpus will be have a rc2 for 0.9.5? Or just straight to a release from here.
 14 2015-05-21 08:54:13 <wumpus> I suppose we first have to actually test that it is deterministic now
 15 2015-05-21 08:54:38 <wumpus> would be a mess to go straight to release then realize that this wasn't enough
 16 2015-05-21 08:56:52 <wumpus> https://travis-ci.org/bitcoin/bitcoin/jobs/63368746  another timeout in test_bitcoin :/ (for #6098) ... I'm starting to think this new scheduler test does not finish sometimes
 17 2015-05-21 08:58:12 <wumpus> (log output it doesn't actually say which unit test takes too long, but my suspicion is the scheduler test because it's newest)
 18 2015-05-21 09:01:13 <jonasschnelli> wumpus: Indeed. How can we track this down? I couldn't reproduce the issue localy.
 19 2015-05-21 09:10:01 <wumpus> add a printf at the start and end of the test, log the time it took
 20 2015-05-21 09:10:38 <wumpus> (the other option would be to comment out the scheduler test and see if the transient problems stop happening)
 21 2015-05-21 09:11:22 <wumpus> though if the test is correct, and this is a real problem in the underlying code, it's important to fix this
 22 2015-05-21 10:55:29 <wumpus> fanquake: I agree that after we have two/three macosx v0.9.5rc2 signatures that match, we can go to the final immediately
 23 2015-05-21 10:56:36 <wumpus> (as that's, I guess, the only thing left to be tested)
 24 2015-05-21 12:15:46 <wumpus> yes, it's unfortunate, with other OSes it would not be necessary, but 0.9 osx intermediate files are not deterministic so it's impossible to check that the qt dep stays the same
 25 2015-05-21 12:16:47 <wumpus> (which it 99% sure should, because the openssl headers don't change just the library)
 26 2015-05-21 14:11:53 <StephenM347> Were there any alert messages sent recently to warn old versions to update?
 27 2015-05-21 14:14:02 <StephenM347> And, if so, for what reason and what versions need to update?
 28 2015-05-21 14:17:59 <wumpus> here's a list of past alerts: https://en.bitcoin.it/wiki/Alerts#Past_alerts
 29 2015-05-21 15:05:22 <wumpus> 0.9.5rc2 osx gitian: d4e3eac02605815ae2133ed714340c309aa3e142b501c58bf318ef8ee131981c  Bitcoin-Qt.dmg
 30 2015-05-21 15:44:53 <michagogo> wumpus: will start building (deps) now
 31 2015-05-21 15:45:20 <michagogo> I see we're 2 versions behind on OpenSSL. I'm guessing the changes aren't relevant to us?
 32 2015-05-21 15:47:00 <wumpus> see discussion in https://github.com/bitcoin/bitcoin/pull/5929
 33 2015-05-21 15:47:36 <michagogo> o_O
 34 2015-05-21 15:47:40 <michagogo> that's...
 35 2015-05-21 15:47:42 <michagogo> o_O
 36 2015-05-21 15:50:35 <wumpus> so essentially, even though it's an openssl minor release, the diff is too large to review
 37 2015-05-21 15:51:02 <wumpus> and it's not incredibly important, it would only affect the use of ssl for payment requests, nothing that affects ecdsa
 38 2015-05-21 15:59:11 <michagogo> wumpus/cfields: in the 0.9 builds, should it be safe to use gbuild -i for building Qt and Bitcoin Core immediately after building depends?
 39 2015-05-21 16:00:35 <michagogo> I ask because after the lxc change (to build with debootstrap directly) a big part of the build time is the upgrade of the packages in the VM, since debootstrap doesn't use -updates and -security
 40 2015-05-21 16:01:55 <iwilcox> Can't it be told to?
 41 2015-05-21 16:02:02 <michagogo> iwilcox: can it?
 42 2015-05-21 16:03:07 <wumpus> michagogo: I worked around the lengthy update by re-generating the i386 image
 43 2015-05-21 16:03:24 <michagogo> wumpus: after the latest lxc change?
 44 2015-05-21 16:03:39 <michagogo> Wait, you don't use lxc
 45 2015-05-21 16:03:41 <wumpus> michagogo: today; but I don't use lxc, it worked with kvm
 46 2015-05-21 16:03:42 <michagogo> It's not relevant for you
 47 2015-05-21 16:03:58 <michagogo> KVM is unchanged
 48 2015-05-21 16:04:17 <wumpus> well my kvm VM was also stuck a long time on updates with every bulid
 49 2015-05-21 16:04:36 <michagogo> wumpus: this is getting stuck for much longer than that
 50 2015-05-21 16:04:42 <michagogo> The problem is that the base container that is now created only includes packages from precise
 51 2015-05-21 16:04:50 <iwilcox> michagogo: Might want to look at multistrap, if that doesn't disrupt things too much.
 52 2015-05-21 16:04:50 <michagogo> and not from precise-updates and precise-security
 53 2015-05-21 16:05:12 <michagogo> So it needs to upgrade 130ish packages each time the VM is reset
 54 2015-05-21 16:05:27 <wumpus> I am not sure whether using -i is safe, but I think if you only build macosx it should be ok
 55 2015-05-21 16:20:34 <shamoon> where in the source code does the reference client select the UTXO's to reduce fees?
 56 2015-05-21 16:26:23 <wumpus> shamoon: you mean the wallet output selection? SelectCoins in wallet.cpp
 57 2015-05-21 16:31:41 <shamoon> where is the updated fees for the 0.10 client?
 58 2015-05-21 16:32:49 <cfields> michagogo: for 0.9, i don't recall if it's realistic to expect that to work
 59 2015-05-21 16:33:09 <cfields> michagogo: for 0.10+, things were designed so that it should, though
 60 2015-05-21 16:33:15 <michagogo> cfields: even when doing it all-Mac? :-/
 61 2015-05-21 16:33:37 <cfields> michagogo: my guess would be that for osx, since it's all cross, it should work
 62 2015-05-21 16:33:42 <cfields> i just can't say for sure
 63 2015-05-21 16:34:00 <michagogo> Looks like deps and qt use the same packages and the actual build uses a superset
 64 2015-05-21 16:34:43 <cfields> qt would be the troublesome one, since it's more easily affected by extra stuff laying around
 65 2015-05-21 16:35:29 <wumpus> hm, test_bitcoin started hanging here
 66 2015-05-21 16:36:08 <wumpus> (system under heavy load - so this is probably the travis issue)
 67 2015-05-21 16:36:27 <cfields> wumpus: gdb --pid `pidof test_bitcoin`, should show you what it's crunching on
 68 2015-05-21 16:36:40 <cfields> i'm sure you were aware, though :)
 69 2015-05-21 16:44:51 <wumpus> yes, it's in scheduler_tests
 70 2015-05-21 16:45:51 <wumpus> src/test/scheduler_tests.cpp:109 (the join call)
 71 2015-05-21 16:46:37 <wumpus> so after the fix, the test is broken the other way around, instead of waiting too little it waits too long
 72 2015-05-21 16:47:56 <wumpus> all the threads have quit, except one (number 46) which is stuck at #2  0x000055555581ff5c in CScheduler::serviceQueue (this=0x7fffffffc210) at scheduler.cpp:42
 73 2015-05-21 16:51:28 <wumpus> oooh... stepping into that thread what it sees is: stopRequested=false, stopWhenEmpty=false, looks like it never got the memo?
 74 2015-05-21 16:52:42 <wumpus> I have a gut feeling: serviceQueue() sets those two flags to false at the beginning; I think this thread was late to the party and cleared those flags. Not every thread should be doing this...
 75 2015-05-21 16:56:41 <wumpus> removing those lines from the top of serviceQueue appears to have solved the issue, at least locally
 76 2015-05-21 17:44:28 <wumpus> https://github.com/bitcoin/bitcoin/pull/6171
 77 2015-05-21 17:52:34 <michagogo> cfields: hm
 78 2015-05-21 17:53:02 <michagogo> If I on-target into it and rm -rf /home/ubuntu/{build,cache,out.install}
 79 2015-05-21 17:53:08 <michagogo> would that work?
 80 2015-05-21 17:53:30 <michagogo> (since there shouldn't be any other packages installed, I'd think that would be the extent of the changes?)
 81 2015-05-21 17:54:21 <cfields> michagogo: for 0.9, i really can't remember what stuff conflicted. but i do remember gavin banging his head against the wall because his re-used env didn't produce the same results
 82 2015-05-21 17:54:43 <michagogo> cfields: but he was using one VM with a lot of different packages installed, wasn't he?
 83 2015-05-21 17:54:53 <cfields> yea
 84 2015-05-21 17:54:57 <michagogo> Because he was on a Mac and didn't have apt-cacher
 85 2015-05-21 17:55:36 <michagogo> In this case it's a clean VM, that has only the same packages that would be installed for the other builds
 86 2015-05-21 17:55:45 <michagogo> or rather, doesn't have any packages that wouldn't be installed
 87 2015-05-21 17:56:15 <michagogo> Only question is whether or not there's anything that could affect the build besides packages and ~/*
 88 2015-05-21 17:56:39 <cfields> michagogo: there's an easy way to find out :)
 89 2015-05-21 17:56:47 <cfields> wumpus: nice job hunting that down
 90 2015-05-21 17:57:17 <michagogo> Well, yeah... just means that it'll be a very long build of qt wasted.
 91 2015-05-21 18:05:28 <michagogo> wumpus: hm, I thought you said the OS X intermediates weren't deterministic? I match your deps.
 92 2015-05-21 18:05:29 <cfields> wumpus: to clarify though, doesn't that mean that new jobs are still being started after stop() has been called?
 93 2015-05-21 18:09:15 <michagogo> ...I feel really stupid right now
 94 2015-05-21 18:09:25 <michagogo> I went back to the previous gbuild line and added -i
 95 2015-05-21 18:09:33 <michagogo> ...but I forgot to change the yml filename
 96 2015-05-21 18:09:51 <cfields> heh
 97 2015-05-21 19:22:25 <gmaxwell> cfields: yup. sounds right-- though if you're going to go through the trouble of putting it behind a DEFINE, I'd include it in secp256k1.c.
 98 2015-05-21 19:29:26 <cfields> gmaxwell: ok
 99 2015-05-21 19:29:39 <cfields> gmaxwell: there is the issue of endian-ness to worry about, though, no?
100 2015-05-21 19:31:41 <gmaxwell> cfields: indeed, though there are mostly reliable byteorder macros. ... use that and have an additional define that can be manually set if its gets it wrong?  All we can do is best effort, I think.
101 2015-05-21 19:34:06 <cfields> gmaxwell: i meant:  ./gen_context on LE builder for BE target. It's then stored by the builder in LE as a char array, wouldn't the BE target read it in backwards?
102 2015-05-21 19:42:48 <gmaxwell> cfields: hm. I had thought it was read with just shifts and masks. But irritatingly it is only at the byte level. The generator should emit the output with a GE_CONST like macro.
103 2015-05-21 19:43:13 <gmaxwell> (I'd mentioned GE_CONST to tdlinux but then thought it must not be needed when he didn't use it. :) )
104 2015-05-21 19:43:46 <cfields> gmaxwell: what would that macro look like? One based on its storage type, you mean?
105 2015-05-21 19:43:48 <gmaxwell> e.g. it should write a header that wraps every word in a byteswapping macro like geconst does (though ge const also does unpacking)
106 2015-05-21 19:45:57 <michagogo> It's still upgrading the vm for the i386 linux build (the first of the two)
107 2015-05-21 19:46:01 <cfields> well then we're back to the header being group-type dependent, no?
108 2015-05-21 19:47:07 <gmaxwell> cfields: e.g. the macro splits the constants into bytes and reassembles the numbers.
109 2015-05-21 19:47:26 <gmaxwell> oh hey there already is a SECP256K1_FE_STORAGE_CONST
110 2015-05-21 19:47:27 <gmaxwell> tada.
111 2015-05-21 19:47:29 <gmaxwell> it should use that.
112 2015-05-21 19:48:44 <wumpus> if you use the right data type, instead of bytes, won't the C compiler take care of the byte swapping itself?
113 2015-05-21 19:49:05 <wumpus> (or probaly, I am misunderstanding what you're trying to do)
114 2015-05-21 19:50:07 <cfields> gmaxwell: ah, i see what you mean. That splits to 32bits when necessary, so it can be stored always as 64bit
115 2015-05-21 19:50:08 <cfields> (i think)
116 2015-05-21 19:51:04 <cfields> wumpus: problem here (as i understand it) is that the data type varies based on the runtime implementation used
117 2015-05-21 19:51:29 <wumpus> runtime? no
118 2015-05-21 19:51:34 <wumpus> 32 or 64 bit is configure time
119 2015-05-21 19:52:05 <wumpus> SECP256K1_FE_STORAGE_CONST in the 64-bit case merges two 32-bit words per slot, in 32-bit case it's just a simple struct initializer wrapper
120 2015-05-21 19:52:16 <wumpus> (just as you need,I think)
121 2015-05-21 19:52:57 <cfields> wumpus: yes, sorry.. configure time. but the current discussion is how to generate static storage data independent of the config
122 2015-05-21 19:52:59 <wumpus> a matter of including the right field_*.h file which depends on configure
123 2015-05-21 19:54:02 <wumpus> and then using SECP256K1_FE_STORAGE_CONST with 8 32-bit values, it will compile to the type actually used
124 2015-05-21 19:54:54 <wumpus> there should be zero need for byteswap macros here
125 2015-05-21 19:55:36 <cfields> wumpus: agreed. I'll take a stab at it that way.
126 2015-05-21 20:59:23 <shamoon> can i send a multisig tx with an OP_RETURN?
127 2015-05-21 21:03:04 <michagogo> shamoon: what exactly do you mean by "a multisig tx"?
128 2015-05-21 21:03:43 <shamoon> michagogo: i'm not 100% sure. basically, so that either one of 2 parties can receive the funds
129 2015-05-21 21:03:51 <michagogo> Er, what?
130 2015-05-21 21:03:54 <shamoon> address
131 2015-05-21 21:03:55 <shamoon> not tx
132 2015-05-21 21:03:57 <michagogo> That's a 1-of-2 multisig
133 2015-05-21 21:04:15 <michagogo> OP_RETURN is irrelevant
134 2015-05-21 21:04:55 <michagogo> OP_RETURN is a way to burn 0 or more satoshis
135 2015-05-21 21:04:55 <shamoon> how can i create a raw TX
136 2015-05-21 21:05:01 <shamoon> that's 1-of-2
137 2015-05-21 21:05:04 <shamoon> address
138 2015-05-21 21:05:09 <shamoon> AND have an OP_RETURN as an output
139 2015-05-21 21:05:33 <michagogo> shamoon: so you want a transaction with 2 outputs, one OP_RETURN and one multisig?
140 2015-05-21 21:05:38 <shamoon> yes
141 2015-05-21 21:06:02 <Luke-Jr> shamoon: why do you think this is useful?
142 2015-05-21 21:06:03 <michagogo> You just create the multisig (P2SH) address and do the same thing that you would do if you were sending to a P2PKH address
143 2015-05-21 21:06:09 <shamoon> interesting
144 2015-05-21 21:06:10 <michagogo> but why are you doing this?
145 2015-05-21 21:07:05 <shamoon> not sure yet - just learning more about how the protocol works
146 2015-05-21 21:07:11 <shamoon> how can i get the "key" to put in a tx?
147 2015-05-21 21:07:14 <shamoon> sorry - address
148 2015-05-21 21:07:19 <shamoon> addmultisigaddress
149 2015-05-21 21:07:33 <michagogo> you want createmultisig or something like that, I think
150 2015-05-21 21:07:43 <michagogo> that rpc is to add a multisig address to the wallet
151 2015-05-21 21:08:03 <Luke-Jr> shamoon: you could just as well make it a p2sh 1-of-3 and have the hash you're committing to be the multisig
152 2015-05-21 21:08:33 <Luke-Jr> slightly abuses the checkmultisig, but probably better for the network
153 2015-05-21 21:08:49 <shamoon> how do i get the "key"?
154 2015-05-21 21:10:13 <shamoon> Luke-Jr: michagogo
155 2015-05-21 21:10:25 <michagogo> That's a public key
156 2015-05-21 21:10:49 <michagogo> If you're working with the Bitcoin Core wallet, I think the getaddrinfo rpc will give you that
157 2015-05-21 21:11:07 <michagogo> You're doing all this on testnet, right?
158 2015-05-21 21:11:09 <belcher> pure multisig is nonstandard i thought? it would end up slower for his transactions to confirm
159 2015-05-21 21:11:29 <michagogo> I think up to m-of-3 is standard
160 2015-05-21 21:11:36 <shamoon> bitcoin-cli addmultisigaddress 1 <["1","2"]>
161 2015-05-21 21:11:38 <shamoon> yes, testnet
162 2015-05-21 21:12:21 <shamoon> $ bitcoin-cli getaddrinfo
163 2015-05-21 21:12:21 <shamoon> error: {"code":-32601,"message":"Method not found"}
164 2015-05-21 21:12:24 <Luke-Jr> belcher: there is no reason to use bare multisig
165 2015-05-21 21:12:34 <belcher> yes
166 2015-05-21 21:12:44 <shamoon> dumpprivkey
167 2015-05-21 21:13:06 <Luke-Jr> shamoon: no
168 2015-05-21 21:13:56 <michagogo> no, you need the public key, not private
169 2015-05-21 21:14:05 <michagogo> maybe getaddressinfo?
170 2015-05-21 21:14:12 <michagogo> Look at the list for something like tha
171 2015-05-21 21:14:13 <michagogo> t
172 2015-05-21 21:15:36 <michagogo> Oh, I think it's actually validateaddress
173 2015-05-21 21:15:47 <shamoon> found it
174 2015-05-21 21:16:05 <michagogo> so yeah, validateaddress will give you the pubkey
175 2015-05-21 21:16:19 <michagogo> then you want to use that with createmultisig
176 2015-05-21 21:16:51 <shamoon> thanks!
177 2015-05-21 21:16:55 <shamoon> you guys rock!
178 2015-05-21 21:19:21 <shamoon> what counts as a valid pubkey?
179 2015-05-21 21:20:01 <michagogo> erm, I guess 04 and 64 bytes or 02/03 and 32 bytes?
180 2015-05-21 21:20:27 <michagogo> (or is it 02+64 or 03/04+32? don't remember)
181 2015-05-21 21:21:51 <michagogo> ...finally, the linux 64-bit vm finished upgrading
182 2015-05-21 21:21:58 <michagogo> (the second one)
183 2015-05-21 21:42:56 <gmaxwell> wumpus: the only thing where byteswapping matters is the sha256 implementation when using the dummy build config.
184 2015-05-21 22:00:29 <cfields> gmaxwell: you happen to have any easy way to check what the correct values should be?
185 2015-05-21 22:01:23 <cfields> I've implemented it as you suggested, but it crashes at runtime. Need to check what's getting crossed up
186 2015-05-21 22:03:07 <gmaxwell> just printf %x the structure members at runtime is easiest.  (I mean, I can compute the values in sage but the library already does it).
187 2015-05-21 22:03:22 <gmaxwell> what the crash you're getting?
188 2015-05-21 22:03:45 <gmaxwell> (having wrong values is frighteningly likely to just work, but produce incorrect results.)
189 2015-05-21 22:05:39 <cfields> secp256k1_ecdsa_sig_sign at tests.cpp:140
190 2015-05-21 22:06:12 <cfields> ok, i'll mess around with some printfs. hopefully i haven't managed to break the --disable-ecmult-static-context case
191 2015-05-21 22:06:30 <gmaxwell> just drop your printfs in a clean tree. :)
192 2015-05-21 22:22:14 <TD-Linux> cfields, rather than the big byte array, I could do an explicit population of the struct members instead
193 2015-05-21 22:23:02 <cfields> TD-Linux: yea, see the discussion above. that's what i'm working on atm
194 2015-05-21 22:34:38 <cfields> TD-Linux: here's my temp hacking: https://github.com/theuni/secp256k1/commit/f5ed0253c70981c74ef0a965c2015b4486768dbc
195 2015-05-21 22:45:15 <TD-Linux> what's up with the order swap in SECP256K1_FE_STORAGE_CONST?
196 2015-05-21 22:45:58 <cfields> yep, that was the problem
197 2015-05-21 22:45:59 <cfields> works now
198 2015-05-21 22:46:39 <cfields> unsure why it's swapped that way, but i had to swap going the other way as well
199 2015-05-21 22:47:16 <gmaxwell> it makes it BE like the SECP256K1_FE_CONST().
200 2015-05-21 22:47:49 <gmaxwell> the only effect is that SECP256K1_FE_CONST and SECP256K1_FE_STORAGE_CONST can work with the same input data.
201 2015-05-21 22:48:30 <gmaxwell> (the FE const format is an implementation specific over-complete number representation; unpacking it is not entirely trivial)
202 2015-05-21 22:48:35 <cfields> generated header looks like: http://pastebin.com/raw.php?i=RitMbeq9
203 2015-05-21 22:49:37 <TD-Linux> more compact than my byte spam :)
204 2015-05-21 22:57:06 <cfields> TD-Linux: you want to clean that up and take it? or i can clean it up and add it to yours
205 2015-05-21 22:58:59 <TD-Linux> sure, I can update my pull request
206 2015-05-21 22:59:21 <TD-Linux> do you mind if I squash it?
207 2015-05-21 22:59:32 <cfields> nope, whatever's easiest