1 2014-08-06 00:47:36 <alfacent> What does the "C" in CCriticalSection mean? Does it mean current?
  2 2014-08-06 00:49:28 <alfacent> hi sabfer
  3 2014-08-06 00:49:53 <alfacent> hi fanquake
  4 2014-08-06 00:50:28 <fanquake> morning
  5 2014-08-06 00:50:53 <alfacent> What does the "C" in CCriticalSection mean? Does it mean current?
  6 2014-08-06 00:51:26 <sabfer> alfacent: hi!
  7 2014-08-06 01:14:21 <alfacent> What does the "C" in CCriticalSection mean? Does it mean current?
  8 2014-08-06 03:10:50 <andytoshi> what was the motivation for having a builtin ripemd160 impl? what was used before?
  9 2014-08-06 03:15:57 <gmaxwell> andytoshi: we're moving in a direction where we'll be able to be built without openssl.
 10 2014-08-06 03:16:43 <gmaxwell> (I think right now we are only missing a random pool, libsecp256k1, and the KDF/crypto for wallet encryption for being able to build bitcoind without openssl)
 11 2014-08-06 03:20:38 <andytoshi> coolio
 12 2014-08-06 03:20:54 <Belxjander> gmaxwell: so basically migrating the essential cryptographic routines from the libraries into the main source tree?
 13 2014-08-06 03:21:11 <andytoshi> on the rust side of things i am thinking of submitting a ripemd160 implementation to rust-crypto, but i figured i should poke my head in at what you guys were doing..
 14 2014-08-06 03:24:29 <gmaxwell> andytoshi: certantly a dependency on a standard system library is way better than ... openssl. :)
 15 2014-08-06 03:24:46 <andytoshi> yeah, i'm very much trying to avoid openssl :)
 16 2014-08-06 03:25:01 <andytoshi> i subscribe to the RSS feed for 'openssl valhalla' and have been horrified over the last several months..
 17 2014-08-06 03:25:36 <gmaxwell> Belxjander: s/libraries/openssl/  and really, our dependencies there are small. Since we're already going to go to libsecp256k1 for performance reasons (>6x faster than openssl), the rest is pretty trivial.
 18 2014-08-06 03:26:31 <gmaxwell> Openssl has also been a huge liability that has had negative consequences for the system in the past (e.g. that all bitcoin nodes must accept invalid signature encodings is a consequence of hidden behavior in openssl)
 19 2014-08-06 03:26:46 <E-Rage> sipa: around?
 20 2014-08-06 07:29:34 <gribble> The operation succeeded.
 21 2014-08-06 07:29:34 <sipa> ;;later tell alfacent it's old satoshi style, and means 'class'
 22 2014-08-06 07:30:14 <sipa> E-Rage: now i am
 23 2014-08-06 07:52:10 <wumpus> cfields: pong
 24 2014-08-06 08:14:21 <wumpus> Jouke_: any updates on #4604?
 25 2014-08-06 08:15:31 <Jouke_> wumpus: I'll try to get back to you later today
 26 2014-08-06 08:15:39 <wumpus> if not I'll try some experiments of myself with json and large data
 27 2014-08-06 08:16:34 <stonecoldpat> wumpus: do you know a good method to convert json tx back to rawtransactions (into hex?)
 28 2014-08-06 08:18:43 <wumpus> stonecoldpat: well in general it may not always be losslessly possible, any small change may invalidate the signature, and the re-encoding of parsed data into a transaction hex may encode slightly differently than the original tx
 29 2014-08-06 08:18:59 <wumpus> stonecoldpat: I suggest just storing the hex
 30 2014-08-06 08:19:49 <wumpus> unless you're manipulating transactions that aren't signed yet, then it's a valid use case
 31 2014-08-06 08:20:05 <stonecoldpat> wumpus: i was about to say yeah i'm modifying transactions before they are signed
 32 2014-08-06 08:20:15 <Jouke_> wumpus: the problem is: I have no experience with gdb
 33 2014-08-06 08:20:18 <stonecoldpat> wumpus: ive been using brainwallet, but would prefer a more uatomated way
 34 2014-08-06 08:21:18 <wumpus> stonecoldpat: git master includes the 'bitcoin-tx' utility which can be used for manipulating raw transactions
 35 2014-08-06 08:21:54 <stonecoldpat> wumpus: ill check that out now thank you! :)
 36 2014-08-06 08:22:03 <wumpus> Jouke_: I do, but I don't have any large wallets available for testing, but I can of course insert some synthetic data, that will work if it's just a problem with communciation
 37 2014-08-06 08:39:21 <gdm85> wumpus: I also looked briefly into that, basically with gdb one needs to know also which thread to look at
 38 2014-08-06 08:39:27 <wumpus> Jouke_: ok - managed to reproduce it by making listtransactions return a requested number of random transaction records
 39 2014-08-06 08:40:02 <gdm85> well, looks like you're already used to do that :)
 40 2014-08-06 08:40:20 <wumpus> gdm85: well not necessarily, you can set a breakpoint on listtransactions, and any thread that hits it will trigger that
 41 2014-08-06 08:41:05 <gdm85> wumpus: I honestly admit that too many years of IDEs didn't let my gdb skills advance that far..but yeah, good to know, I will check that in future
 42 2014-08-06 08:41:13 <wumpus> after about 300000 records it starts giving the 'error: no response from server' error, however the time taken to do the query keeps scaling up after that
 43 2014-08-06 08:41:29 <gdm85> wumpus: you have already an insight on root cause?
 44 2014-08-06 08:42:01 <gdm85> oh, so response time is not linearly increasing? maybe too much memory being allocated?
 45 2014-08-06 08:42:15 <wumpus> gdm85: gdb looks errible initially if you're used to IDEs, however it's one  of the most flexible and powerful debugging tools in existence so it does pay to learn it
 46 2014-08-06 08:42:41 <gdm85> usually with gdb I just go as far to understand where a SEGFAULT is in the source code
 47 2014-08-06 08:43:02 <gdm85> but yeah, I am sure it's one of those valuable "beast" toolkits
 48 2014-08-06 08:43:17 <wumpus> gdm85: not entirely; but it happens *after* the json data structure is built in memory and before writing to the network
 49 2014-08-06 08:45:46 <gdm85> I thought of memory starvation when I saw this problem, but never checked the source
 50 2014-08-06 08:46:28 <michagogo> ...ayfkm
 51 2014-08-06 08:46:45 <michagogo> gavinandresen cfields wumpus: http://9to5mac.com/2014/08/04/apple-changing-gatekeeper-app-signing-rules-in-os-x-10-9-5-yosemite-could-break-some-apps/
 52 2014-08-06 08:47:01 <gdm85> could also be related to socket timeout values
 53 2014-08-06 08:50:46 <wumpus> I'm fairly sure that isn't it; if it was, the request time would cap out at some point when requestig more data
 54 2014-08-06 08:51:02 <wumpus> instead, it takes more time but returns less (no) data :-)
 55 2014-08-06 08:52:22 <wumpus> anyhow, the RPC system is far from optimized for handling large amounts of data
 56 2014-08-06 08:52:58 <wumpus> for example instead of streaming the JSON data out, it first builds a string and writes that out
 57 2014-08-06 08:53:56 <gdm85> oh, I see
 58 2014-08-06 08:54:17 <michagogo> And the debug window is even less optimized :-P
 59 2014-08-06 08:54:30 <gdm85> probably buffered io would address #4604
 60 2014-08-06 08:54:35 <wumpus> so even if this issue is fixed, you should regard this as a warning that you're up against the upper scaling limits
 61 2014-08-06 08:55:20 <michagogo> Locked up the whole GUI the other day when I tried inadvertently to fetch 2 million hex digits of rickroll
 62 2014-08-06 08:55:20 <wumpus> michagogo: but that's less of a problem, humans aren't optmized to process large amounts of informations either
 63 2014-08-06 08:55:48 <wumpus> michagogo: at a certain point there's just no useful thing to do; maybe we should handle it like numpy and print large arrays abbreviated
 64 2014-08-06 08:55:56 <gdm85> wumpus: indeed
 65 2014-08-06 08:56:13 <DiceCoin> Hey
 66 2014-08-06 08:56:23 <michagogo> RPC still worked, but the GUI locked up for several minutes
 67 2014-08-06 08:56:25 <DiceCoin> Can anyone help me?
 68 2014-08-06 08:56:28 <iwilcox> DiceCoin: Your question is off-topic here.
 69 2014-08-06 08:56:34 <DiceCoin> What is?
 70 2014-08-06 08:56:39 <michagogo> wumpus: NAK, if I understand correctly
 71 2014-08-06 08:56:47 <gdm85> iwilcox: his nickname, not the question :P
 72 2014-08-06 08:56:55 <DiceCoin> I havent even asked the question yet.
 73 2014-08-06 08:57:01 <iwilcox> You asked in #bitcoin.
 74 2014-08-06 08:57:02 <michagogo> In many places truncated data is worse than no data at all
 75 2014-08-06 08:57:05 <DiceCoin> Oh
 76 2014-08-06 08:57:09 <DiceCoin> I got no answer there :/
 77 2014-08-06 08:57:17 <DiceCoin> You dont happen to know iwilcox, do you?
 78 2014-08-06 08:57:17 <michagogo> It should just fail, and not silently.
 79 2014-08-06 08:57:19 <wumpus> michagogo: ok, printing no data at all is also acceptable way to handle 'too much data'
 80 2014-08-06 08:57:26 <iwilcox> DiceCoin: You'll get completely ignored here.
 81 2014-08-06 08:57:34 <wumpus> michagogo: but sometimes it's useful to print the first few records with ... after that
 82 2014-08-06 08:57:46 <wumpus> michagogo: that's not 'failing silently'
 83 2014-08-06 08:57:47 <michagogo> wumpus: I guess it depends on the call
 84 2014-08-06 08:57:54 <wumpus> anyhow I don't feel like argueing this
 85 2014-08-06 08:58:04 <wumpus> for some reason I always get into arguments with you about stupid things
 86 2014-08-06 08:58:13 <michagogo> Hm?
 87 2014-08-06 08:58:55 <gdm85> iwilcox: I think question needs to be development-related, and about development of the Bitcoin project
 88 2014-08-06 08:59:01 <gdm85> ops.. DiceCoin ^
 89 2014-08-06 08:59:39 <wumpus> michagogo: to be clear I'm talking about what is shown in the GUI, obviously truncating what is returned over the network is not acceptable
 90 2014-08-06 09:00:34 <michagogo> wumpus: of course.
 91 2014-08-06 09:01:01 <michagogo> But I think there *is* a limit on the length of the input box
 92 2014-08-06 09:01:33 <michagogo> Which has annoyed me a few times when a paste got truncated and failed in various weird ways
 93 2014-08-06 09:01:50 <wumpus> yes, there is a limit, I think 64k or so
 94 2014-08-06 09:01:54 <michagogo> (Until I found the ruby class on the wiki for connecting to rpc)
 95 2014-08-06 09:02:23 <wumpus> but it makes sense that Uis have "DoS" limits like that; after that, rendering would become prohobitively slow as well as memory used in font processing etc...
 96 2014-08-06 09:02:38 <michagogo> True
 97 2014-08-06 09:02:57 <michagogo> Truncation is annoying, though, in many cases
 98 2014-08-06 09:03:06 <wumpus> it's better than segfaulting.
 99 2014-08-06 09:03:11 <michagogo> (I guess for some calls it would be fine, but not all)
100 2014-08-06 09:03:17 <michagogo> wumpus: well, yes
101 2014-08-06 09:03:30 <michagogo> It's just a question of partial return or no return
102 2014-08-06 09:03:33 <wumpus> there are always limits to the range of applications for a tool
103 2014-08-06 09:03:49 <michagogo> Now I just have a batch file that runs irb with a script that sets up the rpc class and the clipboard gem :P
104 2014-08-06 09:06:08 <wumpus> what could work is a multi-line input
105 2014-08-06 09:06:34 <wumpus> qt can handle quite large buffers providing not everything is on one line
106 2014-08-06 09:07:39 <wumpus> or you could add a warning box if the limit is hit
107 2014-08-06 09:09:32 <wumpus> or detect large pastes and show just (large data), where the actual data is not shown but only inserted when you hit enter, you may need to immplement your own input widget for that though
108 2014-08-06 09:10:10 <wumpus> you could do the same when large data is returned, just show a 'copy to clipboard' button but not the actual data
109 2014-08-06 09:13:18 <michagogo> wumpus: now that's an idea
110 2014-08-06 09:13:56 <michagogo> Though maybe an option to open a pop-up with a larger text box with the whole thing? *shrug*
111 2014-08-06 09:13:59 <michagogo> I
112 2014-08-06 09:14:08 <wumpus> maybe add a 'send to soundcard' button too ;-)
113 2014-08-06 09:14:11 <michagogo> I mean, you can always just paste into notepad or something
114 2014-08-06 09:14:20 <michagogo> wumpus: :P
115 2014-08-06 09:14:41 <sipa> wumpus: and have an 'upgrade to bitcoin core pro' button which enables 'send to videocard' ?
116 2014-08-06 09:15:07 <michagogo> wumpus: how about a "send to sound card" option special-cased for that specific getrawtransaction
117 2014-08-06 09:15:11 <wumpus> sipa: hahahhaa, yes, now in 3D
118 2014-08-06 09:15:24 <michagogo> Ooh, I know!
119 2014-08-06 09:15:28 <dsnrk> 
ACTION thinks the RPC console is too user accessible anyway

120 2014-08-06 09:15:46 <michagogo> Use a DHT to track transactions that should have the sound card option!
121 2014-08-06 09:15:50 <michagogo> 
ACTION runs away

122 2014-08-06 09:15:54 <wumpus> dsnrk: there should at least be an alcohol lock on it! :p
123 2014-08-06 09:16:19 <sipa> yeah, there should be a 2048 game you need to win to unlock it
124 2014-08-06 09:16:26 <wumpus> make people solve a few simple equations first, and draw a straight line, before openining it
125 2014-08-06 09:16:27 <wumpus> or that
126 2014-08-06 09:16:39 <sipa> also, to use as entropy source for keygen
127 2014-08-06 09:16:47 <dsnrk> wumpus: well, yes. it's an unpopular opinion but there's a lot of casual instructions "just go here and type dumpprivkey in the window.." which lead to some easy footgunning.
128 2014-08-06 09:17:31 <michagogo> One possibility would be to define a set of "dangerous" RPCs that are only available with a config option
129 2014-08-06 09:18:22 <dsnrk> if/when BIP32 makes it into the client the dumpprivkey RPC should be disabled, certainly.
130 2014-08-06 09:18:25 <michagogo> (I think this conversation may have already happened$
131 2014-08-06 09:18:38 <michagogo> s/\$/)/
132 2014-08-06 09:18:46 <wumpus> dsnrk: I agree with you on one hand, but on the other hand, I want the powerful options to be available for developers and such easily
133 2014-08-06 09:18:59 <wumpus> dsnrk: bitcoin-qt isn't really for casual users anyway
134 2014-08-06 09:19:32 <dsnrk> wumpus: at the moment it's the only client that's not doing security stupid things, I'd prefer to be able to recommend it.
135 2014-08-06 09:19:58 <wumpus> dsnrk: that said, I'm ok with adding a big ugly warning to the debug console, I mean even firefox has a 'this breaks your warranty', then again we have no warranty either way :P
136 2014-08-06 09:20:27 <wumpus> the send tab is just as dangerous...
137 2014-08-06 09:20:59 <wumpus> send to the wrong person, or send the wrong amount, etc... it's not a program you want to use if you're drunk or clueless
138 2014-08-06 09:21:07 <dsnrk> I disagree. a user on reddit before was being told it was OK to export a private key from his electrum wallet and import it into a blockchain.info wallet.
139 2014-08-06 09:21:27 <dsnrk> which is just pure mouth-foaming insanity.
140 2014-08-06 09:21:44 <wumpus> at least the wallet isn't... a node-only bitcoind is quite safe to play around with
141 2014-08-06 09:22:11 <dsnrk> the fact that people aren't scared of private keys but are of sending says something is horribly wrong with the way interfaces work.
142 2014-08-06 09:22:20 <michagogo> dsnrk: +1
143 2014-08-06 09:24:01 <wumpus> or even worse, forget that you made your backup 100 transactions ago and not 99...
144 2014-08-06 09:25:00 <dsnrk> so make the keypool 9999999. that's nothing compared with people blasting away their coins into change addresses they don't know they own.
145 2014-08-06 09:25:10 <wumpus> it's like a whole weapon arsenal aimed at your foot
146 2014-08-06 09:27:41 <dsnrk> wallet software is like victorian machinery. big spinning wheels and gears everywhere ready to take your head off.
147 2014-08-06 09:28:34 <wumpus> dsnrk: anyhow, if want to make the wallet UI safer, contributions in that regard are certainly welcome
148 2014-08-06 09:29:11 <wumpus> dsnrk: exactly
149 2014-08-06 09:29:53 <dsnrk> wumpus: I'll add it to my wish list.
150 2014-08-06 09:30:40 <sipa> a node-only bitcoind has no secret data :)
151 2014-08-06 09:31:27 <wumpus> sipa: yes, it's so refreshing
152 2014-08-06 09:34:01 <michagogo> sipa: well, except the IP addresses of its peers :-P
153 2014-08-06 09:34:47 <dsnrk> and the contents of SPV peers wallets.
154 2014-08-06 09:36:16 <wumpus> that's private data, but not 'secret' as such
155 2014-08-06 09:37:00 <dsnrk> still wouldn't make people happy if you captured and published it.
156 2014-08-06 09:37:13 <wumpus> after all, data revealed to random peers cannot really be considered secret
157 2014-08-06 09:38:38 <dsnrk> wonder if people know it's not secret.
158 2014-08-06 09:47:37 <dsnrk> no that's silly. people still don't think that blockchain.info can steal from their wallet at will.
159 2014-08-06 09:53:52 <Belxjander> dsnrk: well considering the semi random narture of wallet generation...
160 2014-08-06 09:54:32 <dsnrk> semi random?
161 2014-08-06 09:54:43 <Belxjander> I wonder how hard it would be for partial reversal of addresses against inputs and "tag" people that way following the money
162 2014-08-06 09:55:06 <Belxjander> dsnrk: I don't consider any digital prng to be truly ransdom
163 2014-08-06 09:55:18 <sipa> no, it's pseudo random :)
164 2014-08-06 09:55:24 <sipa> you know, the P stands for pseudo :p
165 2014-08-06 09:56:32 <dsnrk> Belxjander: we all know blockchain.info's random is often anything but.
166 2014-08-06 09:56:49 <dsnrk> Belxjander: check their commit log and you'll see their latest fumble.
167 2014-08-06 09:58:08 <sipa> Belxjander: do you mean that semirandomness of keys could be used to help tracking coins?
168 2014-08-06 09:58:17 <sipa> s/coins/identities/
169 2014-08-06 09:59:10 <dsnrk> knowing the private key doesn't help you find anything about the owner.
170 2014-08-06 09:59:22 <dsnrk> there's much, much easier ways to identify people in Bitcoin.
171 2014-08-06 10:00:31 <dsnrk> google does the job most of the time.
172 2014-08-06 10:05:24 <wumpus> how would that work anyway? even *if* you could detect a pattern in the randomness of the private keys, that wouldn't translate to a detectable pattern in the public keys used
173 2014-08-06 10:06:09 <Belxjander> wumpus: not interested in the patterns so much as making a whole massive amount of keys and seeing if any pubkey addresses would map to existing addresses
174 2014-08-06 10:06:34 <gmaxwell> if someone is guessing your private keys you have problems worse than privacy…
175 2014-08-06 10:06:40 <wumpus> exactly
176 2014-08-06 10:06:59 <Belxjander> well my own keys have been updated twice already
177 2014-08-06 10:07:12 <Belxjander> along with the address space attached
178 2014-08-06 10:08:41 <dsnrk> huh>
179 2014-08-06 12:20:09 <gdm85> wumpus: regarding limits of an application: buffered IO solves that nicely
180 2014-08-06 12:20:35 <gdm85> and I politely disagree that truncation should be acceptable :P better an error than a lie
181 2014-08-06 12:21:26 <wumpus> gdm85: what are you talking about?
182 2014-08-06 12:21:48 <wumpus> gdm85: oh, did you read the context of my statements at all?
183 2014-08-06 12:22:04 <gdm85> wumpus: you were talking about the qt gui debug window, right?
184 2014-08-06 12:22:51 <wumpus> for example, if in numpy you have a very large matrix, and you accidentally try to print it in the CLI, you get the outer numbers (or first few rows) with the rest interposed with ...
185 2014-08-06 12:23:46 <wumpus> I think that's a good way of handling unwieldy-large data in a user interface, instead of scrolling for days to print it all...
186 2014-08-06 12:23:55 <gdm85> I was referring to data truncation in API responses, or also in UI without the ellipsis hint of truncation '...'
187 2014-08-06 12:24:02 <gdm85> that would not be acceptable to me, but in that case yeah it's fine
188 2014-08-06 12:24:08 <wumpus> but anyhow, if you have a better implementation I look forward to it, I don't like discussing things like this
189 2014-08-06 12:24:10 <gdm85> you cannot clog up a textbox with too much input
190 2014-08-06 12:24:44 <gdm85> yeah sorry I was not clear
191 2014-08-06 12:24:44 <wumpus> of course you cannot pull the same thing on the network RPC, but I even said that literally.
192 2014-08-06 12:24:57 <gdm85> sure
193 2014-08-06 12:36:48 <wumpus> gdm85: anyhow, did you see https://github.com/bitcoin/bitcoin/pull/4640 ?
194 2014-08-06 12:37:23 <Jouke_> wumpus: building as we speak :)
195 2014-08-06 12:38:04 <gdm85> wumpus: no, I didn't! nice. that sets a hard limit as I see
196 2014-08-06 12:38:04 <wumpus> ok :)
197 2014-08-06 12:38:17 <wumpus> gdm85: no, it removes the limit
198 2014-08-06 12:38:43 <wumpus> it was using the server-side DoS check on the client side as well, which made no sense
199 2014-08-06 12:38:47 <gdm85> oh
200 2014-08-06 12:39:10 <wumpus> 'hey, I requested too much data, let's return an error!' :p
201 2014-08-06 12:40:04 <gmaxwell> lol
202 2014-08-06 12:40:24 <gmaxwell> "help! it did what I asked for! I'm being attacked!"
203 2014-08-06 12:44:11 <gdm85> wumpus: one could also replace those "return HTTP_INTERNAL_SERVER_ERROR" with proper client-side errors (I know, PRs are welcome... :)
204 2014-08-06 12:44:41 <gdm85> although trivial, that would still be an improvement right?
205 2014-08-06 12:46:22 <wumpus> gdm85: but it never gets there anymore for the client
206 2014-08-06 12:46:45 <gdm85> ah, ok
207 2014-08-06 12:51:28 <wumpus> eh and it seems that the return value of ReadHTTPMessage is completely ignored, both by the server and the client
208 2014-08-06 12:56:26 <wumpus> c++ has such a lovely jumble of different error-handling paradigms
209 2014-08-06 13:02:57 <wumpus> you never know what you'll get, will it raise an exception, return an error code, return an error object, or are we old-fashioned and do we set a global errno, or if you're feeling really adventurous, setjmp/longjmp! (no, luckily we don't use the latter one in bitcoind, but some libraries such as libpng use it)... and that's only in its fairly short history, I'm sure it will gain more if we just give it a few more years :-)
210 2014-08-06 13:04:39 <gmaxwell> I recently encountered a library with a whole callback setup that used setjmp longjmp, not just error handling.
211 2014-08-06 13:05:38 <wumpus> a co-routine emulation maybe?
212 2014-08-06 13:06:57 <gmaxwell> yes, pretty much, though it used it everywhere, even for things which really were just callbacks.
213 2014-08-06 13:09:23 <Jouke_> wumpus: I can fetch all the transactions with your PR :)
214 2014-08-06 13:09:29 <wumpus> there are some very interesting applications for setjmp/longjmp, although it gets quite unreadable
215 2014-08-06 13:09:35 <wumpus> Jouke_: cool
216 2014-08-06 13:16:55 <chichov> uhm, how did I get a std::vector<unsigned char> or something similar from CPubKey?
217 2014-08-06 13:17:48 <sipa> to do what?
218 2014-08-06 13:18:05 <sipa> (not that that's a bad idea, but maybe you don't need to)
219 2014-08-06 13:18:26 <chichov> I need a byte array for arbitrary modifications
220 2014-08-06 13:18:35 <chichov> or a hex string, for that matter
221 2014-08-06 13:18:43 <wumpus> chichov: std::vector<unsigned char> bla(pubkey.begin(), pubkey.end())
222 2014-08-06 13:18:51 <chichov> wumpus: much obliged
223 2014-08-06 13:19:02 <jgarzik> gmaxwell, <puke>
224 2014-08-06 13:20:08 <gdm85> gmaxwell: was that some UPX compressor?
225 2014-08-06 13:20:21 <gmaxwell> no, computer algebra system
226 2014-08-06 13:32:41 <jgarzik> gmaxwell, Those sorts of libraries were the bane of my existence, when I worked for MandrakeSoft.  I was building -every- package for 64-bit Alpha CPUs, new at the time.  Any idiocy like longjmp would require manual intervention and porting.
227 2014-08-06 13:33:13 <jgarzik> interpreters that did games like building userspace trampolines were a nightmare
228 2014-08-06 13:33:28 <jgarzik> longjmp city, though at least they had a reason
229 2014-08-06 13:33:34 <gdm85> jgarzik: packages with assembly in their sources?
230 2014-08-06 13:34:04 <jgarzik> gdm85, longjmp is a C routine
231 2014-08-06 13:35:01 <wumpus> trampolines are lots of fun, especially when stacks became non-executable
232 2014-08-06 13:35:05 <gdm85> jgarzik: ah, yes, now I remember
233 2014-08-06 13:38:06 <gmaxwell> wumpus: alas for my GCC nested functions!
234 2014-08-06 13:39:23 <gmaxwell> (no, I've never actually used them— but I've wished their implementation wasn't awful before so that I could have used them)
235 2014-08-06 13:39:32 <wumpus> gmaxwell: oh no!
236 2014-08-06 14:51:42 <cfields> michagogo: re signing, i've got a tree around somewhere that prepares us for that stuff
237 2014-08-06 14:53:37 <wumpus> sipa: so #4498 only adds the policy now; I hadn't noticed that change
238 2014-08-06 14:54:19 <wumpus> thought it also transformed a few files
239 2014-08-06 14:54:26 <warren> btw, did secp256k1 get in yet?
240 2014-08-06 14:54:32 <wumpus> warren: no
241 2014-08-06 14:54:38 <warren> any PR?
242 2014-08-06 14:54:52 <wumpus> cfields has a tree for it, but no PR
243 2014-08-06 14:55:09 <warren> why no PR?
244 2014-08-06 14:55:18 <wumpus> because it's not intended to be added yet
245 2014-08-06 14:56:21 <sipa> soon
246 2014-08-06 14:56:26 <cfields> wumpus: heard anything about font corruption on recent osx builds?
247 2014-08-06 14:56:44 <wumpus> cfields: none at all
248 2014-08-06 14:56:50 <cfields> ok
249 2014-08-06 14:56:51 <warren> cfields: retina or non?
250 2014-08-06 14:57:04 <wumpus> cfields: did anything change there recently?
251 2014-08-06 14:57:15 <cfields> 10.9 retina
252 2014-08-06 14:57:22 <wumpus> I mean, after the 0.9.2.1 fix
253 2014-08-06 14:57:26 <cfields> wumpus: seems to have to do with the unicode slim spaces
254 2014-08-06 14:57:55 <wumpus> cfields: they're not slim, or they're not spaces?
255 2014-08-06 14:57:57 <sipa> wumpus: i moved the 'preview' part to a separate branch
256 2014-08-06 14:57:59 <cfields> wumpus: i'm still trying to track down the exact issue, but i think i'm going to leave it as a TODO for the deps. I suspect that current gitian builds suffer as well.
257 2014-08-06 14:58:38 <wumpus> sipa: ok, makes sense
258 2014-08-06 14:58:44 <cfields> wumpus: they're boxes, like the font can't find the character
259 2014-08-06 14:58:55 <wumpus> cfields: how lame :/
260 2014-08-06 14:59:21 <cfields> wumpus: seems to have to do with the default font selection (again) for osx mavericks. I'm guessing it's probably only visible there
261 2014-08-06 14:59:49 <cfields> also, it doesn't happen when I build native on my 10.9 machine. May have to do with using an SDK that's too low
262 2014-08-06 14:59:54 <wumpus> cfields: it feels to me that macosx really made a regression there
263 2014-08-06 15:00:33 <wumpus> even the most trivial things like Typewriter fonts or spaces start breaking down
264 2014-08-06 15:00:35 <cfields> wumpus: yea, they switched around their font handling to cope with retina, and it seems they didn't account for some necessary back-compat
265 2014-08-06 15:01:16 <cfields> for example, forcing "Courier" as the label fonts makes it work. So it must have to do with the font selection/fallback mechanisms in qt
266 2014-08-06 15:01:54 <cfields> also, qt 5.3[.1] fixed a bunch of osx/mavericks/font bugs. But no luck there, same problem
267 2014-08-06 15:04:59 <wumpus> it's unfortunate that we have to work around this on a case-by-case basis, can't we force Qt to pick a different default font on mac?
268 2014-08-06 15:05:34 <cfields> yea, if we decide that's the way to go. Still trying to track down where the actual bug lies
269 2014-08-06 15:10:06 <cfields> wumpus: do we choose the default font anywhere? I've grepped and it doesn't look that way, just want to make sure I'm not overlooking some qt'ism (xml) somewhere
270 2014-08-06 15:10:11 <jgarzik> wumpus, sipa: what are the remaining blockers for adding libsecp256k1 to bitcoin tree, with build-default-disabled?
271 2014-08-06 15:11:29 <wumpus> cfields: no, we don't change that, I had hoped the operating system would make sane choices there
272 2014-08-06 15:11:36 <cfields> ok, thanks
273 2014-08-06 15:11:45 <wumpus> cfields: the closest we get it setting a font hint, for the addreesses
274 2014-08-06 15:11:51 <cfields> right
275 2014-08-06 15:12:43 <wumpus> jgarzik: I'm not sure, but I leave it up to sipa
276 2014-08-06 15:44:27 <cfields> wumpus: ugh, building against 10.8 sdk fixes
277 2014-08-06 15:45:43 <wumpus> cfields: woohoo
278 2014-08-06 15:46:36 <cfields> heh, just when i thought i had the deps stuff finished up. Will see what the implications of bumping are
279 2014-08-06 15:51:05 <wumpus> I think we already bumped the sdk once for this 'retina' compatibility :(
280 2014-08-06 15:51:33 <wumpus> sometimes feels like we're going in circles
281 2014-08-06 15:51:40 <wumpus> stupid macs
282 2014-08-06 15:52:08 <cfields> yea
283 2014-08-06 15:52:18 <cfields> i tried 10.8 at the time and everything seemed to work fine
284 2014-08-06 15:52:31 <cfields> decided to go with 10.7 for the sake of not changing too much at once
285 2014-08-06 15:53:35 <cfields> looking back, that was probably the wrong call
286 2014-08-06 15:55:21 <wumpus> well no one would sanely expect this
287 2014-08-06 16:32:50 <Guest14323> is there an OP_CHECKMULTISIG expert here?
288 2014-08-06 16:41:07 <justanotheruser> Guest14323: what is your question? It's probably better in #bitcoin
289 2014-08-06 16:45:31 <Guest14323> #bitcoin is way too busy. I have 2of3 multisig, merchant, consumer, and arbiter. There will be three distince tx: a) consumer pays merchant, b) arbiter pays merchant, and c) arbiter pays consumer. Arbiter also pays himself when he is involved.
290 2014-08-06 16:46:15 <Guest14323> Can I have different combinations in the outputs of each tx whereby one public key is all zeros?
291 2014-08-06 16:46:37 <Guest14323> Thereby disallowing the signing of one public key?
292 2014-08-06 16:47:06 <sipa> then just remove it?
293 2014-08-06 16:47:12 <sipa> and do signing with one key less
294 2014-08-06 16:47:23 <Guest14323> So for example, the merchant and the arbiter could sign one tx but the consumer couldn't sign it>
295 2014-08-06 16:47:25 <Guest14323> ?
296 2014-08-06 16:47:41 <sipa> you need to know the public keys of the signers before the crediting payment
297 2014-08-06 16:47:46 <sipa> you can't change the keys afterwards
298 2014-08-06 16:49:50 <Guest14323> the output script would normally be OP_2 PubM PubC PubA OP_3 OP_CHECKMULTISIG
299 2014-08-06 16:50:55 <Guest14323> can I have OP_2 PubM 0 PubA OP_3 OP_CHECKMULTISIG on the tx that pays the merchant?
300 2014-08-06 17:13:36 <maraoz> gmaxwell: could you assign a bip number to https://github.com/bitcoin/bips/pull/89 please? BIP-0045 if possible.
301 2014-08-06 17:17:48 <gmaxwell> maraoz: oh wow, I had no idea that was waiting.
302 2014-08-06 17:17:56 <gmaxwell> Did I miss an email?
303 2014-08-06 17:19:06 <maraoz> I sent you two emails (May 28 and Jul 10). There's no rush anyway, but having a number would help (our current implementation is using 45 as the purpose number in the BIP32 structure)
304 2014-08-06 17:19:43 <maraoz> gmaxwell@gmail.com right?
305 2014-08-06 17:20:48 <gmaxwell> yea. Weird. I see the emails from you in gmail unread.
306 2014-08-06 17:26:24 <maraoz> gmaxwell: no problem.
307 2014-08-06 17:36:14 <michagogo> 17:51:40 <cfields> michagogo: re signing, i've got a tree around somewhere that prepares us for that stuff <-- after linking the article, I looked at the actual Apple doc on the change
308 2014-08-06 17:36:34 <michagogo> Looks like, despite what the article said, there's no need to build with Mavericks or anything like that
309 2014-08-06 17:36:44 <michagogo> It just needs to be signed on there
310 2014-08-06 17:36:50 <michagogo> (I hope Gavin has Mavericks...)
311 2014-08-06 17:37:11 <cfields> michagogo: it has to be reorganized though
312 2014-08-06 17:37:19 <michagogo> ah, does it?
313 2014-08-06 17:37:30 <michagogo> 
ACTION looks again

314 2014-08-06 17:37:52 <cfields> yea, frameworks have to be signed per-version
315 2014-08-06 17:37:58 <cfields> and a few other little nits
316 2014-08-06 17:40:15 <michagogo> 19:50:52 <Guest14323> can I have OP_2 PubM 0 PubA OP_3 OP_CHECKMULTISIG on the tx that pays the merchant?
317 2014-08-06 17:40:30 <michagogo> Uh, that's identical to OP_2 PubM PubA OP_2 OP_CHECKMULTISIG
318 2014-08-06 17:40:57 <Guest14323> thx
319 2014-08-06 17:41:02 <michagogo> And the scriptPubKey (the conditions for spending the output) are set when you send funds to the multisig address
320 2014-08-06 17:41:15 <Guest14323> right
321 2014-08-06 17:41:17 <michagogo> Guest14323: I'm not sure what you're trying to do here,
322 2014-08-06 17:41:27 <michagogo> See the last part of the topic, please.
323 2014-08-06 17:41:57 <Guest14323> have multiple spend tx from the same multisig address. the contract can have different outcomes where some parties don't get paid
324 2014-08-06 17:43:09 <michagogo> Uh, no. If you send to a multisig address of 2-of-[M,C,A] then those funds can be spent by any 2 of them
325 2014-08-06 17:43:50 <michagogo> Guest14323: But zoom out. What are you planning to use this transaction for?
326 2014-08-06 17:46:30 <Guest14323> the multisig address contains payout funds for a contract. the contract can have multiple outcomes, so there is a separate tx for each outcome.
327 2014-08-06 17:47:05 <Guest14323> the default tx requires signatures from UserA and UserB.
328 2014-08-06 17:47:59 <Guest14323> the other require a sig from either UserA OR UserB and and arbiter.
329 2014-08-06 17:48:08 <Guest14323> *the others*
330 2014-08-06 17:48:27 <michagogo> Guest14323: uh, I'm not sure you fully understand how multisig works. You fund the multisig address. Once you do that, the funds can be spent either by both users or by either user and the arbiter.
331 2014-08-06 17:48:49 <michagogo> When the outcome is determined, if both users agree on the outcome, you create the relevant transaction and sign it
332 2014-08-06 17:49:16 <michagogo> If there's a dispute, you get the arbiter involved, you create the relevant transaction, and the arbiter and one of the users sign it
333 2014-08-06 17:49:36 <michagogo> Guest14323: take a look at http://testnet.bitrated.com/
334 2014-08-06 17:49:43 <Guest14323> the arbiter has two tx, one pays funds to UserA and himself, the other pays UserB and himself
335 2014-08-06 17:49:56 <michagogo> That's a site that does exactly what you're looking for, it sounds like
336 2014-08-06 17:50:09 <michagogo> Guest14323: Neither of those transactions needs to exist unless there's a dispute
337 2014-08-06 17:50:17 <michagogo> You don't need to create those yourself
338 2014-08-06 17:50:46 <Guest14323> but all tx are created when the multisig is funded, and all parties have access to all tx
339 2014-08-06 17:51:02 <michagogo> Why do you think you need to create all the transactions when the multisig is funded?
340 2014-08-06 17:51:07 <Guest14323> so i'm trying to limit who can sign what tx
341 2014-08-06 17:51:12 <michagogo> Anyone can create a transaction
342 2014-08-06 17:51:56 <Guest14323> the contract is finalized and all spend tx are created when the multisig is funded
343 2014-08-06 17:52:00 <michagogo> Literally anyone can create a transaction that says "spend this output and create these outputs". It's the signing that you need the keys for
344 2014-08-06 17:52:12 <Guest14323> correct
345 2014-08-06 17:52:20 <michagogo> Again, WHY do you think you need to create any spending transactions in advance?
346 2014-08-06 17:52:57 <michagogo> You don't.
347 2014-08-06 17:53:23 <michagogo> When the time comes to spend, whether that's to the merchant, or a refund back to the user, that's when you create the transaction
348 2014-08-06 17:53:39 <Guest14323> because the tx that pays UserA will be signed by UserA and then forwarded to UserB. if the contract resolves in UserA's favor then UserB will isgn it.
349 2014-08-06 17:54:00 <Guest14323> if UserB doesn't sign then it goes to arbitration
350 2014-08-06 17:54:05 <michagogo> If you need the arbitrater, when a decision is made, you go ahead and create the transaction paying one user and the arbitrator
351 2014-08-06 17:54:16 <Guest14323> and visa versa UserB/UserA
352 2014-08-06 17:54:28 <michagogo> Guest14323: You haven't explained to me what's wrong with creating the transaction when it's time to spend
353 2014-08-06 17:54:56 <Guest14323> because one or both users may not be present. think Bitmessage
354 2014-08-06 17:55:37 <Guest14323> everything except the signing must be put in place when the contract is finalized
355 2014-08-06 17:55:52 <Guest14323> so all parties have all payout tx
356 2014-08-06 17:56:00 <michagogo> Okay, I see
357 2014-08-06 17:56:13 <michagogo> But what do you mean by "restricting who can sign"?
358 2014-08-06 17:56:40 <michagogo> You just create transactions spending to userA and to userB, each user signs their own and sends it to the other
359 2014-08-06 17:56:46 <Guest14323> because I don't want UserB signing a payout that isn't his
360 2014-08-06 17:56:51 <michagogo> Uh?
361 2014-08-06 17:57:01 <michagogo> What do you mean?
362 2014-08-06 17:57:30 <michagogo> As in, you don't want userB to sign a payout that's not to himself? o_O
363 2014-08-06 17:57:42 <michagogo> Why would userB do that?
364 2014-08-06 17:58:41 <midnightmagic> 
ACTION points at #bitcoin :-)

365 2014-08-06 18:04:32 <Guest14323> michagogo: because each of the spend tx distribute the funds in a different manner. one spend doesn't pay anything to UserB (because he defaulted). I don't want him signing some other spend tx that gives him a partial payment.
366 2014-08-06 18:05:11 <michagogo> Guest14323: Uh. His signature alone doesn't give him anything.
367 2014-08-06 18:06:06 <michagogo> A spend that gives him partial payment will only be signed if UserA agrees, or if the arbitrator agrees.
368 2014-08-06 18:06:22 <michagogo> You just need to trust the arbitrator to do the right thing.
369 2014-08-06 18:06:30 <Guest14323> Understand, but some tx are partially signed when the contract is finalized. One or more parties need not be present a the conclusion.
370 2014-08-06 18:07:57 <Guest14323> So the main tx will be signed by UserA AND UserB, the others will be signed by some combination of (UserA OR UserX) or (UserB OR UserX)
371 2014-08-06 18:08:11 <Guest14323> the multisig is 2of5
372 2014-08-06 18:08:58 <michagogo> Guest14323: we should do as midnightmagic suggests and move to #bitcoin
373 2014-08-06 18:09:01 <Guest14323> but what you said earlier solves my problem: ichagogo> Uh, that's identical to OP_2 PubM PubA OP_2 OP_CHECKMULTISIG
374 2014-08-06 18:09:13 <cfields> wumpus: got it fixed without bumping the sdk. will PR it. we can evaluate an sdk bump later.
375 2014-08-06 18:09:15 <Guest14323> i think i'm done here
376 2014-08-06 18:09:21 <michagogo> Guest14323: no, wait
377 2014-08-06 18:09:43 <michagogo> That OP_2 PubM PubA OP_2 OP_CHECKMULTISIG needs to be selected at the time you fund it
378 2014-08-06 18:11:34 <Guest14323> ok then I'm back to OP_2 pubA <zeros> pubB OP_3 OP_CHECKMULTISIG
379 2014-08-06 18:11:47 <Guest14323> for 2of3
380 2014-08-06 18:11:51 <michagogo> ....no
381 2014-08-06 18:12:06 <michagogo> OP_2 pubA <zeros> pubB OP_3 OP_CHECKMULTISIG is identical to OP_2 PubM PubA OP_2 OP_CHECKMULTISIG, as I said earlier
382 2014-08-06 18:13:52 <sipa> Guest14323: that's identical to OP_2 pubA pubB OP_2
383 2014-08-06 18:14:13 <sipa> oh, sorry, missed michagogo's sentence
384 2014-08-06 18:15:33 <Guest14323> when i createmultisig, i'll use all three pub keys. will OP_2 pubA <zeros> pubB OP_3 OP_CHECKMULTISIG allow sigs from #1 and #3, or will it break? i guess this is something I should model on testnet
385 2014-08-06 18:15:51 <sipa> Guest14323: that will change the p2sh address
386 2014-08-06 18:15:56 <sipa> you cannot change the keys after the fact
387 2014-08-06 18:16:03 <michagogo> Again. "OP_2 pubA <zeros> pubB OP_3 OP_CHECKMULTISIG" does EXACTLY the same thing as "OP_2 PubA PubB OP_2 OP_CHECKMULTISIG"
388 2014-08-06 18:16:13 <michagogo> A P2SH address is for a single script
389 2014-08-06 18:16:15 <sipa> except for having a different p2sh address
390 2014-08-06 18:16:30 <michagogo> At the time you fund the multisig, the spending conditions are set in e-stone.
391 2014-08-06 18:16:51 <Guest14323> but this is spending the multisig
392 2014-08-06 18:16:55 <michagogo> right
393 2014-08-06 18:17:05 <michagogo> At the time you fund the multisig, the conditions to spend from the multisig are set in e-stone.
394 2014-08-06 18:17:10 <sipa> yes, the script when spending has to match the conditions set when crediting
395 2014-08-06 18:17:45 <Guest14323> so if it's 2of5 then all 5 pubkey must be present in the output of the funding tx
396 2014-08-06 18:17:53 <michagogo> It's like saying "I'm spending to an address, why can't I use a different pubkey when I spend that?"
397 2014-08-06 18:17:54 <sipa> no
398 2014-08-06 18:18:00 <michagogo> No
399 2014-08-06 18:18:01 <sipa> but they have to be present in the spending script
400 2014-08-06 18:18:07 <michagogo> All 5 pubkeys are present in the input of the spending tx
401 2014-08-06 18:18:42 <michagogo> What's present in the output of the funding TX is the hash of "OP_2 pubA ... pubE OP_5 OP_CHECKMULTISIG"
402 2014-08-06 18:19:05 <michagogo> And then when spending, you must provide that string again, and satisfy it.
403 2014-08-06 18:19:09 <Guest14323> sigs are present in the input os the spending tx
404 2014-08-06 18:19:16 <Guest14323> *of*
405 2014-08-06 18:19:26 <michagogo> Yes, they are, along with the pubkeys
406 2014-08-06 18:19:36 <michagogo> Or rather, before the pubkeys.
407 2014-08-06 18:20:27 <michagogo> The input of the spending tx will consist of [sig1] [sig2] [OP_2 pubA ... pubE OP_5 OP_CHECKMULTISIG]