1 2012-02-03 00:03:35 <Moron__> has anyone heard of the new virus on the news... you can get it just by opening an email and you dont even need to download anything
  2 2012-02-03 00:03:37 <Moron__> ??
  3 2012-02-03 00:05:14 <BlueMatt> Moron__: yea, a ton of email programs - especially the m$ written ones which have a billion and a half unnecessary and often not perfectly coded features, have security vulnerabilities...
  4 2012-02-03 00:05:49 <gmaxwell> Moron__: GOOD TIMES!
  5 2012-02-03 00:06:11 <BlueMatt> also, the news media rocks
  6 2012-02-03 00:06:18 <Moron__> :) gmaxwell
  7 2012-02-03 00:06:44 <gmaxwell> (http://en.wikipedia.org/wiki/Goodtimes_virus  for people who aren't old enough to remember when an email virus was only a crazy hoax... back when mail was just text)
  8 2012-02-03 00:06:57 <Moron__> oh heh
  9 2012-02-03 00:07:00 <Moron__> yeh...
 10 2012-02-03 00:07:09 <Moron__> we should just get rid of html for email
 11 2012-02-03 00:07:20 <Moron__> its an unnessary and buggy format thats prone to exploits
 12 2012-02-03 00:07:30 <BlueMatt> heh
 13 2012-02-03 00:07:31 <Moron__> i think emails should be in .pdf
 14 2012-02-03 00:07:37 <BlueMatt> heh
 15 2012-02-03 00:07:38 <BlueMatt> yea
 16 2012-02-03 00:07:50 <BlueMatt> I love the pdf standard, its so simple and uncomplicated
 17 2012-02-03 00:08:19 <gmaxwell> because having one turing complete language in our email (js) is less good then two or three (js, ps, and the adobe forms script stuff)
 18 2012-02-03 00:08:42 <BlueMatt> yep
 19 2012-02-03 00:09:43 <Moron__> i cant wait until someone fixes email too
 20 2012-02-03 00:09:54 <Moron__> there needs to be a captcha or something to send an email... cos theres way too much spam
 21 2012-02-03 00:10:32 <BlueMatt> yea, I cant wait for google wave to catch on
 22 2012-02-03 00:10:35 <BlueMatt> oh wait
 23 2012-02-03 00:10:41 <gmaxwell> Moron__: the remote mail server could give you a getwork and require a share in order to accept mail.
 24 2012-02-03 00:10:53 <BlueMatt> heh that would be great
 25 2012-02-03 00:11:39 <Moron__> gmaxwell: why not simply send a private key with a small amount of BTC, like an electronic stamp
 26 2012-02-03 00:11:48 <Moron__> that way you could have 1st class, second class, etc...
 27 2012-02-03 00:12:41 <gmaxwell> Moron__: because you'd also doublespend the private key before they got a chance to use it.
 28 2012-02-03 00:12:59 <Moron__> oh
 29 2012-02-03 00:14:34 <Moron__> how about a protocol change then.... if you wanna send a mail to someone, you could send first a request for a bitcoin address, you then send some btc to the bitcoin address, then you get a reply, and then you send the mail?
 30 2012-02-03 00:15:18 <Moron__> im sure people wont mind spending the equivalent of 0.05 usd to send a mail, and it might incentivise people to actually check their mail
 31 2012-02-03 00:15:25 <Moron__> rather than disregarding most of em
 32 2012-02-03 00:16:08 <roconnor> heh, blockexplorer lists the total TBTC of my transaction as 0
 33 2012-02-03 00:17:27 <gmaxwell> Moron__: because you have to already have bitcoin for that. Anyone can mine. Also processing the bitcoin transaction takes time, and it requires the server to run a client to see the payment.
 34 2012-02-03 00:17:58 <gmaxwell> (for mining the server would just proxy to some pool)
 35 2012-02-03 00:20:29 <Moron__> i see we now have wallet encryption built into the client
 36 2012-02-03 00:20:31 <Moron__> thats good i think
 37 2012-02-03 00:20:37 <Moron__> but do you think one day we will have blockchain encryption?
 38 2012-02-03 00:21:14 <luke-jr> &
 39 2012-02-03 00:21:16 <luke-jr> why?
 40 2012-02-03 00:21:47 <Moron__> well, some people might not wanna advertise to the world that theyre sending 10btc to their friend halfway across the globe :)
 41 2012-02-03 00:22:16 <luke-jr> that's how bitcoin works
 42 2012-02-03 00:22:31 <Moron__> oh
 43 2012-02-03 00:22:45 <luke-jr> http://luke.dashjr.org/programs/bitcoin/w/bitcoind/stable.git/commitdiff/c11e2b8679e13f739a58faf2a3439d4aaed24364
 44 2012-02-03 00:22:52 <luke-jr> ^ very much appreciate review of this backport
 45 2012-02-03 00:22:57 <luke-jr> it wasn't pretty
 46 2012-02-03 00:23:29 <BlueMatt> meh, that might not be worth backporting...
 47 2012-02-03 01:02:46 <sipa> Moron__: the point of the blockchain is exactly that everyone can verify it
 48 2012-02-03 01:03:03 <sipa> why would you want to encrypt it? you should not put personally identifiable information in it
 49 2012-02-03 01:03:21 <sipa> well, except homomorphic encryption maybe
 50 2012-02-03 01:05:05 <Moron__> eww no, i dont agree with that kinda behaviour
 51 2012-02-03 01:05:25 <gmaxwell> Moron__: see the section on private in bitcoin pdf. 10. I think.
 52 2012-02-03 01:05:49 <gmaxwell> If you use your addresses carefully you're not advertising your activities.
 53 2012-02-03 01:06:54 <sipa> gmaxwell: even just having two chains already implies several pools
 54 2012-02-03 01:07:36 <gmaxwell> sipa: :-/
 55 2012-02-03 01:08:04 <sipa> possible of course, but i like how the current implementation so nicely integrates with the current system, and already provides at least some of the possible benefits of determinstic wallets
 56 2012-02-03 01:13:54 <XMPPwocky> so if a Bitcoin client gets a block (ignoring checkpoints) that's lower in height than one it already has, does the client keep that block?
 57 2012-02-03 01:14:15 <roconnor> when does bitcoins 32-bit clock overflow again?
 58 2012-02-03 01:15:01 <gmaxwell> XMPPwocky: yes, subject to the orphan flooding protection.
 59 2012-02-03 01:15:08 <sipa> $ date --date "@$((2**32-1))"
 60 2012-02-03 01:15:25 <roconnor> thanks
 61 2012-02-03 01:16:11 <XMPPwocky> gmaxwell: but if there's a checkpoint after it, it just gets silently dropped?
 62 2012-02-03 01:16:18 <JFK911> then what?  transition to a 33 bit clock?
 63 2012-02-03 01:17:02 <gmaxwell> JFK911: no.. just make sure the wrap is handled okay.
 64 2012-02-03 01:17:55 <BlueMatt> the wrap is gonna have some ugly code
 65 2012-02-03 01:18:06 <BlueMatt> (not that I think bitcoin will make it to 2106, but...)
 66 2012-02-03 01:18:37 <gmaxwell> it's not like the timestamp is actually used in many places.
 67 2012-02-03 01:19:18 <BlueMatt> where is it used? blocks, ...?
 68 2012-02-03 01:19:52 <sipa> just have a int64 GetTimeOf(uint32 t) that interprets it as the 2^32*n+t which is closest to the current date
 69 2012-02-03 01:20:12 <sipa> well, not in blocks of course
 70 2012-02-03 01:21:06 <roconnor> Is that before or after the last statoshi is distributed?
 71 2012-02-03 01:21:17 <gmaxwell> before
 72 2012-02-03 01:21:31 <gmaxwell> (most likely)
 73 2012-02-03 01:21:33 <sipa> probably before
 74 2012-02-03 01:21:35 <sipa> indeed
 75 2012-02-03 01:22:41 <da2ce7> BlueMatt: prob by then we will have had a hard fork of the chain and have fixed all of the unclean ness.
 76 2012-02-03 01:22:48 <gmaxwell> a very disruptive break in computing power might put bitcoin ahead of schedule due to clamping.. but it would have to be bogglingly massive to move the time by 40 years. :)
 77 2012-02-03 01:23:31 <BlueMatt> da2ce7: yep, probably
 78 2012-02-03 01:23:35 <da2ce7> gmaxwell: or timewarp.
 79 2012-02-03 01:24:06 <gmaxwell> nah.
 80 2012-02-03 01:24:15 <roconnor> gmaxwell: more likely timewarping
 81 2012-02-03 01:24:19 <roconnor> opps
 82 2012-02-03 01:24:22 <roconnor> I'm way too slow
 83 2012-02-03 01:24:51 <sipa> when is the intended last satoshi subsidy?
 84 2012-02-03 01:25:02 <BlueMatt> gmaxwell: you dont think we will have to hard fork at some point before 2106?
 85 2012-02-03 01:25:29 <sipa> 2140, right
 86 2012-02-03 01:26:07 <gmaxwell> BlueMatt: we would probably if computing power increased enough to move the subsidy from 2140 to before 2106!
 87 2012-02-03 01:26:22 <BlueMatt> heh, yep
 88 2012-02-03 01:27:10 <sipa> so, 104 instead of 138 years, that means a growth of 138/104 per two weeks
 89 2012-02-03 01:27:12 <gmaxwell> I expect if bitcoin (or its economic direct successor) was still used int 2100 the granularity would have also been increased.
 90 2012-02-03 01:27:34 <sipa> no, per 104/138*2 weeks
 91 2012-02-03 01:28:01 <sipa> so a growth of 2.7% per day
 92 2012-02-03 01:28:36 <da2ce7> it would be fun to develop the 'bitcoin after hardfork' and do a few tests with hardforks on the testnet.
 93 2012-02-03 01:30:11 <BlueMatt> that does seem a bit much
 94 2012-02-03 01:30:18 <BlueMatt> that said, you never know...
 95 2012-02-03 01:31:41 <gmaxwell> the aliens give us all quantum computers one day, and the we need to square the difficulty to catch up.
 96 2012-02-03 01:35:42 <da2ce7> well that isn't that much...
 97 2012-02-03 01:42:26 <theymos> On the Hardfork Wishlist wiki page, it says "This changes would involve converting old blocks: uint64_t for timestamp field in blocks." Can you just interpret version-1 timestamps differently from version-2?
 98 2012-02-03 01:43:00 <roconnor> theymos: nope because currently version 2 blocks are interpreted exactly as version 1 blocks
 99 2012-02-03 01:43:22 <theymos> That's stupid and should be fixed.
100 2012-02-03 01:43:25 <gmaxwell> oh well then we just put the rest of the timestamp there. done.
101 2012-02-03 01:43:36 <gmaxwell> theymos: it's compatible. hurrah.
102 2012-02-03 01:44:38 <theymos> Are tx versions also ignored? If so, that could be used as a nice flag for BIP 16 stuff instead of using templates.
103 2012-02-03 01:44:52 <roconnor> theymos: AFAIU all version numbers are ignored
104 2012-02-03 01:45:29 <sipa> also, even if they were not ignored, you can't introduce a backward-compatible upgrade using them
105 2012-02-03 01:45:38 <gribble> New news from bitcoinrss: gavinandresen opened issue 794 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/794>
106 2012-02-03 01:46:50 <theymos> Not backward-compatible, but new nodes would be able to distinguish between the two formats easily.
107 2012-02-03 02:05:33 <sipa> theymos: not backward-compatible == hardfork
108 2012-02-03 02:09:51 <theymos> I know. I was talking about extending the timestamp, which will require a hardfork anyway. It seems best to do this by updating the block version number and then treating old version-1 blocks differently than version-2 blocks. However, if version-2+ blocks are currently allowed, this scheme isn't going to work.
109 2012-02-03 02:11:50 <roconnor> theymos: on testnet I use random version numbers
110 2012-02-03 02:14:29 <theymos> Seems best IMO to start discouraging non-standard versions now and rejecting them later.
111 2012-02-03 02:15:42 <roconnor> theymos: I think you are right, I think BIP 16 / 17 would be better if they also required transaction version 2 or higher.
112 2012-02-03 02:15:48 <sipa> theymos: Gavin was thinking about something like that, iirc
113 2012-02-03 02:17:08 <sipa> actually, we could retroactively introduce the rule "if only the lower 8 bits of the version number differ, the block/tx format is identical, and only previously-valid things are made invalid"
114 2012-02-03 02:17:40 <sipa> as currently all version numbers are accepted, this rule on itself only makes previously-valid things invalid, causing no fork
115 2012-02-03 02:19:24 <sipa> gmaxwell, roconnor, theymos: what do you think about that?
116 2012-02-03 02:19:58 <roconnor> I'm confused by it
117 2012-02-03 02:20:10 <theymos> Yeah, I don't understand what you mean.
118 2012-02-03 02:20:24 <sipa> ok
119 2012-02-03 02:20:38 <sipa> so assume we want to fix the problem that version numbers are ignored
120 2012-02-03 02:21:01 <sipa> the question raises: what does a client need to do when it encounters a block or tx with a version it does not know about
121 2012-02-03 02:21:39 <sipa> two possibilities exist: interpret it as the highest version it does understand, or assume it will not be valid it all
122 2012-02-03 02:22:03 <sipa> for the change introduced by BIP16 or BIP17, you want the former behaviour
123 2012-02-03 02:22:13 <sipa> if you do a hardfork, you want the latter behaviour
124 2012-02-03 02:22:38 <roconnor> a good start would be having BIP 16 / 17 use version numbers
125 2012-02-03 02:22:42 <sipa> so i propose splitting the version number into two parts: a major version (the high bits) and a minor version (the low 8 bits)
126 2012-02-03 02:22:55 <theymos> Ah, I like that idea. Adds some flags for BIP16-type things, but still allows for hardfork stuff.
127 2012-02-03 02:23:25 <sipa> if only the minor number is increased, a client is allowed (and required) to interpret it as the highest version it does know about
128 2012-02-03 02:23:37 <sipa> if the major number is increased, a client must reject it
129 2012-02-03 02:23:49 <roconnor> sipa: at first glance it sounds good
130 2012-02-03 02:24:35 <sipa> as currently all version numbers are accepted, this rule on itself only makes previously-valid things invalid (the major version update requirement), thus it can be done without a hardfork
131 2012-02-03 02:27:35 <sipa> so together with BIP16/BIP17 this means changing the version number to 0x0002, and also not intepreting transactions with version 0x0001 as BIP16/BIP17 enabled
132 2012-02-03 02:28:19 <theymos> Seems very elegant to me. Might even satisfy Luke.
133 2012-02-03 02:28:49 <roconnor> hashtypes are also an issue
134 2012-02-03 02:30:01 <roconnor> sipa: BIP it
135 2012-02-03 02:30:32 <sipa> one thing to think about is the interaction of blocks and transactions
136 2012-02-03 02:31:53 <sipa> i'd say there is only one version number space, and the version number of a block cannot be lower than the highest version used by one of its transactions
137 2012-02-03 02:33:16 <theymos> The blocks are going to get rejected due to invalid transactions anyway, so using up a version number in the block seems pointless. Tying them together like that would only offer a small shortcut in verification.
138 2012-02-03 02:34:02 <sipa> yes, but it does allow backward-compatible updates to the block rules that do not require a corresponding update in the transaction versions
139 2012-02-03 02:34:24 <sipa> and it prevents needing to keep two sets of version-number-rules with possibly strange interactions
140 2012-02-03 02:34:34 <luke-jr> does it still execute the scripts?
141 2012-02-03 02:34:39 <sipa> ?
142 2012-02-03 02:35:29 <luke-jr> sipa: if the version is changed, do the scripts still execute?
143 2012-02-03 02:35:40 <sipa> the minor version or the major one?
144 2012-02-03 02:35:46 <luke-jr> right now I mean
145 2012-02-03 02:36:00 <luke-jr> (I'd prefer a 16-bit major + 16-bit minor fwiw)
146 2012-02-03 02:37:05 <luke-jr> either way, using version like this would IMO move me from "Very weak" on BIP 16 to "Yes" (with Prefer still BIP 17, which could also have a similar version rule if adopted)
147 2012-02-03 02:37:42 <roconnor> I agree with luke-jr, it is a big improvement.
148 2012-02-03 02:37:56 <TuxBlackEdo> yep much better
149 2012-02-03 02:38:01 <theymos> Yeah, I'd love to see this.
150 2012-02-03 02:38:10 <luke-jr> jgarzik: (#794) nobody was talking about hashespersec
151 2012-02-03 02:38:25 <roconnor> it fixes to some extent some backwards compatibility issues.
152 2012-02-03 02:38:33 <splatster> etotheipi_: Anything new in terms of build procedure for OS X? I still can't get it working
153 2012-02-03 02:38:49 <luke-jr> sipa: would you prefer to make it part of BIP 18, or just a minor revision to BIP 16?
154 2012-02-03 02:39:01 <sipa> i think it needs to be a BIP on itself
155 2012-02-03 02:39:07 <roconnor> really this BIP should be done first
156 2012-02-03 02:39:15 <luke-jr> wouldn't it replace BIP 16?
157 2012-02-03 02:39:15 <roconnor> make sure there is suffiecent mining support
158 2012-02-03 02:39:21 <sipa> luke-jr: no
159 2012-02-03 02:39:23 <roconnor> then do BIP16 or BIP 17
160 2012-02-03 02:39:55 <luke-jr> sipa: so the BIP is "only apply BIP 16 when version = 2"?
161 2012-02-03 02:39:57 <luke-jr> O.o
162 2012-02-03 02:40:03 <sipa> wait
163 2012-02-03 02:40:08 <roconnor> when version >= 2
164 2012-02-03 02:40:14 <sipa> there are two independent changes here
165 2012-02-03 02:40:36 <luke-jr> oh, you're talking about the major/minor split
166 2012-02-03 02:40:36 <theymos> I suggest including in the BIP that clients should start discouraging and then later rejecting blocks with strange major versions.
167 2012-02-03 02:40:37 <sipa> 1) the behaviour updates implied by BIP16, BIP17 or this version policy
168 2012-02-03 02:40:57 <sipa> 2) the "soft" blockchain split that is require by all three
169 2012-02-03 02:42:20 <sipa> i'd prefer a) BIP16 and BIP17 to do a minor modification "these new style transactions require a minor tx version of 0x0002" and b) have the voting adapted so it reflects both the change to the version number policy as the change by BIP16 or BIP17
170 2012-02-03 02:43:07 <luke-jr> sounds good to me
171 2012-02-03 02:43:21 <luke-jr> want me to update BIP 17, or will you do that?
172 2012-02-03 02:43:28 <roconnor> sipa: version 2 or greater?
173 2012-02-03 02:43:37 <luke-jr> or maybe I should just wait until BIP 16 is updated and Withdraw 17
174 2012-02-03 02:43:38 <sipa> roconnor: indeed, or greater
175 2012-02-03 02:43:56 <theymos> sipa: It probably is easiest and safest to tie the versions together, especially if minor versions are 16 bytes and you don't need to worry about wasting values.
176 2012-02-03 02:43:57 <sipa> luke-jr: i think this proposal needs to be formally made into a BIP first
177 2012-02-03 02:44:36 <luke-jr> theymos: you are genius btw
178 2012-02-03 02:44:46 <theymos> Why?
179 2012-02-03 02:44:50 <luke-jr> theymos: for suggesting this
180 2012-02-03 02:44:55 <theymos> This is sipa's idea.
181 2012-02-03 02:44:58 <luke-jr> oh
182 2012-02-03 02:45:06 <luke-jr> I already knew sipa was genius though
183 2012-02-03 02:45:31 <sipa> theymos: what about this: the block is allowed to be of a higher minor version than the transactions in it; it simply means the minor did not perform the validation required by the higher minor version
184 2012-02-03 02:45:35 <sipa> this replaces voting
185 2012-02-03 02:45:37 <sipa> AND
186 2012-02-03 02:45:45 <sipa> *miner
187 2012-02-03 02:46:03 <luke-jr> O.o
188 2012-02-03 02:46:19 <theymos> That seems too complex to me.
189 2012-02-03 02:46:38 <sipa> It looks extremely elegant to me.
190 2012-02-03 02:46:46 <sipa> (but maybe a bridge too far)
191 2012-02-03 02:47:59 <theymos> It doesn't seem right to me that the miner would ignore instructions in a tx that it can't or won't understand.
192 2012-02-03 02:48:15 <sipa> theymos: that is what is going to happen anyway
193 2012-02-03 02:48:50 <sipa> if BIP16/BIP17 are enabled right now as soon as 55% minors support it, the other 45% will create blocks which did not do the validation required by BIP16/17
194 2012-02-03 02:49:12 <luke-jr> sipa: no, the other 45% will ignore due to IsStandard
195 2012-02-03 02:49:25 <theymos> Yeah, you're right about that. I wasn't thinking about it in the right way.
196 2012-02-03 02:49:52 <sipa> luke-jr: if you assume they are all running the satoshi client with unmodified isstandard rules, yes
197 2012-02-03 02:50:09 <luke-jr> sipa: most are.
198 2012-02-03 02:50:12 <sipa> i know
199 2012-02-03 02:50:20 <sipa> so in practice, you are right
200 2012-02-03 02:53:36 <theymos> With this new info in the chain, Bitcoin could alert miners (not shutting down, of course) when a large percentage of recent blocks have higher minor versions. This'd help speed up deployment of new rules.
201 2012-02-03 02:54:13 <luke-jr> theymos: Gavin already has an alert function
202 2012-02-03 02:54:26 <theymos> That can't be targeted at miners, though.
203 2012-02-03 02:54:38 <luke-jr> o i c
204 2012-02-03 02:54:53 <sipa> you could also have a rule that makes the client favor blocks with a higher version number - though i'm not sure this is entirely safe
205 2012-02-03 02:56:41 <theymos> I think that'd only be safe if it applied to versions <= versions the client knows about.
206 2012-02-03 02:58:15 <sipa> a block with version 0x0001 and transaction of version 0x0002 in it, is still invalid to clients which support version 0x0002 if the 0x0002 transactions in it fail the stronger validation
207 2012-02-03 03:07:45 <jgarzik> luke-jr: gavin said in the issue, quote, "I think hashespersec should be greater than zero, also..."
208 2012-02-03 03:08:25 <luke-jr> oh, missed that
209 2012-02-03 03:08:37 <luke-jr> "generate" : true, <-- he's right?
210 2012-02-03 03:09:14 <sipa> hmm, how about including the supported major/minor block/tx version in the protocol version?
211 2012-02-03 03:09:24 <sipa> that could be done in another BIP, though
212 2012-02-03 03:18:14 <nanotube> luke-jr: well, even if generate=true, client doesn't start mining until it has all the blocks. we don't know whether client had all blocks at the time that getinfo was executed.
213 2012-02-03 04:03:03 <sipa> the only way i see is having the rules for each minor version be of the form: (if blocktime<X, minorV>Y is identical to minorV=Y)
214 2012-02-03 05:18:07 <sipa> https://raw.github.com/gist/1728493/111c3dcfc89bc75d764990832ca153a92139f441/gistfile1.txt
215 2012-02-03 09:39:16 <cuqa> hey, anyone know who is owner of this address ?
216 2012-02-03 09:39:17 <cuqa> http://blockchain.info/address/e349bc52c931a910d9876c559383aaeacadab850
217 2012-02-03 09:42:41 <Eliel> cuqa: looks very much like the wallet address for some pool somewhere.
218 2012-02-03 09:42:58 <cuqa> yup, thats for sure
219 2012-02-03 09:43:37 <Eliel> you could probably estimate the pool hashrate by counting the 50BTC from the last 2 weeks.
220 2012-02-03 09:44:03 <Eliel> but it doesn't look like a small pool, nor a new one
221 2012-02-03 09:44:42 <cuqa> right, good idea
222 2012-02-03 09:45:19 <Eliel> hmm... the pool looks to be getting blocks at around 1 per hour.
223 2012-02-03 09:46:03 <Eliel> that leaves basically 3 options, deepbit, slush and btcguild.
224 2012-02-03 09:46:19 <Graet> my guess is mining.cz - but hey
225 2012-02-03 09:46:29 <Graet> ie slush
226 2012-02-03 09:57:24 <Eliel> cuqa: ok, verified it, it's slush's pool's address. The coinbases in the blocks clearly identify the pool.
227 2012-02-03 09:57:37 <Eliel> so, mining.cz as Graet said.
228 2012-02-03 09:57:41 <cuqa> thx
229 2012-02-03 09:58:02 <cuqa> ok thought me that, because its via tor
230 2012-02-03 10:15:24 <shargalarg> lua based script engine?
231 2012-02-03 10:21:08 <sipa> ?
232 2012-02-03 13:23:08 <vsrinivas> i've heard that bitcoind 0.6-notyet doesn't support solo mining via getwork; is this the case?
233 2012-02-03 13:29:43 <luke-jr> sipa: FWIW, something is wrong with the new address stuff I think; been testing it on Eligius, but it crashed overnight and corrupted addr.dat
234 2012-02-03 13:30:47 <sipa> hmm, Gavin also reported a segfault with it; i'll look into it
235 2012-02-03 13:38:12 <luke-jr> sipa: it seems to have corrupted wallet.dat possibly too fwiw
236 2012-02-03 13:41:30 <sipa> that seems strange
237 2012-02-03 13:51:37 <shargs> tyranadon
238 2012-02-03 13:53:59 <luke-jr> sipa: I accidentally the corrupt files :<
239 2012-02-03 13:54:16 <luke-jr> I am running in gdb now
240 2012-02-03 13:55:05 <sipa> https://gist.github.com/1728493
241 2012-02-03 13:59:02 <luke-jr> "Clients ignore blocks and transaction with major version numbers they do not know about, and use the rules associated with the highest minor version they know about, not higher than that of the block or transaction."
242 2012-02-03 13:59:10 <jgarzik> heh
243 2012-02-03 13:59:12 <luke-jr> do not understand the second part
244 2012-02-03 13:59:19 <jgarzik> Mr. Libcoin is dodging gmaxwell's questions now
245 2012-02-03 13:59:24 <jgarzik> confidence--
246 2012-02-03 14:00:38 <sipa> jgarzik: i had a private e-mail conversation with him today - turns out his code is far from thread safe
247 2012-02-03 14:00:46 <luke-jr> "* should validate unmined transactions with version X.Z using the rules of version X.[min(Z,Y)]."
248 2012-02-03 14:00:57 <luke-jr> ^ only for Z >= Y ?
249 2012-02-03 14:01:06 <luke-jr> (in which case, min is redundant)
250 2012-02-03 14:01:06 <sipa> no
251 2012-02-03 14:01:27 <luke-jr> oh ok, I think I get it now&
252 2012-02-03 14:02:04 <luke-jr> sipa: so version 2 would be valid with pre-P2SH transactions too?
253 2012-02-03 14:02:14 <sipa> yes
254 2012-02-03 14:02:50 <luke-jr> :/
255 2012-02-03 14:03:28 <sipa> new versions cannot make previously-valid things invalid
256 2012-02-03 14:03:41 <luke-jr> no?
257 2012-02-03 14:03:46 <luke-jr> isn't that the whole point?
258 2012-02-03 14:04:03 <sipa> you can't -- doing so would require a hard fork
259 2012-02-03 14:04:23 <luke-jr> no, only making previously-invalid things valid would
260 2012-02-03 14:04:32 <sipa> oh
261 2012-02-03 14:04:35 <sipa> miswritten!
262 2012-02-03 14:04:52 <sipa> i mean they can only make previously-valid things invalid
263 2012-02-03 14:05:25 <luke-jr> I was thinking of version==2 being a P2SH marker, and only allowing P2SH while the old-style continued to use version==1
264 2012-02-03 14:06:25 <sipa> and what about transactions that are valid when interpreted as P2SH, and invalid using the old rules?
265 2012-02-03 14:06:31 <sipa> which is probably all of them
266 2012-02-03 14:07:36 <sipa> wait
267 2012-02-03 14:07:50 <sipa> you are right, you could define version 2 to be P2SH only
268 2012-02-03 14:10:18 <sipa> however, that would imply that any further update to the script language is done in a way that is compatible with P2SH
269 2012-02-03 14:10:36 <luke-jr> with your current BIP, yes
270 2012-02-03 14:10:49 <sipa> i don't think there is another way
271 2012-02-03 14:10:58 <luke-jr> perhaps there are really 3 categories needed: major, minor, and alternative?
272 2012-02-03 14:11:18 <luke-jr> ie, if version 3 isn't supported, fall back to version 1
273 2012-02-03 14:11:45 <sipa> right, turn the minor-version space into a tree instead of a list
274 2012-02-03 14:11:53 <luke-jr> 8-bits major (are we really going to hardfork over 255 times?), 8-bits minor, 16-bits alternative?
275 2012-02-03 14:12:17 <sipa> that's only moving the problem
276 2012-02-03 14:12:22 <luke-jr> ?
277 2012-02-03 14:12:30 <luke-jr> or 8/12/12 maybe
278 2012-02-03 14:12:41 <sipa> how does alternative work?
279 2012-02-03 14:13:04 <luke-jr> if the major.minor.alternative isn't supported, it falls over to major.minor.1
280 2012-02-03 14:14:00 <luke-jr> major/minor work with your current rules as-is
281 2012-02-03 14:15:03 <sipa> ok, say we have 0.0.1 (current), 0.0.2 (p2sh), 0.0.3 (p2sh with an improved scripting language)
282 2012-02-03 14:15:27 <sipa> now comes the time when a real minor update is needed; what rules does 0.1.0 have?
283 2012-02-03 14:15:33 <forrestv> we're 10GH/s below Bitcoins.lc
284 2012-02-03 14:15:39 <forrestv> err, wrong channel :p
285 2012-02-03 14:16:17 <sipa> Eliel: have you read by proposal?
286 2012-02-03 14:16:25 <Eliel> which one?
287 2012-02-03 14:16:33 <sipa> https://gist.github.com/1728493
288 2012-02-03 14:17:24 <Eliel> ah no I didn't. Reading
289 2012-02-03 14:17:29 <sipa> luke-jr: will you immediately have 0.1.0, 0.1.1 and 0.1.2 ?
290 2012-02-03 14:19:03 <luke-jr> sipa: that would make sense if it's 8/8/16
291 2012-02-03 14:21:02 <sipa> luke-jr: the general problem is that with whatever set of interpreting version numbers you will introduce, you need a way to specify (for old clients) what sequence of older rulesets to use
292 2012-02-03 14:21:44 <sipa> which is 0.1.0's predecessor?
293 2012-02-03 14:22:58 <shargs> cain cain
294 2012-02-03 14:23:43 <sipa> luke-jr: ok, say 0.1.1 is a successor to 0.0.1, 0.1.2 is a successor to 0.0.2, 0.1.3 is a successor to 0.0.3
295 2012-02-03 14:24:12 <sipa> now you want to introduce some other change, independent from the scripting language, that is compatible with all three
296 2012-02-03 14:24:56 <sipa> * all 6
297 2012-02-03 14:25:12 <sipa> at that point, you need a fourth version number
298 2012-02-03 14:26:06 <luke-jr> new alternative based on one of the others sounds like a plan; it's not perfect :p
299 2012-02-03 14:30:05 <Eliel> sipa: I think the following strategy for old clients when they encounter transaction with major version higher than they support could work: when received as lone transaction, just drop them, don't forward, don't mine them. When received in a block, pretend they aren't there and validate the rest of the block.
300 2012-02-03 14:31:39 <Eliel> this would allow avoiding blockchain forks just because old clients can't parse things.
301 2012-02-03 14:31:59 <Eliel> and would keep old clients compatible enough to not force an upgrade immediately.
302 2012-02-03 14:35:43 <sipa> that way, you don't have semi-verification by old nodes
303 2012-02-03 14:38:43 <Eliel> that's not done by old nodes in case of major version change in your spec either.
304 2012-02-03 14:39:02 <shargs> ok
305 2012-02-03 14:39:04 <Eliel> they just drop the whole block if it contains anything they don't understand
306 2012-02-03 14:39:39 <sipa> major version update is for changes that cannot be made into something that fits the old rules
307 2012-02-03 14:40:06 <Eliel> yes, major version update for transactions is what I meant there.
308 2012-02-03 14:40:23 <Eliel> it won't work for major version update for blocks but for transactions, yes.
309 2012-02-03 14:47:58 <gmaxwell> Eliel: what happens when a old version txn spends outputs from a new version txn?
310 2012-02-03 14:48:22 <gmaxwell> If they ignored the new version txn completely they'd fail that block under your rules.
311 2012-02-03 14:50:02 <jamescarr> how hard is it to get started with mining for bitcoins with today's market? I mean, couldn't I just fire up a bunch of EC2 instances and get started?
312 2012-02-03 14:50:10 <jamescarr> or is the barrier to entry higher now?
313 2012-02-03 14:50:27 <Eliel> gmaxwell: if it ends up in a non-orphaned part of the chain, then accept it.
314 2012-02-03 14:50:44 <sipa> jamescarr: of course you could, but it would not be profitable
315 2012-02-03 14:51:58 <jamescarr> how come?
316 2012-02-03 14:52:21 <sipa> how could it be profitable? if it was, everyone would do it, increasing the difficulty until it isn't
317 2012-02-03 14:52:23 <gavinandresen> EC2 instances have never been profitable for mining
318 2012-02-03 14:52:47 <gavinandresen> ... even when bitcoins were selling for 0.5 cents apiece they were not profitable....
319 2012-02-03 14:53:17 <sipa> with own hardware you have better value for money, so those will always force other ways (e.g. EC2) out of the market
320 2012-02-03 14:53:28 <jamescarr> I'm guessing I could use a free t1.micro instance, but that wouldn't get me far beyond an initial mine I guess
321 2012-02-03 14:53:29 <gmaxwell> Eliel: then you're not really validating anything, you're just trusting the longest chain, with a potentially variable lag.
322 2012-02-03 14:53:30 <gavinandresen> sipa: I think I like your version proposal, although it means there has to be a linear sequence of supported new features.
323 2012-02-03 14:53:41 <Eliel> gmaxwell: of course, it'd be ideal if the client had code that explicitly tells the user that they ought to upgrade when those transactions start ending up in the chain and not being orphaned by miners.
324 2012-02-03 14:54:09 <gmaxwell> Eliel: we have the alert feature, which is different but can serve the same purpose.
325 2012-02-03 14:54:16 <Eliel> gmaxwell: exactly, the idea is not to validate but rather allow old clients some leeway in upgrading in the case of major transaction upgrade.
326 2012-02-03 14:54:25 <gmaxwell> Eliel: I think what you're suggesting would fundimentally change the security properties of bitcoin in a negative way.
327 2012-02-03 14:54:35 <gavinandresen> What is Eliel suggesting?
328 2012-02-03 14:55:00 <sipa> gavinandresen: assume transactions with unknown version are valid
329 2012-02-03 14:55:07 <gmaxwell> no, even more than that.
330 2012-02-03 14:55:07 <sipa> unconditionally
331 2012-02-03 14:55:22 <gavinandresen> Ummm.....
332 2012-02-03 14:55:23 <gmaxwell> with the response to my question it becomes more generally,  when blocks contain invalid things, just discourage the block until its burried.
333 2012-02-03 14:55:25 <Eliel> sipa: not unconditionally. They have to end up in the chain
334 2012-02-03 14:55:59 <gavinandresen> ... so a rogue miner creates a block with an invalid-to-everybody-else-but-unknown-version transaction that does... whatever they like....
335 2012-02-03 14:56:34 <gmaxwell> Basically it would give all nodes no more security than SPV nodes (or really spv nodes in a world where everyone was a SPV node)
336 2012-02-03 14:57:15 <gmaxwell> Eliel: Have you seen my rant about how narrow in scope the mining "vote" is?
337 2012-02-03 14:57:36 <gavinandresen> Yup, if you're willing to let the longest chain always validate everything for you then just be a SPV node and save yourself a lot of block-downloading time
338 2012-02-03 14:57:44 <Eliel> it takes 51+% of miners accepting the weirdness for it to have practical effects.
339 2012-02-03 14:58:10 <sipa> Eliel: i create a transaction with version 0.255 today
340 2012-02-03 14:58:17 <sipa> and everyone will assume it's valid
341 2012-02-03 14:58:37 <Eliel> sipa: no, it'll be ignored, old clients won't mine them, nor forward.
342 2012-02-03 14:58:52 <sipa> ok, i pay a miner to put it in a block
343 2012-02-03 14:59:04 <helo> the block will fail validation won't it?
344 2012-02-03 14:59:10 <phantomcircuit> helo, no it wont
345 2012-02-03 14:59:13 <phantomcircuit> that's the problem
346 2012-02-03 14:59:18 <helo> i see hhe
347 2012-02-03 14:59:25 <helo> heh
348 2012-02-03 14:59:39 <Eliel> sipa: other miners will reject the block.
349 2012-02-03 14:59:40 <gmaxwell> helo: Eliel is proposing changing the rules so that invalid transactions would be accepted if the version was from the future.
350 2012-02-03 14:59:55 <gavinandresen> but just for clients, not for miners?
351 2012-02-03 14:59:55 <gmaxwell> Eliel: Bitcoin is more secure than just trusting a vote though. For the most part you don't even trust the vote to have the right results (which has a somewhat odd outcome that it makes the vote have the right results)
352 2012-02-03 15:00:06 <Eliel> yes, not for miners.
353 2012-02-03 15:00:22 <gmaxwell> Eliel: please see my rant directed towards genjix's claim that bitcoin is run by a majority vote, https://bitcointalk.org/index.php?topic=61922.msg723476#msg723476
354 2012-02-03 15:01:23 <sipa> Eliel: i thought that when validating you ignore transactions in blocks with a version you don't know?
355 2012-02-03 15:01:46 <gmaxwell> I can see the email now "Hello fellow miners, with the upcoming drop to 12.5 BTC/block most of us will be hurting. I propose we apply this patch which will have the following effect:
356 2012-02-03 15:02:01 <Diablo-D3> oh shit
357 2012-02-03 15:02:06 <Diablo-D3> gmaxwell: you know though
358 2012-02-03 15:02:13 <Diablo-D3> it'd be hilarious to just keep producing 50 btc forever
359 2012-02-03 15:02:24 <Diablo-D3> mining would end up becoming some sort of industry
360 2012-02-03 15:02:33 <Diablo-D3> you'd have the entire moon converted into some giant DC
361 2012-02-03 15:02:33 <sipa> it will anyway
362 2012-02-03 15:02:55 <Graet> latency would be a killer Diablo-D3
363 2012-02-03 15:02:57 <Eliel> gmaxwell: surely that will be block level validation? I'm not suggesting to accept major changes there and just assume valid.
364 2012-02-03 15:02:57 <gmaxwell> Starting at block 630000 your node will add a transaction with version 0.3 which draws from block 0 and rewards you another 12.5 BTC, you will also accept blocks like this."
365 2012-02-03 15:03:30 <sipa> Eliel: ok, so only some rules are allowed to be changed by version numbers
366 2012-02-03 15:03:32 <sipa> which ones?
367 2012-02-03 15:03:33 <Eliel> gmaxwell: I'm talking about transaction validation.
368 2012-02-03 15:03:39 <Diablo-D3> pretty sure gmaxwell is just kidding
369 2012-02-03 15:03:46 <gmaxwell> Eliel: yes, I just proposed an additional transaction.
370 2012-02-03 15:04:04 <helo> gmaxwell: nice relativity analogy
371 2012-02-03 15:04:25 <Eliel> gmaxwell: it breaks the overall block integrity check that makes sure inputs and outputs sum up to acceptable totals.
372 2012-02-03 15:04:48 <Eliel> gmaxwell: or more like, it's double spending
373 2012-02-03 15:04:53 <gmaxwell> Eliel: you said these txn were not validated, just accepted.
374 2012-02-03 15:05:28 <Eliel> they can't be even detected as txn if the old client can't tell enough to check that double spends can't occur.
375 2012-02-03 15:05:39 <gmaxwell> helo: yea, when you get down to it .. thats the fundimental limit we're fighting. I used to use that as an argument why something light bitcoin (a consistent zero trust decenteralized system) was not possible.
376 2012-02-03 15:06:27 <gmaxwell> Eliel: then we can modify my hypothetical email to make them just spend lost coins. For example, we're aware of several tens of thousands of lost coins...
377 2012-02-03 15:07:51 <Eliel> gmaxwell: the input part of those txs are old-style so those can be verified.
378 2012-02-03 15:09:03 <gavinandresen> ... so miners to full validation but clients do some kind of half-validation...
379 2012-02-03 15:09:27 <gavinandresen> Until they upgrade, then they can do full validation.
380 2012-02-03 15:10:00 <Eliel> It's an idea. It could very well have some bad hole in it.
381 2012-02-03 15:10:39 <Eliel> it'd ease the upgrade process if the network rules need changing.
382 2012-02-03 15:10:49 <Eliel> for some of the rules.
383 2012-02-03 15:11:04 <cjd> "Warning: The bitcoin in this transaction comes from a transaction which your version cannot completely verify, please upgrade so you can be sure it's valid."
384 2012-02-03 15:11:18 <gmaxwell> cjd: ::cries:: you're missing the point.
385 2012-02-03 15:11:42 <gmaxwell> As a user of bitcoin I don't just care if txn to me have a valid history, I care that no one else is inflating the currency or robbing other people too.
386 2012-02-03 15:11:42 <k9quaint> cjd: you used the wrong font!
387 2012-02-03 15:12:42 <Eliel> sipa: I was basically thinking to restrict this to the scripting system.
388 2012-02-03 15:12:48 <gavinandresen> gmaxwell: to be fair, the 'balance of payments' could be validated even if there are scriptPubKeys you don't understand.
389 2012-02-03 15:14:07 <Eliel> I guess the only hot question it leaves us with is if we can be sure miners couldn't team up to do evil stuff with this.
390 2012-02-03 15:15:08 <gavinandresen> I still don't understand what "this" is
391 2012-02-03 15:15:53 <Eliel> I was commenting on sipa's bip predraft
392 2012-02-03 15:16:18 <Eliel> on how to use the version numbers in blocks and transactions
393 2012-02-03 15:16:28 <sipa> currently, if i run a bitcoin full node, i *know* that the entire history i am seeing is valid
394 2012-02-03 15:16:32 <gavinandresen> I have two hot questions about that:  1. will miners agree to go through the whole "express support, upgrade their bitcoinds" again any time soon for it.
395 2012-02-03 15:17:10 <gavinandresen> And 2. Is it enough-better than the scheme we're using now (strings in the coinbase to express support for new stuff) to justify all that work.
396 2012-02-03 15:18:00 <sipa> the rule change i proposed changes this to "i know that the entire history is valid up to the rules my client supports"
397 2012-02-03 15:19:14 <gavinandresen> sipa:  but if you think about it, that's not a change.
398 2012-02-03 15:19:47 <sipa> not really, it just formalizes what is otherwise done ad-hoc
399 2012-02-03 15:21:20 <gavinandresen> sure.  Like I said, my only real hot question is whether or not it should be a development priority.
400 2012-02-03 15:21:34 <gavinandresen> ... because there are LOTS of other things to work on
401 2012-02-03 15:21:51 <sipa> i think it is easy implementation-wise, actually
402 2012-02-03 15:22:08 <sipa> but i haven't thought too much about that
403 2012-02-03 15:22:35 <gavinandresen> If by implementation you mean writing the code, then I agree.  Rolling it out to the miners....
404 2012-02-03 15:23:30 <sipa> gavinandresen: do it at the same time as BIP16?
405 2012-02-03 15:23:45 <gavinandresen> no, that would be a nightmare.
406 2012-02-03 15:24:02 <gavinandresen> ... since we're already in the middle of that rollout.
407 2012-02-03 15:24:14 <shargs> why does 1and1 take 5 years to activate a hosting account
408 2012-02-03 15:24:35 <gavinandresen> shargs: because they don't accept bitcoin?
409 2012-02-03 15:24:37 <phantomcircuit> shargs, because chargebacks
410 2012-02-03 15:24:46 <Eliel> sipa: after thinking some more on my suggestion, I've come to think that what I suggested should only be applied with clients that could be difficult to upgrade fast.
411 2012-02-03 15:24:46 <phantomcircuit> gavinandresen, you dont know how right you are
412 2012-02-03 15:24:55 <phantomcircuit> also "Sorry, but this account information isn't available right now. Please try again later." fuck lloyds
413 2012-02-03 15:25:02 <phantomcircuit> how are these morons still in business
414 2012-02-03 15:25:56 <roconnor> gavinandresen: what was your opinion about modifying BIP 16 to require version 2 or higher?
415 2012-02-03 15:26:13 <shargs> yes it would be better if they took btc
416 2012-02-03 15:26:34 <luke-jr> in the middle of rolling out BIP 17*
417 2012-02-03 15:26:48 <phantomcircuit> shargs, screw 1and1 use momentovps.com
418 2012-02-03 15:27:02 <gavinandresen> roconnor: if it'll get luke to stop beating a dead horse, sure.
419 2012-02-03 15:27:56 <sipa> now i think about it: i think you only need version 2 on the transaction spending a P2SH
420 2012-02-03 15:28:02 <sipa> not the one creating it
421 2012-02-03 15:28:08 <gavinandresen> I was about to ask that.
422 2012-02-03 15:28:16 <luke-jr> sipa: so I can put version 1 on a spending to bypass the check? ;)
423 2012-02-03 15:28:37 <sipa> luke-jr: right :D
424 2012-02-03 15:28:41 <sipa> thanks for pointing that out
425 2012-02-03 15:28:59 <roconnor> As I understand the situtation, what we want to do is pass the versioning support BIP first (though sufficent miner concencus) and then go on to pass BIP 16 (or 17).
426 2012-02-03 15:29:37 <sipa> if they are not being rolled out simultaneously, i think it will be very hard to get version support before BIP16
427 2012-02-03 15:29:38 <gavinandresen> roconnor: who is "we" ?
428 2012-02-03 15:29:53 <roconnor> s/we/you
429 2012-02-03 15:30:17 <roconnor> as in you guys
430 2012-02-03 15:30:30 <roconnor> and s/want/ought
431 2012-02-03 15:30:33 <roconnor> :)
432 2012-02-03 15:30:36 <Eliel> luke-jr: that sounds like a borked version system. inputs and outputs obviously need separate versions :)
433 2012-02-03 15:31:24 <luke-jr> Eliel: I think too late for that
434 2012-02-03 15:31:34 <gavinandresen> roconnor: sipa's proposal needs lots more thought, in my humble opinion.  In the meantime, bitcoins continue to get stolen....
435 2012-02-03 15:31:42 <luke-jr> while the txn version could be split into 16-bit input and 16-bit output right now, what if there's differing kinds of inputs?
436 2012-02-03 15:31:45 <shargs> cool phantomcircuit i shall
437 2012-02-03 15:32:03 <Eliel> luke-jr: not necessarily, only the output version needs to be specified really. input version can be looked up from the previous txouts
438 2012-02-03 15:32:14 <luke-jr> it would be trivial to require version==2 on P2SH transactions, and leave the version details for the future
439 2012-02-03 15:33:46 <roconnor> gavinandresen: okay
440 2012-02-03 15:34:18 <luke-jr> btw, should spending multisig transactions put the change back into the multisig?
441 2012-02-03 15:35:49 <Eliel> luke-jr: that's up to the client really I think. Depending on the user's needs.
442 2012-02-03 15:37:17 <roconnor> gavinandresen: BTW, do you think that off-line wallets are insuffent to tackle the bitcoins get stolen problem?
443 2012-02-03 15:37:58 <gavinandresen> roconnor: latest theft was from a mining pool. How are they going to have an offline wallet when they make payouts constantly?
444 2012-02-03 15:39:08 <roconnor> oh; how would multisig have helped them?
445 2012-02-03 15:39:42 <roconnor> (though mining pools ought to be sophistcated enought to do multisig themselves right now; they don't need short addresses)
446 2012-02-03 15:39:49 <roconnor> IIUC
447 2012-02-03 15:40:07 <gavinandresen> They could mine into a multisig, and subscribe to a wallet protection service that looked for odd transaction patterns
448 2012-02-03 15:40:09 <roconnor> maybe I don't understand correctly
449 2012-02-03 15:40:18 <gavinandresen> (for example)
450 2012-02-03 15:40:30 <gavinandresen> Like emptying the entire wallet all at once....
451 2012-02-03 15:41:48 <roconnor> gavinandresen: I guess I don't really see how short addresses is needed for that.
452 2012-02-03 15:41:52 <roconnor> but anyhow
453 2012-02-03 15:42:14 <roconnor> gavinandresen: thanks for answering my question. :)
454 2012-02-03 15:42:23 <gavinandresen> roconnor: it's not, but, good decision or bad, the IsStandard multisig changes are bundled with the p2sh stuff
455 2012-02-03 15:46:07 <shargs> hmmmm
456 2012-02-03 15:46:12 <shargs> sounds like an inside job
457 2012-02-03 15:47:07 <shargs> "we got hacked" = "we bought a yacht"
458 2012-02-03 15:47:28 <Diablo-D3> can I haz yacht? =/
459 2012-02-03 15:51:46 <phantomcircuit> which pool ?
460 2012-02-03 15:52:09 <sipa> btcserv
461 2012-02-03 15:52:16 <phantomcircuit> facepalm
462 2012-02-03 15:52:20 <phantomcircuit> <-- FACEPALM
463 2012-02-03 15:52:48 <copumpkin> is there some way in bitcoin-qt to go back and rename unnamed addresses?
464 2012-02-03 15:53:10 <copumpkin> oh
465 2012-02-03 15:53:11 <copumpkin> edit label
466 2012-02-03 16:09:53 <Matoking> Bitcoin-qt should minimize to system tray and disappear from taskbar when I minimize it, no?
467 2012-02-03 16:15:27 <graingert> Matoking: it should close to systray
468 2012-02-03 16:15:39 <Matoking> But the window stays at the taskbar
469 2012-02-03 16:15:42 <graingert> Matoking: not minimise to systray, otherwise what's the point of minimize
470 2012-02-03 16:15:45 <graingert> *close*
471 2012-02-03 16:15:54 <graingert> you need to enable this in settings
472 2012-02-03 16:16:17 <Matoking> Hmm
473 2012-02-03 16:16:28 <Matoking> "Minimize to the tray instead of the taskbar" doesn't seem to work
474 2012-02-03 16:16:53 <Matoking> It still has the window minimize to the taskbar and the tray
475 2012-02-03 16:17:12 <marf_away> click on cross
476 2012-02-03 16:17:21 <marf_away> than it goes in tray
477 2012-02-03 16:17:41 <Matoking> I think I found a way to fix it though
478 2012-02-03 16:17:51 <marf_away> yes click on the Cross!!
479 2012-02-03 16:18:11 <Matoking> That's not what I meant
480 2012-02-03 16:18:21 <Matoking> I have "Minimize to the tray instead of the taskbar" enabled
481 2012-02-03 16:18:22 <graingert> minimize to tray is stupid and wrong
482 2012-02-03 16:18:34 <Matoking> So shouldn't it work that way?
483 2012-02-03 16:18:38 <marf_away> no
484 2012-02-03 16:18:47 <marf_away> its about the cross behavior
485 2012-02-03 16:19:02 <marf_away> minimizing or closing
486 2012-02-03 16:19:25 <Matoking> Closing works the same way had I that option enabled or not
487 2012-02-03 16:19:40 <marf_away> hmm
488 2012-02-03 16:19:45 <marf_away> ok dont know
489 2012-02-03 16:19:46 <marf_away> ;D
490 2012-02-03 16:25:04 <jamescarr> so I installed a wallet and it's been synchronizing with the network forever, after an hour it is at 61%
491 2012-02-03 16:25:06 <jamescarr> is this normal?
492 2012-02-03 16:25:34 <sipa> unfortunately, yes
493 2012-02-03 16:25:36 <marf_away> yes
494 2012-02-03 16:25:45 <marf_away> takes maybe 4-5 h additional!
495 2012-02-03 16:26:33 <marf_away> last 40% are much slower :/
496 2012-02-03 16:38:57 <Matoking> Oh goodie
497 2012-02-03 16:39:08 <Matoking> Something has changed in the bitcoin repository and now I can't compile it
498 2012-02-03 17:02:41 <Matoking> And when I get it to compile, it crashes instantly when I try to run it
499 2012-02-03 17:03:20 <sipa> what error did you get?
500 2012-02-03 17:03:45 <Matoking> 
501 2012-02-03 17:03:45 <Matoking> CWintab::OpenCWintab::OpenInvalid parameter passed to C runtime function.
502 2012-02-03 17:03:45 <Matoking> Invalid parameter passed to C runtime function.
503 2012-02-03 17:03:46 <Matoking> C:UsersJanneitcoin-qt-build-desktop-Qt_4_7_4_for_Desktop_-_MinGW_4_4__Qt_SDK__Release
504 2012-02-03 17:03:47 <Matoking> terminate called after throwing an instance of 'DbRunRecoveryException'
505 2012-02-03 17:03:48 <Matoking> C:UsersJanneitcoin-qt-build-desktop-Qt_4_7_4_for_Desktop_-_MinGW_4_4__Qt_SDK__Release
506 2012-02-03 17:03:54 <luke-jr> sipa: what do you think of replacing the magic template in BIP 16 with if(version == 2) ?
507 2012-02-03 17:04:55 <sipa> that can't possibly be backward-compatible
508 2012-02-03 17:05:00 <sipa> you definitely need the script
509 2012-02-03 17:05:16 <sipa> as in, the prefix and suffix to make it into a script that old versions accept
510 2012-02-03 17:05:39 <sipa> it IS possible to only have it interpreted as P2SH when it is in a version-2 tx, thought
511 2012-02-03 17:05:43 <sipa> *though
512 2012-02-03 17:05:48 <sipa> but i'm not in favor of that
513 2012-02-03 17:05:51 <luke-jr> sipa: I don't mean get rid of the script, just the new hehaviour
514 2012-02-03 17:06:17 <luke-jr> err
515 2012-02-03 17:06:24 <luke-jr> not get rid of it, but make it based on the version==2
516 2012-02-03 17:06:44 <luke-jr> and only the template passing IsStandard for version==2
517 2012-02-03 17:07:06 <Matoking> Okay
518 2012-02-03 17:07:10 <Matoking> Using different data dir worked
519 2012-02-03 17:07:21 <Matoking> It's most likely Berkeley DB backwards compatibility issues or something
520 2012-02-03 17:07:53 <Matoking> Okay
521 2012-02-03 17:09:06 <luke-jr> Matoking: try stopping and starting again
522 2012-02-03 17:09:54 <Matoking> Anyway
523 2012-02-03 17:10:02 <Matoking> I got the Minimize to the tray instead of the taskbar issue fixed
524 2012-02-03 17:10:08 <Matoking> As small as it may be
525 2012-02-03 17:17:52 <gribble> New news from bitcoinrss: Matoking opened pull request 795 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/795>
526 2012-02-03 17:23:04 <luke-jr> Matoking: I suspect you're going to be asked to rebase that into 1 commit&
527 2012-02-03 17:23:26 <Matoking> I hate Git
528 2012-02-03 17:23:45 <sipa> git rebase -i upstream/master
529 2012-02-03 17:23:53 <luke-jr> sipa: not that simple :p
530 2012-02-03 17:23:53 <sipa> change all but the first to "fix"
531 2012-02-03 17:23:54 <sipa> save
532 2012-02-03 17:24:42 <luke-jr> Matoking: git reset --hard origin/master ; git diff eead6ed2^..a017ec92 | patch -p1 ; git commit -a -c eead6ed2
533 2012-02-03 17:24:47 <luke-jr> I *think* that will rebase+combine
534 2012-02-03 17:25:22 <sipa> mine certainly will :)
535 2012-02-03 17:25:38 <luke-jr> sipa: it'll combine the "Blah" ? :P
536 2012-02-03 17:26:05 <sipa> ?
537 2012-02-03 17:27:04 <luke-jr> https://github.com/bitcoin/bitcoin/pull/795/commits
538 2012-02-03 17:27:30 <Matoking> Well now it opened COMMIT_EDITMSG
539 2012-02-03 17:27:32 <Matoking> This is new
540 2012-02-03 17:27:38 <luke-jr> O.o
541 2012-02-03 17:27:54 <luke-jr> just exit as-is
542 2012-02-03 17:27:58 <luke-jr> it should already be filled in for you
543 2012-02-03 17:31:52 <makomk> Hmmmm. I don't suppose that the p2pool protocol is documented anywhere?
544 2012-02-03 17:32:07 <sipa> ask in #p2pool :)
545 2012-02-03 17:32:54 <TradersEdgeDice> #bitcoin-otc
546 2012-02-03 17:35:12 <sipa> you may want to put /join in front of that?
547 2012-02-03 17:40:36 <Moron__> #gayporn
548 2012-02-03 17:40:48 <Moron__> ohps
549 2012-02-03 17:40:51 <Moron__> forgot the /join
550 2012-02-03 17:41:10 <Matoking> Classy
551 2012-02-03 17:43:42 <luke-jr> Matoking: did that work? :P
552 2012-02-03 17:43:50 <Matoking> @luke-jr https://github.com/bitcoin/bitcoin/pull/795/files
553 2012-02-03 17:43:58 <Matoking> That's what it did :P
554 2012-02-03 17:44:08 <luke-jr> O.O
555 2012-02-03 17:44:56 <luke-jr> oooooo
556 2012-02-03 17:45:08 <Matoking> Also
557 2012-02-03 17:45:17 <Matoking> Passing a NULL instead of a temporary QWidget may work too
558 2012-02-03 17:45:30 <luke-jr> 1 sec
559 2012-02-03 17:45:32 <Matoking> But the window size and such won't be probably preserved
560 2012-02-03 17:47:11 <luke-jr> git reset --hard origin/master ; git cherry-pick eead6ed2
561 2012-02-03 17:47:14 <luke-jr> Matoking: ^
562 2012-02-03 17:48:40 <Matoking> The previous  cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit anyway : git commit --allow-empty otherwise use git reset
563 2012-02-03 17:49:46 <Matoking> It also appears to be that bitcoin-qt fails to compile yet again
564 2012-02-03 17:51:14 <luke-jr> is your origin the mainline git repo?
565 2012-02-03 17:51:36 <luke-jr> git reset --hard d2291cc ; git cherry-pick eead6ed2
566 2012-02-03 17:52:31 <cjd> git clean -dxf ??
567 2012-02-03 17:53:05 <Matoking> Complaining about time-traveling
568 2012-02-03 17:53:10 <Matoking> Guess I'll force it to commit
569 2012-02-03 17:53:26 <Moron__> u bad bad man :P
570 2012-02-03 17:53:54 <Matoking> Holy Batman it seems to have worked
571 2012-02-03 17:53:57 <Moron__> u shouldnt force them to commit like that, let them do it in their own time...
572 2012-02-03 17:54:21 <Matoking> Well now everything is all nifty like in one single commit
573 2012-02-03 17:56:23 <helo> my client apparently has missed a transaction, so my balance doesn't agree with blockexplorer
574 2012-02-03 17:56:43 <helo> i am synched up though
575 2012-02-03 17:56:53 <Moron__> have you tried turning off your pc and on agai/
576 2012-02-03 17:56:54 <Moron__> ?
577 2012-02-03 17:57:00 <Diablo-D3> helo: quit and run bitcoin-qt --rescan
578 2012-02-03 17:57:10 <Diablo-D3> it'll take a shitload of time to start up, but it should fix shit
579 2012-02-03 17:57:27 <Matoking> Aren't balances on Blockexplorer different sometimes due to change addresses that are invisible to BlockexploreR?
580 2012-02-03 17:57:44 <Diablo-D3> Matoking: not quite.
581 2012-02-03 17:57:50 <helo> is this not something that needs further investigation?
582 2012-02-03 17:57:54 <Matoking> "While the last "balance" is the accurate number of bitcoins available to this address, it is likely not the balance available to this person. Every time a transaction is sent, some bitcoins are usually sent back to yourself at a new address (not included in the Bitcoin UI)"
583 2012-02-03 17:58:05 <Diablo-D3> yes, that.
584 2012-02-03 17:58:57 <Diablo-D3> helo: like I said, if you think its wrong, do what I said
585 2012-02-03 17:59:08 <Diablo-D3> it'll take awhile for bitcoin to start back up, but it manually rescans everything
586 2012-02-03 17:59:34 <midnightmagic> -rescan doesn't take a long time.
587 2012-02-03 17:59:56 <Diablo-D3> yeah it does
588 2012-02-03 18:00:07 <midnightmagic> Define "long time".
589 2012-02-03 18:00:11 <helo> spoooky
590 2012-02-03 18:00:13 <midnightmagic> Mine takes a few seconds.
591 2012-02-03 18:00:13 <sipa> something like 20s
592 2012-02-03 18:00:14 <Diablo-D3> more than without using it
593 2012-02-03 18:00:27 <midnightmagic> lol okay by that definition, yes, it takes a long time.
594 2012-02-03 18:00:29 <Diablo-D3> I have like several thousand tx
595 2012-02-03 18:00:38 <Diablo-D3> it takes more than it should
596 2012-02-03 18:02:14 <helo> it's pure luck that i even noticed this in the first place... might others have the same situation but not know?
597 2012-02-03 18:02:31 <Diablo-D3> noticed what?
598 2012-02-03 18:02:32 <helo> it appears that the ending balance is correct across my addresses... the transaction was just not shown in the list
599 2012-02-03 18:02:32 <sipa> helo: did rescan fix it?
600 2012-02-03 18:02:46 <helo> apparently it did
601 2012-02-03 18:03:00 <Diablo-D3> heh, thats why its there
602 2012-02-03 18:03:23 <sipa> did you do anything special ever with that wallet?
603 2012-02-03 18:03:33 <helo> never
604 2012-02-03 18:03:53 <helo> received some mining rewards, transferred a little to a couple other addresses
605 2012-02-03 18:04:44 <helo> i guess a big problem would be if my balance was incorrect. presumably i'd still have been able to send it all correctly
606 2012-02-03 18:05:01 <luke-jr> sipa: I've seen this reported multiple times with generation
607 2012-02-03 18:05:14 <sipa> was it a generation that was missing?
608 2012-02-03 18:05:17 <helo> yes
609 2012-02-03 18:05:32 <Diablo-D3> hrm weird
610 2012-02-03 18:05:40 <Diablo-D3> I suppose generations arent getting the testing they should
611 2012-02-03 18:05:44 <helo> luke nailed it immediately when i mentioned in #eligius :)
612 2012-02-03 18:05:55 <luke-jr> generations really need to be refactored IMO
613 2012-02-03 18:06:04 <luke-jr> so they appear like normal transactions re address/account/etc
614 2012-02-03 18:06:37 <sipa> agree
615 2012-02-03 18:07:11 <midnightmagic> helo: The worst problems I ever encountered were due to a crashing machine, or a killed bitcoind, and -rescan is my best friend.
616 2012-02-03 18:07:34 <Diablo-D3> yeah
617 2012-02-03 18:07:44 <Matoking> Ugh
618 2012-02-03 18:08:07 <helo> perhaps a sanity check to indicate the need to -rescan might be nice
619 2012-02-03 18:08:17 <Matoking> Looks like it doesn't want to be compiled right now
620 2012-02-03 18:09:00 <helo> just running through all of the transactions shown would have indicated a discrepancy with the balance shown
621 2012-02-03 18:09:02 <sipa> i don't get it
622 2012-02-03 18:09:13 <sipa> -rescan should not be needed since 0.3.21
623 2012-02-03 18:09:27 <helo> i've only ever used 0.5+
624 2012-02-03 18:10:28 <Diablo-D3> sipa: computers that lock up frequently would need it I assume
625 2012-02-03 18:12:29 <luke-jr> Diablo-D3: there was some code added to automate -rescan when needed though
626 2012-02-03 18:13:04 <Diablo-D3> maybe it should just be used every time
627 2012-02-03 18:13:31 <sipa> it is used every time
628 2012-02-03 18:13:47 <sipa> the wallet stores up to which block it is synced
629 2012-02-03 18:14:25 <sipa> if that differs from the current head of the block chain in the database, a rescan is done from the last common block on
630 2012-02-03 18:15:53 <Matoking> Compile error about undefined references about boost functions > Downloaded the newest boost library and extracted it > compiles fine > git stuff > won't compile anymore
631 2012-02-03 19:29:14 <gmaxwell> https://bitcointalk.org/index.php?topic=62376.0 < spooky partitioned node.
632 2012-02-03 19:29:31 <BlueMatt> ooo
633 2012-02-03 19:29:33 <BlueMatt> yuck
634 2012-02-03 19:30:06 <gmaxwell> 66 addresses found from DNS seeds  < but he was not getting connected.
635 2012-02-03 19:30:18 <BlueMatt> wtf???
636 2012-02-03 19:30:21 <BlueMatt> and irc too
637 2012-02-03 19:30:55 <gmaxwell> well. the nodes he got from IRC are not listening, according to a commenter there. Unshocking to me.
638 2012-02-03 19:31:14 <BlueMatt> shocking to me
639 2012-02-03 19:31:18 <gmaxwell> addnode worked, so he can make outbound connections.
640 2012-02-03 19:31:21 <BlueMatt> oh, irc
641 2012-02-03 19:31:31 <gmaxwell> dnsseed .. yea that part is shocking to me.
642 2012-02-03 19:31:32 <BlueMatt> dnsseed is what scares me
643 2012-02-03 19:32:48 <sipa> his clock is off
644 2012-02-03 19:33:01 <sipa> the lastseen of the retrieved nodes is in the future
645 2012-02-03 19:33:28 <BlueMatt> oh...
646 2012-02-03 19:33:31 <sipa> by ehm
647 2012-02-03 19:33:36 <sipa> 7 years :S
648 2012-02-03 19:34:16 <theymos> You're supposed to get a warning when that happens.
649 2012-02-03 19:34:33 <BlueMatt> god thats scary that someone from anonymous got a copy of an fbi conference call discussing hackers...
650 2012-02-03 19:36:06 <cjd> it is somewhat of concern that someone with a clock way off could be sybiled
651 2012-02-03 19:37:16 <BlueMatt> clock off 7 years...thats just weird...
652 2012-02-03 19:37:57 <cjd> indeed but if someone owned a few hundred nodes which were patched to allow anyone to connect to them nomatter how far off their clock is ...
653 2012-02-03 19:38:29 <cjd> not sure what they could get out of it but it's definitely not desirable
654 2012-02-03 19:39:01 <Moron__> hows it hanging peoplez!
655 2012-02-03 19:40:02 <cjd> probably "impossible" to attack since so many other stars would have to be aligned
656 2012-02-03 19:44:30 <theymos> I wonder if he was also connecting to himself or something. Bitcoin should have given him a warning when it found that none of his peers had the same time.
657 2012-02-03 19:48:19 <theymos> sipa: Did you post a draft of that version-related BIP anywhere yet?
658 2012-02-03 19:50:21 <sipa> theymos: https://gist.github.com/1728493
659 2012-02-03 19:50:32 <theymos> Thanks.
660 2012-02-03 19:51:44 <Eliel> BlueMatt: it could well be due to insider connections rather than direct hacking skills.
661 2012-02-03 19:52:36 <BlueMatt> Eliel: probably, either way its scary
662 2012-02-03 19:56:07 <Eliel> cjd: I find talking about being a member of anonymous a bit strange though. While there's certainly people who're more involved than others, all you need to do to become involed is... well, become involved.
663 2012-02-03 20:00:12 <roconnor> BTW, is all this network-time syncing stuff in the standard client really that important or just nonsense?
664 2012-02-03 20:01:23 <BlueMatt> its important to have a synced clock
665 2012-02-03 20:01:31 <BlueMatt> how you do it...doesnt matter
666 2012-02-03 20:01:48 <roconnor> BlueMatt: why does it matter if you are off by a few hours?
667 2012-02-03 20:01:59 <Eliel> it would be nice if it wouldn't be centrally controlled though, the time.
668 2012-02-03 20:02:05 <BlueMatt> you may reject blocks incorrectly
669 2012-02-03 20:02:25 <roconnor> BlueMatt: only for a few hours at most, then you will accept them.
670 2012-02-03 20:02:33 <cjd> IMO it's one of the most important things
671 2012-02-03 20:02:42 <theymos> I think you actually need to restart Bitcoin to accept them at the moment.
672 2012-02-03 20:02:44 <BlueMatt> roconnor: ok, well its important for miners to have good time
673 2012-02-03 20:03:04 <roconnor> BlueMatt: certainly they have an incentive to have thier block accepted
674 2012-02-03 20:03:07 <BlueMatt> Eliel: currently it is, but you can see how well tahts working...
675 2012-02-03 20:03:24 <Eliel> there was this proposal for a nakamoto-chain based decentralized time keeping proposal I read earlier today though :)
676 2012-02-03 20:03:27 <roconnor> BlueMatt: though I forget what the incentive is for them to give accurate time.
677 2012-02-03 20:03:28 <Eliel> it looked interesting.
678 2012-02-03 20:03:46 <cjd> and all of the time metrics are tailored to the timesync, which is why realsolid's change of the 1440 block retarget time was a disaster
679 2012-02-03 20:03:48 <Eliel> but I think it requires some hardware that's not installed by default.
680 2012-02-03 20:04:10 <roconnor> cjd: huh?
681 2012-02-03 20:04:22 <BlueMatt> roconnor: the only incentive is to have blocks within range so that other miners accept them afair
682 2012-02-03 20:05:37 <roconnor> BlueMatt: by that logic miners should produce time stamps with the earliest valid time, since that is the most likely to be accepted by the most people.
683 2012-02-03 20:05:48 <BlueMatt> roconnor: yep
684 2012-02-03 20:06:02 <sipa> almost all well-connected nodes in the network are off by at most a few seconds, i assume
685 2012-02-03 20:06:03 <BlueMatt> except it would kill diff
686 2012-02-03 20:06:09 <midnightmagic> It's not scary.
687 2012-02-03 20:06:26 <gmaxwell> roconnor: the accepted times are pretty sloppy up to two hours in the future will be accepted.
688 2012-02-03 20:06:35 <gmaxwell> so you just need your clock to be within that.
689 2012-02-03 20:06:58 <midnightmagic> BlueMatt: Why is the recorded phone call scary?
690 2012-02-03 20:07:29 <gmaxwell> sipa: good catch on the times.
691 2012-02-03 20:07:58 <gmaxwell> Did -qt break the time notice?
692 2012-02-03 20:08:28 <BlueMatt> midnightmagic: ok, scary might not be the right word, fucked up maybe, but seriously if people can find out info on where the cops are when investigating them, that is very, very fucked up
693 2012-02-03 20:08:28 <gmaxwell> Eliel: oh, I hadn't intended to make that public.
694 2012-02-03 20:08:38 <roconnor> BlueMatt: do miners have any incentive to keep difficulty low?  The whole, exchange rate/ difficulty/ hashrate interplay is kinda confusing.
695 2012-02-03 20:08:51 <sipa> wumpus: does bitcoin-qt give a warning in case the system time looks off?
696 2012-02-03 20:09:09 <gmaxwell> roconnor: if they drive the difficulty up they'll generate less bitcoin.
697 2012-02-03 20:09:38 <theymos> The time warning uses the same mechanism as alerts. If alerts work I think the time warning should work.
698 2012-02-03 20:09:41 <midnightmagic> BlueMatt: I don't find it fucked-up. Deliberately delaying trial via in-chambers submission (without defence present) is what's fucked up.
699 2012-02-03 20:10:15 <BlueMatt> roconnor: if you assume mining power at each pool is static, no, but it gets more complicated as you look to the future.  In the short term they will make less, in the long term they will still make the same % of the total generated bitcoin
700 2012-02-03 20:10:16 <gmaxwell> I know there _was_ a warning becuase people would whine about it on IRC from time to time when their timezone was wrong but the clock was "right".
701 2012-02-03 20:10:45 <Eliel> gmaxwell: ah, it was yours :D
702 2012-02-03 20:10:57 <BlueMatt> midnightmagic: are you kidding me? you dont see it as a problem if someone is being investigated and they know where the cops are with the investigation so they can run or otherwise change their behavior to avoid being caught?
703 2012-02-03 20:11:07 <Eliel> gmaxwell: I think it could work well as a replacement for the time algorithm in bitcoin :)
704 2012-02-03 20:11:26 <gmaxwell> Eliel: nah, requires hardware. .. the time in bitcoin .. is dumb but at least pretty easy to reason about.
705 2012-02-03 20:11:46 <gmaxwell> (well, and that reasoning says its subject to attack right now, but that can be improved)
706 2012-02-03 20:11:59 <Eliel> gmaxwell: I wonder if a wlan card would be enough for that :)
707 2012-02-03 20:12:22 <Moron__> hey guys
708 2012-02-03 20:12:37 <Moron__> bitcoin has a distributed time stamping system right?
709 2012-02-03 20:12:58 <BlueMatt> wrong
710 2012-02-03 20:13:12 <midnightmagic> BlueMatt: No, not if the cops are comporting their investigation the way those cops are, no. (Including the use of international telephone chatrooms where people-present are unknown.)
711 2012-02-03 20:13:19 <Moron__> wrong?
712 2012-02-03 20:13:34 <gmaxwell> BlueMatt: see the "features we need to prevent moronic behavior" on my features page. ;)
713 2012-02-03 20:13:48 <luke-jr> sipa: didn't like the alternates idea?
714 2012-02-03 20:14:09 <luke-jr> Moron__: it's possible to make one using merged-mining, but nobody has done it
715 2012-02-03 20:14:09 <sipa> luke-jr: as i said, it only moves the problem
716 2012-02-03 20:14:15 <BlueMatt> midnightmagic: my point isnt whether it was easy or hard, my point is the cops need to do a better job because they are fucking up there
717 2012-02-03 20:14:16 <luke-jr> sipa: how so?
718 2012-02-03 20:14:18 <gmaxwell> Moron__: No, bitcoin uses an agreement protocol which works based on something that resembles distributed time stamping, but it's not quite to say it has one.
719 2012-02-03 20:14:22 <sipa> luke-jr: i gave you an example
720 2012-02-03 20:14:31 <sipa> at some point you need an extra version number
721 2012-02-03 20:14:44 <sipa> yes, 3 may be enough, or 4 may be enough, who knows
722 2012-02-03 20:14:47 <luke-jr> sipa: you gave me an example of how it's imperfect, not how it doesn't help :p
723 2012-02-03 20:14:55 <BlueMatt> gmaxwell: if you mean https://en.bitcoin.it/wiki/User:Gmaxwell/features I see no Moronic in cntrol-f
724 2012-02-03 20:15:07 <Eliel> gmaxwell: the idea of a decentralized space radar based on cheap hardware spread over the globe acting together tickles my curiosity, by the way :D
725 2012-02-03 20:15:37 <sipa> but i'd rather stick with not putting all optional features independently in the version number, and see it as linear progression
726 2012-02-03 20:15:49 <gmaxwell> BlueMatt: I was more polite "Features to avoid inefficient uses of the network "
727 2012-02-03 20:15:57 <gmaxwell> (notary service)
728 2012-02-03 20:16:05 <BlueMatt> gmaxwell: mmm, yep agreed
729 2012-02-03 20:16:17 <gmaxwell> Eliel: that part is pure handwaving, I don't think the SNR exists to make it realistic. but ... it was a fun thought.
730 2012-02-03 20:16:18 <Moron__> gmaxwell: how does this protocol manage to work if everyones in a different timezone?
731 2012-02-03 20:16:27 <BlueMatt> we just need to have like 5 full-time people working on all these side projects to make bitcoin more efficient ;)
732 2012-02-03 20:16:30 <gmaxwell> Moron__: people know what timezone they're in.
733 2012-02-03 20:16:47 <Moron__> but the client doesnt seem to ask what timezone theyre in?
734 2012-02-03 20:16:52 <gmaxwell> Eliel: the solar clock part is probably realistic, but lots of engineering would be required to flesh it out.
735 2012-02-03 20:16:52 <Moron__> is it autodetected somehow?
736 2012-02-03 20:17:04 <sipa> Moron__: internally it's just all UTC
737 2012-02-03 20:17:06 <gmaxwell> Moron__: your computer knows what timezone it's in, just like it knows the current time.
738 2012-02-03 20:17:06 <luke-jr> sipa: I see it as more of a drafting tool
739 2012-02-03 20:17:15 <Moron__> oh i c
740 2012-02-03 20:17:19 <midnightmagic> BlueMatt: Not easy or hard: just incorrectly IMO, and interfering with a speedy trial.
741 2012-02-03 20:17:42 <Moron__> if you persuaded enough people to change the time on their computer... could bitcoin be exploited/messed up somehow?
742 2012-02-03 20:17:53 <luke-jr> sipa: version==2 'drafts' P2SH; if it doesn't work out, we could use version==3 to 'draft' another incompatible P2SH without breaking the old one etc
743 2012-02-03 20:17:57 <Moron__> and what happens with daylights saving time?
744 2012-02-03 20:18:06 <midnightmagic> Moron__: Why did you choose that username anyway?
745 2012-02-03 20:18:12 <gmaxwell> Moron__: UTC doesn't change with daylights saving time.
746 2012-02-03 20:18:29 <sipa> luke-jr: so you'd need to make each version refer to its basepoint?
747 2012-02-03 20:18:37 <Moron__> midnightmagic: i donno, people suggested I should pick a username that fits my personality
748 2012-02-03 20:18:39 <Eliel> gmaxwell: you could also potentially use it as a space radar for tracking things floating about in space near earth & sun :) Although, I don't know how accurate that could be made :)
749 2012-02-03 20:18:49 <luke-jr> sipa: the 'basepoint' would be the minor versions
750 2012-02-03 20:18:50 <sipa> luke-jr: X.Y.Z, meaning if you don't know X.Y, use X.Z
751 2012-02-03 20:19:09 <midnightmagic> Moron__: You are asking questions. You're head and shoulders above a large number of other people who come in here.
752 2012-02-03 20:19:11 <sipa> unfortunately, that doesn't work, because what if you also don't know X.Z?
753 2012-02-03 20:19:26 <gmaxwell> Eliel: considering that the _real_ radar for that uses hundreds of thousands of watts.. well hm. the suns output is pretty strong too.
754 2012-02-03 20:19:29 <luke-jr> sipa: X.Y.Z would mean if you don't know X.Y.Z, try X.Y.1 next
755 2012-02-03 20:19:33 <Moron__> midnightmagic: uhh, thanks... i think...
756 2012-02-03 20:19:46 <gmaxwell> Eliel: http://www.afspc.af.mil/library/factsheets/factsheet.asp?id=3656
757 2012-02-03 20:19:58 <midnightmagic> Moron__: Your nickname doesn't suit you IMO.
758 2012-02-03 20:20:09 <cjd> Moron__: note that some people (/me included) pass over questions coming from people with "funny" nicks because it looks like a trolling attempt.
759 2012-02-03 20:20:09 <sipa> luke-jr: every time a new proposal is added, you increase the minor version number (just have 2 versions for now)
760 2012-02-03 20:20:19 <gmaxwell> Eliel: also, http://en.wikipedia.org/wiki/Air_Force_Space_Surveillance_System
761 2012-02-03 20:20:31 <sipa> luke-jr: each of them either builds upon the previous one, or skips it (because it wasn't used or whatever)
762 2012-02-03 20:20:46 <luke-jr> sipa: problem with just that is, there's no way to "back out" is there?
763 2012-02-03 20:20:51 <BlueMatt> midnightmagic: yea, the cops messed up by using something easy to intercept.  and thats my point, they shouldnt be doing that thats fucked up and scary to some extent.  wrt speedy trial, seriously? who cares? if the kid gets out on bail and they delay 2 months because they want to work on another case that is related I see absolutely nothing wrong with that
764 2012-02-03 20:20:54 <sipa> luke-jr: how so?
765 2012-02-03 20:20:58 <Moron__> midnightmagic: i would change it, but ive built up quite a reputation already
766 2012-02-03 20:21:07 <luke-jr> sipa: because X.Y implies X.(Y-1) for compat
767 2012-02-03 20:21:20 <luke-jr> since old clients will enforce X.(Y-1) rules on X.Y
768 2012-02-03 20:21:20 <sipa> did you read what i say?
769 2012-02-03 20:21:39 <luke-jr> maybe I misunderstood it
770 2012-02-03 20:21:47 <sipa> (sorry, i'm very tired)
771 2012-02-03 20:21:53 <luke-jr> I'll reread.
772 2012-02-03 20:22:00 <sipa> i mean: that is what you want
773 2012-02-03 20:22:08 <sipa> being able to add new versions
774 2012-02-03 20:22:23 <sipa> but the ability to skip previously-introduced versions while doing so
775 2012-02-03 20:22:37 <midnightmagic> BlueMatt: Ah, I see. Yes, it is fucked up, now that you have explained that the problem you have is with the cops not using secure channels. A speedy trial is a fundamental precept of justice. If prosecution waits too long, many judges will simply throw the case out.
776 2012-02-03 20:22:53 <midnightmagic> :)
777 2012-02-03 20:22:54 <luke-jr> midnightmagic: LOL
778 2012-02-03 20:23:07 <BlueMatt> midnightmagic: yea, speedy trial is very important, but 2 months is not anything to complain about
779 2012-02-03 20:23:33 <luke-jr> midnightmagic: that fails when you're forced to choose between a 15 minute trial, or "voluntarily" give up your right to speedy trial so you get more time to make your case
780 2012-02-03 20:23:38 <theymos> sipa: I read your BIP draft and it all looks good to me. Though that X/Y/Z notation is kind of hard to understand.
781 2012-02-03 20:24:06 <luke-jr> sipa: it sounds workable, but I suspect that leaves you with a lot of never-used versions, and potentially blockchain forks
782 2012-02-03 20:24:06 <midnightmagic> BlueMatt: Yes it is when the submission is in secret and without defence counsel present. That's a huge deal.
783 2012-02-03 20:24:32 <BlueMatt> midnightmagic: ofc it is, if you did it with defense council present then you ruin the whole reason for doing it in the first place
784 2012-02-03 20:24:32 <roconnor> who is under investigation?
785 2012-02-03 20:24:38 <luke-jr> sipa: ie, what if I set my version to 0.3.2, but it's valid under 1 rules and not 2 rules?
786 2012-02-03 20:24:51 <BlueMatt> roconnor: some teen hackers in england, doesnt matter who
787 2012-02-03 20:25:14 <BlueMatt> roconnor: http://www.youtube.com/watch?v=pl3spwzUZfQ&feature=youtu.be
788 2012-02-03 20:25:28 <roconnor> okay; I just wanted to know what to look up to follow what you guys are talking about
789 2012-02-03 20:25:31 <midnightmagic> BlueMatt: Of course it is a big deal to have the secret submission without defence present to object to his client's rights being trampled, and a judge who allows it?
790 2012-02-03 20:25:35 <midnightmagic> Is that what you mean?
791 2012-02-03 20:25:50 <BlueMatt> no, I mean its not a big deal at all
792 2012-02-03 20:25:54 <BlueMatt> its 2 fucking months
793 2012-02-03 20:26:14 <BlueMatt> and you also dont know how the judge responded, the guy thought he might only get 6 weeks
794 2012-02-03 20:26:18 <midnightmagic> BlueMatt: Why can't they submit with defence present? It's a secret delay, with judge collusion.
795 2012-02-03 20:26:44 <midnightmagic> I'm not sure that's even legal.
796 2012-02-03 20:26:54 <BlueMatt> if the defense were present, then the whole point (which is to delay to catch friends of the defendant) is ruined
797 2012-02-03 20:27:08 <sipa> luke-jr: the problem is, somehow you need to "encode" in your version number which previous one it builds upon (which should be used if a client doesn't support it)
798 2012-02-03 20:27:39 <sipa> and then you hit the limit of the system, because you have a problem if the client doesn't know that predecessor either
799 2012-02-03 20:27:53 <sipa> you can solve this, using a fourth number in there
800 2012-02-03 20:28:08 <sipa> but then you have two possibilities to go back to, but what if the client knows neither?
801 2012-02-03 20:28:14 <sipa> and so on
802 2012-02-03 20:28:15 <luke-jr> sipa: unless the previous is always 1?
803 2012-02-03 20:28:29 <sipa> yes, than you are limiting where you can build upon
804 2012-02-03 20:28:34 <luke-jr> and if the minor version isn't supported, then you have the current proposal for that
805 2012-02-03 20:28:43 <sipa> that's possible
806 2012-02-03 20:29:04 <sipa> but imho you're trying to fix a shortcoming in a too-limited way
807 2012-02-03 20:29:13 <sipa> and you can't fix it completely
808 2012-02-03 20:29:42 <sipa> so i think it's just easier to let all versions nicely build upon eachother
809 2012-02-03 20:29:58 <luke-jr> sipa: perhaps; I'm just thinking version==2 should be P2SH-only, without breaking the ability to step back and revise that decision in the future
810 2012-02-03 20:30:09 <sipa> i know that's what you want
811 2012-02-03 20:30:18 <sipa> and i agree it would be neat
812 2012-02-03 20:32:02 <sipa> but at some point going that way will hit its limits, and we'll ask... why o why didn't we add a fourth number there
813 2012-02-03 20:32:52 <midnightmagic> BlueMatt: It speaks to the objectivity of the judge. I hope defence raises a huge stink about that once they find out.
814 2012-02-03 20:34:01 <BlueMatt> how can you possibly claim that delaying a trial for 6-8 weeks to catch coconsiprators is unjust?
815 2012-02-03 20:34:12 <BlueMatt> that bullshit
816 2012-02-03 20:34:12 <luke-jr> sipa: sounds like "if we might need 4 car seats in the future, we should get a vehicle with only 2 for now even though we can see the immediate need for 3" ;)
817 2012-02-03 20:34:45 <luke-jr> BlueMatt: does he need to sit in jail for those 6-8 weeks? :p
818 2012-02-03 20:35:09 <BlueMatt> ok, if he does its unjust, but hes a minor there is no way in hell he was denied bail
819 2012-02-03 20:35:51 <luke-jr> minors aren't in the standard justice system in the first place O.o
820 2012-02-03 20:36:10 <BlueMatt> well Im assuming he was somewhere from 16-2X
821 2012-02-03 20:36:18 <BlueMatt> probably a minor doesnt really matter either way though
822 2012-02-03 20:36:30 <cjd> tl;dr criminal justice system dominated by organized crime, Anon pranksters owned them
823 2012-02-03 20:36:31 <BlueMatt> either way Im assuming bail was posted
824 2012-02-03 20:36:45 <BlueMatt> cjd: wow, you really didnt read did you?
825 2012-02-03 20:36:52 <cjd> nope :)
826 2012-02-03 20:38:29 <ThomasV_> BlueMatt: in BIP21, what is the expected behaviour of the client when a URI has a label?
827 2012-02-03 20:39:45 <BlueMatt> ThomasV_: if the clients has space for it, use that as the destination label.  For a user's security, I would suggest displaying both that label and the address being sent to
828 2012-02-03 20:39:53 <BlueMatt> if the client doesnt, meh just drop it
829 2012-02-03 20:41:03 <midnightmagic> BlueMatt: It sounds as though defence was not permitted to speak against the delay. It's not like the delay itself must be completely explained, and why. But defence deserves to know that a delay was requested by the prosecution, and to object to it. But perhaps this is the case. Perhaps it will be while defence is waiting out in the courtroom. If this is the case, I have no problem with it. But totally secret without a chance
830 2012-02-03 20:41:09 <midnightmagic> for defence to object.. that's b-s.
831 2012-02-03 20:41:15 <ThomasV_> BlueMatt: sure, but what is the client supposed to do if he encounters an address for which it already has a label? update it ? only if the user sends the coins?