1 2011-12-16 00:14:33 <BlueMatt> luke-jr: you have a gribble msg waiting
  2 2011-12-16 00:14:47 <luke-jr> I do?
  3 2011-12-16 00:15:00 <luke-jr> :P
  4 2011-12-16 02:01:40 <gmaxwell> bitcoin-address aliasing scheme?
  5 2011-12-16 02:01:51 <BlueMatt> the whole user@domain stuff
  6 2011-12-16 02:02:34 <BlueMatt> the problem is for it to be secure you HAVE to implement a full dnssec-resolving dns recursor in bitcoin
  7 2011-12-16 02:03:09 <BlueMatt> and since some ISPs intercept all dns traffic and forward it to their own dns servers instead of letting it out onto the open web (ok, so Ive only seen it once, but still) you break the security model
  8 2011-12-16 02:03:38 <BlueMatt> (as isp-resolved dns records wont have a full verifiable dnssec chain in them)
  9 2011-12-16 02:03:52 <BlueMatt> also, https is just a generally better idea :)
 10 2011-12-16 02:08:13 <gmaxwell> BlueMatt: sure, yea, you can't count on DNS working right now.
 11 2011-12-16 02:08:27 <gmaxwell> I've personally had an ISP that did that, and I ended up setting up a ipv6 forwarder.
 12 2011-12-16 02:08:34 <gmaxwell> (and later switched ISPs)
 13 2011-12-16 02:08:47 <BlueMatt> ok, so why is dns as an aliasing scheme being considered?
 14 2011-12-16 02:10:24 <gmaxwell> I didn't know that it was. You've got me.
 15 2011-12-16 02:10:31 <BlueMatt> heh
 16 2011-12-16 02:10:43 <gmaxwell> oh, thats that aliasing thread.. 0015? yea, I haven't opened that one.
 17 2011-12-16 02:10:50 <gmaxwell> I thought it was about address book entries.
 18 2011-12-16 02:11:06 <BlueMatt> heh, Ive read like 3 of the emails out of what, like 30?
 19 2011-12-16 02:11:22 <luke-jr> aliasing thread seems too far gone, I don't read it anymore
 20 2011-12-16 02:11:55 <BlueMatt> well dns isnt an option, so its https or someone come up with a better idea
 21 2011-12-16 02:12:05 <luke-jr> no matter what, aliases make Bitcoin centralized.
 22 2011-12-16 02:12:23 <BlueMatt> pretty much
 23 2011-12-16 02:12:44 <BlueMatt> unless you do aliascoin and make bitcoin nodes join that chain too...
 24 2011-12-16 02:12:44 <luke-jr> I think we should stick to addresses and non-human-readable URIs
 25 2011-12-16 02:12:55 <BlueMatt> I still think URIs are much better than aliases
 26 2011-12-16 02:13:03 <luke-jr> BlueMatt: also, any alias system makes a squatting rush
 27 2011-12-16 02:13:11 <luke-jr> sure
 28 2011-12-16 02:13:23 <BlueMatt> but, frankly, I dont have any preferences https-alias or no-alias
 29 2011-12-16 02:13:34 <luke-jr> bitcoin://dashjr.org/<address>
 30 2011-12-16 02:13:46 <BlueMatt> anyway, just thought I'd share the dns-scene-doesnt-work-period idea, back to studying for me
 31 2011-12-16 02:14:15 <luke-jr> require the server to sign its SSL key with <address>, then they can renegotiate a new one for the real send
 32 2011-12-16 02:14:44 <BlueMatt> a. thats a pita, b. it doesnt solve the problem of something you can convey over the phone in 10 seconds or less
 33 2011-12-16 02:15:22 <luke-jr> BlueMatt: phones are already centralized and insecure. just use a SMS
 34 2011-12-16 02:15:44 <BlueMatt> you get the point
 35 2011-12-16 02:15:44 <luke-jr> have your cellphone Bitcoin app automate the SMS send/receive even
 36 2011-12-16 02:16:26 <luke-jr> or heck, use e164 :P
 37 2011-12-16 02:16:52 <luke-jr> I suppose we could do bitcoin://domain, and leave the verify-the-key address optional&
 38 2011-12-16 02:50:13 <CIA-100> libbitcoin: genjix bdb * r86b4802f6a3f / (18 files in 7 dirs): bdb_blockchain organizer. http://tinyurl.com/ca6b9o8
 39 2011-12-16 09:29:55 <epscy> i had a strange thought last night
 40 2011-12-16 09:30:20 <epscy> is it possible to divide bitcoin infinitely?
 41 2011-12-16 09:30:57 <theymos> No. There are only 8 decimals of precision.
 42 2011-12-16 09:31:07 <epscy> in a theoretical sense, if all nodes updated periodically to support larger and larger denominations of bitcoin
 43 2011-12-16 09:31:15 <sipa> in that case, yes
 44 2011-12-16 09:31:38 <sipa> you mean smaller denominations, i suppose
 45 2011-12-16 09:31:45 <epscy> yeah
 46 2011-12-16 09:31:55 <theymos> It would even be possible to support arbitrary precision, though that'd probably be a waste of resources.
 47 2011-12-16 09:32:10 <epscy> is it possible that if that happened, bitcoin could become inflationary?
 48 2011-12-16 09:32:21 <sipa> that's an entirely different issue
 49 2011-12-16 09:33:39 <edcba> money representation doesn't influence that :)
 50 2011-12-16 09:34:21 <epscy> i guess my question is, isn't infinitely divisible bitcoins the same as infinite bitcoins?
 51 2011-12-16 09:34:32 <edcba> no
 52 2011-12-16 09:34:45 <sipa> depends on how you implement the extra division
 53 2011-12-16 09:34:55 <edcba> you have an infinty number between 0 and 1
 54 2011-12-16 09:35:00 <epscy> i imagine every time you did it the economy would devalue
 55 2011-12-16 09:35:11 <edcba> still you have only "1"
 56 2011-12-16 09:35:13 <sipa> if you say that 1 "old" unit (0.00000001 BTC) becomes 1000 new units, there is no problem
 57 2011-12-16 09:36:30 <theymos> You can break gold into a near-infinite number of gold atoms, and that doesn't cause inflation.
 58 2011-12-16 09:36:35 <epscy> the new lowest denomination would be worth what the old lowest denomination would be worth
 59 2011-12-16 09:36:52 <theymos> Why?
 60 2011-12-16 09:36:56 <epscy> over time that is what i would expect to happen
 61 2011-12-16 09:37:06 <sipa> that's possible
 62 2011-12-16 09:37:14 <sipa> but entirely independent from the division step
 63 2011-12-16 09:37:42 <epscy> ok but assume that does happen, bitcoin becomes infinite no?
 64 2011-12-16 09:38:28 <sipa> you're just describing price inflation
 65 2011-12-16 09:38:48 <sipa> that may or may not happen, and it's entirely separate from divisibility
 66 2011-12-16 09:39:10 <epscy> i am not sure why you think it is unrelated
 67 2011-12-16 09:39:46 <epscy> i would expect an increase in the supply (including just adding smaller denominations) to cause inflation
 68 2011-12-16 09:40:56 <sipa> it may increase the technical usability of the system, hence causing its fractions to become more valuable, yes
 69 2011-12-16 09:41:57 <epscy> i suppose it is good that these kind of changes have to be made by consensus then
 70 2011-12-16 09:42:11 <sipa> i believe they won't
 71 2011-12-16 09:42:18 <epscy> and good that it could happen if needed
 72 2011-12-16 09:42:26 <sipa> if more divisibiity is needed, i suppose we'll just move to a successor of bitcoin
 73 2011-12-16 09:57:12 <Eliel> also, a successor of bitcoin can be bootstrapped with bitcoin account balances to begin with, although, I'm not sure if it makes sense to do so.
 74 2011-12-16 09:57:47 <sipa> that's dangerous - it could work if it reliably detects a destruction of an old bitcoin coin
 75 2011-12-16 09:58:22 <sipa> otherwise you're basically doing a block chain split, where each old coin becomes spendable once in the origin bitcoin chain, and once in the new system's one
 76 2011-12-16 10:02:46 <Eliel> sipa: I don't see what the bad thing it'd cause is. The new chain is not the same thing, even if the balances are copied over.
 77 2011-12-16 10:03:22 <Eliel> of course, if the reliable detection of old bitcoin coin destruction is not included, it'll mean quite some uncertainty on what the new coins will be worth but...
 78 2011-12-16 10:59:01 <epscy> theymos: the difference between dividing btc and gold is that their is a practical physical limit on dividing gold
 79 2011-12-16 10:59:11 <epscy> divide it too much and it becomes unusable
 80 2011-12-16 10:59:48 <epscy> although we do divide gold into very small amounts, but mainly for industrial uses rather than sharing out its value
 81 2011-12-16 11:06:31 <sipa> epscy: if you'd divide a bitcoin into pieces of 10^-100 BTC, no-one would do transactions with single units either
 82 2011-12-16 11:06:38 <sipa> so there's a practical limit as well
 83 2011-12-16 11:07:53 <epscy> sipa doesn't that depend entirely on what they are worth?
 84 2011-12-16 11:08:20 <Diablo-D3> no
 85 2011-12-16 11:08:26 <Diablo-D3> btc has a lower size limit
 86 2011-12-16 11:08:39 <Diablo-D3> 8 decimal places below the dot instead of the usual 2
 87 2011-12-16 11:08:51 <epscy> Diablo-D3: I am talking theoretically, if all nodes agreed to change the protocol
 88 2011-12-16 11:09:16 <Diablo-D3> epscy: yes but
 89 2011-12-16 11:09:22 <Diablo-D3> its not a mere protocol change
 90 2011-12-16 11:09:36 <Diablo-D3> I think we're already using longs
 91 2011-12-16 11:09:49 <epscy> i understand that there is a hardware limit
 92 2011-12-16 11:09:50 <sipa> so? there's no problem in using uint256's instead
 93 2011-12-16 11:10:32 <epscy> but theoretically if hardware was keeping up and all nodes upgraded as well as using the new protocol
 94 2011-12-16 11:10:43 <Diablo-D3> sipa: uh, we have to do math on these dude
 95 2011-12-16 11:10:58 <Diablo-D3> I doubt you want to have to use gmp.
 96 2011-12-16 11:11:11 <phantomcircuit> changing that would require 100% of nodes to upgrade or be vulnerable to a double spend
 97 2011-12-16 11:11:13 <phantomcircuit> so
 98 2011-12-16 11:11:22 <Diablo-D3> phantomcircuit: no
 99 2011-12-16 11:11:23 <sipa> he's talking theoretically about the economic aspect of bitcoin divisibility
100 2011-12-16 11:11:39 <Diablo-D3> it wouldnt be vulnerable to double spend
101 2011-12-16 11:11:44 <phantomcircuit> Diablo-D3, ok you can run a dual stack and check for double spends... but still
102 2011-12-16 11:11:53 <sipa> you just need a new chain
103 2011-12-16 11:11:54 <Diablo-D3> the minority would no longer be able to create transactions or even verify new blocks
104 2011-12-16 11:11:54 <sipa> period
105 2011-12-16 11:12:08 <epscy> yeah this is all completely hypothetical
106 2011-12-16 11:12:16 <Diablo-D3> blocks have a bitcoin protocol version header, it would need to be incremented.
107 2011-12-16 11:12:42 <cjdelisle> an easier way would be to accept transactions which had twice the output ad they had input, but only once and only for inputs which were all generated before block X
108 2011-12-16 11:12:42 <phantomcircuit> Diablo-D3, you could still create blocks recognized by the old client
109 2011-12-16 11:12:43 <epscy> and I guess I am more interested in the economic affects of repeatedly adding smaller btc denominations
110 2011-12-16 11:12:49 <epscy> which are hard to predict
111 2011-12-16 11:12:52 <phantomcircuit> although you would be kind of fighting against the tide
112 2011-12-16 11:13:04 <Diablo-D3> phantomcircuit: no we cant
113 2011-12-16 11:13:22 <phantomcircuit> Diablo-D3, remember the double spend would be against an old client
114 2011-12-16 11:13:25 <phantomcircuit> so of course you could
115 2011-12-16 11:13:29 <Diablo-D3> no
116 2011-12-16 11:13:36 <phantomcircuit> uhm yes?
117 2011-12-16 11:13:50 <Diablo-D3> new clients would refuse to accept transactions that dont have uint256 btc field.
118 2011-12-16 11:13:55 <phantomcircuit> nobody else would be mining for old version blocks, but you could still do it
119 2011-12-16 11:14:05 <sipa> and old clients still would
120 2011-12-16 11:14:12 <Diablo-D3> old clients would not be able to understand transactions with a uint256 btc field
121 2011-12-16 11:14:17 <phantomcircuit> yes?
122 2011-12-16 11:14:24 <Diablo-D3> ergo, you could not double spend, you _couldnt spend at all_
123 2011-12-16 11:14:29 <sipa> so old clients would ignore it
124 2011-12-16 11:14:41 <Diablo-D3> old clients would have to ignore the whole block as invalid thus be forever stuck in the past
125 2011-12-16 11:14:46 <sipa> so you get a chain split between old client and new clients
126 2011-12-16 11:14:47 <phantomcircuit> Diablo-D3, im assuming you're bumping the version number in the transaction field
127 2011-12-16 11:14:58 <Diablo-D3> phantomcircuit: both block and transaction
128 2011-12-16 11:14:58 <phantomcircuit> which would mean you could select new or old
129 2011-12-16 11:14:58 <sipa> and each old coin can be spent in both
130 2011-12-16 11:15:14 <Diablo-D3> if you're claiming I can double spend on old clients, "no"
131 2011-12-16 11:15:20 <Diablo-D3> because their chain would never continue
132 2011-12-16 11:15:25 <phantomcircuit> Diablo-D3, ok so you spend the coins once with a new and once with an old, new clients see the new and refuse the old double spend
133 2011-12-16 11:15:31 <phantomcircuit> old clients only see the old
134 2011-12-16 11:15:35 <phantomcircuit> double spend
135 2011-12-16 11:15:39 <Diablo-D3> they'd be unable to split the chain because they'd keep being told of new blocks on the chain they cant understand
136 2011-12-16 11:15:49 <sipa> Diablo-D3: and they'd ignore these
137 2011-12-16 11:15:52 <Diablo-D3> sipa: yup
138 2011-12-16 11:16:00 <sipa> and not ignore any blocks they mine themselves
139 2011-12-16 11:16:02 <phantomcircuit> and you'd be able to keep building onto it all by yourself
140 2011-12-16 11:16:09 <phantomcircuit> it would be slow
141 2011-12-16 11:16:09 <sipa> which suddenly becomes extremely easy
142 2011-12-16 11:16:11 <phantomcircuit> but possible
143 2011-12-16 11:16:12 <Diablo-D3> yet they'd keep trying to mine on a non-cohesive new chain
144 2011-12-16 11:16:19 <phantomcircuit> facepalm
145 2011-12-16 11:16:20 <Diablo-D3> which means the double spending happens on phantom coins
146 2011-12-16 11:16:34 <phantomcircuit> Diablo-D3, coins which SOMEONE thinks have value
147 2011-12-16 11:16:35 <Diablo-D3> and thus never never happened
148 2011-12-16 11:16:45 <phantomcircuit> trust me im right?
149 2011-12-16 11:16:47 <Diablo-D3> phantomcircuit: no, because no one would interact with them
150 2011-12-16 11:16:57 <phantomcircuit> yes idiots with ancient clients would
151 2011-12-16 11:16:59 <Diablo-D3> none of the exchanges nor the vendors would use old clients
152 2011-12-16 11:17:08 <Diablo-D3> so their coins would be de facto worthless
153 2011-12-16 11:17:09 <phantomcircuit> there are still people with clients joining #bitcoin
154 2011-12-16 11:17:44 <phantomcircuit> it's possible to prevent it though
155 2011-12-16 11:18:00 <phantomcircuit> for new transactions simply require a corresponding old transaction that burns the "old" coins
156 2011-12-16 11:18:17 <Diablo-D3> phantomcircuit: you're overthinking it
157 2011-12-16 11:20:18 <phantomcircuit> no im just thinking we would need to be very cautious
158 2011-12-16 11:20:28 <phantomcircuit> it's hard to predict what people will do
159 2011-12-16 11:20:57 <sipa> if you're not yet certain whether the new standard would be adopted by a significant part of the infrastructure, you would definitely require such a rule that burns old coins
160 2011-12-16 11:23:37 <phantomcircuit> honestly it will probably just be easier to start a new chain and let people trade both...
161 2011-12-16 11:23:45 <sipa> indeed
162 2011-12-16 11:38:40 <Diablo-D3> [07:20:57] <sipa> if you're not yet certain whether the new standard would be adopted by a significant part of the infrastructure, you would definitely require such a rule that burns old coins
163 2011-12-16 11:38:47 <Diablo-D3> not explictly burn though
164 2011-12-16 11:38:56 <Diablo-D3> because new coins would just normally reference old coins
165 2011-12-16 11:39:24 <sipa> from the point of view of the old system: burn, from the point of view of the new system: use in a new-style tx
166 2011-12-16 11:43:18 <TD> hrmm
167 2011-12-16 11:43:27 <TD> ThreadSafeMessageBox + Qt seems to create notification bubbles
168 2011-12-16 11:43:29 <TD> not actually alert boxes
169 2011-12-16 11:45:24 <Diablo-D3> sipa: but its burned anyhow
170 2011-12-16 11:45:56 <sipa> Diablo-D3: yes, in the new chain - but you need an explicit separate burn in the old chain
171 2011-12-16 11:46:08 <Diablo-D3> sipa: but why are we using two chains?
172 2011-12-16 11:46:11 <Diablo-D3> we only need one.
173 2011-12-16 11:46:49 <sipa> Diablo-D3: because old clients will only ever see the old chain
174 2011-12-16 11:46:58 <sipa> and you must prevent them from doing a double spend
175 2011-12-16 11:47:25 <sipa> and you can't prevent them from building further upon the old chain
176 2011-12-16 11:49:12 <Diablo-D3> but you shouldnt prevent them
177 2011-12-16 11:49:24 <Diablo-D3> you should just let the double spending happen since it isnt a valid tx according to the majority
178 2011-12-16 11:50:43 <sipa> i think you don't see how bad it is for even a minority to think that a double spend is valid
179 2011-12-16 11:51:12 <sipa> i sure as hell don't want to be in that minority as a merchant
180 2011-12-16 11:59:05 <Diablo-D3> sipa: yes, and merchants always run the newest client
181 2011-12-16 11:59:07 <Diablo-D3> ergo no problem
182 2011-12-16 11:59:34 <TD> just like all merchants use chip/pin and verified by visa
183 2011-12-16 11:59:50 <Diablo-D3> verified by visa doesnt work anyhow
184 2011-12-16 12:00:53 <edcba> verified by visa means visa doesn't do shit
185 2011-12-16 12:01:08 <edcba> and makes pay merchant if somethings goes wrong :)
186 2011-12-16 12:01:44 <TD> you'd expect pool operators to run the latest version
187 2011-12-16 12:01:46 <TD> they don't
188 2011-12-16 12:02:22 <edcba> like expecting corporate people runs IE9
189 2011-12-16 12:30:14 <CIA-100> libbitcoin: genjix bdb * rf828f9093578 /configure.ac: Full optimisations ON. Iff UB exists then I want to suffer. Pain is good. http://tinyurl.com/c48l2u3
190 2011-12-16 12:56:42 <eueueue> why the page bitcoin.org doesn't show 0.5.1 version?
191 2011-12-16 12:57:01 <eueueue> ops
192 2011-12-16 12:57:03 <eueueue> sorry
193 2011-12-16 12:57:08 <eueueue> didn't refresh
194 2011-12-16 12:57:15 <eueueue> everything is ok
195 2011-12-16 12:58:06 <eueueue> Is there any plan to have an option to automatically update bitcoin? something like what firefox does
196 2011-12-16 12:58:34 <tcatm> sure. once we've figured out how to do that securely
197 2011-12-16 12:59:06 <eueueue> ok
198 2011-12-16 12:59:38 <edcba> ie signing package with some bitcoin address :)
199 2011-12-16 13:00:28 <sipa> probably gpg keys
200 2011-12-16 13:00:39 <sipa> of gitian builds
201 2011-12-16 13:00:44 <sipa> by multiple developers
202 2011-12-16 13:01:46 <kinlo> dunno if that will remain nessesary
203 2011-12-16 13:02:11 <kinlo> isn't it the task of the package managers we all have sinds like forever on the good operating systems, and the appstores on the others?
204 2011-12-16 13:02:34 <kinlo> ok, there is one os still a bit behind, but those users are used to that :)
205 2011-12-16 13:11:29 <TD> package management is death for updates
206 2011-12-16 13:11:42 <TD> how fresh is the typical linux distro? answer: they always lag, often by months
207 2011-12-16 13:11:52 <TD> working auto update for linux/serverside installations is important
208 2011-12-16 13:11:57 <TD> for the mac, apple doesn't like bitcoin. so forget that.
209 2011-12-16 13:12:03 <TD> windows has no app store. so forget that too.
210 2011-12-16 13:12:18 <TD> the only platform that has any kind of working auto update that also accepts bitcoin is android
211 2011-12-16 13:12:31 <TD> it'd be really good to make auto update easy
212 2011-12-16 13:32:33 <Diablo-D3> bwhahaha
213 2011-12-16 13:32:44 <Diablo-D3> I wonder how long it'll take before the post I just made gets flagged.
214 2011-12-16 13:38:03 <wumpus> oh man, that reminds me of windows, with all applications trying to do their own updates and update managers
215 2011-12-16 13:38:10 <wumpus> I thought we were saved from that crap on linux
216 2011-12-16 13:38:49 <wumpus> you could always make a ppa with nightly builds if you really want people to always have the latest version
217 2011-12-16 13:58:53 <epscy> Diablo-D3: which post?
218 2011-12-16 14:31:36 <Diablo-D3> epscy: well if I say then someone will flag it
219 2011-12-16 15:15:13 <BlueMatt> luke-jr: whats the url for your 0.4.X and 0.5.0.X git trees
220 2011-12-16 15:23:03 <TD> goddamnit
221 2011-12-16 15:23:14 <TD> how can the java community have made such a pigs ear of something so basic
222 2011-12-16 15:23:17 <TD> devrandom: poke
223 2011-12-16 15:23:25 <kinlo> mmmz
224 2011-12-16 15:23:44 <kinlo> did something change in 0.5.1 in the way bitcoin loads it's block index and such?
225 2011-12-16 15:23:50 <sipa> no
226 2011-12-16 15:23:52 <BlueMatt> kinlo: why so?
227 2011-12-16 15:24:00 <kinlo> starting bitcoind is a magnitude slower then previous version
228 2011-12-16 15:24:17 <sipa> compared to 0.5.0?
229 2011-12-16 15:24:27 <BlueMatt> no reason to be...
230 2011-12-16 15:24:36 <kinlo> yeah - I'm running macosx, might be important
231 2011-12-16 15:24:50 <BlueMatt> still, dont think any code changed there...
232 2011-12-16 15:25:09 <sipa> only dns seeding changed in the startup process
233 2011-12-16 15:28:32 <BlueMatt> mmm, that could be why he sees an improvement, because that could take a ton of time if you dns resolvers are slow (or if a dnsseed is down)
234 2011-12-16 15:29:01 <sipa> but it became slower, he says
235 2011-12-16 15:29:13 <BlueMatt> oh, nevermind...
236 2011-12-16 15:29:43 <BlueMatt> sipa: what are your and luke-jr's dnsseed addresses again?
237 2011-12-16 15:29:49 <BlueMatt> or to-be-dnsseed addresses?
238 2011-12-16 15:30:07 <sipa> mine will be seed.bitcoin.sipa.be
239 2011-12-16 15:35:00 <kinlo> mmmz
240 2011-12-16 15:36:03 <gmaxwell> kinlo: tail debug.log while it starts and see if you can see where its slow
241 2011-12-16 15:36:21 <kinlo> http://www.pastie.org/pastes/3027073/text
242 2011-12-16 15:36:59 <kinlo> kinda weird output
243 2011-12-16 15:37:13 <kinlo> according to that, 0.4 was also really slow :)
244 2011-12-16 15:37:27 <kinlo> but 0.5.0 was very fast
245 2011-12-16 15:37:43 <gmaxwell> oh wow, thats just the raw block index time.
246 2011-12-16 15:37:55 <gmaxwell> I wonder if people have been orphanblock attacking nodes.
247 2011-12-16 15:38:13 <gmaxwell> how big is your blkindex.dat?
248 2011-12-16 15:38:49 <kinlo> -rw-------  1 peter  staff  329281536 Dec 16 17:38 blkindex.dat
249 2011-12-16 15:39:22 <kinlo> this is on my laptop - disk ain't fast, and I don't run the client often and always for relative short periods
250 2011-12-16 15:39:55 <gmaxwell> I suspect the fast loads might be warm-cache.
251 2011-12-16 15:40:30 <kinlo> I did do cold-cache starts too
252 2011-12-16 15:40:47 <kinlo> let me first just download the block index and then do a few warm starts to see how it goes
253 2011-12-16 15:40:57 <gmaxwell> Yes, but perhaps those are all the slow ones?
254 2011-12-16 15:41:12 <kinlo> the warm starts slower then the cold starts?
255 2011-12-16 15:41:22 <gmaxwell> er fast ones.
256 2011-12-16 15:59:07 <kinlo> hmmmz
257 2011-12-16 15:59:12 <luke-jr> BlueMatt: git remote add stable git://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git ; git fetch stable ; git branch -a | grep stable
258 2011-12-16 15:59:14 <luke-jr> ;)
259 2011-12-16 15:59:21 <kinlo> ok, it seems that warm reloads are indeed much, much faster
260 2011-12-16 15:59:29 <kinlo> must be my backup or something pre-heating the index
261 2011-12-16 15:59:54 <luke-jr> BlueMatt: dnsseed.bitcoin.dashjr.org
262 2011-12-16 15:59:58 <BlueMatt> luke-jr: thanks
263 2011-12-16 16:00:29 <luke-jr> BlueMatt: be sure to use the tags, though, as the HEADs are bumped to the next version after the release
264 2011-12-16 16:00:37 <BlueMatt> luke-jr: will do
265 2011-12-16 16:08:43 <devrandom> TD: peek
266 2011-12-16 16:09:22 <TD> devrandom: how do I force damn JDK logging to actually print everything including FINE. i tried setting the level on the logger and the handler, no dice. i wonder if slf4j is screwing me over
267 2011-12-16 16:10:07 <devrandom> I'm not very familiar with logging details
268 2011-12-16 16:10:24 <devrandom> I tend to use the debugger more
269 2011-12-16 16:10:48 <TD> yeah
270 2011-12-16 16:11:37 <BlueMatt> hey, theres a gavin
271 2011-12-16 16:11:49 <TD> but i like logging
272 2011-12-16 16:11:58 <TD> oh well
273 2011-12-16 16:12:14 <gavinandresen> hey, there's matt and mike!
274 2011-12-16 16:12:21 <[Tycho]> Hello.
275 2011-12-16 16:12:25 <BlueMatt> wow, the BIP 15 aliasing thread has gone so far off track...
276 2011-12-16 16:14:09 <TD> devrandom: i have a CL for you to review
277 2011-12-16 16:14:36 <devrandom> TD: you mean a patch? ;)
278 2011-12-16 16:14:51 <TD> right
279 2011-12-16 16:14:54 <TD> a whatever :)
280 2011-12-16 16:14:55 <TD> http://code.google.com/r/hearn-bitcoinj/source/detail?r=b608f2c4ef88d92fd9b3cb682b1f2c80e4af4ff1&name=pending-tx
281 2011-12-16 16:15:00 <TD> first cut at tx confidence levels api
282 2011-12-16 16:15:06 <TD> it's not finished yet. some things are missing
283 2011-12-16 16:15:25 <BlueMatt> TD: ooo, now thats a cool feature
284 2011-12-16 16:15:39 <TD> i want the TransactionConfidence API to provide an estimated count of [tera/peta]hashes of work done per tx
285 2011-12-16 16:15:54 <TD> heh. nooooo.
286 2011-12-16 16:16:00 <TD> bitcoinj is still very, very rough and incomplete
287 2011-12-16 16:16:13 <BlueMatt> hey, the satoshi client feels that way often too...
288 2011-12-16 16:16:18 <devrandom> BlueMatt: it's a thin client
289 2011-12-16 16:16:20 <TD> satoshi client will be the canonical codebase for a long time ... but i'm hoping most of the interesting ecosystem apps get written against bitcoinj :)
290 2011-12-16 16:16:40 <TD> devrandom: the main thing that's missing is how to expose changes in tx confidence to the api user
291 2011-12-16 16:16:44 <BlueMatt> devrandom: I know, but some of the cool stuff thats being done on bitcoinj...
292 2011-12-16 16:16:51 <luke-jr> TD: can I build it to a normal library yet? :P
293 2011-12-16 16:16:54 <TD> devrandom: i'm thinking some kind of alarm api, or event listeners on the TransactionConfidence
294 2011-12-16 16:16:59 <TD> luke-jr: well, it builds to a normal java library ;)
295 2011-12-16 16:17:04 <luke-jr> TD: so no?
296 2011-12-16 16:17:10 <TD> if you want to -lbitcoinj then no. i guess something could be done with gcj
297 2011-12-16 16:17:22 <TD> and the gnu proprietary c++/java binding system they had. cni?
298 2011-12-16 16:17:23 <TD> i forgot
299 2011-12-16 16:17:34 <BlueMatt> can gcj compile libraries?
300 2011-12-16 16:17:40 <luke-jr> BlueMatt: ofc
301 2011-12-16 16:17:47 <TD> i guess genjixs lib will be the thing for c++ devs for the forseeable future, or refactorings of satoshis code (preferable imho)
302 2011-12-16 16:17:52 <luke-jr> Java just has its own not-invented-here build systems
303 2011-12-16 16:17:56 <luke-jr> so nothing works normally
304 2011-12-16 16:17:57 <devrandom> TD: ok, will look in a bit
305 2011-12-16 16:18:00 <TD> devrandom: thanks
306 2011-12-16 16:18:03 <TD> i'll post to the list as well
307 2011-12-16 16:18:09 <TD> devrandom: advice on how to expose confidence changes, appreciated
308 2011-12-16 16:18:44 <luke-jr> TD: 32-bit int
309 2011-12-16 16:18:47 <luke-jr> :p
310 2011-12-16 16:18:58 <luke-jr> ofc, since it's Java, there's probably no point in writing efficient code&
311 2011-12-16 16:19:26 <TD> luke-jr: god, i'd love unsigned types in java
312 2011-12-16 16:19:37 <TD> and yeah, efficiency is not javas strong point. i actually work with c++ in my day job
313 2011-12-16 16:19:45 <luke-jr> TD: actually, you'd want this to be signed :P
314 2011-12-16 16:19:49 <luke-jr> &
315 2011-12-16 16:19:55 <luke-jr> why the heck did you use Java then? :/
316 2011-12-16 16:20:00 <TD> the only times i use java are this project and when i patch the gmail frontend :)
317 2011-12-16 16:20:23 <gavinandresen> sipa: Question for the VersionMeister:  before starting to pull 0.6 stuff, I'll bump the version number to... 0.5.99 ?
318 2011-12-16 16:20:24 <TD> because [a] i originally set out to build an android client, it turned into a general purpose lib later and [b] lots of people know java and find it easier to work with than c++
319 2011-12-16 16:20:38 <luke-jr> anyhow, confidence should probably be negative for transactions that get more and more UNlikely
320 2011-12-16 16:20:46 <sipa> gavinandresen: ACK :)
321 2011-12-16 16:20:47 <TD> so if you want to make bitcoin easier to work with and accessible to more people, java's a pretty good choice
322 2011-12-16 16:20:54 <BlueMatt> if schools stopped teaching so much in java, maybe it could fade away a bit...
323 2011-12-16 16:20:58 <TD> luke-jr: currently i'm not exposing any kind of canonical confidence score
324 2011-12-16 16:21:14 <TD> luke-jr: that might come later. for now you get number of unique peers that announced the tx, and depth in best chain
325 2011-12-16 16:21:15 <devrandom> TD: will think about API
326 2011-12-16 16:21:33 <TD> i want to give depth measured as total work done rather than blocks too, so you can specify confidence thresholds independent of speed
327 2011-12-16 16:21:35 <TD> devrandom: thanks
328 2011-12-16 16:21:37 <luke-jr> TD: ah, I assumed you meant a statistical probability
329 2011-12-16 16:21:56 <sipa> are there non-statistical probabilities? :)
330 2011-12-16 16:21:59 <TD> no. i guess that depends on things that are "unknowable" like the determination of your attckers
331 2011-12-16 16:22:15 <TD> i'd like to provide some pre-canned rule sets so people don't have to know the details of all the different kinds of attacks you can do on bitcoin
332 2011-12-16 16:22:16 <luke-jr> sipa: as he just said, confirmation and peers announcing it :P
333 2011-12-16 16:22:36 <devrandom> I'm thinking confidence levels should be a probability measure... e.g. given an attacker with resources equal to X, what is the probability that they would be able to get a conflicting tx accepted?
334 2011-12-16 16:22:39 <TD> like, "here's rules to use if you write a wallet for personal use", "here's rules for running a merchant", "here's rules if you sell houses" etc
335 2011-12-16 16:22:40 <sipa> luke-jr: sorry, wasn't really following, it sounded a bit like a paradox
336 2011-12-16 16:22:50 <TD> devrandom: i thought about that. like a dollar value of attacker spend
337 2011-12-16 16:22:53 <devrandom> it would get closer and closer to 1
338 2011-12-16 16:23:05 <TD> devrandom: problem is that depends on the some magic numbers like the dollar value of bitcoin and cost of mining hardware
339 2011-12-16 16:23:08 <sipa> BlueMatt: i've learned Java in university, and C/C++ by myself... i feel less and less inclined to do personal coding in Java :)
340 2011-12-16 16:23:18 <luke-jr> devrandom: or -1, if it's a conflict ;)
341 2011-12-16 16:23:20 <devrandom> dollar amount sounds even better actually
342 2011-12-16 16:23:32 <TD> there's no API to fetch exchange rates today
343 2011-12-16 16:23:33 <BlueMatt> sipa: same here, and thats my point, so many classes teach in java
344 2011-12-16 16:23:33 <TD> i'd like to add one
345 2011-12-16 16:23:38 <BlueMatt> sipa: so its become fairly popular
346 2011-12-16 16:23:40 <devrandom> luke-jr: a probability close to zero if there's a conflict
347 2011-12-16 16:23:48 <sipa> BlueMatt: Java is a lot better than C++ in many aspects, but i just so much hate its verbosity :)
348 2011-12-16 16:23:50 <luke-jr> TD: that requires some standard for exchanges
349 2011-12-16 16:23:54 <TD> then it could be used to build something that looks at the value of the transaction vs the cost of mining and tries to guess
350 2011-12-16 16:23:57 <TD> but that's way advanced
351 2011-12-16 16:24:00 <TD> luke-jr: yeah. or a pile of hacks :)
352 2011-12-16 16:24:16 <TD> there are much more important things to fix in bitcoinj than building the perfect tx confidence api
353 2011-12-16 16:24:20 <devrandom> actually, measuring it in terahashes sounds pretty good
354 2011-12-16 16:24:21 <luke-jr> heh
355 2011-12-16 16:24:27 <BlueMatt> sipa: yea, its easier to learn because of its verbosity though...
356 2011-12-16 16:24:34 <TD> devrandom: for advanced users it's the closest you're going to get to something "real" i guess
357 2011-12-16 16:24:43 <TD> devrandom: unless that company comes out with their mining ASICs
358 2011-12-16 16:24:44 <TD> i forgot the name
359 2011-12-16 16:24:47 <TD> butterfly labs?
360 2011-12-16 16:24:52 <luke-jr> TD: I've used one.
361 2011-12-16 16:24:54 <gavinandresen> I still like the idea of exchanges spending from "well-known" addresses to embed the exchange rate in the block chain once per hour...
362 2011-12-16 16:25:01 <BlueMatt> I think [Tycho] is also doing mining hardware
363 2011-12-16 16:25:03 <devrandom> we can have a configured factor to translate TH to $
364 2011-12-16 16:25:12 <BlueMatt> gavinandresen: ...why?
365 2011-12-16 16:25:17 <luke-jr> gavinandresen: too easily abused, and bloats the block chain
366 2011-12-16 16:25:27 <sipa> i'm not sure about the use, gavinandresen
367 2011-12-16 16:25:30 <TD> if it's going to be a pure p2p solution i'd rather explore the pubsub protocol
368 2011-12-16 16:25:36 <luke-jr> I think someone had suggested a p2p exchange once&
369 2011-12-16 16:25:37 <TD> so you could join the p2p network and subscribe to exchange prices
370 2011-12-16 16:26:10 <TD> longer term i'd like to see exchanges issue their own 1:1 fiat:crypto currencies
371 2011-12-16 16:26:13 <[Tycho]> Yes.
372 2011-12-16 16:26:14 <gavinandresen> RE: bloating the chain:  that chicken has already left the roost.  That horse is out of the barn.  That eagle has already landed....
373 2011-12-16 16:26:17 <TD> so there'd be MtGoxUSDCoin
374 2011-12-16 16:26:30 <TD> then you could potentially do chain trades in a p2p fashion and automatically negotiate prices, etc
375 2011-12-16 16:26:43 <helo> don't forget about the goose's egg
376 2011-12-16 16:26:44 <TD> gavinandresen: there's a big difference between theoretically possible and outright encouraged
377 2011-12-16 16:26:59 <TD> one thing i'd like to explore with bitcoinj in 2012 is making alt chains way easier to build
378 2011-12-16 16:27:01 <gavinandresen> RE: why:  because it'd be a cool, secure, decentralized way of doing it.
379 2011-12-16 16:27:02 <BlueMatt> I'd simply like to see someone with a ton of money declare they are fixing the bitcoin rates to USD or some international currency value indicator
380 2011-12-16 16:27:31 <TD> you should just be able to subclass some core classes and put together your own P2P network that uses the bitcoin protocols, with your own definition of a Transaction, and then be able to do merged mining out of the box
381 2011-12-16 16:27:43 <TD> running a very strongly hashed alt chain should be something a student can do in one evening
382 2011-12-16 16:27:57 <TD> then there'd be much less incentive to put non-tx data into the prod blockchain
383 2011-12-16 16:28:00 <devrandom> how do you mine with bitcoinj?  I thought you need a full node
384 2011-12-16 16:28:15 <TD> devrandom: you can't mine bitcoin transactions. but for alternative chains, you'd define your own notion of validity
385 2011-12-16 16:28:32 <sipa> right, it has to be a full node for the alt chain, not for the bitcoin chain
386 2011-12-16 16:28:40 <TD> devrandom: eg for handling exchange rate announcements you'd come up with a "tx" message that just includes the name of the exchange, a signature, and some prices, or something
387 2011-12-16 16:28:48 <TD> devrandom: so validation is easy
388 2011-12-16 16:28:52 <helo> could there be some self-interested motivation for the exchanges to lie about the exchange rate in the blockchain?
389 2011-12-16 16:28:58 <TD> though given the transient nature of exchange rates, i'm not sure recording them forever is the right design either :-)
390 2011-12-16 16:29:11 <devrandom> I see
391 2011-12-16 16:29:38 <TD> helo: i think the end goal should be that if you deposit $100 in Mt. Gox, after doing all the AML checks they issue you with 100 MtGoxCoins
392 2011-12-16 16:29:43 <TD> which run on a separate chain
393 2011-12-16 16:29:54 <TD> merged mined. mtgox gives a little bit of money as incentives.
394 2011-12-16 16:30:04 <TD> at that point you can use luxgladiuses chain trade script to do btc:usd trades atomically and without trust
395 2011-12-16 16:30:08 <luke-jr> why use a chain?
396 2011-12-16 16:30:17 <TD> when there's no trust needed, you can have a broadcast network of open trades
397 2011-12-16 16:30:33 <TD> so you could just broadcast "i have 5 MtGoxCoins and am willing to sell them for 7.6 BTC"
398 2011-12-16 16:30:43 <TD> users then run the software which connects to the p2p network and listens for announced trades
399 2011-12-16 16:30:54 <TD> when it finds one that matches its rules for acceptable prices, it does a chain trade and the coins atomically change hands
400 2011-12-16 16:31:20 <TD> in this way the trading itself becomes decentralized. Mt Gox performs AML duties, bank wires, and creates/destroys MtGoxCoins on the alt chain
401 2011-12-16 16:32:08 <TD> rather than having coins be created via inflation, each block would be allowed to claim only fees. special keys hard-coded into the clients would be recognized as coin creation keys. when it's time for a MtGoxCoin to turn back into USD via  bank wire, the coins are destroyed with an OP_FALSE script
402 2011-12-16 16:32:12 <CIA-100> bitcoin: Gavin Andresen master * r8896c2d / (5 files in 4 dirs): Bump version 0.5.99 (prep for pulling for version 0.6) - http://git.io/jLgNlQ https://github.com/bitcoin/bitcoin/commit/8896c2d9d64d71e25b31d7a389f0b8db49a1e50a
403 2011-12-16 16:32:41 <lianj> how does bank wire and decentralisation match?
404 2011-12-16 16:32:45 <BlueMatt> luke-jr: are you going to cname a ton of eligius relay nodes to your dnsseed?
405 2011-12-16 16:32:46 <TD> i suppose to simplify things a bunch of exchanges could agree to share a single chain. the exchanges would incentivize shared mining by giving away coins valid on their own exchanges
406 2011-12-16 16:32:55 <gmaxwell> though ignoring the enormous trust needed to redeem MtGoxCoins, and the potentially weird regulatory complexities of creating bearer tokens fixed to the USD.
407 2011-12-16 16:33:06 <TD> lianj: bank wire into exchange -> MtGoxCoins created. MtGoxCoins destroyed -> bank wire out of exchange.
408 2011-12-16 16:33:28 <TD> gmaxwell: yes. at least in the EU that'd probably make you an issuer of the dreaded "e-currency" :) so you'd need a big deposit
409 2011-12-16 16:33:33 <TD> i think it's a million euros or something ridiculous like that
410 2011-12-16 16:33:56 <TD> gmaxwell: and yes you have to trust that MtGox backs their coins 1:1 with actual deposits. however beyond that you don't need to rely on them at all
411 2011-12-16 16:34:10 <TD> you can use your own security mechanisms, guard your mtgoxcoin keys however you like, etc
412 2011-12-16 16:34:37 <TD> such an exchange currency would be a strong competitor to bitcoin itself, i guess, as you'd be swapping unknown large volatility for the relatively low and known volatility of big fiats
413 2011-12-16 16:35:03 <TD> assuming the euro doesn't tank and take the dollar with it of course. then bitcoin might start looking rather stable in comparison ....
414 2011-12-16 16:36:00 <devrandom> maybe tie it to the SDR
415 2011-12-16 16:36:20 <helo> would it not be illegal for mtgox to create digital equivalents to USD?
416 2011-12-16 16:36:33 <helo> saying "this is a mtgox coin, it's the same as a dollar"
417 2011-12-16 16:36:49 <TD> i don't think there's anything wrong with creating tokens backed 1:1 by an existing currency
418 2011-12-16 16:37:00 <TD> at least in the EU not only is it legal, there is a whole regulatory framework around it. i'd be surprised if it's illegal in the USA
419 2011-12-16 16:37:08 <helo> i thought it was the same as printing a fake dollar bill and saying "this is a dollar"
420 2011-12-16 16:37:15 <TD> assuming you follow all the regulations (which is very hard because there are so many and they are so vague)
421 2011-12-16 16:37:30 <TD> no. why would it be the same?
422 2011-12-16 16:37:45 <TD> if i fake the currency itself, that's way different than swapping you 1:1 with something i promise is equivalent
423 2011-12-16 16:37:52 <helo> because you're creating something yourself and saying "this is a dollar"
424 2011-12-16 16:38:06 <helo> hmm, maybe
425 2011-12-16 16:38:13 <TD> think about store gift cards and things
426 2011-12-16 16:38:15 <BlueMatt> gavinandresen: yea, ok same problem as before, different qt/boost binary inputs and different bitcoin-qt binaries...
427 2011-12-16 16:38:28 <BlueMatt> devrandom: have you recently built the qt-win32 gitian zips?
428 2011-12-16 16:38:50 <devrandom> BlueMatt: not recently
429 2011-12-16 16:39:00 <devrandom> well, let me check
430 2011-12-16 16:39:04 <BlueMatt> do you happen to have hashes for ones you built any time?
431 2011-12-16 16:39:22 <gavinandresen> BlueMatt: let me know if/how I can help...
432 2011-12-16 16:40:19 <devrandom> BlueMatt: I have one from Nov 21 - e5af9ca68aa98e8edd1e1b1bb96bbd0800f1a929270823f1bccf729aada157e4
433 2011-12-16 16:40:22 <BlueMatt> gavinandresen: Im rebuilding my qt-win32 and boost-win32 gitian zips, if you could do the same and see if you get the same hashes
434 2011-12-16 16:40:33 <BlueMatt> devrandom: 4.7.4?
435 2011-12-16 16:40:46 <devrandom> I think 5.0
436 2011-12-16 16:40:48 <devrandom> oh
437 2011-12-16 16:41:35 <devrandom> 321247297648eebd4f1d0195addf51eeb9f1dcf538a78bf3c67d11dadbc40faf  qt-everywhere-opensource-src-4.7.4.tar.gz
438 2011-12-16 16:41:54 <BlueMatt> devrandom: oh, no the qt-win32-4.7.4-gitian.zip file
439 2011-12-16 16:41:58 <BlueMatt> not the original source
440 2011-12-16 16:42:00 <phantomcircuit> TD[gone], depends on where you are and what kind of volume you're doing
441 2011-12-16 16:42:11 <BlueMatt> brb, have to walk back upstairs...
442 2011-12-16 16:43:14 <gavinandresen> devrandom: what checksum is that?  sha256?
443 2011-12-16 16:43:37 <devrandom> yes
444 2011-12-16 16:43:43 <gavinandresen> hmm, mine is:
445 2011-12-16 16:43:48 <gavinandresen> 97195ebce8a46f9929fb971d9ae58326d011c4d54425389e6e936514f540221e  qt-everywhere-opensource-src-4.7.4.tar.gz
446 2011-12-16 16:45:24 <devrandom> uh oh
447 2011-12-16 16:45:50 <BlueMatt> ?
448 2011-12-16 16:45:54 <gavinandresen> BlueMatt: checksum on my qt-everwhere-.tar.gz is different from devrandom's... I'm re-fetching to see if it changes again
449 2011-12-16 16:46:05 <devrandom> gavinandresen: I'll upload mine somewhere and we can compare?
450 2011-12-16 16:46:12 <BlueMatt> oh, well thats weird, that should never be different...
451 2011-12-16 16:46:26 <gavinandresen> ... unless qt snuck in a minor release but didnt' change the filename or something
452 2011-12-16 16:46:30 <devrandom> ack, it's 210MB
453 2011-12-16 16:46:42 <gavinandresen> yes, it is big....
454 2011-12-16 16:46:56 <devrandom> I'll wait for you to refetch instead
455 2011-12-16 16:47:09 <BlueMatt> my ssha256 is 97195ebce8a46f9929fb971d9ae58326d011c4d54425389e6e936514f540221e
456 2011-12-16 16:47:44 <BlueMatt> and my qt-win32-4.7.4-gitian.zip is 606f0ea210dff45b31fa2712dff09ccdcf0b5791ca60f8d9521edc69ec67645f
457 2011-12-16 16:49:11 <gavinandresen> c29e6d4e73cbfeedabe4abf79aae26964b38d0fa942904fd79ded1a6445254b7  qt-win32-4.7.4-gitian.zip
458 2011-12-16 16:49:23 <gavinandresen> 97195ebce8a46f9929fb971d9ae58326d011c4d54425389e6e936514f540221e  qt-everywhere-opensource-src-4.7.4.tar.gz
459 2011-12-16 16:49:24 <phantomcircuit> is it just me or is all the stuff about name aliases silly
460 2011-12-16 16:49:29 <phantomcircuit> you can just implement all of them
461 2011-12-16 16:49:32 <phantomcircuit> they're all fairly simple
462 2011-12-16 16:49:36 <phantomcircuit> let the best man win
463 2011-12-16 16:49:44 <gavinandresen> phantomcircuit: +1
464 2011-12-16 16:49:50 <BlueMatt> phantomcircuit: that is the worst way to do it...
465 2011-12-16 16:49:55 <phantomcircuit> lold
466 2011-12-16 16:50:02 <phantomcircuit> CONTRADICT ALL THE THINGS
467 2011-12-16 16:50:13 <BlueMatt> the dns one cannot be implemented securely on some isps
468 2011-12-16 16:50:19 <devrandom> gavinandresen: BlueMatt so I'm the odd man out
469 2011-12-16 16:50:31 <phantomcircuit> the dns one cannot by implemented securely on most isps
470 2011-12-16 16:50:35 <BlueMatt> well gavinandresen has different results on the final build, which is really the pobrlem
471 2011-12-16 16:50:52 <devrandom> BlueMatt: was it deterministic for you?
472 2011-12-16 16:51:03 <BlueMatt> IIRC yes, though I have to check now...
473 2011-12-16 16:51:04 <gavinandresen> Yes, same input, different output... I'll let the re-download finish, then rebuild and see if I get the same .gitian.zip
474 2011-12-16 16:51:07 <devrandom> BlueMatt: and do you match me?
475 2011-12-16 16:51:17 <BlueMatt> on the -win32-zip?
476 2011-12-16 16:51:24 <phantomcircuit> i think the email version is best but really the value there is being able to send the bitcoins to someones email who doesn't yet have the client
477 2011-12-16 16:51:39 <phantomcircuit> which is obviously fairly complicated and probably requires trusting someone
478 2011-12-16 16:51:46 <devrandom> BlueMatt: yes
479 2011-12-16 16:51:57 <BlueMatt> devrandom: whats yous sha on the -win32.zip
480 2011-12-16 16:52:17 <BlueMatt> I thought I matched someone, whether it was wumpus or whoever when the qt gitian stuff was being written
481 2011-12-16 16:53:19 <gavinandresen> I thought Walter Stanish made some very good points, that I expect nobody read because he uses too many words to make his points.
482 2011-12-16 16:53:34 <wumpus> yes, we had a matching hash once
483 2011-12-16 16:53:39 <devrandom> BlueMatt: I have one from Nov 21 - e5af9ca68aa98e8edd1e1b1bb96bbd0800f1a929270823f1bccf729aada157e4
484 2011-12-16 16:54:24 <BlueMatt> devrandom: no, you have a different original source and different build results form me
485 2011-12-16 16:54:34 <wumpus> it looked like it was deterministic back then, I built it 10 times and hash was the same every time
486 2011-12-16 16:54:36 <luke-jr> 321247297648eebd4f1d0195addf51eeb9f1dcf538a78bf3c67d11dadbc40faf  /usr/portage/distfiles/qt-everywhere-opensource-src-4.7.4.tar.gz
487 2011-12-16 16:54:37 <BlueMatt> wumpus: do you happen to still have the hash of the -win32.zip file lying around?
488 2011-12-16 16:54:38 <phantomcircuit> gavinandresen, i stopped reading when the thread got so deep thunderbird was cutting off names entirely
489 2011-12-16 16:54:40 <luke-jr> ^ canonical Gentoo SHA256sum
490 2011-12-16 16:54:43 <phantomcircuit> :|
491 2011-12-16 16:55:18 <gavinandresen> phantomcircuit: Walter Stanish is the "Use IIBAN numbers" proponent.  Which I think is a great idea, except that IIBAN is Yet Another Fledgling Standard
492 2011-12-16 16:55:19 <BlueMatt> luke-jr: ok, wtf...
493 2011-12-16 16:55:42 <luke-jr> http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.2.tar.gz <-- Gentoo origin
494 2011-12-16 16:55:55 <BlueMatt> luke-jr: no, 4.7.4
495 2011-12-16 16:56:01 <luke-jr> oh right
496 2011-12-16 16:56:17 <phantomcircuit> gavinandresen, yeah i saw iiban, seems like a good idea but not well supported
497 2011-12-16 16:56:30 <wumpus> 97195ebce8a46f9929fb971d9ae58326d011c4d54425389e6e936514f540221e  inputs/qt-everywhere-opensource-src-4.7.4.tar.gz
498 2011-12-16 16:56:54 <luke-jr> http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.4.tar.gz
499 2011-12-16 16:57:05 <gavinandresen> So same inputs for Matt/Me/wumpus, 3 different outputs....
500 2011-12-16 16:57:32 <wumpus> at a certain point there was an issue that the date was embedded somewhere, so every day it had a new hash
501 2011-12-16 16:57:44 <luke-jr> >_<
502 2011-12-16 16:57:51 <wumpus> I fixed that though
503 2011-12-16 16:57:54 <luke-jr> probably the gzip mtime
504 2011-12-16 16:58:03 <BlueMatt> odd, and I thought it was deterministic...
505 2011-12-16 16:58:06 <wumpus> nope it was something in the bowels of qt itself
506 2011-12-16 16:58:09 <luke-jr> oh
507 2011-12-16 16:58:26 <wumpus> some build id... the problem is that you can't enable the faketime for the entire duration of the build
508 2011-12-16 16:58:38 <wumpus> qt's build system gets confused and keeps rebuilding the same targets. sometimes.
509 2011-12-16 16:58:52 <wumpus> it does luke-jr, that's what faketime is for
510 2011-12-16 16:59:06 <luke-jr> wumpus: so have every call to time() return LastTime + 1
511 2011-12-16 16:59:26 <wumpus> which works for the bitcoin build, but it doesn't work for qt
512 2011-12-16 16:59:55 <wumpus> yes that'd be an idea, as long as there is no parallelism it should work
513 2011-12-16 17:00:00 <devrandom> luke-jr: we use libfaketime... I don't know if a VM's clock can be easily stopped
514 2011-12-16 17:00:15 <devrandom> oh wumpus already said
515 2011-12-16 17:00:16 <gavinandresen> I'm rebuilding, if it is reproducible on my machine then we'll know it is not a time thing...
516 2011-12-16 17:00:38 <luke-jr> wumpus: perhaps there's a safe way to parallelize it
517 2011-12-16 17:00:41 <wumpus> yeah I think I solved the time thing.. but there might be another one
518 2011-12-16 17:00:53 <gavinandresen> (I vaguely recall rebuilding before and getting the same result, but maybe that was all builds-done-in-a-single-day...)
519 2011-12-16 17:00:59 <devrandom> ok, I got the 9719 qt sources
520 2011-12-16 17:02:33 <luke-jr> aha, my qt 4.7.4 source isn't complete :p
521 2011-12-16 17:02:49 <BlueMatt> yea, I just rebuilt gitian 4.7.4 and got a different hash...let me go look at the file diff
522 2011-12-16 17:04:09 <devrandom> FWIW, my old package had a bunch of doc diffs, and also:
523 2011-12-16 17:04:12 <devrandom> -#define QT_PACKAGEDATE_STR "2011-09-12"
524 2011-12-16 17:04:13 <devrandom> +#define QT_PACKAGEDATE_STR "2011-08-23"
525 2011-12-16 17:04:21 <BlueMatt> wumpus: mmm, Im getting the same old crap that I got in the bitcoin builds where CONFIG flags in files are changing order...
526 2011-12-16 17:05:39 <devrandom> BlueMatt: is that affecting final output?
527 2011-12-16 17:06:14 <BlueMatt> devrandom: those files (eg plugins/codecs/qcncodecs.prl:4 are in the final output
528 2011-12-16 17:06:29 <wumpus> this is the fix I made back then: sed 's/$TODAY/2011-01-30/' -i configure
529 2011-12-16 17:06:33 <BlueMatt> quite a few of the .prl's have eg QMAKE_PRL_CONFIG with different orders
530 2011-12-16 17:06:34 <devrandom> sigh
531 2011-12-16 17:06:49 <luke-jr> are you guys using -j1?
532 2011-12-16 17:07:03 <wumpus> but I don't think it was QT_PACKAGEDATE_STR
533 2011-12-16 17:07:11 <wumpus> so that might be another one :/
534 2011-12-16 17:07:20 <luke-jr> actually, why aren't you just using Ubuntu's qt packages?
535 2011-12-16 17:07:30 <wumpus> windows
536 2011-12-16 17:07:34 <luke-jr> oh right
537 2011-12-16 17:08:21 <luke-jr> in that case, why not just use Nokia's Win32 binaries? ;)
538 2011-12-16 17:08:33 <wumpus> they don't support static linking
539 2011-12-16 17:08:37 <wumpus> at least not well
540 2011-12-16 17:08:45 <luke-jr> shouldn't be static linking in the first place
541 2011-12-16 17:08:59 <wumpus> on windows it's preferable to do so
542 2011-12-16 17:09:03 <luke-jr> no, it isn't.
543 2011-12-16 17:09:15 <wumpus> it means you have one portable exe
544 2011-12-16 17:09:18 <wumpus> instead of a zillion dlls
545 2011-12-16 17:09:21 <luke-jr> which is irrelevant
546 2011-12-16 17:09:27 <gavinandresen> ... somebody would have to volunteer to modify the setup.nsi to install the dlls...
547 2011-12-16 17:09:34 <luke-jr> wallet.dat isn't portable anyway
548 2011-12-16 17:09:43 <luke-jr> (rather, it's not "one portable exe")
549 2011-12-16 17:09:44 <sipa> it's not?
550 2011-12-16 17:09:50 <luke-jr> sipa: it's a separate file
551 2011-12-16 17:09:52 <wumpus> it is portable, you can use bitcoin on an usb stick
552 2011-12-16 17:09:53 <sipa> yeah sure
553 2011-12-16 17:10:01 <luke-jr> wumpus: you can do that with DLLs too
554 2011-12-16 17:10:01 <wumpus> no need to install dlls all over the system
555 2011-12-16 17:10:11 <luke-jr> DLLs can be installed in the same directory as the EXE
556 2011-12-16 17:10:13 <wumpus> oh, sure...
557 2011-12-16 17:10:28 <sipa> luke-jr: then what's the advantage?
558 2011-12-16 17:10:31 <wumpus> but then you can just as well staticlaly link
559 2011-12-16 17:10:36 <wumpus> they are not *shared*
560 2011-12-16 17:10:45 <luke-jr> sipa: advanced users *can* delete them to use a system Qt
561 2011-12-16 17:10:55 <wumpus> advanced users can compile it themselves
562 2011-12-16 17:11:01 <luke-jr> wumpus: they *might* be shared if Windows implements some kind of deduplication
563 2011-12-16 17:11:07 <wumpus> I don't think we have to care much about those on windows
564 2011-12-16 17:11:14 <luke-jr> wumpus: no, we don't support compiling for Windows :P
565 2011-12-16 17:11:20 <luke-jr> on*
566 2011-12-16 17:11:26 <wumpus> you can compile it fine in qt creator in windows
567 2011-12-16 17:11:30 <wumpus> that's what I did in the beginning
568 2011-12-16 17:12:03 <wumpus> the only reason for using gitian is because it is safer and (should be) deterministic
569 2011-12-16 17:13:41 <luke-jr> anyhow, using DLLs is easier
570 2011-12-16 17:13:59 <luke-jr> you don't have to build Qt yourself, and it enables some advanced uses for users
571 2011-12-16 17:14:10 <luke-jr> at no expense
572 2011-12-16 17:14:12 <wumpus> anyway, that moves the trust to trolltech compiling the dlls, I think the everything-from-source approach is best
573 2011-12-16 17:14:21 <luke-jr> you already trust Ubuntu
574 2011-12-16 17:14:38 <wumpus> yeah...
575 2011-12-16 17:14:44 <luke-jr> and Microsoft
576 2011-12-16 17:14:47 <devrandom> luke-jr: for now
577 2011-12-16 17:14:47 <sipa> and Intel
578 2011-12-16 17:15:06 <BlueMatt> ...ominous
579 2011-12-16 17:15:13 <sipa> who knows what that microcode on my CPU is doing
580 2011-12-16 17:15:25 <gavinandresen> For what it is worth.. the Mac release ships with the qt binaries (not statically linked-- all the other depencies ARE statically linked, though)
581 2011-12-16 17:15:36 <luke-jr> sipa: it's got a builtin cellular modem to upload your private data to Intel
582 2011-12-16 17:15:45 <wumpus> yeah yeah the question is not whether your paranoid, but whether you're paranoid enough...
583 2011-12-16 17:16:02 <sipa> luke-jr: cool
584 2011-12-16 17:16:31 <luke-jr> sipa: also, there's a government faction planning to take down a plane in the middle of NYC, to justify a war
585 2011-12-16 17:16:41 <luke-jr> oh wait, that one actually ended up happening&
586 2011-12-16 17:17:00 <gavinandresen> lets not go there, please
587 2011-12-16 17:17:04 <wumpus> but that's a good point, it's not good that CPU companies are so centralized
588 2011-12-16 17:17:08 <luke-jr> gavinandresen: TV quotes are fun
589 2011-12-16 17:17:18 <wumpus> then again, I guess that's outside the scope of bitcoin
590 2011-12-16 17:17:19 <gavinandresen> How about productive paranoia discussion:  next steps for multi-device authentication?
591 2011-12-16 17:17:41 <luke-jr> gavinandresen: Yubikey at least is useless for this
592 2011-12-16 17:18:21 <gavinandresen> luke-jr: sure, you need a device that can show you the transaction being proposed, an OK button to confirm it, and the ability for it to generate an ECDSA signature.
593 2011-12-16 17:18:33 <luke-jr> well, that's not multi-device auth, that's a hardware wallet :P
594 2011-12-16 17:18:47 <gavinandresen> The device could be your cell phone....
595 2011-12-16 17:18:49 <wumpus> that could be one of the devices
596 2011-12-16 17:18:53 <luke-jr> step 1 for that is splitting up the wallet code from the GUI, by designing a Wallet Protocol
597 2011-12-16 17:19:00 <gavinandresen> ... or a web page that a trojan is unlikely to know about....
598 2011-12-16 17:19:07 <wumpus> or just use bitcoinj
599 2011-12-16 17:19:08 <wumpus> :P
600 2011-12-16 17:19:37 <luke-jr> then the GUI could talk to a CPU wallet (bitcoind), or an external device
601 2011-12-16 17:19:41 <BlueMatt> wumpus, sipa, gavinandresen, devrandom: do you have sha256 hashes of boost-win32-1.47.0-gitian.zip
602 2011-12-16 17:19:59 <gavinandresen> 6e3eb548b9d955c0bc6f71c51042b713b678136a  boost_1_47_0.tar.bz2
603 2011-12-16 17:20:08 <gavinandresen> oops, those are sha1
604 2011-12-16 17:20:14 <wumpus> 815a5d9faac4dbd523fbcf3fe1065e443c0bbf43427c44aa423422c6ec4c2e31  inputs/boost_1_47_0.tar.bz2
605 2011-12-16 17:20:15 <gavinandresen> 815a5d9faac4dbd523fbcf3fe1065e443c0bbf43427c44aa423422c6ec4c2e31  boost_1_47_0.tar.bz2
606 2011-12-16 17:20:16 <gavinandresen> c527428c8a7d8b6afb3214bbde831a1704a6893a0b05f08c1050f9e96e493a2d  boost-win32-1.47.0-gitian.zip
607 2011-12-16 17:20:21 <luke-jr> lol
608 2011-12-16 17:20:32 <BlueMatt> 774e7cf13e668be948700b4f37b007439afa6e3d7d8cf810fc52cb9c6f9d11cf  inputs/boost-win32-1.47.0-gitian.zip
609 2011-12-16 17:20:38 <wumpus> lol:/
610 2011-12-16 17:20:40 <BlueMatt> yay, boost isnt deterministic either...
611 2011-12-16 17:20:55 <luke-jr> why not leave gitian a separate project and let them deal with that? >.>
612 2011-12-16 17:21:17 <wumpus> eh which 'them'?
613 2011-12-16 17:21:27 <BlueMatt> luke-jr: them is devrandom...
614 2011-12-16 17:21:41 <gavinandresen> ... and gitian is a separate project.
615 2011-12-16 17:22:03 <luke-jr> :D
616 2011-12-16 17:22:21 <BlueMatt> anyway, gavin can you upload the -win32.zip gitian files for boost and qt that you used somewhere so we can atleast duplicate the bitcoin zip
617 2011-12-16 17:22:22 <luke-jr> gavinandresen: yeah, I mean just not hold up Bitcoin-Qt releases for gitian issues
618 2011-12-16 17:22:25 <wumpus> the problem also isn't in gitian itself
619 2011-12-16 17:22:49 <luke-jr> wumpus: I disagree. Software build systems shouldn't need to focus on being deterministic.
620 2011-12-16 17:22:59 <luke-jr> deterministic should be a result of the build environment
621 2011-12-16 17:23:05 <gavinandresen> BlueMatt: sure...
622 2011-12-16 17:23:27 <wumpus> yes, in theory.... but meanwhile in the actual world, it's all interlinked messily
623 2011-12-16 17:23:39 <devrandom> luke-jr: gavinandresen: I believe that creating trusted binaries is a goal for the bitcoin project
624 2011-12-16 17:23:43 <devrandom> right?
625 2011-12-16 17:23:50 <gavinandresen> devrandom: yes, absolutely
626 2011-12-16 17:24:08 <gavinandresen> ... but it isn't the only or the primary goal
627 2011-12-16 17:24:08 <luke-jr> devrandom: ideally, but not nearly as important as having multiple clients IMO
628 2011-12-16 17:24:35 <devrandom> gavinandresen: understood
629 2011-12-16 17:24:45 <luke-jr> it's not like we're talkign about 1.0 yet
630 2011-12-16 17:24:57 <BlueMatt> luke-jr: everything is a work-in-progress
631 2011-12-16 17:25:12 <gavinandresen> we'll never get deterministic builds if we don't work through the problems
632 2011-12-16 17:25:16 <devrandom> I have my -win32.zip contents sha256'ed here: https://gitian.org/qt.txt
633 2011-12-16 17:25:47 <wumpus> but does libfaketime support the time=time+1 trick? it'd be much better than setting a fixed time, at least for the qt build, and would allow getting rid of the hacks I added
634 2011-12-16 17:27:33 <luke-jr> I think the real problem you guys will hit is that Linux itself isn't deterministic ;)
635 2011-12-16 17:27:51 <gavinandresen> BlueMatt: uploading the win32-gitian.zips now, should be done in a few minutes....
636 2011-12-16 17:27:54 <wumpus> I don't think that's the issue luke-jr
637 2011-12-16 17:28:17 <luke-jr> wumpus: if any part of the build process depends on thread execution order, it will be
638 2011-12-16 17:28:17 <wumpus> given the build steps are done in the same order, and don't incorporate real timestamps, the result is deterministic
639 2011-12-16 17:28:34 <gmaxwell> luke-jr: er, it's perfectly possible to have determinstic builds. I use binary diffing all the time to make sure that source-code-only changes really are source-code-only
640 2011-12-16 17:28:50 <luke-jr> gmaxwell: KDE needs to do that.
641 2011-12-16 17:29:01 <gmaxwell> luke-jr: then you make sure that the output doesn't depend on that.
642 2011-12-16 17:29:04 <luke-jr> KDE 4.7 broke something because of an accidental precedence change
643 2011-12-16 17:29:21 <gmaxwell> Yea, I've _caught_ mistakes like that, but I actually try.
644 2011-12-16 17:29:28 <luke-jr> gmaxwell: I'm not sure boost or Qt consider deterministic a feature they care about.
645 2011-12-16 17:29:42 <wumpus> they don't
646 2011-12-16 17:29:50 <gmaxwell> (On time I accidently corrected a precedence bug when I was just doing some code cleanup, doh)
647 2011-12-16 17:30:17 <gavinandresen> luke-jr sipa:  Any consensus on bitcoin address numbering ?
648 2011-12-16 17:30:19 <gmaxwell> "good news, fixed a bug. Bad news: wasn't actually trying to change the code"
649 2011-12-16 17:30:40 <luke-jr> gavinandresen: I think we're going with my last proposal for 20-byte data
650 2011-12-16 17:32:23 <luke-jr> sipa: are you okay with just leaving the keys on 128 since they don't make sense in the 20-byte proposal?
651 2011-12-16 17:32:43 <luke-jr> IMO changing it out from under Bitbill/casacious for no reason would be bad
652 2011-12-16 17:33:01 <devrandom> BlueMatt: gavinandresen: I have to run, and will take a look at builds this weekend.  meanwhile you can compare your files to the sha256 url I posted above.
653 2011-12-16 17:33:09 <BlueMatt> devrandom: will do, see ya
654 2011-12-16 17:33:20 <devrandom> this was done with: find . -type f  | xargs -n10 sha256sum   > qt.txt
655 2011-12-16 17:33:33 <gavinandresen> luke-jr: ... so byte \05 for OP_EVAL.  And testnet changes from 111 to 192 (and 196 for OP_EVAL)
656 2011-12-16 17:36:02 <luke-jr> gavinandresen: yes
657 2011-12-16 17:38:29 <helo> can merged mining do testnet as well?
658 2011-12-16 17:39:15 <luke-jr> helo: no
659 2011-12-16 17:40:16 <helo> might cut down on blockchain bloat if testnet was usable for normal development i.e.- regular solved blocks :(
660 2011-12-16 17:40:47 <gavinandresen> luke-jr: I updated https://en.bitcoin.it/wiki/BIP_0013   can you make sure I got it right
661 2011-12-16 17:42:27 <luke-jr> helo: I agree, but such a change is non-trivial
662 2011-12-16 17:42:38 <luke-jr> helo: ideally, bitcoin itself should support merged mining
663 2011-12-16 17:43:22 <luke-jr> but that's one of those "when we fork the block chain" thing
664 2011-12-16 17:44:58 <gavinandresen> BlueMatt wumpus:  my -gitian.zips are up at   http://skypaint.com/bitcoin/
665 2011-12-16 17:45:12 <BlueMatt> gavinandresen: thanks
666 2011-12-16 17:45:19 <wumpus> ok thanks
667 2011-12-16 17:46:16 <luke-jr> gavinandresen: looks correct, but I question whether discussion of the version number scheme belongs in the OP_EVAL BIP
668 2011-12-16 17:46:45 <luke-jr> ie, the "Rationale" section
669 2011-12-16 17:47:12 <gavinandresen> Magic numbers need some rationale....
670 2011-12-16 17:47:23 <gavinandresen> ... even if just "11 is gavin's favorite number."
671 2011-12-16 17:47:28 <luke-jr> yes, but the BIP is about OP_EVAL, not the number
672 2011-12-16 17:47:47 <luke-jr> perhaps I should make a new BIP for the 20-byte scheme we're suing&
673 2011-12-16 17:47:49 <luke-jr> using*
674 2011-12-16 17:47:51 <gavinandresen> Right.  And there is no "new scheme for bitcoin address versions" BIP.  I don't care to write one....
675 2011-12-16 17:48:13 <luke-jr> (one that will hopefully be deprecated by a snaer repaacement)
676 2011-12-16 17:48:58 <gavinandresen> luke-jr: BIP 12 is about OP_EVAL-- BIP 13 is about the associated numbering scheme.  Maybe BIP13 should be superceded by your grander scheme, but, again, I don't care
677 2011-12-16 17:49:29 <wumpus> which commit to build?
678 2011-12-16 17:49:37 <gavinandresen> v0.5.1
679 2011-12-16 18:23:52 <luke-jr> https://en.bitcoin.it/wiki/In_Person_Traders <-- genius
680 2011-12-16 18:24:17 <wumpus> 0507969680fd1952f57b54842a8f463c40f3add3d6614281fab4be53916c0b76  bitcoin-0.5.1-win32-setup.exe
681 2011-12-16 18:24:45 <wumpus> luke-jr: nice
682 2011-12-16 18:29:32 <gavinandresen> Quick check:  nobody else has started working on BIP 14 yet, right?  (that's the separate protocol-version-from-client-version BIP)
683 2011-12-16 18:32:29 <BlueMatt> using gavin's inputs, both me and gavin got:
684 2011-12-16 18:32:30 <BlueMatt> 3ab0c764dad7e82cd6a65312da820ecab455193795e54cb3903d4c45ae94cad0  bitcoin-0.5.1-win32-setup.exe
685 2011-12-16 18:33:57 <TD> gavinandresen: i switched bitcoinj to use the proposed string format but didn't do anything beyond that
686 2011-12-16 18:35:01 <gavinandresen> TD: assuming nobody else has started, I'm going to implement it for bitcoind/bitcoin-qt (remove VERSION and have separate PROTOCOL_VERSION and CLIENT_VERSION)
687 2011-12-16 18:35:44 <gavinandresen> ... with PROTOCOL_VERSION starting at 60000
688 2011-12-16 18:35:49 <TD> cool
689 2011-12-16 18:36:48 <genjix> how can i report security vulnerabilities with bitcoin
690 2011-12-16 18:38:43 <genjix> jgarzik, sipa or gavinandresen
691 2011-12-16 18:38:51 <wumpus> BlueMatt: huh, seems I got a different output
692 2011-12-16 18:39:31 <gavinandresen> genjix:  bitcoin-security@lists.sourceforge.com (or is it .net?)
693 2011-12-16 18:39:40 <gavinandresen> genjix: ... or just email us
694 2011-12-16 18:39:42 <jgarzik> bitcoin-security@lists.sourceforge.net
695 2011-12-16 18:39:46 <wumpus> 0507969680fd1952f57b54842a8f463c40f3add3d6614281fab4be53916c0b76  build/out/bitcoin-0.5.1-win32-setup.exe
696 2011-12-16 18:39:47 <wumpus> 01aad906ac14b9a2f877b2743272e1203004a7573b002396a11475037703ba86  build/out/bitcoin-qt.exe
697 2011-12-16 18:39:51 <wumpus> hm no I didn't
698 2011-12-16 18:39:53 <wumpus> it matches
699 2011-12-16 18:40:11 <wumpus> strange, the hash printed by gitian itself (see above) was different...
700 2011-12-16 18:40:13 <jgarzik> gavinandresen: we should get a security@bitcoin.org alias
701 2011-12-16 18:40:33 <gavinandresen> jgarzik: ACK.  can you make that happen?
702 2011-12-16 18:40:33 <genjix> ok thanks
703 2011-12-16 18:40:52 <wumpus> ok so we all got the same exe, that's great
704 2011-12-16 18:41:29 <jgarzik> gavinandresen: I think tcatm can
705 2011-12-16 18:41:39 <BlueMatt> wumpus: can you commit your sigs on the gitian output to bitcoin/gitian.sigs
706 2011-12-16 18:41:50 <BlueMatt> wumpus: (see doc/releaseprocess.txt for info)
707 2011-12-16 18:47:27 <tcatm> gavinandresen, jgarzik: I can't. I don't have access to bitcoin.org's DNS nor to a server that could handle the emails.
708 2011-12-16 18:49:25 <jgarzik> tcatm: that's sirius?
709 2011-12-16 18:50:27 <tcatm> I think so.
710 2011-12-16 18:51:15 <wumpus> BlueMatt: ok, added a pull request
711 2011-12-16 18:51:58 <[Tycho]> jgarzik: hello. Do you know why getwork returns block header for hashing not as just 80 bytes, but concatenated with another field ?
712 2011-12-16 18:53:03 <luke-jr> gavinandresen: if it makes things any easier, my 'next' branch is up to date and could be merged into master easily
713 2011-12-16 18:53:11 <luke-jr> (I think&)
714 2011-12-16 18:53:23 <luke-jr> actually not sure if I updated it after you rebased something
715 2011-12-16 18:53:51 <genjix> ok check your emails
716 2011-12-16 18:54:28 <genjix> at gavinandresen, jgarzik and tcatm
717 2011-12-16 18:54:30 <luke-jr> looks like the rebase was testnet stuff, which I do *not* have in 'next' right now
718 2011-12-16 18:54:54 <BlueMatt> wumpus: ok, you can push there now
719 2011-12-16 18:54:59 <gavinandresen> genjix: thanks
720 2011-12-16 18:55:07 <genjix> no worries
721 2011-12-16 18:55:54 <genjix> is phantomcircuit added? can you add him to the list :) bitcoin-security@covertinferno.org
722 2011-12-16 18:57:07 <BlueMatt> wumpus: oh, can you add linux sigs as well?
723 2011-12-16 18:57:11 <luke-jr> genjix: me too please
724 2011-12-16 18:57:27 <luke-jr> genjix: luke+bitcoin+security@dashjr.org
725 2011-12-16 18:57:39 <genjix> i dont control the list
726 2011-12-16 18:57:42 <luke-jr> who does?
727 2011-12-16 18:57:57 <genjix> not sure. someone here like jgar of gandres
728 2011-12-16 18:58:09 <BlueMatt> wumpus: also, can you confirm your pgp key id
729 2011-12-16 18:58:30 <genjix> luke-jr: i can forward you the mail also though
730 2011-12-16 18:58:32 <luke-jr> gavinandresen: do you want me to make an explicit pull request for 'next'?
731 2011-12-16 18:59:02 <gavinandresen> luke-jr: next is a whole bunch of pull requests bundled up?
732 2011-12-16 18:59:13 <luke-jr> gavinandresen: yes, all merged together (conflicts resolved)
733 2011-12-16 18:59:52 <gavinandresen> luke-jr:  no, I'd rather pull/discuss new features one by one
734 2011-12-16 19:00:00 <luke-jr> gavinandresen: I also have a 'next-test' with things not yet ACK'd for 0.6; I test/use that one.
735 2011-12-16 19:00:15 <luke-jr> gavinandresen: 'next' only has stuff already discussed/ACK'd
736 2011-12-16 19:04:10 <luke-jr> oh well, regardless of how the merging gets done, the GitHub pull req overview of it all is IMO useful& close it if you want
737 2011-12-16 19:05:48 <luke-jr> "Showing 41 changed files with 2,585 additions and 472 deletions."
738 2011-12-16 19:05:49 <luke-jr> :o
739 2011-12-16 19:06:19 <luke-jr> gavinandresen: in fact, if you *don't* close it, GitHub will probably mess with it when I update it&
740 2011-12-16 19:06:28 <luke-jr> (ie, when you pull things individually)
741 2011-12-16 19:06:58 <BlueMatt> wumpus: https://github.com/bitcoin/bitcoin/pull/706
742 2011-12-16 19:06:58 <luke-jr> (so please do)
743 2011-12-16 19:08:22 <luke-jr> https://github.com/bitcoin/bitcoin/pull/705
744 2011-12-16 19:08:43 <BlueMatt> wumpus: also, if you dont mind can you give me a final review of https://github.com/bitcoin/bitcoin/pull/593 , Id like to see it pulled for 0.6, but I want your ACK...or are there any more suggestions you have?
745 2011-12-16 19:09:14 <[eval]> bitcoind from PPA updated to 0.5.1 yay
746 2011-12-16 19:09:35 <BlueMatt> [eval]: you're welcome ;)
747 2011-12-16 19:10:46 <luke-jr> https://github.com/bitcoin/bitcoin/pull/705 <-- 'next' summary
748 2011-12-16 19:14:40 <[eval]> BlueMatt: thanks :D
749 2011-12-16 19:15:29 <[eval]> luke-jr: i just forked the repo and am working on setting up git on my machine... gonna familiarize myself with the internals of bitcoin and try and create those pull requests we were talking about in #bitcoin :>
750 2011-12-16 19:17:45 <luke-jr> [eval]: cool
751 2011-12-16 19:23:00 <[eval]> gavinandresen: many thanks :> that was one of the first places i was going to look after figuring out git
752 2011-12-16 19:23:25 <[eval]> this may take me a while; i haven't coded in C++ in a long, long time
753 2011-12-16 19:23:28 <luke-jr> (FYI, what [eval] and I discussed was being able to add fees to transactions later)
754 2011-12-16 19:23:49 <[eval]> (without doing versioning)
755 2011-12-16 19:25:30 <[eval]> i might do it as two separate pull requests: one to redeem a low-priority transaction's outputs with a high-priority transaction thereby getting them both into a block (allowing the recipient to retroactively "up" a transaction's priority either by paying fees or by adding high-priority inputs)...
756 2011-12-16 19:26:34 <[eval]> and one to actually replace one transaction with another by decreasing one of the outputs to add fees or adding an input and increasing one of the outputs by <= the amount of the additional input (thus either raising priority or adding a fee)
757 2011-12-16 19:28:04 <[eval]> this should allow transactions to be "unstuck" if miners don't accept them without opening up opportunities for double-spending
758 2011-12-16 19:29:54 <[eval]> until a transaction is in a block, it's in the memory pool only and not written to disk?
759 2011-12-16 19:30:05 <JFK911> what sense does that make
760 2011-12-16 19:30:37 <luke-jr> [eval]: actually, right now nodes won't even put it in the memory pool without fees
761 2011-12-16 19:31:37 <BlueMatt> [eval]: there is already support for transaction replacement written into the client and short-circuited, I would suggest using that ;)
762 2011-12-16 19:33:30 <luke-jr> [eval]: they won't relay it, currently.
763 2011-12-16 19:33:32 <[eval]> BlueMatt: i'm like a bull in a china shop right now; i don't know what's where till i read all the code :P
764 2011-12-16 19:33:50 <BlueMatt> (though a second spend would work, its more stuff in the chain and really is not the preferred way to do it...that said, if the tx is one your received instead of sent you have to, so maybe just one rpc command to increase fee that will automatically choose between the possibilities based on who the coins were to...
765 2011-12-16 19:33:54 <[eval]> luke-jr: so what's the problem? if it doesn't get relayed and it doesn't get put in the memory pool, it doesn't really exist at all, does it?
766 2011-12-16 19:34:24 <luke-jr> [eval]: the problem is that your own client has no way to reissue it
767 2011-12-16 19:35:15 <gavinandresen> teaching the client to give up re-transmitting transactions that haven't made it into a block after... a long time... is a good idea.
768 2011-12-16 19:35:38 <luke-jr> gavinandresen: better would be to reissue the same one, under a new txid/fee
769 2011-12-16 19:35:47 <BlueMatt> implementing the tx replacement stuff that was written in originally is another good idea...
770 2011-12-16 19:36:05 <luke-jr> gavinandresen: don't want to have people doing attacks where someone's transaction gets "undone" then later goes through after they've resent it
771 2011-12-16 19:36:25 <TD> shadders: hey
772 2011-12-16 19:36:57 <gavinandresen> luke-jr: good point.
773 2011-12-16 19:37:27 <TD> [eval]: i'd like to see miners consider fees for transactions including all pending dependencies
774 2011-12-16 19:37:32 <luke-jr> in other words, we never want to display "transaction cancelled" when there's any chance it could be valid still
775 2011-12-16 19:37:42 <TD> [eval]: i think long term incorporating chains of transactions together to claim the fees on the last one will be quite common