1 2011-11-14 00:01:04 <iddo> but mental poker doesn't involve computing ecdsa signature
  2 2011-11-14 00:05:11 <eueueue> another example is: the admin show 10 options of products to buy.  (each one has a different price) the btc will be spent on the option with more %. voted.
  3 2011-11-14 00:10:16 <iddo> everyone who votes pledges the same fixed amount of btc ?
  4 2011-11-14 00:10:50 <eueueue> tell: yes
  5 2011-11-14 00:12:10 <iddo> who receives the product?
  6 2011-11-14 00:12:49 <eueueue> iddo: the condominiun admin, who adminstrate the admin key
  7 2011-11-14 00:13:04 <eueueue> that receive the btcs of all residents
  8 2011-11-14 00:14:40 <iddo> the price of each of the 10 products is the same?
  9 2011-11-14 00:15:24 <eueueue> no
 10 2011-11-14 00:15:39 <eueueue> the choose of products will be represented my numbers
 11 2011-11-14 00:16:20 <eueueue> the condominiun admin will tell: number one is product.... number 2 is product .....
 12 2011-11-14 00:16:22 <iddo> so what happens to rest of btc if they vote to buy product that's cheaper?
 13 2011-11-14 00:16:37 <eueueue> will remain on the admin key
 14 2011-11-14 00:17:31 <eueueue> example: the admin key has 1000btc. but he needs to by a product of 10btc. has has 10 option to this product to choose. some is 12 other is 14btc
 15 2011-11-14 00:17:34 <iddo> but you want the voters to decide which product to buy, and disallow the admin to decide?
 16 2011-11-14 00:17:46 <eueueue> yes
 17 2011-11-14 00:18:20 <eueueue> the admin will give the options of products that will be represented by numbers
 18 2011-11-14 00:19:18 <eueueue> i'm staying crazy
 19 2011-11-14 00:19:19 <eueueue> hhehe
 20 2011-11-14 00:19:24 <iddo> hmm so if 10btc then you want the voters to do a transaction that sends 10btc to shop to buy product, and sends 990btc to admin so he can do whatever he wants with the 990 ?
 21 2011-11-14 00:19:34 <eueueue> better write a good argument
 22 2011-11-14 00:19:58 <eueueue> the idea is:
 23 2011-11-14 00:21:27 <eueueue> the admin will have a key with as much as btc the residentes paid on the year. But he can only spend the btc with approval of residentes.
 24 2011-11-14 00:21:58 <eueueue> the admin key will need 80% of approval of specific keys
 25 2011-11-14 00:22:10 <eueueue> the specific yes are the key of the residentes
 26 2011-11-14 00:22:46 <iddo> 80% ? you said they vote and whatever product wins is bought?
 27 2011-11-14 00:23:09 <eueueue> forguet everthing I told
 28 2011-11-14 00:23:16 <iddo> :)
 29 2011-11-14 00:23:19 <eueueue> and think in this:
 30 2011-11-14 00:23:27 <eueueue> the admin will have a key with as much as btc the residentes paid on the year. But he can only spend the btc with approval of residentes
 31 2011-11-14 00:23:38 <eueueue> the admin key will need 80% of approval of specific keys
 32 2011-11-14 00:23:48 <eueueue> the specific yes are the key of the residentes
 33 2011-11-14 00:24:09 <eueueue> the specific keys are the keys of the residentes
 34 2011-11-14 00:24:21 <eueueue> by design, this is possible?
 35 2011-11-14 00:24:44 <eueueue> I think all I wrote before, I wanted to explaing this situtation
 36 2011-11-14 00:25:24 <iddo> so admin tells residents he wanna buy some product, and if 80% agree then they allow him to buy the product?
 37 2011-11-14 00:25:33 <eueueue> yes
 38 2011-11-14 00:26:08 <phantomcircuit> eueueue, congratulations you've just reinvented the cooperative
 39 2011-11-14 00:26:33 <gmaxwell> cooperative.. but with cryptography!
 40 2011-11-14 00:26:52 <eueueue> but if he wants to buy a product and exist different kind of this product he could give an option to residentes choose which one to but
 41 2011-11-14 00:26:55 <iddo> ok so it's same as your previous scenario, just instead of signing a transaction that sends the btc to admin address, they sign txn that sends 10btc of the total btc to shop address
 42 2011-11-14 00:27:28 <eueueue> i think yes
 43 2011-11-14 00:28:28 <eueueue> it's possible by design?
 44 2011-11-14 00:28:46 <eueueue> cooperative
 45 2011-11-14 00:28:53 <cjdelisle> gmaxwell: I expanded on your proposal a bit: http://btc.pastebay.com/144544
 46 2011-11-14 00:29:02 <eueueue> people together choose what to buy or not to buy
 47 2011-11-14 00:30:31 <gmaxwell> cjdelisle: you can spend and recieve transactions without the open tree though, using a lite client. You only need the headers and the tree fragments.
 48 2011-11-14 00:31:15 <gmaxwell> cjdelisle: it's just with lite clients you can't validate on your own, you must wait until a txn paying you is burried before you're confident that it was valid at all.
 49 2011-11-14 00:32:26 <cjdelisle> I was aiming at allowing all nodes to be light in the far future.
 50 2011-11-14 00:32:41 <cjdelisle> re why it's stupidly complex
 51 2011-11-14 00:33:32 <gmaxwell> ::nods:: yes, I know the advantages of using open txn trees. ;) But thats not clear in your intro.
 52 2011-11-14 00:34:23 <gmaxwell> Haven't read your complete page yet, though one thing that bothered me was the risk of an attacker intentionally producing transactions that fall on the same spots on the tree, thus causing super long branches.
 53 2011-11-14 00:34:56 <cjdelisle> yup, I can't fix that because if I did, it would blow the amazing getdiff magic trick to hell
 54 2011-11-14 00:35:50 <gmaxwell> cjdelisle: well, one thing I thought of was using some function of the chain to periodically perturb the hash used for the tree.
 55 2011-11-14 00:36:02 <gmaxwell> but it would mean that you'd need to reconstruct the full tree whenever it changed.
 56 2011-11-14 00:36:21 <gmaxwell> I suppose you could also just make txn fees go up for ugly tree attachment.
 57 2011-11-14 00:36:35 <cjdelisle> I thought of that
 58 2011-11-14 00:36:54 <cjdelisle> it could be added to the "security concerns" part of the paper
 59 2011-11-14 00:37:02 <iddo> why isn't it enough for lite client to start new wallet and chain headers from last checkpoint of official client?
 60 2011-11-14 00:37:38 <gmaxwell> iddo: because not all nodes can be lite.
 61 2011-11-14 00:37:52 <gmaxwell> cjdelisle: under a scheme that commits to open txn, all nodes can be lite.
 62 2011-11-14 00:38:00 <gmaxwell> (or, really, semi-lite)
 63 2011-11-14 00:38:59 <cjdelisle> there's a whole range of lightness
 64 2011-11-14 00:39:15 <cjdelisle> miners can hold the last 200 blocks, you or I can hold the last 3
 65 2011-11-14 00:39:26 <iddo> but for lite clients, starting just from last checkpoint is good or bad?
 66 2011-11-14 00:39:49 <gmaxwell> I don't see why checkpoints matter.
 67 2011-11-14 00:40:18 <iddo> matters so not to download the entire chain headers when you connect the first time?
 68 2011-11-14 00:40:20 <gmaxwell> They just introduce an ugly and unwanted trust factor. A light client can just get 'enough' blocks and trust that someone wouldn't waste that much computation on a fraud chain.
 69 2011-11-14 00:40:38 <gmaxwell> besides, headers are cheap as hell.
 70 2011-11-14 00:40:43 <cjdelisle> indeed
 71 2011-11-14 00:40:50 <iddo> i see
 72 2011-11-14 00:40:52 <cjdelisle> and this stuff doesn't even need the header
 73 2011-11-14 00:41:09 <cjdelisle> it can literally function with nothing more than the array of hashes
 74 2011-11-14 00:41:16 <cjdelisle> block hashes
 75 2011-11-14 00:41:19 <gmaxwell> iddo: ten years of headers is only 42mbytes. No big deal.
 76 2011-11-14 00:41:32 <iddo> if miners trim spent txns from their chain locally, how will a new miner get the full chain?
 77 2011-11-14 00:41:45 <cjdelisle> err yea, it probably wants the whole headers so it can prove that they actually fit together
 78 2011-11-14 00:41:58 <gmaxwell> iddo: they don't need the full chain under this scheme.
 79 2011-11-14 00:42:06 <gmaxwell> because the headers commit to the open transactions.
 80 2011-11-14 00:42:36 <cjdelisle> I've been using "unspent transactions" because calling it OpenTransactions will open a can of worms ;)
 81 2011-11-14 00:42:53 <iddo> the scheme in pastebay i didn't understand yet, i was asking about bitcoin in general
 82 2011-11-14 00:43:01 <gmaxwell> I used the phrase first.
 83 2011-11-14 00:43:02 <gmaxwell> ;)
 84 2011-11-14 00:43:10 <cjdelisle> hehe
 85 2011-11-14 00:43:22 <cjdelisle> git offa mah laawn
 86 2011-11-14 00:43:36 <gmaxwell> iddo: they can't. They either have to trust that peers aren't lying or they need to get a copy from an archive someplace.
 87 2011-11-14 00:45:16 <iddo> is there some flag saying that the chain of the miner wasn't trimmed? or should there be such flag? so it could be monitored for making sure enough nodes in the network have the full chain?
 88 2011-11-14 00:46:25 <iddo> or maybe just miner who trimmed his chain shouldn't send it to others?
 89 2011-11-14 00:46:40 <iddo> (i realize the official client doesn't trim)
 90 2011-11-14 00:54:23 <gmaxwell> iddo: I don't think there is currently any way to send a trimmed chain to others.
 91 2011-11-14 02:14:23 <gmaxwell> If anyone is in need of OpenSSL RPMs for Fedora 16 so you can build bitcoin from git, I've posted some here: https://people.xiph.org/~greg/openssl/
 92 2011-11-14 02:14:37 <gmaxwell> If people are interested I'll also maintain ones for prior fedora versions and centos.
 93 2011-11-14 02:33:32 <CIA-89> poolserverj: shadders * c34d97b39b7c r234 / (9 files in 6 dirs):
 94 2011-11-14 02:47:43 <roconnor> etotheipi_: did you implement DER decoding?
 95 2011-11-14 02:49:37 <roconnor> etotheipi_: there is something unusual about transaction 95038c3155de45fc7753f90b35c04b494ff1379e665dbbd9d013496a2531b7a7
 96 2011-11-14 02:51:05 <cjdelisle> what language are you using? der encoding is pretty common
 97 2011-11-14 02:51:37 <roconnor> I wrote my own special DER decoder for what is needed in bitcoin
 98 2011-11-14 02:51:44 <roconnor> etotheipi_ is using python
 99 2011-11-14 02:52:36 <cjdelisle> why not use openssl or gcrypt or bouncycastle or whatever?
100 2011-11-14 02:53:54 <roconnor> because then I wouldn't know what is going down the wire
101 2011-11-14 03:08:48 <denisx> why is sending bitcoind a midstate in the getwork call?
102 2011-11-14 03:08:53 <denisx> pushpoold does not use it
103 2011-11-14 03:08:56 <denisx> who does?
104 2011-11-14 03:10:18 <nanotube> it's legacy
105 2011-11-14 03:15:08 <jgarzik> denisx: nobody
106 2011-11-14 03:19:36 <denisx> and the target?
107 2011-11-14 03:19:48 <denisx> it seems to be part of the data already
108 2011-11-14 03:27:20 <denisx> jgarzik: so it is safe to say JoelKatz he can omit misstate?
109 2011-11-14 03:27:31 <denisx> to tell
110 2011-11-14 03:30:57 <roconnor> crap
111 2011-11-14 03:33:48 <roconnor> I might have to read the openssl sources to debug this
112 2011-11-14 03:36:38 <jgarzik> denisx: some miners may break
113 2011-11-14 03:40:50 <luke-jr> denisx: up until recently, cgminer required midstate
114 2011-11-14 03:41:20 <luke-jr> pushpoold *does* pass midstate on to the end miner if it's there
115 2011-11-14 03:42:09 <luke-jr> denisx: perhaps interested in my pushpoold+bitcoind replacement? ;)
116 2011-11-14 03:42:42 <denisx> luke-jr: replacement? you merged them?
117 2011-11-14 03:43:04 <luke-jr> (jgarzik: no offense intended: it was really bitcoind and libevent that were to blame for me replacing pushpool; your code is good :p)
118 2011-11-14 03:43:25 <luke-jr> denisx: it only uses bitcoind to tell it which transactions to put in blocks (via getmemorypool)
119 2011-11-14 03:43:26 <denisx> whats wrong with libevent?
120 2011-11-14 03:43:47 <luke-jr> denisx: as you know, the older version pushpool uses in mainline has issues
121 2011-11-14 03:43:59 <denisx> yes
122 2011-11-14 03:44:47 <denisx> but to have them separated has also advantages
123 2011-11-14 03:45:07 <denisx> if only bitcoind had multiuser support
124 2011-11-14 03:45:12 <luke-jr> denisx: does it? :p
125 2011-11-14 03:46:03 <luke-jr> my algorithm is super-fast at getting work for clients
126 2011-11-14 03:46:30 <denisx> how many getworks/sec?
127 2011-11-14 03:47:02 <luke-jr> depends on the CPU of course, but easily 5,000/sec sustained, probably much more
128 2011-11-14 03:47:10 <luke-jr> bursts can go higher
129 2011-11-14 03:48:02 <luke-jr> denisx: feel free to clone http://eligius.st/~luke-jr/.eloipool.git to look at it
130 2011-11-14 03:48:23 <luke-jr> it's not currently licensed for distribution/use mainly because I want some third-party reviews of it first :p
131 2011-11-14 03:48:42 <luke-jr> I plan to AGPL it
132 2011-11-14 03:49:26 <cocktopus> AGPL is evil
133 2011-11-14 03:49:32 <MimeNarrator> gmaxwell: isn't openssl in either the standard fedora repos or fedora fusion?
134 2011-11-14 03:49:59 <luke-jr> cocktopus: I was going to be even less free originally ;)
135 2011-11-14 03:50:03 <gmaxwell> MimeNarrator: of course openssl is in standard fedora. But it has all ECC removed, so its useless for bitcoin.
136 2011-11-14 03:50:10 <MimeNarrator> ah
137 2011-11-14 03:50:31 <cocktopus> luke-jr: go big or go home :)
138 2011-11-14 03:50:52 <gmaxwell> MimeNarrator: (because the openssl developers won't seperate out the everyone-agrees-its-patented ecc stuff from the obviously not patentable ecc stuff, so fedora just removes all of it since basically no one uses it)
139 2011-11-14 03:50:55 <luke-jr> cocktopus: my original license was "contribute or go away" ;)
140 2011-11-14 03:51:13 <cocktopus> ;)
141 2011-11-14 03:51:48 <luke-jr> but shadders over there is competing too strong with PoolServerJ
142 2011-11-14 03:51:54 <luke-jr> so I feel I need something more liberal :|
143 2011-11-14 03:54:05 <denisx> go BSD
144 2011-11-14 03:54:29 <cocktopus> woot
145 2011-11-14 03:54:59 <kiba> hello I am looking for bitcoin related work
146 2011-11-14 03:56:34 <shadders> luke-jr: I'm sure there's a healthy market for eloipool... there's plenty of java-haters out there that won't touch poolserverj
147 2011-11-14 03:57:05 <kiba> dun dun dun
148 2011-11-14 04:02:20 <luke-jr> denisx: BSD enables too much abuse
149 2011-11-14 04:03:41 <cocktopus> i prefer wtfpl or beerware  :P
150 2011-11-14 04:04:06 <luke-jr> beerware is non-free
151 2011-11-14 04:05:21 <cocktopus> free enough for me
152 2011-11-14 04:05:32 <cocktopus> i like to donate to an author that makes good stuff
153 2011-11-14 04:23:18 <roconnor> this signature shouldn't be valid
154 2011-11-14 04:25:11 <gmaxwell> uh oh?
155 2011-11-14 04:26:10 <roconnor> Maybe this is a bug in openssl?
156 2011-11-14 04:26:20 <roconnor> more likely I'm mistaken
157 2011-11-14 04:26:22 <roconnor> but still ...
158 2011-11-14 04:27:38 <gmaxwell> Is it a point compressed key or something?
159 2011-11-14 04:27:56 <roconnor> gmaxwell: on the testnet in transaction 95038c3155de45fc7753f90b35c04b494ff1379e665dbbd9d013496a2531b7a7 there is a DER encodined ECDSA sigature: 304402208cc1fc128333d3f0b3eaeb2c6705b6d86624edea42c62eb1abaaa947f3ace8ae0220c40312c291b500084556dc5e331f8e143aca30fd885585a7baf7382cbe0b36c501
160 2011-11-14 04:29:01 <roconnor> There are two integers encoded in the ECDSA signature: 02208cc1fc128333d3f0b3eaeb2c6705b6d86624edea42c62eb1abaaa947f3ace8ae and 0220c40312c291b500084556dc5e331f8e143aca30fd885585a7baf7382cbe0b36c5
161 2011-11-14 04:29:14 <roconnor> look carefully and the second integer
162 2011-11-14 04:29:23 <roconnor> the first 0x20 means that it is an integer
163 2011-11-14 04:29:34 <roconnor> the next 0x20 says that it is 32 bytes
164 2011-11-14 04:29:59 <roconnor> but, the kicker is that the integer begins with 0xc4
165 2011-11-14 04:30:08 <roconnor> the leading bit is 1!!!
166 2011-11-14 04:30:17 <roconnor> which is supposed to be a negative number
167 2011-11-14 04:31:08 <roconnor> and the numbers in a signature, if I understand well, must be non-negative.
168 2011-11-14 04:31:44 <roconnor> it is hard to tell for sure because the DER decoding in openssl is all implemented with macros
169 2011-11-14 04:31:51 <etotheipi_> roconnor,  are you sure you're not reading the wrong endian?
170 2011-11-14 04:32:02 <etotheipi_> DER is encoded big-endian
171 2011-11-14 04:32:32 <roconnor> etotheipi_: I've validated tens of thousands of ECSDA signatures before
172 2011-11-14 04:32:42 <roconnor> this is the first one I've encountered that is negative.
173 2011-11-14 04:32:52 <etotheipi_> okay, just making sure
174 2011-11-14 04:32:57 <roconnor> or rather the first one I've encountered with a leading bit 1.
175 2011-11-14 04:33:04 <roconnor> etotheipi_: no problem
176 2011-11-14 04:33:09 <etotheipi_> wait...
177 2011-11-14 04:33:28 <etotheipi_> I'm confused... (r,s) *are* positive numbers
178 2011-11-14 04:33:46 <etotheipi_> and I seem to remember, when the the top bit is 1, there's supposed to be an extra 0x00 byte in front to fix the problem
179 2011-11-14 04:33:48 <roconnor> etotheipi_: well, they are supposed to be
180 2011-11-14 04:33:52 <roconnor> etotheipi_: yep
181 2011-11-14 04:34:05 <roconnor> but there is no extra 0x00 byte here
182 2011-11-14 04:34:20 <etotheipi_> but is it possible that the library you are using *always* interprets them as unsigned?
183 2011-11-14 04:34:32 <etotheipi_> regardless of the leadbyte
184 2011-11-14 04:34:53 <roconnor> well, my library (I wrote) fails to decode numbers with a leading bit of 1
185 2011-11-14 04:34:59 <roconnor> so it rejected this signature
186 2011-11-14 04:35:13 <etotheipi_> hmmm
187 2011-11-14 04:35:58 <roconnor> and I cannot (easily) inspect the sources of DER decoding in openssl since it is macro heavy stuff
188 2011-11-14 04:36:17 <etotheipi_> even if it wasn't macro-heavy... I've looked into DER before
189 2011-11-14 04:36:24 <etotheipi_> it's pretty heavy, itself
190 2011-11-14 04:36:34 <roconnor> I was following the DER speck
191 2011-11-14 04:36:36 <roconnor> *spec
192 2011-11-14 04:36:51 <etotheipi_> I couldn't quite figure out the spec
193 2011-11-14 04:37:16 <luke-jr> roconnor: cpp && indent
194 2011-11-14 04:37:33 <roconnor> luke-jr: ya, this is pushing my c ablities
195 2011-11-14 04:37:39 <etotheipi_> try adding a leading 0x00 byte to each sig before you parse it... see if it passes
196 2011-11-14 04:38:08 <etotheipi_> er.. .adding leading 0x00 to each sig component
197 2011-11-14 04:38:15 <roconnor> ya, I'm trying that now
198 2011-11-14 04:38:33 <roconnor> (or rather I'm trying with interpreting it as unsigned)
199 2011-11-14 04:39:13 <etotheipi_> well, that would be only explanation
200 2011-11-14 04:39:30 <etotheipi_> it can't be negative, and so if the client accepted it as valid, it must be interpretted as unsigned
201 2011-11-14 04:39:37 <etotheipi_> regardless of what the DER suggests should happen
202 2011-11-14 04:40:31 <roconnor> the whole point of DER is to be deterministic
203 2011-11-14 04:40:50 <etotheipi_> haha, I don't disagree with you... but Bitcoin is big an complicated...as you know, they got quite a few *intended* details wrong
204 2011-11-14 04:40:57 <etotheipi_> although if it's actually in the OpenSSL code
205 2011-11-14 04:41:10 <roconnor> right now, I'm conjecturing it is a bug in openssl
206 2011-11-14 04:41:25 <roconnor> well, I'm conjucturing that I'm wrong in some way that I don't see yet
207 2011-11-14 04:41:56 <roconnor> etotheipi_: The signature passes if it is treated as unsigned
208 2011-11-14 04:42:08 <roconnor> I think this is a bug in openssl
209 2011-11-14 04:42:13 <roconnor> or I don't understand DER
210 2011-11-14 04:42:51 <roconnor> This could maybe even be a serious bug; because it means there is more than one way to encode the same values using DER
211 2011-11-14 04:44:42 <roconnor> I should go to bed
212 2011-11-14 04:45:12 <gmaxwell> oh I think we knew there was a redundant encoding issue.
213 2011-11-14 04:45:22 <roconnor> gmaxwell: oh?
214 2011-11-14 04:45:34 <luke-jr> I think so too
215 2011-11-14 04:45:42 <luke-jr> I don't see why it matters.
216 2011-11-14 04:45:50 <luke-jr> There's more than one way to encode the txn anyway
217 2011-11-14 04:45:52 <gmaxwell> It's a fork risk if not everyone supports it.
218 2011-11-14 04:45:55 <roconnor> well, I don't think it is a problem for bitcoin, as much as it is a problem for openssl
219 2011-11-14 04:46:14 <gmaxwell> yes, I'm pretty sure there was a advisory for openssl earlier this year for this.
220 2011-11-14 04:46:43 <etotheipi_> well, even for sig values that *don't* have a leading bit, you can still add the 0x00 byte (as I do), so that gives two possible ways for half of all sigs
221 2011-11-14 04:46:50 <luke-jr> gmaxwell: oooh, so if openssl is fixed, we get a fork? :|
222 2011-11-14 04:47:10 <roconnor> luke-jr: sounds plausible
223 2011-11-14 04:47:13 <luke-jr> ew
224 2011-11-14 04:47:18 <roconnor> etotheipi_: I was wondering about htat
225 2011-11-14 04:47:23 <gmaxwell> I can't seem to find it. darnit.
226 2011-11-14 04:50:12 <etotheipi_> you are an amazingly-thorough developer, roconnor
227 2011-11-14 04:50:35 <roconnor> etotheipi_: this is what happens when you implement everything from scratch
228 2011-11-14 04:50:50 <etotheipi_> I have tons of patience, and try to be thorough, but sometimes I just concede to having to do what works without sweating too much
229 2011-11-14 04:50:50 <roconnor> the real hero is the crazy person who posted that transaction to testnet
230 2011-11-14 04:51:11 <roconnor> how did he make such a signature? why did he drop the leading 0x00?
231 2011-11-14 04:51:41 <etotheipi_> I mean, I always add the leading 0x00 because I know it's a valid encoding, and then I don't have to think about it...
232 2011-11-14 04:52:04 <etotheipi_> dropping the zero sounds questionable... but what's the worst that can happen?  his tx is rejected?
233 2011-11-14 04:53:14 <roconnor> gmaxwell: I'm going to bed; let me know if you guys find any details about this
234 2011-11-14 04:53:38 <roconnor> like I said, I don't think it is really a problem for bitcoin as much as it is a problem for openssl
235 2011-11-14 04:53:51 <roconnor> ... though if openssl says it is a bug and fixes it, then we have a problem for bitcoin
236 2011-11-14 04:54:05 <etotheipi_> does BTC do any processing on the DER strings?
237 2011-11-14 04:54:09 <etotheipi_> or is it all openssl?
238 2011-11-14 04:54:15 <roconnor> it is all openssl
239 2011-11-14 04:54:31 <roconnor> so if openssl changes then the bitcoin protocol changes
240 2011-11-14 04:54:36 <roconnor> nice, isn't it
241 2011-11-14 04:54:52 <etotheipi_> does the client dynamically link to OpenSSL?  or static?
242 2011-11-14 04:55:05 <roconnor> etotheipi_: dynamic IIRC
243 2011-11-14 04:55:14 <roconnor> not certain though
244 2011-11-14 04:55:22 <etotheipi_> if it's dynamic, that could be dangerous
245 2011-11-14 04:55:50 <etotheipi_> but I bet it kind of has to be... I doubt they could distribute the static libraries with the client
246 2011-11-14 04:55:51 <gmaxwell> The distributed binaries are static, if you build yourself its dynamic.
247 2011-11-14 07:44:47 <sipa> roconnor: before i look deeper: der encoding is diffferent from the mpi encoding that is used for numbers
248 2011-11-14 07:45:21 <sipa> sure the rules for negative integers are the same?
249 2011-11-14 08:06:14 <AliciaC> my harddrive got messed up overnight and it was the only place I had my bitcoin wallet (no backups), does anyone know if there is a particular pattern I could search for to recover it? (partition table is broken and so is the filesystem index I guess, but a lot of the data that was stored seems to be intact)
250 2011-11-14 08:06:32 <edcba> hmm
251 2011-11-14 08:07:02 <edcba> create another wallet on another computer and look for start of wallet.dat i guess
252 2011-11-14 08:07:05 <Diablo-D3> THIS IS WHY YOU BACKUP SHIT
253 2011-11-14 08:07:24 <edcba> or that's why wallet.dat is not a good idea
254 2011-11-14 08:07:59 <abragin> AliciaC - you can try various filesystem repair tools, they usually find files in a broken filesystem
255 2011-11-14 08:08:01 <abragin> including filenames
256 2011-11-14 08:08:11 <abragin> esepcially if it was NTFS, you have a good chance
257 2011-11-14 08:08:45 <AliciaC> ah, I should look into that, I've only been running photorec so far to try to recover some files, the filesystem is ext4
258 2011-11-14 08:09:03 <abragin> ah, ext4, not so bad either
259 2011-11-14 08:09:10 <Diablo-D3> edcba: SHIT, BACK IT UP
260 2011-11-14 08:10:02 <edcba> also
261 2011-11-14 08:10:41 <edcba> especially now that wallet.dat isn't useless anymore after a single transaction :)
262 2011-11-14 08:13:18 <edcba> i have some 01 04 20 66 60 F9 pattern at 61A0 in file
263 2011-11-14 08:13:32 <edcba> but most of beginning of file looks empty
264 2011-11-14 08:14:16 <edcba> now it just be some public/private key of mine :)
265 2011-11-14 08:14:21 <edcba> +may
266 2011-11-14 08:15:08 <AliciaC> *nods* I couldn't find that in the other wallet file I have here
267 2011-11-14 08:22:45 <wboy1> Hey Guys,any javascripts dev's that are interested in joining a bitcoin related funded startup,drop me a message,Thanks!
268 2011-11-14 08:25:02 <edcba> javascript dev lol
269 2011-11-14 08:25:21 <edcba> you mean you need some guy who *only* knows JS ?
270 2011-11-14 08:26:22 <edcba> ;;bc,mtgox
271 2011-11-14 08:26:23 <gribble> {"ticker":{"high":3.03,"low":2.3,"avg":2.63160626,"vwap":2.570532461,"vol":289596,"last_all":2.66702,"last_local":2.66702,"last":2.66702,"buy":2.6655,"sell":2.667}}
272 2011-11-14 08:28:30 <Joric> wboy1, http://ragecoin.appspot.com ? :)
273 2011-11-14 08:30:32 <wboy1> hehe hell no:)
274 2011-11-14 08:30:45 <wboy1> ya js :)
275 2011-11-14 08:32:57 <Joric> i was using mybitcoin on that site but it fell apart (
276 2011-11-14 08:37:54 <wboy1> lol mybitcoin suck:)heh
277 2011-11-14 12:02:12 <roconnor> sipa: in fact, I'm claiming the encoding rules are different.  I'm claiming that DER uses 2-complement signed integers.
278 2011-11-14 12:09:35 <UukGoblin> sipa, what happened to the graphs? they're unreadable now :-/
279 2011-11-14 12:09:48 <UukGoblin> at least the short-term ones
280 2011-11-14 12:11:22 <upb> why do people like reinventing wheels ?:P
281 2011-11-14 12:11:39 <roconnor> sipa: more specifically I'm claiming that DER is supposed to use 2-complement signed integers, but openssl is actually implementing it as unsigned integers
282 2011-11-14 12:12:57 <roconnor> upb: hey, I didn't write ISO/IEC 8825-1:2003(E).  Don't slap the messenger. :)
283 2011-11-14 12:13:17 <upb> arent you writing your own der decoder ?:P
284 2011-11-14 12:14:08 <roconnor> ... true
285 2011-11-14 12:14:46 <roconnor> heh
286 2011-11-14 12:15:00 <roconnor> it's part of my evil plan to fork the blockchain
287 2011-11-14 12:15:48 <sipa> UukGoblin: seems my bitcoind died
288 2011-11-14 12:16:42 <UukGoblin> sipa, ah yes, it like to do that every now and then
289 2011-11-14 12:16:53 <sipa> owww... out of disk space
290 2011-11-14 12:16:56 <UukGoblin> likes*
291 2011-11-14 12:17:03 <UukGoblin> ah, quite a common reason :->
292 2011-11-14 12:19:00 <sipa> roconnor: right... that does look like a mistake
293 2011-11-14 12:22:35 <sipa> roconnor: from openssl's asn1.h:
294 2011-11-14 12:22:36 <sipa> #define V_ASN1_NEG                      0x100   /* negative flag */
295 2011-11-14 12:22:41 <sipa> #define V_ASN1_INTEGER                  2
296 2011-11-14 12:23:31 <sipa> roconnor: sounds to me like they encode negative integers using a different tag
297 2011-11-14 12:26:56 <roconnor> The INTEGER type denotes an arbitrary integer. INTEGER values can be positive, negative, or zero, and can have any magnitude.
298 2011-11-14 12:27:03 <roconnor> from http://luca.ntop.org/Teaching/Appunti/asn1.html
299 2011-11-14 12:28:18 <roconnor> it aslo says on that page that 02 01 80 encodes -128
300 2011-11-14 12:28:38 <roconnor> and 02 02 FF 7F encodes -129
301 2011-11-14 12:32:39 <sipa> roconnor: i know, i looked over the DER specification
302 2011-11-14 12:32:49 <sipa> but it seems openssl uses a slightly different standard?
303 2011-11-14 12:33:06 <sipa> roconnor: do signatures normally have the extra zero byte in front?
304 2011-11-14 12:33:31 <sipa> because maybe openssl encodes correctly according to DER, but is lax in parsing it
305 2011-11-14 13:33:15 <wboy1> Hey Guys,any javascripts dev's that are interested in joining a bitcoin related funded startup,drop me a message,Thanks!
306 2011-11-14 13:57:00 <CIA-89> bitcoin: Gavin Andresen master * r88a1b89 / src/bitcoinrpc.cpp :
307 2011-11-14 13:57:50 <CIA-89> bitcoin: Gavin Andresen master * re6a729d / (12 files in 3 dirs):
308 2011-11-14 14:04:53 <roconnor> sipa: signuatres normally have an extra 0x00 in the front
309 2011-11-14 14:05:15 <roconnor> sipa: if openssl is using a very slightly incompatible standard to DER, that will be very confusing for everyone
310 2011-11-14 14:05:30 <roconnor> sounds more like microsoft than openssl
311 2011-11-14 14:07:20 <luke-jr> gavinandresen: any news on a fix?
312 2011-11-14 14:08:29 <sipa> roconnor: my assumption is then that openssl creates correct DER-conforming signatures, but allows signatures that do not follow the strict rules
313 2011-11-14 14:08:30 <gavinandresen> luke-jr: I'm pulling sipa's dump-all-private-keys branch and will work through the test plan on my machine
314 2011-11-14 14:09:02 <sipa> roconnor: and someone using an alternative client produced these signatures without the 0 byte
315 2011-11-14 14:09:09 <gavinandresen> ... assuming tests all pass, I'll tag a 0.5 rc4, compile binaries, and then work on back-porting to 0.4
316 2011-11-14 14:10:17 <luke-jr> k
317 2011-11-14 14:10:33 <gavinandresen> ... I just rebased the pull, by the way.
318 2011-11-14 14:11:04 <luke-jr> do you plan to build 0.4.1 binaries, btw, or should I be looking for someone to do that?
319 2011-11-14 14:11:26 <sipa> what about wxbitcoin 0.4?
320 2011-11-14 14:12:57 <gavinandresen> luke-jr: if you can help with 0.4.1 binaries, that'd make me happy.
321 2011-11-14 14:13:23 <gavinandresen> sipa:  if somebody can volunteer to backport the GUI changes to wx 0.4.1 that'd make me VERY happy
322 2011-11-14 14:14:38 <sipa> gavinandresen: you may want to ask BlueMatt
323 2011-11-14 14:16:32 <AliciaC> I didn't have any problem compiling bitcoins 0.4 on GNU/Linux, (if we're talking about the same versions..)
324 2011-11-14 14:29:24 <AlexWaters1> sipa: any chance you know the best way for me to get private keys in hex, in a text file?
325 2011-11-14 14:30:09 <sipa> AlexWaters1: https://github.com/sipa/bitcoin/tree/dumpallkeys
326 2011-11-14 14:30:19 <sipa> RPC call gethexprivkeys
327 2011-11-14 14:31:31 <gavinandresen> AlexWaters1: I was just testing that to update the gist with instructions...
328 2011-11-14 14:32:05 <sipa> gavinandresen: have you verified that it outputs the private keys in correct endianness?
329 2011-11-14 14:32:06 <gavinandresen> sipa:  Weirdness with gethexprivkeys:  it seems to be dumping an extra private key
330 2011-11-14 14:32:15 <gavinandresen> sipa: endianness is correct, yes
331 2011-11-14 14:32:42 <sipa> "extra" ?
332 2011-11-14 14:32:43 <gavinandresen> sipa: I'll email you the wallet and what I"m seeing
333 2011-11-14 14:32:47 <sipa> ok
334 2011-11-14 14:34:57 <AlexWaters1> gavinandresen: awesome - thank you Gavin. Good Bruins game?
335 2011-11-14 14:35:21 <edcba> :Wg 2
336 2011-11-14 14:35:24 <edcba> oops
337 2011-11-14 14:36:04 <gavinandresen> AlexWaters1: yeah, they won 6-2.  Went with a Buffalo fan that wasn't happy, though
338 2011-11-14 14:36:39 <gavinandresen> sipa: email sent, it shouldn't affect testing but does look like a bug in gethexprivkeys/dumpwallet
339 2011-11-14 14:37:03 <AlexWaters1> gavinandresen: I only saw the highlights of Miller getting smashed...good comeback
340 2011-11-14 14:40:52 <gavinandresen> AlexWaters1: I've updated https://gist.github.com/1361001
341 2011-11-14 14:40:59 <sipa> gavinandresen: can you run rcp dumpwallet, and see whether it also contains that extra key?
342 2011-11-14 14:44:48 <gavinandresen> sipa: sure, if you can tell me what 00d7b26c8554264e49f77a08d9fe91ac6389caee4cbd1a56659b4c61c1ee7d71 in the private key base58 encoding
343 2011-11-14 14:45:27 <sipa> ah, damnit, of course
344 2011-11-14 14:45:31 <sipa> never mind, i'll figure it out
345 2011-11-14 14:46:00 <gavinandresen> sipa: looks like dumpwallet has the same bug, I get 105 keys out of it (should be 104)
346 2011-11-14 14:46:27 <sipa> gavinandresen: getallhexkeys and dumpwallet should report keys in the same order, so the first one...
347 2011-11-14 14:46:42 <AlexWaters1> gavinandresen: thank you testing in ubuntu now
348 2011-11-14 14:48:55 <hippich> is there open source bitcoin faucet available?
349 2011-11-14 15:01:12 <AlexWaters1> sipa: i'm getting a 'did you run git update-server-info on the server error' when trying to clone https://github.com/sipa/bitcoin/tree/dumpallkeys - should i just clone your repo and checkout the dumpallkeys branch? is this my error?
350 2011-11-14 15:01:31 <sipa> AlexWaters1: yes
351 2011-11-14 15:06:51 <roconnor> sipa: I think it is somewhat bad of openssl to accept incorrect encodings of signatures as valid signatures.
352 2011-11-14 15:07:10 <roconnor> sipa: I find it plausible that this could be a security problem.
353 2011-11-14 15:08:40 <gavinandresen> 'discouraging' transactions that are not in the strictest, canonical encoding would be a very good idea, in my humble opinion.  Patches welcome....
354 2011-11-14 15:09:46 <roconnor> gavinandresen: this particular problem is with openssl
355 2011-11-14 15:10:30 <roconnor> gavinandresen: though if openssl changes its behaviour, then that becomes a bitcoin problem
356 2011-11-14 15:10:52 <gavinandresen> roconnor: exactly.  And maybe a problem for lots of other things that use openssl
357 2011-11-14 15:11:03 <roconnor> yep :/
358 2011-11-14 15:11:23 <roconnor> what I really need is a contact person from openssl
359 2011-11-14 15:12:16 <gavinandresen> roconnor: when this came up before, I suggested that decoding then re-encoding signatures, and comparing the re-encoded to the original, might be a good check
360 2011-11-14 15:12:32 <gavinandresen> (I assume OpenSSL always encodes in strictest, most-canonical form)
361 2011-11-14 15:13:03 <roconnor> gavinandresen: has this particular issue of signed vs unsigned integers in signature come up before?
362 2011-11-14 15:13:26 <gavinandresen> roconnor: I think it was a different BER versus DER encoding issue.
363 2011-11-14 15:13:48 <roconnor> ah
364 2011-11-14 15:14:17 <gavinandresen> my memory if famously bad for that kind of detail, though...
365 2011-11-14 15:14:37 <roconnor> that's okay
366 2011-11-14 15:19:06 <gavinandresen> roconnor: If you do find an actual exploit due to OpenSSL accepting multiple encodings, please send email to bitcoin-security@lists.sourceforge.net
367 2011-11-14 15:20:23 <roconnor> :)
368 2011-11-14 15:20:39 <roconnor> I don't think I know enough about openssl to transform this "bug" into an exploit unfortunately
369 2011-11-14 15:21:17 <gavinandresen> Last time 'we' thought about it, the consensus was "it makes us uncomfortable, but we don't see how to exploit it..."
370 2011-11-14 15:21:25 <sipa> i don't think signatures are ever reconstructed and compared to other signatures
371 2011-11-14 15:21:30 <sipa> they're just checked for validity
372 2011-11-14 15:22:12 <roconnor> my concern would be the use in a more general system where one part of the system thinks the signature is valid, and another part of the system (not using openssl) thinks it is invalid.
373 2011-11-14 15:22:26 <AlexWaters1> so i built sipa's dumpallkeys branch, ran bitcoind, ran bitcoind gethexprivkeys > privatkeys.txt, and compared to wallet.dat with bfind.py (102 matches). I then encrypted the wallet and ran bfind.py again - and it's still returning 102 matches. surely I am missing something here...
374 2011-11-14 15:22:31 <roconnor> I imagine that could break some invarients
375 2011-11-14 15:22:47 <sipa> AlexWaters1: encrypted using which version?
376 2011-11-14 15:23:01 <gavinandresen> AlexWaters1: what sipa said, his branch doesn't include the fix
377 2011-11-14 15:23:07 <AlexWaters1> same build, ahhh
378 2011-11-14 15:23:08 <AlexWaters1> lol
379 2011-11-14 15:23:10 <AlexWaters1> wow, sorry
380 2011-11-14 15:23:22 <sipa> ok, that just proves how bad the situation is
381 2011-11-14 15:23:23 <roconnor> this system wouldn't be bitcoin; some other system using openssl
382 2011-11-14 15:23:55 <AlexWaters1> i just stole all my keys =O
383 2011-11-14 15:24:31 <sipa> naughty you
384 2011-11-14 15:26:04 <gavinandresen> sipa:  what does this mean:  GetAllReserveKeyHashes() : unknown key in key pool
385 2011-11-14 15:26:57 <gavinandresen> (test case was:  your branch, brand-new wallet.  My fix:  encrypt wallet.  Your branch:  unlock wallet, then try to gethexprivkeys)
386 2011-11-14 15:27:09 <sipa> gavinandresen: there's a keypool entry in the wallet.dat with a pubkey for which no privkey is known
387 2011-11-14 15:27:44 <sipa> wait a sec
388 2011-11-14 15:27:48 <sipa> that code may be wrong
389 2011-11-14 15:39:26 <skitixch> hey, could someone help me figure out why this example of a websocket implementation isn't working for me? https://gist.github.com/1215530
390 2011-11-14 15:42:50 <skitixch> or how about this, is anyone familiar with websockets in here?
391 2011-11-14 15:44:34 <sipa> gavinandresen: do you get any reserve keys from dumping an encrypted but unlocked wallet?
392 2011-11-14 15:44:56 <nmat> skitixch I think mtgox no longer supports websockets. let me find the thread...
393 2011-11-14 15:45:06 <gavinandresen> sipa:  I'll check...  (I was doing some poking around with bitcointools)
394 2011-11-14 15:45:51 <skitixch> nmat (!) if that's the case, is there still a way to pull realtime market stats?
395 2011-11-14 15:46:47 <nmat> skitixch https://bitcointalk.org/index.php?topic=14412.msg613253#msg613253
396 2011-11-14 15:46:49 <gavinandresen> sipa:  I'm running with keypool=10, by the way, makes testing a lot faster
397 2011-11-14 15:47:43 <gavinandresen> sipa:  unlock wallet, then call dumpwallet and I get the GetAllReserveKeyHashes() : unknown key in key pool error
398 2011-11-14 15:48:00 <gavinandresen> (is there another way to dump the wallet?)
399 2011-11-14 15:48:33 <sipa> it seems the code in GetAllReserveKeys wasn't adapted from encrypted wallets
400 2011-11-14 15:48:48 <skitixch> nmat awesome, thanks for the heads up. Do you know if the mtgox api on their site is still accurate then?
401 2011-11-14 15:49:02 <gavinandresen> sipa: do you have time to fix it now?
402 2011-11-14 15:51:15 <ByteCoin> ;;seen runeks
403 2011-11-14 15:51:15 <gribble> I have not seen runeks.
404 2011-11-14 15:51:17 <nmat> skitixch I have no idea... check the mtgox api at the wiki and magical tux posts at bitcointalk. this was a recent change
405 2011-11-14 15:52:23 <skitixch> nmat: thank you so much, this partially explains why I was tearing my hair out the other day.
406 2011-11-14 15:52:55 <nmat> skitixch np. good luck
407 2011-11-14 15:53:00 <skitixch> thanks :)
408 2011-11-14 15:53:03 <ByteCoin> Hi sipa, gavinandresen. Has the current problems with plaintext private keys remaining in the database made you inclined to consider moving to a deterministic wallet?
409 2011-11-14 15:53:13 <ByteCoin> Over some timescale...
410 2011-11-14 15:53:39 <gavinandresen> ByteCoin: yes, I was inclined to move to a deterministic wallet even before the current problem...
411 2011-11-14 15:54:31 <gavinandresen> ... although I think multi-device signatures is still more important (because the passphrase-stealing-trojan is a bigger threat)
412 2011-11-14 15:55:12 <ByteCoin> Ok. Agreed on all points. Do you think that all the developers a positive about deterministic wallets?
413 2011-11-14 15:55:24 <ByteCoin> Just off the top of your head...
414 2011-11-14 15:55:39 <AlexWaters1> gavinandresen: before i encrypt the wallet to test against the hex output - should i be building from https://github.com/gavinandresen/bitcoin-git/tree/encryptionbug ?
415 2011-11-14 15:55:58 <gavinandresen> AlexWaters1: yes
416 2011-11-14 15:56:13 <AlexWaters1> gavinandresen: i am getting an error in db.cpp:47:42 ... has no member named 'generic_string' ...
417 2011-11-14 15:56:33 <AlexWaters1> during build
418 2011-11-14 15:56:38 <gavinandresen> grrr..  boost filesystem 2/3 difference...
419 2011-11-14 15:56:53 <gavinandresen> I think i need to add an #ifdef
420 2011-11-14 15:56:57 <gavinandresen> one sec
421 2011-11-14 15:57:35 <sipa> gavinandresen: should be fixed, just testing whether it compiles now
422 2011-11-14 15:59:02 <sipa> gavinandresen: ok, done
423 2011-11-14 15:59:09 <sipa> untested, but the bug was quite obvious
424 2011-11-14 15:59:29 <gavinandresen> sipa: thanks.... Alex: figuring out what the right #ifdef is now...
425 2011-11-14 16:00:56 <AlexWaters1> gavinandresen: cool - i'm in no rush if you're busy. i can pull some other tests in my new shiny windows qt binary that i have been playing with
426 2011-11-14 16:01:23 <gavinandresen> AlexWaters1: I'm busy with this :-)
427 2011-11-14 16:02:28 <cjdelisle> ByteCoin: did you propose a system for supporting light clients using an unspent transaction hashtree?
428 2011-11-14 16:05:07 <AlexWaters1> ;;seen bluematt
429 2011-11-14 16:05:07 <gribble> bluematt was last seen in #bitcoin-dev 2 days, 23 hours, 4 minutes, and 51 seconds ago: <BlueMatt> gavinandresen: hmmm
430 2011-11-14 16:06:32 <ByteCoin> cjdelisle: Yes I did. It was not intended purely for light clients but could be used by all clients. I don't know where the light-client-only misapprehension came from...
431 2011-11-14 16:06:37 <AlexWaters1> does anyone know why jenkins is building bitcoin-qt.exe superbly in http://jenkins.bluematt.me/job/Bitcoin/ws/ but isn't building it at all in http://jenkins.bluematt.me/job/Bitcoin-Testing-Build/ws/ ?
432 2011-11-14 16:07:17 <cjdelisle> do you have a copy of the proposal?
433 2011-11-14 16:07:59 <gavinandresen> alexwaters: I just pushed a fix to the encryptionbug branch
434 2011-11-14 16:08:21 <alexwaters> gavinandresen: ok
435 2011-11-14 16:08:34 <cjdelisle> ByteCoin: I made a similar proposal, which should theoretically allow all clients to become "light clients" in the future. http://btc.pastebay.com/144544  I'd be interested to read your work on the subject.
436 2011-11-14 16:10:27 <cjdelisle> A limitation of my proposal is that when a block comes out, nodes will have to query information about every transaction in that block so you have a "tx count * node count" storm of messages.
437 2011-11-14 16:10:53 <gavinandresen> ByteCoin: I haven't heard any objections to deterministic wallets; the only concern I'd have is if you set your deterministic wallet passphrase when you first get bitcoin you're likely to forget it, because your wallet is empty so you probably don't care much...
438 2011-11-14 16:11:18 <gavinandresen> ByteCoin: ... but a good 'emergency backup' plan of some sort would fix that.
439 2011-11-14 16:12:07 <alexwaters> gavinandresen: it built - thanks
440 2011-11-14 16:12:33 <ByteCoin> gavin: Indeed. The devil's in the implementation details. Thanks for the answer. I'm feeling confident development is going in a positive direction.
441 2011-11-14 16:13:56 <alexwaters> so with an old wallet, after building with the patch - i am still getting 102 matches found
442 2011-11-14 16:14:27 <alexwaters> is the fix retroactive?
443 2011-11-14 16:14:54 <ByteCoin> cjdelisle: My balance sheet proposal is probably best explained here https://bitcointalk.org/index.php?topic=505.0
444 2011-11-14 16:15:23 <gavinandresen> sipa:  thanks, showprivkeys is working now
445 2011-11-14 16:15:38 <ByteCoin> It's more of an idea for discussion rather than a completely specified proposal though...
446 2011-11-14 16:15:54 <gavinandresen> alexwaters: it should upgrade the wallet and then shut down when you run the patched bitcoind
447 2011-11-14 16:15:55 <alexwaters> hmm, i'm reading that it should rewrite the wallet.dat upon encryption - very confused
448 2011-11-14 16:16:14 <gavinandresen> alexwaters: what did you run,when?
449 2011-11-14 16:16:23 <alexwaters> gavinandresen: it gave me that message. i restarted the daemon and then ran bfind.py
450 2011-11-14 16:16:33 <alexwaters> do i have to give the encryptwallet command 2x?
451 2011-11-14 16:16:50 <gavinandresen> alexwaters: nope....
452 2011-11-14 16:17:24 <alexwaters> ok i can make a quick vid to show steps - i think it might be easier
453 2011-11-14 16:17:59 <alexwaters> have people tested with sucessful 0 matches? am i a black sheep right now?
454 2011-11-14 16:18:31 <gavinandresen> working for me...
455 2011-11-14 16:18:40 <alexwaters> ok eta 15 minutes
456 2011-11-14 16:18:45 <gavinandresen> check the dates on your wallet.dat?  Is it being rewritten?
457 2011-11-14 16:19:10 <gavinandresen> ... and are you running the same -datadir for bitcoin and the bfind.py ?
458 2011-11-14 16:19:36 <alexwaters> gavinandresen: yes it has been modified after building your pull
459 2011-11-14 16:20:11 <alexwaters> i have bfind.py running in .bitcoin - the default folder. it's the only datadir i've used (haven't been passing -datadir=)
460 2011-11-14 16:20:31 <alexwaters> i had copied the keyfile.txt to my .bitcoin directory earlier
461 2011-11-14 16:21:14 <alexwaters> privatekeys.txt*
462 2011-11-14 16:23:36 <gavinandresen> alexwaters: testing on ubuntu, right?
463 2011-11-14 16:24:38 <ByteCoin> cjdelisle: I have read your article. Is it being discussed on the forum? The problem with all these schemes (including mine) is that without developer support, there's no point discussing the details,
464 2011-11-14 16:32:27 <sipa> gavinandresen: is the 'extra' key still there as well?
465 2011-11-14 16:33:05 <gavinandresen> sipa: not sure... running a fresh testcase to try to reproduce alex's problem and gethexprivkeys is now returning blank lines when run on an UNencrypted wallet
466 2011-11-14 16:33:56 <sipa> buh, i'll need to do some testing myself i fear - not now though
467 2011-11-14 16:34:45 <gavinandresen> sipa:  oops, nope, mistaken:  it was an encrypted, LOCKED wallet
468 2011-11-14 16:35:15 <sipa> ah, right, getallhexkeys doesn't check whether the wallet state is ok, and getkey fails if not
469 2011-11-14 16:35:19 <sipa> it was written hastily
470 2011-11-14 16:36:37 <alexwaters> gavinandresen: yes natty, sorry was afk
471 2011-11-14 16:39:47 <gavinandresen> alexwaters: I definitely can't reproduce on my Mac, linked against bdb 4.8 ...
472 2011-11-14 16:40:10 <gavinandresen> alexwaters: I'll setup an ubuntu test environment after lunch.  What version of bdb are you linking against?
473 2011-11-14 16:41:13 <alexwaters> hrm, trying to remember where bdb puts their files
474 2011-11-14 16:41:28 <alexwaters> usr/bin?
475 2011-11-14 16:41:47 <alexwaters> nope...
476 2011-11-14 16:43:12 <gavinandresen> look for DB_VERSION_STRING in include/something/db.h
477 2011-11-14 16:43:22 <gavinandresen> (or include/db.h  ... depending ...)
478 2011-11-14 16:43:58 <alexwaters> yeah searching my filesystem for berkeley only came back with python libraries..werid
479 2011-11-14 16:44:01 <alexwaters> ok checking
480 2011-11-14 16:45:05 <gavinandresen> alexwaters: afk for lunch for a bit, but here's the results of my last test run:  https://gist.github.com/1364565
481 2011-11-14 16:45:45 <gavinandresen> (with one of my 'real' wallets, encrypted with a 0.5.0 release candidate build)
482 2011-11-14 16:52:03 <alexwaters> gavinandresen: ok interesting. it could be my weird way of using the python - or my libs - or my wallet coming from sipa's build - or my anger at the Islanders sucking so bad
483 2011-11-14 16:54:10 <gavinandresen> alexwaters: make sure privatekeys.txt looks reasonable... (should be full of hexadecimal strings, 64-characters-per-line....)
484 2011-11-14 17:01:09 <AliciaC> are you sure it's not base64? (I know in other situations base64 is used a lot for cryptographic keys)
485 2011-11-14 17:05:57 <cjdelisle> ByteCoin: sorry, was away having lunch, my proposal is not being discussed on the forum because I am not a forum member, if you feel like pasting it that would be cool.. After reading your proposal I am not sure what you mean by "balance sheet" since there are some advanced transactions and until they are claimed, it is not possible to know "who" has the money so a simple "alice has 5$, bob has 3" type of balance sheet wouldn't work.
486 2011-11-14 17:08:03 <alexwaters> is it possible for bitcoin to build without berkeleydb? this is driving me nuts, i can't find it - and berkeleydb -v doesn't have a path to reference
487 2011-11-14 17:08:35 <cjdelisle> As far as developer support, I always design proposals with the idea that 95% of the community will hate them and try to guerila patch them in to the network even so.
488 2011-11-14 17:09:56 <alexwaters> gavinandresen: the privatekeys.txt is giving me 101 lines, 65 col of hex and an additional linebreak at the end for a total of 102 lines
489 2011-11-14 17:11:12 <alexwaters> i counted the characters across - there's 64
490 2011-11-14 17:11:34 <lianj> the empty line is the secret network-takeover keypair
491 2011-11-14 17:13:18 <gavinandresen> alexwaters: find /usr/include -name db.h -print  aught to find it...
492 2011-11-14 17:13:54 <gavinandresen> ... unless you have your dependencies setup oddly.
493 2011-11-14 17:18:55 <alexwaters> Berkeley DB 4.8.30 - thank you. my brain is runing on fumes (no sleep)
494 2011-11-14 17:19:01 <alexwaters> running*
495 2011-11-14 17:19:24 <alexwaters> lianj: aha!
496 2011-11-14 17:24:26 <roconnor> sipa:
497 2011-11-14 17:24:28 <roconnor> /* Custom primitive type for BIGNUM handling. This reads in an ASN1_INTEGER as a
498 2011-11-14 17:24:30 <roconnor> * BIGNUM directly. Currently it ignores the sign which isn't a problem since all
499 2011-11-14 17:24:31 <roconnor> * BIGNUMs used are non negative and anything that looks negative is normally due
500 2011-11-14 17:24:33 <roconnor> * to an encoding error.
501 2011-11-14 17:24:34 <roconnor> */
502 2011-11-14 17:24:52 <roconnor> This is from openssl-1.0.0e/crypto/asn1/x_bignum.c
503 2011-11-14 17:25:00 <roconnor> so it looks like it is deliberate
504 2011-11-14 17:25:23 <roconnor> Although I question their claim that it isn't a problem.
505 2011-11-14 17:26:02 <roconnor> If this isn't exploitable today; I suspect it is only a matter of time.
506 2011-11-14 17:38:42 <luke-jr> roconnor: that looks like they're saying "not checking for negative, because anything that might be negative should be invalid at a higher level"
507 2011-11-14 19:48:29 <makomk> edcba: if you haven't recovered your bitcoins yet, https://bitcointalk.org/index.php?topic=25091.0 might be worth trying though it's limited and very user-unfriendly.
508 2011-11-14 20:03:46 <wboy1> Hey Guys,any javascript dev's that are interested in joining a bitcoin related funded startup,drop me a message,Thanks!
509 2011-11-14 20:18:37 <edcba> makomk: i didn't lose any bitcoin yet afaik :)
510 2011-11-14 20:39:36 <mjdb_> is anyone mining under opensuse11.4 cant get my second card working...
511 2011-11-14 20:41:06 <mjdb_> or even just general help...  i have a monitor hooked up and a desktop running from both cards under xinerama
512 2011-11-14 20:41:16 <mjdb_> aticonfig --lsa shows both cards
513 2011-11-14 20:41:25 <mjdb_> clinfo shows just 1
514 2011-11-14 21:06:37 <tcatm> cool new bitcoincharts feature: raw chart data in a table :)
515 2011-11-14 21:07:02 <Mqrius> Does nibor have a presence on IRC?
516 2011-11-14 21:07:37 <edcba> same as namtab i guess
517 2011-11-14 21:08:30 <Satori> I'm building a site that uses BitCoin, and I need to know how to get everything installed and configured.  Is there anyone knowledgeable on this here?
518 2011-11-14 21:08:52 <edcba> lol
519 2011-11-14 21:09:07 <cjdelisle> nah, nobody here really knows anything
520 2011-11-14 21:09:23 <edcba> maybe 4 ppl have implemented bitcoin themselves here i guess
521 2011-11-14 21:09:57 <Satori> Beats the market speculator convo scrolling through #bitcoin i suppose.
522 2011-11-14 21:10:21 <edcba> indeed
523 2011-11-14 21:11:42 <roconnor> Satori: I think you just download the binaries and run bitcoind (or bitcoin)
524 2011-11-14 21:11:53 <roconnor> Satori: then it is available for RPC
525 2011-11-14 21:12:13 <Satori> I'm using Drupal 7 and its plug-ins.  They're asking for JSON-RPC, that's working with XMLRPC.  As I'm not very familiar with PHP, I'm uncertain whether there's a specific library I need to add to my PHP configuration.  I already have XMLRPC.
526 2011-11-14 21:12:14 <roconnor> oh wait, maybe there is a configuration file to edit
527 2011-11-14 21:12:26 <Satori> There is.  That I can probably get myself.
528 2011-11-14 21:12:35 <edcba> yes to set your user/pass :)
529 2011-11-14 21:20:41 <tcatm> sipa: the y-axis looks a bit weird on http://bitcoin.sipa.be/speed-thumbnail.png
530 2011-11-14 21:21:06 <Satori> Does anyone know whether JSON-RPC is part of XML-RPC, or needs to be added somehow?
531 2011-11-14 21:27:44 <luke-jr> Satori: JSON-RPC has nothing to do with XML-RPC
532 2011-11-14 21:28:59 <Satori> luke-jr: My understanding is that Drupal uses XML-RPC to interact with JSON-RPC, or the other way 'round.  Website interface to RPC to bitcoind.
533 2011-11-14 21:29:29 <luke-jr> k, well Drupal is stupid, not the norm
534 2011-11-14 21:29:43 <Satori> Hey, thanks.  And those shoes look nice.
535 2011-11-14 21:29:46 <Satori> =)
536 2011-11-14 21:31:15 <Satori> Found the answer.  JSON-RPC has come standard with PHP since 5.2.0 and on, in case anyone else asks.  It's likely, as bitcoin-for-Drupal is just starting to happen.
537 2011-11-14 21:32:34 <Satori> luke-jr: How do most sites do it?  Site -> RPC -> BitCoin, yes?
538 2011-11-14 21:32:55 <luke-jr> dunno
539 2011-11-14 21:33:01 <luke-jr> I just use system()
540 2011-11-14 21:33:05 <luke-jr> <.<
541 2011-11-14 21:33:41 <Satori> Alrighty.  Thanks guys!
542 2011-11-14 21:34:01 <tcatm> Satori: with a good webserver you could proxy RPC so you can access it via JavaScript (I do that for my js-remote demo ;)
543 2011-11-14 21:35:09 <Satori> tcatm: Worth knowing.  Drupal essentially constrains you to work with the modules available or build one yourself though.
544 2011-11-14 21:36:51 <Diablo-D3> guess what peopl
545 2011-11-14 21:36:55 <Diablo-D3> its share the pain time
546 2011-11-14 21:36:59 <Diablo-D3> http://pastebin.com/VuizTHAm
547 2011-11-14 21:37:02 <Diablo-D3> behold, PAIN
548 2011-11-14 21:38:44 <cocktopus> wat
549 2011-11-14 21:38:49 <cocktopus> ees
550 2011-11-14 21:38:51 <cocktopus> dees
551 2011-11-14 21:38:53 <cocktopus> shit
552 2011-11-14 21:39:30 <phantomcircuit> what
553 2011-11-14 21:39:31 <phantomcircuit> the
554 2011-11-14 21:39:32 <phantomcircuit> fuck
555 2011-11-14 21:39:50 <phantomcircuit> HESessionResults
556 2011-11-14 21:39:56 <phantomcircuit> the fuck could that be
557 2011-11-14 21:40:18 <Diablo-D3> [05:38:09] <Diablo-D3> apparently
558 2011-11-14 21:40:32 <cocktopus> oh jesus
559 2011-11-14 21:40:57 <cocktopus> quick, someone refactor it to one line before my brain '
560 2011-11-14 21:41:01 <cocktopus> splodes
561 2011-11-14 21:41:04 <Diablo-D3> too late
562 2011-11-14 21:42:46 <da2ce7> Diablo-D3, http://pastebin.com/VuizTHAm  <--- what is that ugly piece of shit?
563 2011-11-14 21:43:05 <Diablo-D3> da2ce7: see description
564 2011-11-14 21:43:28 <phantomcircuit> Diablo-D3, that is
565 2011-11-14 21:43:31 <da2ce7> now hiring now ?
566 2011-11-14 21:43:32 <phantomcircuit> impressively stupid
567 2011-11-14 21:43:41 <Diablo-D3> oh and the fun part?
568 2011-11-14 21:43:44 <Diablo-D3> it might be in google's code.
569 2011-11-14 21:43:49 <da2ce7> omg.
570 2011-11-14 21:44:26 <Diablo-D3> if your java looks like this, I will rape you in your sleep
571 2011-11-14 21:45:00 <Matt_von_Mises> Hello. Since you can broadcast transactions to the network that have a time before they are valid, I assume future software could create repeat payments without needing to be online?
572 2011-11-14 21:45:20 <Diablo-D3> Matt_von_Mises: no.
573 2011-11-14 21:45:21 <Matt_von_Mises> Just need to broadcast the payments all at once that come valid after intervals.
574 2011-11-14 21:45:36 <Diablo-D3> because "future" transactipns I _think_ cant be more than 10 minutes in the future.
575 2011-11-14 21:45:37 <Matt_von_Mises> I didn't read something right then
576 2011-11-14 21:45:40 <da2ce7> Matt_von_Mises, yes, but you need to do some crazy scripting stuff. afaik
577 2011-11-14 21:45:46 <Diablo-D3> or what da2ce7 said
578 2011-11-14 21:45:56 <Matt_von_Mises> "because "future" transactipns I _think_ cant be more than 10 minutes in the future." THat isn't what I read
579 2011-11-14 21:46:12 <Matt_von_Mises> I read you can place a time into transactions where it only is valid after that time.
580 2011-11-14 21:46:18 <Diablo-D3> well, it'd be weird if it works, Matt_von_Mises.
581 2011-11-14 21:46:22 <Matt_von_Mises> And it didn't say only 10 minutes
582 2011-11-14 21:46:25 <phantomcircuit> either way it's disabled iirc
583 2011-11-14 21:46:40 <phantomcircuit> yes it is
584 2011-11-14 21:46:48 <phantomcircuit> it's by block number of by unix timestamp
585 2011-11-14 21:47:00 <phantomcircuit> Matt_von_Mises, so the answer is you should but you cant
586 2011-11-14 21:47:04 <Matt_von_Mises> Disabled?
587 2011-11-14 21:47:19 <Matt_von_Mises> People were talling me this could be done before
588 2011-11-14 21:47:25 <phantomcircuit> default client drops transactions which dont have lock_time == 0
589 2011-11-14 21:47:43 <Matt_von_Mises> You could create self-terminating wallets with a third party that send the coins back to you after a time period.
590 2011-11-14 21:47:44 <phantomcircuit> Diablo-D3, do you know why?
591 2011-11-14 21:48:19 <Matt_von_Mises> So now you cannot make joint wallets that terminate automatically?
592 2011-11-14 21:48:32 <Matt_von_Mises> It was on the bitcoin wiki, it said it could be don
593 2011-11-14 21:48:33 <Matt_von_Mises> e
594 2011-11-14 21:48:36 <phantomcircuit> well yes and no
595 2011-11-14 21:48:38 <Matt_von_Mises> But the lock time is basically a lie?
596 2011-11-14 21:48:54 <phantomcircuit> mostly no
597 2011-11-14 21:48:58 <da2ce7> Matt_von_Mises, what you are talking about it is planned, just not implemented yet.  Scripting bitcoin tx's is very hard.
598 2011-11-14 21:48:58 <phantomcircuit> but kind of yes
599 2011-11-14 21:49:15 <phantomcircuit> da2ce7, it's actually implemented but disabled
600 2011-11-14 21:50:00 <Diablo-D3> do I know why it doesnt work?
601 2011-11-14 21:50:02 <da2ce7> phantomcircuit, so the code is one switch way from working?
602 2011-11-14 21:50:04 <Diablo-D3> yeah, because theres no ui for it
603 2011-11-14 21:50:06 <Matt_von_Mises> So in the future I make a joint wallet with a third party to make trustable instant payments, I use the service to send some bitcoins to a normal address but the person wont get them because "it's disabled"?
604 2011-11-14 21:50:19 <Matt_von_Mises> With the older software
605 2011-11-14 21:50:29 <Matt_von_Mises> Older in the context of this future idea.
606 2011-11-14 21:50:50 <phantomcircuit> Matt_von_Mises, im actually not sure about that one
607 2011-11-14 21:50:53 <Matt_von_Mises> Wait but for that idea...
608 2011-11-14 21:50:57 <da2ce7> Matt_von_Mises, well 'non-standard tx's' don't get relayed; or automaticaly acepted into a block.
609 2011-11-14 21:50:57 <Matt_von_Mises> It would be fine
610 2011-11-14 21:51:08 <Matt_von_Mises> Because the lock time is only used for the transaction to myself
611 2011-11-14 21:51:13 <Matt_von_Mises> And I ahve the new software
612 2011-11-14 21:51:16 <da2ce7> however if you are mining your own blocks you can place em' in and your tx's will be still vaild.
613 2011-11-14 21:51:20 <phantomcircuit> Matt_von_Mises, you could swing it if you could convince a miner actually
614 2011-11-14 21:51:24 <Matt_von_Mises> But I can't send lock time transactions to people with old software?
615 2011-11-14 21:51:37 <phantomcircuit> i remember the reason for it now too
616 2011-11-14 21:51:40 <da2ce7> Matt_von_Mises, no everyone will except em'
617 2011-11-14 21:51:49 <phantomcircuit> the cutoff is hard
618 2011-11-14 21:51:58 <phantomcircuit> and not all nodes have the same time
619 2011-11-14 21:52:05 <Matt_von_Mises> Hold on, what are you saying now. Clients will accept them?
620 2011-11-14 21:52:07 <Matt_von_Mises> But miners wont?
621 2011-11-14 21:52:22 <phantomcircuit> so it makes doing a low confirm double spend easier
622 2011-11-14 21:52:26 <da2ce7> Matt_von_Mises, everyone accepts them IF they get into a block...
623 2011-11-14 21:52:33 <da2ce7> getting into a block is the hard part.
624 2011-11-14 21:52:41 <Matt_von_Mises> So it is a miner problem?
625 2011-11-14 21:52:55 <da2ce7> no it is a stablity problem.
626 2011-11-14 21:52:55 <phantomcircuit> Matt_von_Mises, normal clients wont relay them, so they wont tend to make it to a miner
627 2011-11-14 21:53:00 <phantomcircuit> so they dont tend to get into blocks
628 2011-11-14 21:53:08 <Matt_von_Mises> So they are valid transactions, you just need to have miners that mine the lock time transactions and no miners accept this yet?
629 2011-11-14 21:53:25 <da2ce7> no
630 2011-11-14 21:53:32 <da2ce7> eliguis should
631 2011-11-14 21:53:33 <Matt_von_Mises> Clients don't relay them so when you broadcast, they get lost?
632 2011-11-14 21:53:39 <Matt_von_Mises> Or stuck
633 2011-11-14 21:53:44 <Matt_von_Mises> Whatever language I should use
634 2011-11-14 21:53:45 <da2ce7> if you send directly to that miner, it should work.
635 2011-11-14 21:54:04 <Matt_von_Mises> Does the protocol allow you to find miners on the network?
636 2011-11-14 21:54:16 <phantomcircuit> Matt_von_Mises, no you have to guess
637 2011-11-14 21:54:36 <Matt_von_Mises> Guess? Well that wont work out then.
638 2011-11-14 21:54:36 <phantomcircuit> Matt_von_Mises, although if you just want to send a transaction to everybody that's actually a fairly cheap operation
639 2011-11-14 21:55:09 <Matt_von_Mises> Alright,s o you send the transaction to everyone and you are safe in the knowledge that it will be processed?
640 2011-11-14 21:55:30 <Matt_von_Mises> With the lock time element included?
641 2011-11-14 21:57:51 <sipa> AliciaC: i wrote it, it's hexadecimal :)
642 2011-11-14 21:58:06 <luke-jr> sipa: next time use tonal!
643 2011-11-14 21:59:05 <da2ce7> luke-jr is the fore-runner of my 'troll of the year' award; :)
644 2011-11-14 21:59:23 <luke-jr> da2ce7: 'cept I ain't trollin
645 2011-11-14 21:59:34 <da2ce7> :O
646 2011-11-14 22:00:15 <Matt_von_Mises> Since I'm doing an online bitcoin survey should I just assume repeat payments is a feature I can add to a list in a question?
647 2011-11-14 22:01:24 <da2ce7> Matt_von_Mises, maybe; depends if people want to wait annother 3months for it or not...
648 2011-11-14 22:01:54 <da2ce7> there is lost of work to get a feature working 'in-proof-of-concept' to stable and solid...
649 2011-11-14 22:02:18 <da2ce7> even our simple 'encrypt wallet' function had* has issues.
650 2011-11-14 22:02:33 <da2ce7> and that took lots of work also,
651 2011-11-14 22:03:40 <da2ce7> the bitcoin community has very good programmers;  however the problems we are dealing with are non-trivial if you want to do them in  a super-solid and secure way.
652 2011-11-14 22:03:46 <Matt_von_Mises> Ok, well thanks for the answers
653 2011-11-14 22:03:56 <sipa> the software is still beta, and there are far more urgent matters to deal with first
654 2011-11-14 22:04:01 <Matt_von_Mises> People have already been working on the repeat transactions? I didn't even know
655 2011-11-14 22:04:10 <Matt_von_Mises> Urgent matters?
656 2011-11-14 22:04:15 <Matt_von_Mises> What are those?
657 2011-11-14 22:04:27 <sipa> security
658 2011-11-14 22:04:49 <sipa> things like second keys, external devices, deterministic wallets
659 2011-11-14 22:06:31 <gmaxwell> even after the core security things are done .... there are more secondary security improvements like DOS resistance, network paritioning detection, double spend detection.
660 2011-11-14 22:11:57 <Matt_von_Mises> There aren't any severe security issues though, right?
661 2011-11-14 22:13:22 <gmaxwell> there isn't anything that isn't well understood by bitcoin users, except perhaps the recently discovered fact that the wallet encryption can leave unencrypted data in the wallet.
662 2011-11-14 22:13:58 <gmaxwell> But just because people are aware of the security limitations and aren't in any severe danger that doesn't mean they aren't essential priorities for development.
663 2011-11-14 22:14:50 <gmaxwell> I think it's fair to say that security should be the primary focus of the core developers, simply because there is more room for experimentation, diversity, market solutions, etc. for most other things.
664 2011-11-14 22:16:26 <sipa> gmaxwell: i don't understand that last sentence
665 2011-11-14 22:16:54 <cjdelisle> core devs need to do security because users will push feature patches..
666 2011-11-14 22:17:06 <cjdelisle> as I understand
667 2011-11-14 22:17:34 <gmaxwell> yes basically. Or route around missing features with external services.
668 2011-11-14 22:17:53 <gmaxwell> But you can't route around a loss of confidence from less security.
669 2011-11-14 22:19:01 <gmaxwell> and security has little tolerance for misunderstanding the system, while other things may.
670 2011-11-14 22:22:02 <cjdelisle> Is it planned to use wallet crypto from the start in the future?
671 2011-11-14 22:22:43 <Matt_von_Mises> I'm reading this -> https://en.bitcoin.it/wiki/Smart_Property But would it be upheld in current legal systems?
672 2011-11-14 22:24:06 <sipa> cjdelisle: 0.5.0rc4 will flush the keypool when encrypting the wallet, so if you encrypt a fresh wallet, you end up with the same
673 2011-11-14 22:24:28 <cjdelisle> Because wallet crypto could be worked into the UI very nicely with a: Welcome to Bitcoin, [new wallet] [open wallet]
674 2011-11-14 22:25:06 <cjdelisle> [new wallet] -> Name your wallet: ___  Passphrase: ___
675 2011-11-14 22:25:16 <cjdelisle> Then it feels natural
676 2011-11-14 22:25:23 <sipa> That's one thing that is not clear to me yet: should the bitcoin ui have one (or more) internal wallets, that can be exported and imported
677 2011-11-14 22:25:48 <sipa> or should it be considered a view/editor/manager for existing wallet files, stored at locations you choose
678 2011-11-14 22:25:58 <cjdelisle> ^^
679 2011-11-14 22:26:05 <cjdelisle> I like the second FWIW
680 2011-11-14 22:26:21 <cjdelisle> Most software "thinks" that way
681 2011-11-14 22:26:51 <luke-jr> sipa: neither
682 2011-11-14 22:26:57 <luke-jr> UIs shouldn't touch wallet files at all
683 2011-11-14 22:27:19 <luke-jr> they should talk to wallet servers over a standard protocol, and the latter deal with all the security issues
684 2011-11-14 22:27:30 <cjdelisle> mmhmm
685 2011-11-14 22:27:36 <sipa> ok; same question for your wallet server
686 2011-11-14 22:28:51 <luke-jr> I think there's room for both single-user wallet servers and multiuser servers
687 2011-11-14 22:33:34 <agath> Q. What's yellow and dangerous?
688 2011-11-14 22:33:45 <agath> A. *((int*)rand()) = 0xffff00;
689 2011-11-14 22:34:35 <cjdelisle> that's yellow?
690 2011-11-14 22:34:54 <iocor> 0xffff00; is yellow
691 2011-11-14 22:35:11 <iocor> and *((int)*rand()) will almost certainly segfault
692 2011-11-14 22:35:14 <cjdelisle> if by yellow you mean pink, yes.
693 2011-11-14 22:35:25 <iocor> red + green = yellow
694 2011-11-14 22:35:29 <sipa> what about *((int*)rand) = 0xFFFF00