1 2011-12-14 01:01:11 <jjjrmy> Anyone hungry? Buy a snack with Bitcoins: http://giftcoin.net/
  2 2011-12-14 01:23:50 <jjjrmy> Anyone interested in having their site or product Advertised on www.giftcoin.net
  3 2011-12-14 01:29:12 <xenland> jjjrmy: every time you post spam a bitcoin is lost to a scam.
  4 2011-12-14 01:29:24 <jjjrmy> xenland: a what?
  5 2011-12-14 01:29:38 <xenland> jjjrmy: Huh?
  6 2011-12-14 01:29:49 <jjjrmy> xenland: that makes no sense, but okay. It's not spam, I was asking.
  7 2011-12-14 01:30:24 <xenland> jjjrmy: How could you be spamming? You can't eat a chat room....
  8 2011-12-14 01:30:39 <xenland> jjjrmy: even tho i wouldn't eat spam its not delightful
  9 2011-12-14 01:30:43 <jjjrmy> xenland: I was referring people to my site if anyone was interested
 10 2011-12-14 01:31:16 <xenland> heh
 11 2011-12-14 01:31:18 <xenland> I kid
 12 2011-12-14 01:32:21 <xenland> But what i said is true. What all the miners are really doing is crawling the internet to see when people spam to add entropy. When people spam bitcoins are lost tho.... :/
 13 2011-12-14 01:32:44 <jjjrmy> xenland: what?
 14 2011-12-14 01:33:18 <xenland> seriously look at gaviins github page
 15 2011-12-14 01:35:31 <jjjrmy> xenland: no clue what that is.
 16 2011-12-14 01:36:06 <xenland> you know
 17 2011-12-14 01:42:16 <nanotube> xenland: you mean. :)
 18 2011-12-14 01:43:49 <xenland> I was jk'n.... :(
 19 2011-12-14 01:43:58 <xenland> hehe
 20 2011-12-14 02:27:01 <[Tycho]> Hello, people.
 21 2011-12-14 02:28:32 <xenland> ello tycho
 22 2011-12-14 02:36:52 <JFK911> Tycho
 23 2011-12-14 02:37:00 <JFK911> Hi!
 24 2011-12-14 02:59:22 <[Tycho]> Is there a tool to export transaction from a wallet ?
 25 2011-12-14 03:17:44 <midnightmagic> Hey, are the devs considering replacing SHA2 with new hash algos as developed over time by NIST, or is a change only contemplated in the event of a break in SHA2?
 26 2011-12-14 03:18:54 <theymos> Probably only if SHA-256 becomes weak.
 27 2011-12-14 03:19:22 <midnightmagic> That's what I thought. Someone is claiming that the devs plan on 10-yr cycles and to keep up with advancing SHA standards.
 28 2011-12-14 03:19:38 <luke-jr> 10 years wouldn't be unreasonable IMO
 29 2011-12-14 03:19:48 <luke-jr> especially at block chain forks
 30 2011-12-14 03:20:37 <theymos> Yeah, it might be nice to change things if the chain was forking anyway. SHA-3 should be given at least 5-10 years of scrutiny first, though.
 31 2011-12-14 03:20:53 <midnightmagic> why would the chain be forking anyway?
 32 2011-12-14 03:21:15 <midnightmagic> like to accommodate new txn types?
 33 2011-12-14 03:22:25 <theymos> Yeah, or some serious bug. Hopefully it won't happen too often, but it's bound to happen eventually.
 34 2011-12-14 03:22:31 <theymos> Satoshi says: "SHA-256 is very strong.  It's not like the incremental step from MD5 to SHA1.  It can last several decades unless there's some massive breakthrough attack."
 35 2011-12-14 03:23:25 <theymos> I think he also said elsewhere that the system would certainly need to be completely redone before this becomes an issue.
 36 2011-12-14 03:24:05 <midnightmagic> I wish I were around before Satoshi went quiet.
 37 2011-12-14 03:24:11 <midnightmagic> oh well.
 38 2011-12-14 03:25:42 <theymos> Oh, actually Satoshi was talking about timestamps. "unsigned int is good until 2106.  Surely the network will have to be totally revamped at least once by then."
 39 2011-12-14 03:26:29 <midnightmagic> oh.
 40 2011-12-14 03:27:01 <midnightmagic> That was the joke he also made right? If anyone finds any signed int, let me know before 2036  and so on?
 41 2011-12-14 03:27:12 <theymos> Yes.
 42 2011-12-14 03:27:18 <theymos> https://bitcointalk.org/index.php?topic=760.msg8413#msg8413
 43 2011-12-14 03:29:52 <luke-jr> midnightmagic: the chain MUST fork at some point to increase the allowed block size
 44 2011-12-14 03:30:05 <luke-jr> midnightmagic: the plan is to make as many improvements/fixes as possible at that point
 45 2011-12-14 03:30:19 <midnightmagic> yikes.
 46 2011-12-14 03:30:20 <theymos> Yeah, that'll probably be the next one. Should happen within a year or two.
 47 2011-12-14 03:30:58 <luke-jr> theymos: nah, we can delay it with fee increases :P
 48 2011-12-14 03:31:15 <luke-jr> also at some point there'll have to be a fork to make Bitcoin scale.
 49 2011-12-14 03:31:19 <luke-jr> right now, it won't.
 50 2011-12-14 03:32:22 <theymos> luke-jr: Fees may become non-competative, then. I think the limit should be removed from clients as soon as possible (miners can still enforce their own limit).
 51 2011-12-14 03:35:31 <luke-jr> theymos: what limit?
 52 2011-12-14 03:35:45 <theymos> Blocksize.
 53 2011-12-14 03:35:58 <gmaxwell> Thats nuts.
 54 2011-12-14 03:36:09 <gmaxwell> Bitcoin can already grow the chain at 144 mbytes/day.
 55 2011-12-14 03:36:34 <theymos> I just want to remove the limit from clients so that miners can determine for themselves how much data they want to handle.
 56 2011-12-14 03:37:19 <midnightmagic> i think that is reasonable. I am all about choice. :)
 57 2011-12-14 03:37:46 <gmaxwell> the answer is infinite, so long as the txns have fees. Unless you're quite confidence that the majority will reject a prior block, then you'd be a fool not to build on it even if you think its far too big.
 58 2011-12-14 03:38:45 <gmaxwell> moreover, it would mean that I could mine _one_ block and take out ~100% of the nodes, (e.g. by mining a 100gbyte block).
 59 2011-12-14 03:39:36 <gmaxwell> I think it's pretty clear that the current software could not keep up with the current maximum size if it was sustained block after block. It doesn't make much sense to permit blocks that would make the nodes fall over.
 60 2011-12-14 03:40:34 <luke-jr> I think theymos has a good point.
 61 2011-12-14 03:40:47 <luke-jr> so long as miners are enforcing the 1 MB limit, it would take a 50% attack to grow faster
 62 2011-12-14 03:41:28 <theymos> Everyone would reject a 100 GB block. The exact limit can be agreed-upon by everyone.
 63 2011-12-14 03:41:38 <luke-jr> there might need to be a limit of some sort.
 64 2011-12-14 03:41:40 <gmaxwell> But there is no way to communicate about the limit, so you'll easily spin your wheels.
 65 2011-12-14 03:42:00 <luke-jr> gmaxwell: limit block growth to 2x the previous largest block
 66 2011-12-14 03:42:23 <luke-jr> so the next block could only be 2 MB (for clients) until >1MB blocks get in the main chain
 67 2011-12-14 03:42:29 <gmaxwell> That would mean that one weird shorterm run for forever increase the limit.
 68 2011-12-14 03:42:32 <luke-jr> and then the next could only grow to 4 MB
 69 2011-12-14 03:42:45 <luke-jr> gmaxwell: only if miners built on it
 70 2011-12-14 03:43:33 <theymos> Miners need to keep up on these things. Increases would work like the ongoing OP_EVAL implementation: all miners must upgrade, but clients are OK. (The same "voting" could also be used.)
 71 2011-12-14 03:43:59 <gmaxwell> We talked about things like making the limit be 2x the median of the last N, in the past but there were things people said that made me think it was a bad idea.
 72 2011-12-14 03:44:22 <gmaxwell> but now I can't remember why.
 73 2011-12-14 03:44:37 <gmaxwell> sipa: was it you that cluesticked me over that?
 74 2011-12-14 03:44:56 <theymos> Yeah, I don't like automatic adjustment. The max block size should be determined by market forces.
 75 2011-12-14 03:45:14 <gmaxwell> automatic adjustment _is_ a market force.
 76 2011-12-14 03:46:08 <theymos> The system tries to determine what the supply should be based on previous demand. This isn't as good as having miners decide for themselves what the supply should be.
 77 2011-12-14 03:46:11 <gmaxwell> How does this avoid a race to the bottom on fees which would make sufficient hash power unsustainable?
 78 2011-12-14 03:46:49 <gmaxwell> theymos: they can create fake demand of course, and they can always impose their own lower limits.
 79 2011-12-14 03:46:53 <luke-jr> theymos: automatic adjustment could be used for maximums
 80 2011-12-14 03:46:57 <luke-jr> theymos: just like difficulty
 81 2011-12-14 03:47:16 <luke-jr> theymos: with my concept, the adjustment would only take place as miners willed it
 82 2011-12-14 03:47:28 <gmaxwell> But having an automatic limit applied to the protocol can quench some abuses, like DOSing nodes with jumbo blocks that would get orphaned.
 83 2011-12-14 03:47:59 <gmaxwell> And it also removes some of the agreement hazard.
 84 2011-12-14 03:48:46 <gmaxwell> If we are to actually have a distributed system, then people other than the few big miners have an interest in limiting the block size too.
 85 2011-12-14 03:50:54 <theymos> I'm not sure about it. I'll have to think about it more. I remember being very convinced against automatic adjustment before, but I can't remember my specific arguments.
 86 2011-12-14 03:51:45 <gmaxwell> I think part of my belief that it was a bad idea was because I was thinking of it as the maximum rather than a maximum maximum.
 87 2011-12-14 03:52:00 <gmaxwell> I think it's less objectionable as a maximum maximum.
 88 2011-12-14 03:53:40 <theymos> Some other protocol changes I'd like to see: fix the several broken script things; give users the ability to choose from among several different hash algorithms with signing, etc.; add more NOP script commands for future extensibility; calculate difficulty by looking at *all* involved blocks, not just the edges.
 89 2011-12-14 03:54:37 <midnightmagic> I don't understand what you mean by "just the edges"?
 90 2011-12-14 03:54:48 <gmaxwell> midnightmagic: we miss one of the gaps.
 91 2011-12-14 03:55:19 <midnightmagic> Just block 2016 right?
 92 2011-12-14 03:55:21 <gmaxwell> theymos: there is no clean way to fix that. But we can make miners refuse to extend chains that are borked wrt. that.
 93 2011-12-14 03:55:41 <gmaxwell> midnightmagic: it makes a weird inflation attack possible if you have a majority of hash power.
 94 2011-12-14 03:55:50 <midnightmagic> That's the timewarp bug that namecoin fixed but was a threatened attack.
 95 2011-12-14 03:56:06 <gmaxwell> Right.
 96 2011-12-14 03:56:12 <luke-jr> gmaxwell: can you?
 97 2011-12-14 03:56:12 <midnightmagic> Ah, yes I knew about that. I didn't know what he meant by the "edges" comment.
 98 2011-12-14 03:56:37 <theymos> gmaxwell: It seems best to take every block in the interval into account. Then you never have to worry about these tricks.
 99 2011-12-14 03:56:44 <gmaxwell> luke-jr: We can, except you hate it because it depends on being more anal about some timestamps. :)
100 2011-12-14 03:56:53 <luke-jr> gmaxwell: no.
101 2011-12-14 03:57:07 <luke-jr> gmaxwell: being more anal doesn't help.
102 2011-12-14 03:57:08 <gmaxwell> theymos: yes but there is no way to deploy that without creating a universal flag day.
103 2011-12-14 03:57:25 <gmaxwell> luke-jr: it does if the attacker doesn't have a majority hash power, it doesn't if they do.
104 2011-12-14 03:57:25 <theymos> I was talking about stuff to change after a fork.
105 2011-12-14 03:57:35 <luke-jr> gmaxwell: and Tycho would need to be in on it, and he has no reaosn to be
106 2011-12-14 03:57:52 <luke-jr> gmaxwell: if the attacker doesn't have a majority hash power, none of this matters at all
107 2011-12-14 03:58:45 <luke-jr> the existing time limits are sufficient
108 2011-12-14 03:58:54 <luke-jr> the problem only exists when those limits are ignored
109 2011-12-14 03:59:00 <gmaxwell> luke-jr: ::shrugs:: you can mine a weird block on that position and dork up the difficutly a little.
110 2011-12-14 03:59:16 <luke-jr> gmaxwell: not significantly, no.
111 2011-12-14 04:00:30 <gmaxwell> Fair enough.
112 2011-12-14 04:00:54 <gmaxwell> though I do agree that it would be good to fix, too bad there is no way to do it in a compatble way. :(
113 2011-12-14 04:04:46 <theymos> Different subject: Someone recently reported to me something they believed to be a critical bug in Bitcoin. This person is unreliable, their report was vague, and it doesn't seem to me that it's a problem, so I just told them to email bitcoin-security. Apparently they didn't, though, so I'll mention it here just in case:
114 2011-12-14 04:08:03 <aleod> I'm not familiar with the code, but maybe bitcoin should use CryptGenRandom or the OpenSSL random seed function instead?
115 2011-12-14 04:08:26 <cjdelisle> if that's the only random seed, it sounds wrong to me.. it doesn't sound like as much of a disaster as he suggests but IMO CryptGenRandom should be used.
116 2011-12-14 04:08:52 <gmaxwell> IIRC it used multiple sources on windows, including its own timing loop.
117 2011-12-14 04:09:02 <cjdelisle> But very often these things will get seeds from a bunch of places, libevent does the same, so getting random material from something like that is not wrong.
118 2011-12-14 04:09:44 <gmaxwell> oh...
119 2011-12-14 04:09:51 <gmaxwell> wumpus: around?
120 2011-12-14 04:09:54 <theymos> That plus the internal counter is the only source Bitcoin uses. It replaces /dev/urandom.
121 2011-12-14 04:10:24 <gmaxwell> fuck fuck fuck
122 2011-12-14 04:10:35 <gmaxwell> wx bitcoin removed the timing loops.
123 2011-12-14 04:10:38 <gmaxwell> er qt
124 2011-12-14 04:10:49 <copumpkin> wat?
125 2011-12-14 04:11:20 <luke-jr> if it were a problem, wouldn't we have seen address collisions by now?
126 2011-12-14 04:11:24 <gmaxwell> I'm pretty sure there used to be more rand_adds in the UI.
127 2011-12-14 04:11:39 <theymos> Oh, I was looking at the old code... Sorry for not reporting this privately. It looked very unreliable to me.
128 2011-12-14 04:11:41 <gmaxwell> luke-jr: nah, because the registry shit is probably machine unique but it can be stolen.
129 2011-12-14 04:12:08 <gmaxwell> well, I'm going off memory _I know_ there was some random sources in the UI... which are apparently not there anymore.
130 2011-12-14 04:12:15 <luke-jr> why aren't we using generic OpenSSL seeds?
131 2011-12-14 04:12:31 <cjdelisle> roll your own security = :(
132 2011-12-14 04:12:33 <gmaxwell> We are, but iirc it doesn't have a system entropy source on windows.
133 2011-12-14 04:12:42 <gmaxwell> if it does then there is no issue.
134 2011-12-14 04:13:01 <theymos> gmaxwell: Right. It uses /dev/urandom on Linux, but on Windows it relies on the program to provide seed.
135 2011-12-14 04:13:54 <luke-jr> /dev/urandom is no good too
136 2011-12-14 04:14:07 <gmaxwell> it's fine.
137 2011-12-14 04:14:39 <aleod> /dev/urandom might not work great in virtual machines iirc. I could be wrong
138 2011-12-14 04:15:05 <luke-jr> aleod: or any servers, really
139 2011-12-14 04:15:22 <gmaxwell> so.. okay, qt killed a significant source of randomness, but there appear to be other ones.
140 2011-12-14 04:16:00 <gmaxwell> luke-jr: it's a cryptographic prng seeded with at worst 100 bits per second of real randomness.
141 2011-12-14 04:16:11 <gmaxwell> luke-jr: no the timer feeds it.
142 2011-12-14 04:16:21 <luke-jr> gmaxwell: many systems don't *have* 100 bits per second of real entropy
143 2011-12-14 04:16:25 <luke-jr> &
144 2011-12-14 04:16:29 <gmaxwell> (though it's pretty much timer + keyboard + mouse)
145 2011-12-14 04:16:29 <luke-jr> how could a timer?
146 2011-12-14 04:16:40 <luke-jr> timers are predictable
147 2011-12-14 04:16:56 <cjdelisle> many systems don't *have* 100 bits per second of real entropy <-- blah blah blah angels on a pin
148 2011-12-14 04:17:00 <gmaxwell> luke-jr: it takes the low order bit of the number of cpucycles run between timer events, it's a reasonable random source (e.g. would pass all the diehard tests)
149 2011-12-14 04:17:23 <luke-jr> & 1 bit isn't much
150 2011-12-14 04:18:35 <luke-jr> my desktop seems to get entropy about once every 3-8 seconds
151 2011-12-14 04:19:00 <luke-jr> Eligius Su seems to get it much more often
152 2011-12-14 04:19:04 <copumpkin> just read from the microphone ^_^
153 2011-12-14 04:19:06 <gmaxwell> in any case this is a stupid tangent, we need to determine if that report is a real issue.
154 2011-12-14 04:19:18 <luke-jr> copumpkin: I was going to suggest wifi garbage
155 2011-12-14 04:19:53 <luke-jr> gmaxwell: we should make the user draw a picture :D
156 2011-12-14 04:20:03 <cjdelisle> IMO I'd pull in libevent just to have access to a multi-seed random generator which has had real review (used on tor).
157 2011-12-14 04:20:10 <gmaxwell> Stop.
158 2011-12-14 04:20:15 <gmaxwell> Potential security hole.
159 2011-12-14 04:20:18 <luke-jr> cjdelisle: libevent is crap
160 2011-12-14 04:20:20 <copumpkin> or you could really freak people out by turning on their webcams, telling the users to turn all the lights out, and amplifying the resulting image a lot
161 2011-12-14 04:20:22 <gmaxwell> What we shoule do is blah blah.
162 2011-12-14 04:20:25 <copumpkin> ;)
163 2011-12-14 04:20:27 <cjdelisle> &
164 2011-12-14 04:20:31 <gmaxwell> Can someone figure out wtf this is:
165 2011-12-14 04:20:33 <luke-jr> cjdelisle: libevent is the cause of the one major bug in pushpool
166 2011-12-14 04:20:44 <gmaxwell> I don't see that symbol anywhere in the bitcoin source.
167 2011-12-14 04:21:01 <luke-jr> "The RAND_screen() function is available for the convenience of Windows programmers. It adds the current contents of the screen to the PRNG. For applications that can catch Windows events, seeding the PRNG by calling RAND_event() is a significantly better source of randomness. It should be noted that both methods cannot be used on servers that run without user interaction."
168 2011-12-14 04:21:07 <aleod> it's in openssl
169 2011-12-14 04:21:16 <gmaxwell> whew.
170 2011-12-14 04:21:18 <aleod> nm, misread
171 2011-12-14 04:21:19 <gmaxwell> okay. world not over.
172 2011-12-14 04:21:58 <gmaxwell> gavinandresen: Bitcoin-qt managed to remove some of the random pool sources in bitcoin, theymos got a report of someone freaking out saying there was no randomness.
173 2011-12-14 04:22:02 <gavinandresen> I was about to pop in and mention that... they did post to the bitcoin-security list, but I didn't send it through to the bigger list because it was a satoshi-bitcoin-specific issue
174 2011-12-14 04:22:18 <gavinandresen> (I forwarded to the other core satoshi client developers instead)
175 2011-12-14 04:22:19 <luke-jr> "RAND_event() collects the entropy from Windows events such as mouse movements and other user interaction. It should be called with the iMsg, wParam and lParam arguments of all messages sent to the window procedure. It will estimate the entropy contained in the event message (if any), and add it to the PRNG. The program can then process the messages as usual."
176 2011-12-14 04:22:29 <luke-jr> ^ should add RAND_event
177 2011-12-14 04:23:35 <gavinandresen> RAND_screen() is called at startup, then HKEY_PERFORMANCE_DATA is periodically added (on Windows)
178 2011-12-14 04:24:03 <gavinandresen> If somebody wants to measure how much entropy is actually gathered, that'd be spiffy....
179 2011-12-14 04:26:25 <luke-jr> oh, HKEY_PERFORMANCE_DATA changes?
180 2011-12-14 04:26:44 <gavinandresen> Yes, I believe it is a very-high-frequency counter
181 2011-12-14 04:26:58 <doublec> luke-jr: what is the libevent issue that causes a bug in pushpool?
182 2011-12-14 04:27:20 <gavinandresen> (but it is late and I meant to be asleep a while ago so I'm probably misremembering what I read yesterday)
183 2011-12-14 04:27:25 <luke-jr> doublec: it doesn't clean up sockets closed by the http client
184 2011-12-14 04:27:31 <luke-jr> doublec: when libevent functions as http server
185 2011-12-14 04:27:46 <gmaxwell> bitcoin also adds the TSC to the pool frequently.
186 2011-12-14 04:28:08 <gmaxwell> Okay, I'm not worried about this being a pratical problem anymore. It should probably be improved, it doesn't appear urgent.
187 2011-12-14 04:28:30 <doublec> luke-jr: I thought pushpool used libcurl, not libevent's http client stuff
188 2011-12-14 04:28:30 <gavinandresen> send me email if y'all decide there is an issue with insufficient entropy.
189 2011-12-14 04:28:35 <luke-jr> doublec: so every longpoll, pushpool wastes time generating work for N long-since-disconnected clients, and only then do the connections close properly
190 2011-12-14 04:28:42 <gavinandresen> ... or better, submit a patch...
191 2011-12-14 04:28:44 <luke-jr> doublec: libcurl is the client-side, not server-side
192 2011-12-14 04:28:47 <gmaxwell> For a minute I was freaking out because all the UI randomness sources I remember vanished, and I was thinking the registery key was ~static.
193 2011-12-14 04:28:50 <luke-jr> [00:27:31] <luke-jr> doublec: when libevent functions as http server
194 2011-12-14 04:28:53 <doublec> ah right, I see what you're saying
195 2011-12-14 04:29:11 <luke-jr> doublec: also, those sockets pile up in the kernel, and eventually overflow it
196 2011-12-14 04:29:37 <theymos> Why not use the Windows Crypto API to get the randomness? I looked for other programs that used HKEY_PERFORMANCE_DATA, and I couldn't find any.
197 2011-12-14 04:33:40 <cjdelisle> https://github.com/libevent/libevent/blob/master/arc4random.c#L142 <-- there's the libevent/tor method
198 2011-12-14 04:34:12 <cjdelisle> looks like they have a number of ways in linux but only CryptGenRandom() in winx
199 2011-12-14 04:36:09 <gmaxwell> https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/crypto.c#l2392 < the code in Tor proper
200 2011-12-14 04:37:58 <cjdelisle> that looks nicer even than libevent's
201 2011-12-14 04:39:20 <gmaxwell> I'd suggest just taking the code from tor and adding it in addtion to what we have, it's compatibly licensed and has no doubt seen a lot of auditing.
202 2011-12-14 04:39:54 <sipa> gmaxwell: not sure about the block size discussion
203 2011-12-14 04:40:55 <gmaxwell> It also might be useful to add back in UI randomness hooks.
204 2011-12-14 04:42:18 <sipa> what pops up right now: if there is some rule that uses past statistics to determine what is acceptable, a miner may want to add dummy txs until the tx rate is as high as he can sustain, driving less capable miners out of the market
205 2011-12-14 04:44:30 <luke-jr> sipa: that isn't a problem for my proposal
206 2011-12-14 04:44:38 <luke-jr> (it doesn't care how many tx there are)
207 2011-12-14 04:47:48 <sipa> sure, there are other solutions, like letting miners decide
208 2011-12-14 05:08:42 <gmaxwell> I think it needs to have a property that a low hash power trouble maker can't cause regular nodes to start accepting blocks that will DOS the heck out of them.
209 2011-12-14 05:09:43 <gmaxwell> It should also not gratuitously assist a race to the bottom that destroys bitcoin's decenteraliztion by leaving it so only a few very large mining nodes can afford to validate anything.
210 2011-12-14 05:12:38 <luke-jr> gmaxwell: & it does?
211 2011-12-14 05:14:33 <gmaxwell> What does?
212 2011-12-14 05:14:51 <gmaxwell> That was aspirational, not a description of any proposal.
213 2011-12-14 05:15:08 <CIA-100> bitcoin: various signmessage_gui * r3765db..a22535 bitcoind-personal/ (28 files in 6 dirs): (12 commits) http://tinyurl.com/3py2g44
214 2011-12-14 05:15:09 <CIA-100> bitcoin: Luke Dashjr minfee_modes * rdbbf1d4a48c8 bitcoind-personal/src/ (main.cpp main.h wallet.cpp): GetMinFee takes a mode parameter (GMF_{BLOCK,RELAY,SEND}) instead of fForRelay http://tinyurl.com/cbcjmgk
215 2011-12-14 05:15:11 <CIA-100> bitcoin: Luke Dashjr minfee_modes * ra880b29cab0f bitcoind-personal/src/main.cpp: Bugfix: fForRelay should be false when deciding required fee to include in blocks http://tinyurl.com/brpd72r
216 2011-12-14 05:22:18 <wumpus> huh what entropy collection did bitcoin-qt remove? are you sure about that, you were gathering entropy in the UI instead of the core?!? anyway, windows bitcoind would already have had this problem in this case
217 2011-12-14 05:22:57 <gmaxwell> wumpus: yea.. :-/
218 2011-12-14 05:23:08 <gmaxwell> see ui.cpp: void CMainFrame::OnMouseEvents(wxMouseEvent& event)
219 2011-12-14 05:23:16 <wumpus> I really disapprove of doing that
220 2011-12-14 05:23:53 <wumpus> as that makes the UI different from the daemon
221 2011-12-14 05:23:59 <wumpus> you can never rely on the user moving his mouse
222 2011-12-14 05:24:07 <gmaxwell> It's .. randomness. They're already different in that regard. :)
223 2011-12-14 05:24:21 <gmaxwell> In any case, it wasn't relying on it. It was just an additional source.
224 2011-12-14 05:29:12 <luke-jr> wumpus: user interaction is one major source of entropy
225 2011-12-14 05:29:16 <wumpus> also looks like  a great way to make an UI slow, intercept all user events and do some computation on them
226 2011-12-14 05:30:59 <EvanR> wumpus: maybe if youre running on a c64
227 2011-12-14 05:31:10 <wumpus> something like (u)random already integrates all kinds of possible randomness sources
228 2011-12-14 05:31:46 <EvanR> the OS and X and etc etc are all huge giant 'intercept all user events and do some computation on them'
229 2011-12-14 05:31:58 <wumpus> there's no need to try to hand-roll everything... and if we want to split the UI and daemon into separate processes eventually anyway
230 2011-12-14 05:32:02 <EvanR> the key here being that events happen vastly more seldom than cpu cycles
231 2011-12-14 05:32:09 <wumpus> yes I know that
232 2011-12-14 05:32:48 <luke-jr> wumpus: Windows has no urandom
233 2011-12-14 05:33:16 <EvanR> windows does have a crypto RNG
234 2011-12-14 05:33:18 <wumpus> it has a crypto API right? how do non-UI programs like openssh do it on windows?
235 2011-12-14 05:33:27 <luke-jr> wumpus: Windows doesn't have OpenSSH :p
236 2011-12-14 05:33:33 <wumpus> yes there is an openssh for windows
237 2011-12-14 05:33:39 <luke-jr> wumpus: GnuPG tells the user to move their mouse around for a bit
238 2011-12-14 05:34:10 <wumpus> fricking lame
239 2011-12-14 05:34:11 <EvanR> hardware sourced entropy isnt necessarily the only way
240 2011-12-14 05:34:29 <EvanR> some OS just have a secure pure rng
241 2011-12-14 05:34:44 <EvanR> dunno what windows does
242 2011-12-14 05:35:01 <sipa> gnupg consumes ridiculous amounts of entropy
243 2011-12-14 05:35:09 <CIA-100> bitcoin: Luke Dashjr next * r84417e..f654ee bitcoind-personal/ (41 files in 6 dirs): (5 commits) http://tinyurl.com/7fsst7u
244 2011-12-14 05:35:58 <EvanR> with a sufficiently large state and combination of rng algorithms, your only security risk is the attacked finding out the state
245 2011-12-14 05:36:10 <EvanR> no 'entropy' needed
246 2011-12-14 05:36:25 <gmaxwell> wumpus: I recommended copying the code from tor earlier.
247 2011-12-14 05:36:25 <wumpus> but even if that it probably only intercepts the user events and puts them into the entropy, not during the entire run of the program
248 2011-12-14 05:37:08 <gmaxwell> wumpus: though I don't think there was any evidence that the WX hooks hurt performance.
249 2011-12-14 05:38:05 <wumpus> I'm not sure either, I also don't feel like measuring it, but I don't really want to intercept user events when not needed for UI purposes
250 2011-12-14 05:38:43 <gmaxwell> Thats fine, I don't think you need to. We should probably add the tor code and call it done.
251 2011-12-14 05:39:03 <EvanR> accumulating mouse events doesnt have any effect on performance
252 2011-12-14 05:40:02 <EvanR> wumpus: what is your program
253 2011-12-14 05:40:09 <gmaxwell> Bitcoin.
254 2011-12-14 05:40:18 <EvanR> the main client
255 2011-12-14 05:40:26 <gmaxwell> Yes.
256 2011-12-14 05:40:28 <wumpus> using key events would also be cool, so even your passphrase will end up in the random seed :-)
257 2011-12-14 05:40:51 <wumpus> EvanR: yes
258 2011-12-14 05:40:52 <EvanR> c++ nightmare ;)
259 2011-12-14 05:40:58 <EvanR> just reboot
260 2011-12-14 05:41:22 <gmaxwell> wumpus: meh, then I'd want to go audit the random pool stuff and make sure it doesn't keep cleartext inputs around.
261 2011-12-14 05:41:42 <wumpus> yeah exactly
262 2011-12-14 05:42:26 <wumpus> maybe carrieriq could have used that excuse
263 2011-12-14 05:42:32 <wumpus> 'we only use it to seed our RNG!'
264 2011-12-14 05:45:38 <wumpus> maybe use the clipboard too for extra effect and the user's microphone
265 2011-12-14 05:46:02 <EvanR> another theoretical thing, RNGs arent designed to be continually reseeded if you want the same statistical guarantees
266 2011-12-14 05:46:16 <EvanR> like, restarting the sequence
267 2011-12-14 05:46:46 <EvanR> maybe you have a special rng, but normally restarting a sequence after like 10 outputs doesnt mean you have sane statistics ;)
268 2011-12-14 05:47:15 <gmaxwell> EvanR: reseeding in this context means a very different thing.
269 2011-12-14 05:47:20 <EvanR> ok
270 2011-12-14 05:48:18 <gmaxwell> This is a large pool cryptographic rng. When we add seeds we're stirring into the existing pool, it doesn't throw out the old state.
271 2011-12-14 05:49:28 <gmaxwell> You could add 128 bits of real randomness once then add gigabytes of zeros ... while pulling out gigabytes of random data... and still not be able to predict it (unless you can make a serious compromise in the underlying crypto functions it uses).
272 2011-12-14 05:50:06 <EvanR> well it has cryptographic in front of it, so it must be water tight ;)
273 2011-12-14 05:50:30 <cjdelisle> for certain values of "water", it is.
274 2011-12-14 05:52:22 <luke-jr> There
275 2011-12-14 05:52:30 <luke-jr> 'next' and 'next-test' are updated
276 2011-12-14 05:52:54 <EvanR> all this crypto tech and 100% guarantees of everything, and yet all the enemy has to do is scp your wallet while youre out of the room ;)
277 2011-12-14 05:53:16 <gmaxwell> my wallet is encrypted when I'm out of the room.
278 2011-12-14 05:53:47 <EvanR> i havent used those new features
279 2011-12-14 05:54:05 <EvanR> is it user friendly
280 2011-12-14 05:54:22 <EvanR> can i lock myself out of my wallet permanently by forgetting the password
281 2011-12-14 05:55:26 <gmaxwell> yep.
282 2011-12-14 05:56:05 <EvanR> dayum ;)
283 2011-12-14 05:56:30 <luke-jr> I recently learned the hard way, that it's also impossible to decrypt a wallet :/
284 2011-12-14 05:56:37 <luke-jr> so it's a one-way street
285 2011-12-14 05:56:48 <EvanR> life is a one way street
286 2011-12-14 05:56:51 <EvanR> its a metaphor
287 2011-12-14 05:56:54 <EvanR> lol
288 2011-12-14 05:57:19 <EvanR> how much did you lose luke-jr
289 2011-12-14 05:57:41 <luke-jr> EvanR: 6300 BTC if I forget the passphrase
290 2011-12-14 05:57:51 <luke-jr> Testnet
291 2011-12-14 05:58:11 <luke-jr> in case I forget, please remind me that it's "a"
292 2011-12-14 05:58:18 <EvanR> oh ok
293 2011-12-14 05:59:21 <EvanR> so how are alzheimers people supposed to manage their crypto
294 2011-12-14 05:59:41 <cjdelisle> write your password on your monitor
295 2011-12-14 05:59:46 <EvanR> lol
296 2011-12-14 06:00:00 <cjdelisle> also make sure to write that it's your bitcoin password so you don't try to use it for email
297 2011-12-14 06:00:20 <CIA-100> bitcoin: various next-test * raeaec8..e9bcdc bitcoind-personal/ (30 files in 5 dirs): (9 commits) http://tinyurl.com/7vr93zh
298 2011-12-14 06:05:17 <luke-jr> [01:59:11] <luke-jr> selling special limited-edition *testnet* BTC at 25 USD a pop
299 2011-12-14 06:18:07 <wumpus> $25 for testnet coins sounds a tad expensive
300 2011-12-14 06:19:45 <gmaxwell> special edition!
301 2011-12-14 06:20:59 <cjdelisle> gold plated with glenn beck's face on each one
302 2011-12-14 06:21:12 <wumpus> oooh super special confidential military-grade testing coins?
303 2011-12-14 06:21:26 <luke-jr> XD
304 2011-12-14 06:21:41 <gmaxwell> For only 1 BTC I will sell you a wallet with 50 _virgin_ unspent TNBTC.
305 2011-12-14 06:22:34 <gmaxwell> Thats a 50 for 1 deal!!! plus you rid your self of dirty nasty recycled bitcoins and get fresh TNBTC.
306 2011-12-14 06:22:47 <luke-jr> For only 55 BTC I will sell you 50 _virgin_ unspent BTC to any address of your choice.
307 2011-12-14 06:22:49 <luke-jr> <.<
308 2011-12-14 06:22:54 <copumpkin> oh wow
309 2011-12-14 06:23:04 <copumpkin> immaculately conceived BTC
310 2011-12-14 06:23:27 <cjdelisle> for a low price of 75BTC, I will send you 70 _virgins_
311 2011-12-14 06:23:36 <cjdelisle> <small>when you're dead</small>
312 2011-12-14 06:24:46 <wumpus> maybe we should move this to -otc :P
313 2011-12-14 06:24:52 <gmaxwell> ohh alerts work on testnet
314 2011-12-14 06:25:01 <gmaxwell> "errors" : "CAlert system test:         ver.0.5.1 available"
315 2011-12-14 06:25:22 <wumpus> yes bluematt fixed those yesterday in a 10-minute ninja patch :D
316 2011-12-14 06:25:47 <cjdelisle> reminds me of net-send spam
317 2011-12-14 06:26:23 <wumpus> that's so 90's
318 2011-12-14 06:26:27 <gmaxwell> hm? my testnet node is on week-old-git.
319 2011-12-14 06:26:37 <wumpus> these are cryptographically enchanced!
320 2011-12-14 06:26:42 <cjdelisle> heh
321 2011-12-14 06:27:12 <wumpus> gmaxwell: I thought he meant in the UI
322 2011-12-14 06:27:17 <gmaxwell> I have a friend that I mostly talk with via ytalk.
323 2011-12-14 06:27:24 <gmaxwell> ha. ui schmooii.
324 2011-12-14 06:28:29 <cjdelisle> random numbers for sale, generated with military grade algorithms on an offline "air gapped" computer using state of the art battery power supply system
325 2011-12-14 06:30:40 <wumpus> do you promise to sell it only once so I can use it as a one time pad?
326 2011-12-14 06:31:38 <cjdelisle> once your random numbers are generated, they are overwritten with zeros and a special bit is set to indicate that those zeros are not actually randomly generated zeros
327 2011-12-14 06:33:17 <luke-jr> gmaxwell: hmm, does testnet use a different key?
328 2011-12-14 06:33:33 <gmaxwell> I thought the 'key' was the privkey of the genesis block.
329 2011-12-14 06:33:43 <cjdelisle> With the Random Source Patch" for Bitcoin, you can insert your new Cryptographically Secure Random Numbers into your bitcoin and be generating stronger coins right away!
330 2011-12-14 06:33:43 <luke-jr> hmm
331 2011-12-14 06:33:52 <wumpus> hehe
332 2011-12-14 06:33:56 <gmaxwell> or at least thats what I believed from reading the code.
333 2011-12-14 06:34:06 <gmaxwell> cjdelisle: true randomness from Random.org"
334 2011-12-14 06:34:10 <luke-jr> I wonder if you can rebroadcast that testnet alert on mainnet ;)
335 2011-12-14 06:34:44 <wumpus> I'm so happy with my new, stronger, weaponized bitcoin wallet thanks to cjdelisle
336 2011-12-14 06:35:27 <luke-jr> just don't export it!
337 2011-12-14 06:35:38 <luke-jr> except maybe to Iran
338 2011-12-14 06:35:41 <cjdelisle> With these, more random numbers, you will be generating stronger, more secure, more *solid* coins, right away.
339 2011-12-14 06:35:51 <luke-jr> I feel bad for Iran. Everyone's threatening them.
340 2011-12-14 06:35:58 <gmaxwell> ... luke-jr you're naughty.
341 2011-12-14 06:36:01 <luke-jr> &
342 2011-12-14 06:36:07 <cjdelisle> &
343 2011-12-14 06:36:15 <gmaxwell> the genesis block on testnet appears to have the same pubkey.
344 2011-12-14 06:36:28 <gmaxwell> If I'm not misremembering how that works, then yes you could.
345 2011-12-14 06:36:30 <luke-jr> gmaxwell: I dare you.
346 2011-12-14 06:37:08 <gmaxwell> I was arguing against sending an alert!
347 2011-12-14 06:37:44 <luke-jr> well, if this works, you can argue for no confidence in Gavin having the key <.<
348 2011-12-14 06:37:50 <cjdelisle> are alerts replayable?
349 2011-12-14 06:38:00 <cjdelisle> I mean it makes sense that they should not be
350 2011-12-14 06:38:20 <luke-jr> cjdelisle: define replayable
351 2011-12-14 06:38:29 <cjdelisle> can you send it on testnet again?
352 2011-12-14 06:38:36 <wumpus> there are persistent
353 2011-12-14 06:38:39 <gmaxwell> cjdelisle: nodes remember them and don't replay them. .. you might be able to modify them in a way that changes the hash but not the signature and break that.
354 2011-12-14 06:38:40 <wumpus> so they appear until they are canclled
355 2011-12-14 06:38:51 <wumpus> or you upgrade to a newer version they don't appear to
356 2011-12-14 06:39:00 <cjdelisle> I see
357 2011-12-14 06:39:46 <wumpus> changes the hash but not the signature? so the hash is not used for the signature?
358 2011-12-14 06:40:18 <cjdelisle> lemme guess, it hashes over the signature
359 2011-12-14 06:40:19 <gmaxwell> wumpus: I don't recall the format, but bitcoin txn are malleable like this, as the signature doesn't cover everything.
360 2011-12-14 06:40:59 <gmaxwell> if so, you might be able to 'replay' an alert and run people out of memory.
361 2011-12-14 06:41:05 <cjdelisle> in which case you use negative numbers and openssl validates it anyway and the hash changes and then haha
362 2011-12-14 06:41:07 <wumpus> right, but you'd assume the signature to cover the message text, otherwise it's quite pointless
363 2011-12-14 06:41:28 <gmaxwell> sure.
364 2011-12-14 06:42:17 <wumpus> ah you want to accumulate similar messages to perform a DDoS
365 2011-12-14 06:42:31 <luke-jr> my point was just that we might be able to broadcast 0.5.1 announcement on mainnet before gavin is done with it :P
366 2011-12-14 06:42:41 <gmaxwell> yes, I know.
367 2011-12-14 06:42:46 <wumpus> I'm not sure it will store the same sequence id multiple times, but if it does, it sounds dangerous
368 2011-12-14 06:42:58 <gmaxwell> Is gavin actually going to do that? we should totally beat him to it. ;)
369 2011-12-14 06:43:15 <gmaxwell> but not by days, but by minutes.
370 2011-12-14 06:43:37 <wumpus> heh
371 2011-12-14 06:43:39 <luke-jr> gmaxwell: well, if we do it now, he'll have to do the real release in minutes to avoid the flood
372 2011-12-14 06:43:44 <luke-jr> <.<
373 2011-12-14 06:43:58 <luke-jr> assuming someone has a way to wake him up
374 2011-12-14 06:44:09 <gmaxwell> which is why we should not.
375 2011-12-14 06:44:18 <lianj> haha aw :(
376 2011-12-14 06:44:28 <gmaxwell> more funny if he's sitting there. "wtf="
377 2011-12-14 06:44:35 <luke-jr> true
378 2011-12-14 06:44:37 <gmaxwell> "but I didn't press enter yet!"
379 2011-12-14 06:44:50 <luke-jr> ok, let's plan on doing it when he's actively on IRC
380 2011-12-14 06:44:59 <luke-jr> nobody ruin the surprise, k?
381 2011-12-14 06:45:18 <gmaxwell> He'll read the backscroll.
382 2011-12-14 06:45:18 <wumpus> and hope he doesn't read backlogs :p
383 2011-12-14 06:45:25 <luke-jr> he's not online&
384 2011-12-14 06:47:52 <gmaxwell> oh, it's not the same key as the genesis block. .. but its still the same key in testnet.
385 2011-12-14 06:48:04 <luke-jr> >_<
386 2011-12-14 06:50:14 <gmaxwell> looks like the signature covers the whole thing. which is good.
387 2011-12-14 06:50:44 <cjdelisle> does the hash cover the sig?
388 2011-12-14 06:51:09 <gmaxwell> oh.
389 2011-12-14 06:51:14 <gmaxwell> I think so.
390 2011-12-14 06:51:23 <cjdelisle> heh
391 2011-12-14 06:51:36 <cjdelisle> I wonder just what you can make openssl validate
392 2011-12-14 06:51:43 <cjdelisle> leading zeros anyone?
393 2011-12-14 06:51:44 <luke-jr> :D
394 2011-12-14 06:51:44 <[Tycho]> Hmm, I wonder why bitcoin do not delete new transaction if CommitTransaction fails...
395 2011-12-14 06:51:52 <wumpus> still I don't understand why the alerts are in a map by hash, and not by nID, which is according to gavenandresen an unique id
396 2011-12-14 06:53:03 <gmaxwell> cause thats how everything else works in bitcoin, which isn't a bad reason.
397 2011-12-14 06:54:01 <gmaxwell> yea, so I think there is a mild dos vulnerability here.. where you can mutate the signature and give people more copies of an alert. But how many different values would openssl accept?
398 2011-12-14 06:54:45 <gmaxwell> (the same issue would exist for transactions but they spend inputs and the regular DOS rules come into effect, not so for alerts)
399 2011-12-14 06:54:55 <wumpus> well no it's not a bad reason per-ce, but it interacts weirdly with the signature
400 2011-12-14 06:55:32 <gmaxwell> if the system had forced the @#$@# signatures into a canonical form it would not be an issue.
401 2011-12-14 06:55:35 <cjdelisle> there are definitely at least 2 possible valid sig representations
402 2011-12-14 06:56:30 <cjdelisle> messing with content before verifying it is not very safe.. I would not hash the sig into the hash, if it's not valid then it's not going in the hashtree anyway
403 2011-12-14 06:56:54 <cjdelisle> err hashmap or whatever..
404 2011-12-14 06:57:00 <wumpus> agreed
405 2011-12-14 06:57:13 <wumpus> it should hash the contents, the same contents verified by the signature
406 2011-12-14 06:57:26 <cjdelisle> copumpkin: how many valid representations are there of a signature?
407 2011-12-14 06:57:27 <wumpus> that'd be pretty much fool-proof
408 2011-12-14 06:57:36 <gmaxwell> means I can flood you with signature validation operations (much slower than hashes), I know we validate in that order now though we could change it.
409 2011-12-14 06:57:37 <cjdelisle> /nod
410 2011-12-14 06:57:58 <cjdelisle> you could still change it
411 2011-12-14 06:58:12 <wumpus> you could simply drop the requests if you receive too many
412 2011-12-14 06:58:17 <gmaxwell> no, then I give you a bad one and you never accept the good alert?
413 2011-12-14 06:58:19 <cjdelisle> you just don't insert into the table until the sig proves valid
414 2011-12-14 06:58:32 <copumpkin> me?
415 2011-12-14 06:58:36 <gmaxwell> right then that doesn't help you mitgate a validation dos.
416 2011-12-14 06:58:53 <cjdelisle> copumpkin: you know something about the openssl sig representation right?
417 2011-12-14 06:59:10 <copumpkin> hmm
418 2011-12-14 06:59:42 <gmaxwell> E.g. if you check the hash firt, I give you a flood of bad signatures and you burn cpu. If you check the signature first, likewise. If the hash covers the sig, then you can check it first and drop duplicates.
419 2011-12-14 06:59:58 <copumpkin> never really looked into that too deeply, and when I did it was for RSA
420 2011-12-14 07:00:03 <gmaxwell> which would all be well and happy except for the non-canonical form.
421 2011-12-14 07:00:16 <copumpkin> nice thing about the RSA sigs at least is that they don't need the randomized padding
422 2011-12-14 07:00:24 <cjdelisle> gmaxwell: if you store my bad sig hashes, I'll send you gigabytes of them
423 2011-12-14 07:00:32 <copumpkin> although they can have it (the payload describes what kind of padding you have)
424 2011-12-14 07:01:18 <copumpkin> is there a way to make blockexplorer give me more than the largest transactions from the last 300 blocks?
425 2011-12-14 07:01:22 <gmaxwell> cjdelisle: well, I can counter that too... but fine. this isn't the worst issue. You can already dos nodes out using address rumoring anyways.
426 2011-12-14 07:01:43 <copumpkin> cjdelisle: but otherwise I don't really know anything, sorry :)
427 2011-12-14 07:01:51 <cjdelisle> hmm I was thinking like if it's der encoded, maybe adding some kind of nop bytes will alter a sig without "changing it"
428 2011-12-14 07:01:54 <cjdelisle> ok
429 2011-12-14 07:02:02 <cjdelisle> or leading zeros
430 2011-12-14 07:02:02 <gmaxwell> cjdelisle: its der encoded.
431 2011-12-14 07:02:05 <gmaxwell> it starts with 04
432 2011-12-14 07:02:10 <gmaxwell> oh well the key is
433 2011-12-14 07:02:19 <gmaxwell> darn, I don't know about the signature.
434 2011-12-14 07:02:19 <wumpus> huh, if you hash the entire thing you can still sends millions of bad signatures, they wil have different hashes
435 2011-12-14 07:02:37 <copumpkin> the signatures I've seen are usually "raw", but as I said with RSA, there's the whole PKCS whatever padding scheme inside
436 2011-12-14 07:02:46 <wumpus> how will duplicate detection work if you want to flood someone with a lot of invalid signatures which are all different?
437 2011-12-14 07:02:51 <copumpkin> meaning there wasn't a DER wrapper around the signature or anything like that
438 2011-12-14 07:03:09 <copumpkin> but all the usual RSA-isms I'm used to don't apply to your sigs
439 2011-12-14 07:03:10 <gmaxwell> wumpus: ... okay, you've performed a zero trust validation that its past my bedtime via proof of work. Thank you.
440 2011-12-14 07:03:34 <gmaxwell> (I was being idiotic)
441 2011-12-14 07:04:00 <wumpus> :D
442 2011-12-14 07:04:17 <gmaxwell> (too much thinking about block validation where the hash has a special expensive form that can be cheaply checked)
443 2011-12-14 07:04:52 <copumpkin> anyone here have an easily queryable history of large transactions on the block chain? I'm trying to determine the last time one of those 400k+ transactions happened
444 2011-12-14 07:04:54 <wumpus> yes maybe that's the solution, add a proof of work
445 2011-12-14 07:05:14 <copumpkin> it ran off the end of blockexplorer's window of 300 blocks
446 2011-12-14 07:05:30 <gmaxwell> copumpkin: you know those 400k txns are mtgox's right?
447 2011-12-14 07:05:47 <copumpkin> has magicaltux actually confirmed that? cause I asked him and he seemed surprised
448 2011-12-14 07:06:02 <copumpkin> and they appear to have stopped now
449 2011-12-14 07:06:14 <copumpkin> so I was just trying to figure out when they stopped to correlate with something else :)
450 2011-12-14 07:06:27 <gmaxwell> He confirmed control of of ~450k btc at a single address some months ago.
451 2011-12-14 07:06:29 <wumpus> maybe he didn't know he was generating them and he stopped when you notified him
452 2011-12-14 07:06:38 <gmaxwell> I suppose someone should go and trace to see if its mostly the same coin.
453 2011-12-14 07:06:41 <copumpkin> nah, they kept happening for a while afterwards
454 2011-12-14 07:06:50 <gmaxwell> I think people assumed that it was..
455 2011-12-14 07:07:01 <copumpkin> I did too, but I'd prefer to be extra sure :)
456 2011-12-14 07:07:19 <gmaxwell> and have been eagerly waiting to mr. cosmic ray to earn an doctorate in instant-deflation.
457 2011-12-14 07:07:47 <copumpkin> but anyway, does anyone have a record of those megatransactions, just to put my mind at rest? :)
458 2011-12-14 07:08:12 <gmaxwell> (if they were actually using bitcoind at least it checks that it can validate its own txn before sending it but god knows what they're using)
459 2011-12-14 07:08:50 <gmaxwell> copumpkin: https://bitcointalk.org/index.php?topic=53848.0
460 2011-12-14 07:10:41 <copumpkin> did the original poster mean that he actually saw his withdrawal coming from that?
461 2011-12-14 07:11:22 <copumpkin> because the address he linked to didn't actually send a smaller transaction (which is usually the pattern)
462 2011-12-14 07:11:34 <gmaxwell> who knows... but someone could try to trace that back to the 400k btc that mtgox did demonstrate ownership before.
463 2011-12-14 07:12:18 <copumpkin> yeah, we need more graph analysis tools :)
464 2011-12-14 07:12:31 <copumpkin> but when mtgox demonstrated ownership is also relevant
465 2011-12-14 07:12:48 <copumpkin> since they might have ownership of it due to a massive transaction putting that much coin into mtgox
466 2011-12-14 07:13:05 <copumpkin> (still from some single entity owning them)
467 2011-12-14 11:18:56 <Mqrius> Hmm. I actually need an android app that notifies when block X is reached. That'd be nice...
468 2011-12-14 11:27:45 <t4nk515> ,
469 2011-12-14 11:41:52 <sipa> gmaxwell: pubkeys are not der-encoded - it's an encoding defined by secp iirc
470 2011-12-14 11:42:43 <sipa> gmaxwell: signatures are der encoded (and any ber encoding of them is probably accepted)
471 2011-12-14 12:15:03 <SomeoneWeird> use irc and just keep annoying gribble
472 2011-12-14 12:15:06 <SomeoneWeird> Mqrius, ^^
473 2011-12-14 12:15:22 <Mqrius> heya
474 2011-12-14 12:15:47 <SomeoneWeird> ;;bc,blocks
475 2011-12-14 12:15:48 <gribble> 157483
476 2011-12-14 12:16:29 <Mqrius> I sent a transaction in block 157474, but silkroad hasn't processed it yet or something..
477 2011-12-14 12:16:37 <SomeoneWeird> COUGH.
478 2011-12-14 12:16:58 <SomeoneWeird> >.>
479 2011-12-14 12:17:03 <Mqrius> Not buying illegal stuff. I live in the Netherlands :)
480 2011-12-14 12:17:47 <Mqrius> Wonder why it takes so long though
481 2011-12-14 12:19:24 <SomeoneWeird> whats legal that silkroad sels?
482 2011-12-14 12:19:26 <SomeoneWeird> sells*?
483 2011-12-14 12:19:43 <Graet> depende where u live SomeoneWeird
484 2011-12-14 12:19:53 <SomeoneWeird> heh
485 2011-12-14 12:22:31 <Mqrius> Plenty of stuff. It's just a bit cheaper on silk road, occasionally.
486 2011-12-14 12:26:33 <SomeoneWeird> :)
487 2011-12-14 12:27:38 <Mqrius> Hm. Perhaps they send it through their tumbler upon entry? Then it would be 2x6 confirmations? Except that makes no sense at all.
488 2011-12-14 12:29:43 <SomeoneWeird> nah they'd trust their tumbler
489 2011-12-14 12:29:50 <SomeoneWeird> so no reason to add another 6
490 2011-12-14 12:36:16 <Mqrius> Hm. Seem to be other people having issues on their forum today too. Guess I'll just wait
491 2011-12-14 13:54:40 <[eval]> nlocktime doesn't do anything as far as preventing a spend of an output until a certain time, does it?
492 2011-12-14 13:55:09 <[eval]> is it possible (on prodnet) to send coins to an address that can't be redeemed until a certain block (or time)?
493 2011-12-14 13:58:32 <sipa> [eval]: yes, via nlocktime?
494 2011-12-14 14:01:39 <[eval]> sipa: is nLockTime currently used? if i set an nLockTime, will it be respected?
495 2011-12-14 14:01:48 <TD> [eval]: it isn't available currently
496 2011-12-14 14:01:54 <TD> it needs to be re-activated. then people have to upgrade :(
497 2011-12-14 14:02:13 <[eval]> hrm. ok. so i can't give people bitcoins for xmas/hanukkah that they can't spend for 5 years, can i? :(
498 2011-12-14 14:02:30 <TD> not yet. if you know c++ and want to make that possible (along with the contracts it allows), that'd be a great contribution
499 2011-12-14 14:02:33 <TD> the work involves writing tests, mostly
500 2011-12-14 14:02:44 <TD> actually re-activating nLockTime just means deleting a line of code
501 2011-12-14 14:03:40 <sipa> i believe nLockTime is active?
502 2011-12-14 14:03:46 <sipa> transaction replacement isn't
503 2011-12-14 14:04:01 <[eval]> i know c++ to some degree (it's been a long time since i've done anything useful with it and i've never worked on code as complicated as that of bitcoin) but i don't know much about testing :/
504 2011-12-14 14:04:19 <epscy> nLockTime?
505 2011-12-14 14:04:25 <sipa> look in main.h
506 2011-12-14 14:04:31 <sipa> in CTransaction::IsFInal
507 2011-12-14 14:04:47 <epscy> how would that work, is it stored the blockchain?
508 2011-12-14 14:05:00 <sipa> yes, it's part of the transaction data
509 2011-12-14 14:05:02 <epscy> cos if it is in the client then surely you could just disable it?
510 2011-12-14 14:05:16 <sipa> and every miner and relaying node in the network checks it
511 2011-12-14 14:05:33 <epscy> how can you ensure every miner will respect it?
512 2011-12-14 14:05:36 <TD> hmm that's true. lock times aren't so useful without tx replacement, imho
513 2011-12-14 14:05:54 <TD> but if all you want to do is write a transaction that becomes valid after time T then i suppose it could work
514 2011-12-14 14:05:57 <[eval]> IsFinal() only seems to look at nSequence
515 2011-12-14 14:05:59 <[eval]> not nLockTime
516 2011-12-14 14:06:01 <epscy> if a miner allowed you to spend it before the lock time would other miners reject that block?
517 2011-12-14 14:06:12 <[eval]> oh that's ctxin
518 2011-12-14 14:06:24 <[eval]> brb gotta do work at work too :(
519 2011-12-14 14:06:47 <sipa> epscy: then that miner is breaking the network rules, and he will (probably) be ignored by "true" miners
520 2011-12-14 14:07:01 <TD> yeah it's validated as part of the block checks
521 2011-12-14 14:07:06 <TD> a block that breaks that rule will be rejected
522 2011-12-14 14:07:14 <epscy> interesting
523 2011-12-14 14:07:27 <epscy> i know the protocol works by consensus
524 2011-12-14 14:08:01 <epscy> but that seems to give the developers a lot of power
525 2011-12-14 14:08:30 <gmaxwell> 07:06 < epscy> if a miner allowed you to spend it before the lock time would other miners reject that block?
526 2011-12-14 14:08:43 <gmaxwell> Not just miners, everyone that validates which is most nodes today.
527 2011-12-14 14:08:48 <TD> the power lies in the hands of [a] people who decide whether or not to switch versions and [b] miners
528 2011-12-14 14:09:21 <TD> if you want to play with lock times, try on the testnet or a private testnet
529 2011-12-14 14:10:24 <epscy> gmaxwell: cool so the transaction would probably not get relayed
530 2011-12-14 14:11:10 <sipa> epscy: it shouldn't be relayed by any full node
531 2011-12-14 14:11:23 <gmaxwell> not just that but all other (full) nodes will ignore the block as if it never happened.
532 2011-12-14 14:13:00 <ThomasV> gmaxwell: I have a question about type 2 wallets
533 2011-12-14 14:13:14 <ThomasV> Privatekey(type,n) = Master_private_key + H(n|S|type)
534 2011-12-14 14:14:21 <ThomasV> gmaxwell: the result might exceed the allowed range; do I need to use a master private key that has 1 bit less ?
535 2011-12-14 14:14:47 <[eval]> hrm
536 2011-12-14 14:14:51 <sipa> i would assume you do a modulo <fieldorder> afterwards
537 2011-12-14 14:15:03 <sipa> s/fieldorder/grouporder/
538 2011-12-14 14:15:09 <gmaxwell> ThomasV: it's a field add. (or multiply) so it wraps.
539 2011-12-14 14:15:09 <ThomasV> a modulo preserves the key?
540 2011-12-14 14:15:40 <ThomasV> it wraps?
541 2011-12-14 14:15:57 <t4nk515> hellou ppl =)
542 2011-12-14 14:16:25 <[eval]> it doesn't look like nLockTime not being expired will actually prevent the transaction outputs from being spent
543 2011-12-14 14:16:43 <ThomasV> gmaxwell: what do you mean, "it wraps"
544 2011-12-14 14:16:56 <sipa> [eval]: no, but it does prevent the transaction from being included in a block
545 2011-12-14 14:16:59 <gmaxwell> [eval]: the outputs can't be mined because the inputs aren't mined yet.
546 2011-12-14 14:17:27 <gmaxwell> ThomasV: it's reduced modulo the group order.
547 2011-12-14 14:17:43 <sipa> [eval]: so you can "spend" it, in a 0-confirm sense, resulting in a new transaction that cannot be placed in a block either
548 2011-12-14 14:18:33 <ThomasV> gmaxwell: I see. but to implement it, I guess I use a normal addition + modulo, right?
549 2011-12-14 14:18:37 <gmaxwell> (and some of the things that you can do with nlocktime depend on being able to write transaction which aren't valid yet which depend on the not valid yet one)
550 2011-12-14 14:19:15 <[eval]> are testnet's rules for nlocktime different from prodnet's?
551 2011-12-14 14:19:19 <sipa> no
552 2011-12-14 14:19:53 <[eval]> so if i test this on testnet, and it works the way i want it to, i can use it on prodnet and it'll work the way it did on testnet... awesome!
553 2011-12-14 14:20:05 <sipa> it should, yes
554 2011-12-14 14:54:54 <gavinandresen> good morning y'all.
555 2011-12-14 14:55:06 <gavinandresen> gmaxwell: I read the chat logs....
556 2011-12-14 15:07:13 <[eval]> morning and congrats on block 157500 :>
557 2011-12-14 16:23:34 <eueueue> Hi, I'm testing bitcoin 0.5.1 rc1 and I have a problem with traslation with portuguese BR
558 2011-12-14 16:23:37 <eueueue> see:
559 2011-12-14 16:23:43 <eueueue> http://imageshack.us/photo/my-images/860/capturadetelaih.png/
560 2011-12-14 16:23:48 <eueueue> look the menus
561 2011-12-14 16:24:03 <eueueue> start with amp:
562 2011-12-14 16:24:25 <eueueue> and shouldn't
563 2011-12-14 16:24:41 <eueueue> is it a known problem?
564 2011-12-14 16:26:35 <eueueue> anyone?
565 2011-12-14 17:18:33 <ThomasV> tcatm: bitcoincharts is broken?
566 2011-12-14 17:20:16 <tcatm> ThomasV: what's wrong?
567 2011-12-14 17:21:28 <luke-jr> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046136.html
568 2011-12-14 17:31:13 <ThomasV> tcatm: graphs not updating
569 2011-12-14 17:31:19 <tcatm> which graphs?
570 2011-12-14 17:31:31 <ThomasV> http://bitcoincharts.com/charts/mtgoxUSD#rg2ztgSzm1g10zm2g25zv
571 2011-12-14 17:32:08 <tcatm> could be
572 2011-12-14 17:32:38 <tcatm> I don't have access to a graphical browser here.
573 2011-12-14 17:33:27 <ThomasV> tcatm: it's been so for about 6 hours now
574 2011-12-14 17:37:59 <eueueue> Hi, not complete translation is a bug?
575 2011-12-14 17:38:27 <eueueue> I see Portuguese BR is incomplete. How can I help?
576 2011-12-14 17:40:08 <gavinandresen> eueueue : translations are done using Transifex (website)
577 2011-12-14 17:40:08 <luke-jr> eueueue: clone git and start translating?\n2357027
578 2011-12-14 17:40:32 <luke-jr> gavinandresen: not sure that fixes eueueue's bug
579 2011-12-14 17:40:37 <gavinandresen> https://www.transifex.net/projects/p/bitcoin/
580 2011-12-14 17:40:46 <eueueue> Sorry, I'm newbie. Any easy way to help translating
581 2011-12-14 17:40:49 <eueueue> ha ok
582 2011-12-14 17:40:51 <luke-jr> gavinandresen: somehow he's seeing HTML in the menus
583 2011-12-14 17:41:06 <eueueue> will see the site
584 2011-12-14 17:41:13 <gavinandresen> luke-jr: yes, I know, I opened an issue about that'
585 2011-12-14 17:42:30 <wumpus> <source>&amp;Copy to Clipboard</source>
586 2011-12-14 17:42:41 <wumpus> yes, there's certainly something wrong in the BR translation
587 2011-12-14 17:44:04 <wumpus> almost all of the translations are prefixed with &amp;amp and a space
588 2011-12-14 17:44:29 <gavinandresen> Ah, nice, the testnet CAlert message cleared itself
589 2011-12-14 17:44:40 <wumpus> good
590 2011-12-14 17:44:52 <luke-jr> does Transifex let us add strings of not-yet-merged -- maybe even not-yet-written -- stuff, so we can preemptively get translations?
591 2011-12-14 17:45:13 <gavinandresen> I should have set a quicker expiration time, so gmaxwell et al weren't tempted to broadcast it on the main net....
592 2011-12-14 17:45:14 <luke-jr> gavinandresen: "cleared"?
593 2011-12-14 17:45:24 <gavinandresen> CAlerts are sent with an expiration time
594 2011-12-14 17:45:24 <luke-jr> oh, they expire? :/
595 2011-12-14 17:45:32 <luke-jr> nuts
596 2011-12-14 17:46:02 <gavinandresen> Yes, they have "relay until" and "completely expire" times.
597 2011-12-14 17:46:24 <wumpus> luke-jr: I think so, if you upload a ts with those strings  (though do mind that Qt translations have a context as well which should also be right)
598 2011-12-14 17:46:44 <luke-jr> wumpus: well, a ts implies the code is written :P
599 2011-12-14 17:47:20 <wumpus> well maybe the management interface allows adding strings too, I don't know, never seen taht
600 2011-12-14 17:48:01 <luke-jr> wow, 27k lines of diff if I run lupdate on next-test
601 2011-12-14 17:48:22 <luke-jr> 25k on master :o
602 2011-12-14 17:48:52 <wumpus> yes, I don't think lupdate is used for the languages; the ts files come from transifex
603 2011-12-14 17:49:34 <luke-jr> &
604 2011-12-14 17:50:41 <wumpus> which probably has a slightly different xml formatting
605 2011-12-14 17:50:57 <luke-jr> even still, the en ts is outdated by 1.5k lines
606 2011-12-14 17:51:24 <wumpus> the en ts is only used to fill in some strings, it is not meant to be complete
607 2011-12-14 17:51:44 <wumpus> (ie, to make plurals work)
608 2011-12-14 17:51:45 <luke-jr> well then what's the source for Transifex?
609 2011-12-14 17:51:50 <wumpus> ask tcatm
610 2011-12-14 17:52:24 <luke-jr> also, I didn't mean incomplete.
611 2011-12-14 17:52:30 <luke-jr> I meant not in sync with the code
612 2011-12-14 17:52:47 <luke-jr> ie, missing strings
613 2011-12-14 17:53:10 <wumpus> yes for en that doesn't matter, it is supposed to skip most strings
614 2011-12-14 17:53:17 <wumpus> for the other languages that's not supposed to be the case though
615 2011-12-14 17:58:06 <diki> I don't suppose I need to compile a shit ton of things for mingw64(windows) in order to use pdcurses and stuff
616 2011-12-14 17:58:07 <diki> ?
617 2011-12-14 17:58:34 <diki> Cause mingw32 has a small mingw-get, for stuff
618 2011-12-14 17:58:45 <diki> but mingw64 does not look like it has such a feature
619 2011-12-14 18:07:25 <wumpus> why use mingw64 at all?
620 2011-12-14 18:08:02 <diki> to compile x64 apps?
621 2011-12-14 18:08:16 <diki> or rather, minerd which provides 1.2 kilohashes more under x64
622 2011-12-14 18:08:25 <diki> and I mean native x64 compiled code
623 2011-12-14 18:08:30 <diki> for litecoin etc
624 2011-12-14 18:08:48 <wumpus> yeah just noticed most people are fine and dandy with 32bit apps on 64 bit windows
625 2011-12-14 18:09:29 <diki> hmm
626 2011-12-14 18:09:40 <diki> maybe I can use gcc's --host switch and start from there
627 2011-12-14 18:09:45 <diki> --host/target
628 2011-12-14 18:25:15 <tcatm> ThomasV: does it work onw?
629 2011-12-14 18:27:07 <ThomasV> tcatm: yes
630 2011-12-14 19:08:53 <Shaded> Does Nefario use IRC?
631 2011-12-14 19:11:33 <graingert> !seen nefario
632 2011-12-14 19:11:33 <gribble> nefario was last seen in #bitcoin-dev 17 weeks, 2 days, 17 hours, 23 minutes, and 10 seconds ago: <nefario> payup
633 2011-12-14 19:11:33 <TiggrBot> I havent seen {0}
634 2011-12-14 19:47:41 <luke-jr> tcatm: so& any hints on checking the status of translations, and that your translation site is up to date?
635 2011-12-14 19:56:47 <sipa> a statically typed dynamicfish?
636 2011-12-14 20:25:52 <ThomasV> tcatm: apparently your database has a gap in may
637 2011-12-14 20:26:34 <ThomasV> well, for mtgox
638 2011-12-14 20:27:34 <luke-jr> I think script.cpp:ExtractAddressInner has a bug. Can someone confirm? It returns true even if the opcode doesn't have the address/key&
639 2011-12-14 20:34:36 <gavinandresen> luke-jr: you mean "returns true even if the keystore doesn't...." ?
640 2011-12-14 20:35:33 <luke-jr> gavinandresen: I'm assumign the keystore == NULL scenario
641 2011-12-14 20:35:46 <luke-jr> and a script starting with something besides the key/hash
642 2011-12-14 20:36:12 <gavinandresen> Hmm?  vSolutions are only solutions for the standard scripts
643 2011-12-14 20:36:34 <gavinandresen> Solver() returns false if it gets a script that doesn't match one of the standard templates
644 2011-12-14 20:37:40 <gavinandresen> ... so item.first will always be either OP_PUBKEY or OP_PUBKEYHASH.  Well, until the OP_EVAL patch is pulled....
645 2011-12-14 20:38:08 <gavinandresen> It would be clearer if there was another else that did an assert("error..." == 0) or something
646 2011-12-14 20:41:53 <luke-jr> gavinandresen: so you're saying 100% of cases where ExtractAddress is called, cannot reproduce this particular bug?
647 2011-12-14 20:42:06 <luke-jr> but ExtractAddress is technically not a private symbol.. ;)
648 2011-12-14 20:42:55 <gavinandresen> I'm saying that unless you have modified Solver(), that bug will not happen.
649 2011-12-14 20:43:09 <luke-jr> gavinandresen: Solver() isn't called in ExtractAddress
650 2011-12-14 20:43:19 <luke-jr> wait
651 2011-12-14 20:43:20 <luke-jr> nm
652 2011-12-14 20:43:35 <luke-jr> ah well
653 2011-12-14 20:43:46 <luke-jr> can at least remove the FOREACH to be clear :P
654 2011-12-14 20:44:31 <gavinandresen> ExtractAddress changes with the multisignature changes
655 2011-12-14 20:44:43 <luke-jr> ok, so then it WILL be a bug? :P
656 2011-12-14 20:44:51 <gavinandresen> ... because there may be more than one signature to extract....
657 2011-12-14 20:44:54 <luke-jr> but does it make sense to use ExtractAddress on a multisig? :/
658 2011-12-14 20:45:08 <luke-jr> right, ExtractAddress assumes there is only one though
659 2011-12-14 20:45:30 <phantomcircuit> ThomasV, bitcoincharts has been modified to reflect trades which were reversed
660 2011-12-14 20:45:37 <gavinandresen> https://github.com/gavinandresen/bitcoin-git/blob/op_eval/src/script.cpp#L1445
661 2011-12-14 20:45:54 <luke-jr> ah
662 2011-12-14 20:46:14 <gavinandresen> So:  bug fixed.
663 2011-12-14 20:46:32 <gavinandresen> Wait, no:  not-a-bug, but fixed anyway.
664 2011-12-14 20:47:24 <cjdelisle> not-a-bug, but fixed anyway :)
665 2011-12-14 20:48:45 <luke-jr> theoretical, but not practical, bug
666 2011-12-14 21:00:12 <da2ce7> luke-jr: you arround?
667 2011-12-14 21:00:58 <da2ce7> well anyway; I wanted to weigh in on the 'human remembreable bitcoin address' debate...
668 2011-12-14 21:01:09 <luke-jr> &
669 2011-12-14 21:01:16 <luke-jr> why does that mean pinging me?
670 2011-12-14 21:01:35 <da2ce7> why don't we just send coins to a namecoin address?? since we are useing compadible private keys...
671 2011-12-14 21:01:41 <da2ce7> *name coin name-coin.
672 2011-12-14 21:02:51 <luke-jr> da2ce7: wtf does that have to do with anything?
673 2011-12-14 21:02:56 <da2ce7> why you; well it seems (from following the decussion on the mailing list) that you have your head in the clearest position of the lot.
674 2011-12-14 21:03:09 <da2ce7> well there is no binding or anything...
675 2011-12-14 21:03:26 <da2ce7> just lookup the namecoin address; then send your coins to the owner of that address.
676 2011-12-14 21:03:30 <da2ce7> *record.
677 2011-12-14 21:03:56 <da2ce7> as namecoin and bitcoin are compadible.
678 2011-12-14 21:04:01 <sipa> use namecoin as dns resolver if you like
679 2011-12-14 21:04:12 <sipa> don't if you don't
680 2011-12-14 21:04:27 <da2ce7> no need for a bitcoin address; just use the address of the namecoin -namecoin... or whatever it's name is  :P
681 2011-12-14 21:04:28 <luke-jr> &
682 2011-12-14 21:06:16 <sipa> da2ce7: btw, justmoon found a way to make the bloom filter idea viable
683 2011-12-14 21:06:26 <sipa> using two filters
684 2011-12-14 21:06:29 <da2ce7> oh great!
685 2011-12-14 21:06:31 <da2ce7> :)
686 2011-12-14 21:06:49 <helo> so someone registers a namecoin address where a value is your bitcoin address
687 2011-12-14 21:07:11 <luke-jr> sipa: what bloom filter idea?
688 2011-12-14 21:07:35 <da2ce7> helo: no not even that... a specal namecoin 'name-coin' is used as the owniship token for any namecoin record.
689 2011-12-14 21:08:05 <da2ce7> we can just send bitcoin's to public key of that specal 'name-coin'
690 2011-12-14 21:08:51 <da2ce7> no need to define any record dns at all... we only need a globaly unique string... that namecoin provides.
691 2011-12-14 21:23:16 <luke-jr> da2ce7: while I'm polite and cooperative with namecoin, I oppose the concept, and wouldn't want to encourage wider adoption.
692 2011-12-14 21:23:52 <cjdelisle> the concept of dns or the concept of an alternative currency to bitcoin?
693 2011-12-14 21:24:10 <da2ce7> oh ok. i quite like the namecoin concept
694 2011-12-14 21:24:14 <luke-jr> cjdelisle: the concept of DNS beyond the reach of court orders
695 2011-12-14 21:24:41 <helo> i kind of like the concept of money beyond the reach of court orders
696 2011-12-14 21:24:56 <gmaxwell> Namecoin isn't beyond the reach of court orders. Namecoin makes the courts go after _people_ where lawful process can be upheld, instead of mucking with systems where there is no one with the standing to make sure lawful process is followed.
697 2011-12-14 21:24:56 <helo> surely money can do anything DNS could do
698 2011-12-14 21:24:59 <da2ce7> oh; philosophically dislike namecoin
699 2011-12-14 21:25:10 <luke-jr> helo: money has no effect on people other than the holder
700 2011-12-14 21:25:25 <theymos> I like the idea, but I think Namecoin could have been done a lot better. I don't think the current system's economic model or technology will scale.
701 2011-12-14 21:25:27 <luke-jr> gmaxwell: you can't physically take a NMC address from someone
702 2011-12-14 21:25:33 <cjdelisle> What about DDoS or death threats? Should dns not be immune to those?
703 2011-12-14 21:25:47 <gmaxwell> The situation we have today allowed unelected government employees broad power to muck with people without providing for any due process or remedy for error.
704 2011-12-14 21:25:54 <luke-jr> btw, someone was talking about implementing dynamic DNS with namecoin block chain the other day&
705 2011-12-14 21:26:04 <gmaxwell> luke-jr: no, but you physically put the person with that NMC address in jail if they disobey the orders of a court.
706 2011-12-14 21:26:14 <luke-jr> gmaxwell: that won't fix the domain
707 2011-12-14 21:26:20 <da2ce7> if you can prove it....
708 2011-12-14 21:26:35 <gmaxwell> If someone wants to go to jail over their dns name, then great. Thats a balance.
709 2011-12-14 21:26:36 <da2ce7> namecoin is a great way to provide names for TOR hidden services
710 2011-12-14 21:27:06 <luke-jr> gmaxwell: it's not a solution
711 2011-12-14 21:27:43 <da2ce7> luke-jr: I'm like any non-violent technology; namecoin is a usefull technology that helps people.
712 2011-12-14 21:27:51 <da2ce7> *well; if used.
713 2011-12-14 21:27:53 <luke-jr> I suppose you could argue the domain will expire eventually&
714 2011-12-14 21:28:05 <gmaxwell> It will, of course.
715 2011-12-14 21:28:06 <cjdelisle> I like the consept of a DNS root which is resistant to terrorist attacks and cyber-warfare, but I don't like the idea of an alternative currency to support it.
716 2011-12-14 21:28:27 <luke-jr> cjdelisle: implement a better alternative ;)
717 2011-12-14 21:28:35 <luke-jr> also, solve squatters while you're at it :P
718 2011-12-14 21:28:47 <da2ce7> cjdelisle: the currecny is just to make sure that names are not too cheap; and so that they are not all parked.
719 2011-12-14 21:29:01 <luke-jr> da2ce7: they ARE too cheap.
720 2011-12-14 21:29:08 <luke-jr> and most parked
721 2011-12-14 21:29:10 <da2ce7> any limited resource (good names), should have a cost.
722 2011-12-14 21:29:12 <cjdelisle> I intend on implementing something which uses the bitcoin chain for authority and an external system for getting the information.
723 2011-12-14 21:29:26 <theymos> Yeah, I'd like DNS to use Bitcoin. Then the DNS service wouldn't have to worry about currency issues, and Bitcoin would get some "inherent value".
724 2011-12-14 21:29:33 <gmaxwell> cjdelisle: because you want bitcoin to fail.
725 2011-12-14 21:29:46 <cjdelisle> lol  gmaxwell :)
726 2011-12-14 21:29:53 <luke-jr> cjdelisle: NOT the bitcoin chain
727 2011-12-14 21:30:29 <da2ce7> theymos: I just non't like the idea of sticking all the dns info into the blockchain; but I guess that we _could_ use OP_EVAL for that...
728 2011-12-14 21:30:33 <cjdelisle> It's not as if it would add anything to the bitcoin chain which wouldn't be there already if people had to spend btc to get a domain.
729 2011-12-14 21:30:58 <cjdelisle> "sticking all the dns info into the blockchain" <-- Agreed, that is a very bad idea
730 2011-12-14 21:31:09 <gmaxwell> theymos: merged mining creates that benefit for mining now, if namecoin is successful, people can lose interest in bitcoin mostly and bitcoin may still be immune to attack. Thats a very important improvement.
731 2011-12-14 21:31:48 <cjdelisle> gmaxwell: has invested in namecoin and doesn't want a dns system which doesn't use his pyrimid scheme :P
732 2011-12-14 21:31:53 <cjdelisle> see I can point fingers too
733 2011-12-14 21:31:54 <gmaxwell> cjdelisle: sure it would, because there isn't a 1:1 mapping between btc transactions and purchases.
734 2011-12-14 21:32:01 <theymos> gmaxwell: Yeah, merged mining is a big improvement. That's when I stopped thinking Namecoin was doomed and started thinking it might be (unfortunately) good enough to succeed, even though it is not as good as I'd like it.
735 2011-12-14 21:32:05 <luke-jr> cjdelisle could make it so you have to declare <output of at least N value> to represent the name, and if you spend that, you transfer the coin. ;)
736 2011-12-14 21:32:27 <luke-jr> and your client would need to be careful to never spend it accidentally (by using a custom script?)
737 2011-12-14 21:32:53 <cjdelisle> That's my basic thinking, making lookups fast is the hard part
738 2011-12-14 21:32:59 <gmaxwell> cjdelisle: Except your allegation there is a question of fact I own a grand total of 150 nmc at the moment (maybe 200 depending on when luke pays out). I don't really give a shit about it, what I don't want is hundreds of gigs of naming database data in the open transactions of bitcoin,  causing the premature loss of decenteralization.
739 2011-12-14 21:33:04 <cjdelisle> and it's the part which the nmc people have refused to consider
740 2011-12-14 21:33:09 <luke-jr> cjdelisle: just keep a hash of all names?
741 2011-12-14 21:33:44 <cjdelisle> I would like a general purpose solution which allows for fast lookups and validations of names and of bitcoin transactions.
742 2011-12-14 21:33:52 <theymos> A DNS chain without a currency could be a constant 10,000 blocks long (or whatever). DNS names expire, so you don't need to keep a full history.
743 2011-12-14 21:34:09 <cjdelisle> That would be very nice since it would give speed to both BTC and name lookups
744 2011-12-14 21:34:15 <gmaxwell> theymos: namecoin already allows that much,  it has fixed expiration for that reason.
745 2011-12-14 21:34:29 <gmaxwell> they just haven't implemented the pruning crap.
746 2011-12-14 21:34:50 <theymos> gmaxwell: Doesn't it still have to keep track of old unspent currency transactions like Bitcoin does?
747 2011-12-14 21:34:51 <luke-jr> theymos: why use blocks?
748 2011-12-14 21:35:10 <theymos> luke-jr: Keeping track of ordering is useful with DNS.
749 2011-12-14 21:35:20 <luke-jr> theymos: no, you just need the current state
750 2011-12-14 21:35:26 <gmaxwell> theymos: yes, but you don't need to if you're just a zero trust resolver and not a miner.
751 2011-12-14 21:35:42 <gmaxwell> (and like bitcoin you do just need open txn if you're pruned)
752 2011-12-14 21:36:05 <theymos> gmaxwell: That's a good point. What's the fixed expiration time in Namecoin?
753 2011-12-14 21:36:07 <luke-jr> and the Bitcoin block chain tracks where that magic output gets transferred ;)
754 2011-12-14 21:36:27 <gmaxwell> theymos: 12000 blocks I think.
755 2011-12-14 21:37:06 <cjdelisle> Oh, +1 benefit of having names integrated in btc is that you can know who you're sending to.
756 2011-12-14 21:37:08 <luke-jr> IMO, a DNS based on Bitcoin could be implemented with only a "current state of all names" record in the MM table
757 2011-12-14 21:37:13 <luke-jr> ie, no chain
758 2011-12-14 21:37:27 <Diablo-D3> no it cant
759 2011-12-14 21:37:31 <Diablo-D3> you need previous work to prove future work
760 2011-12-14 21:37:35 <luke-jr> nope.
761 2011-12-14 21:37:39 <Diablo-D3> yup.
762 2011-12-14 21:37:42 <gmaxwell> "current state of all names" for .com is like 100gigs of data. doesn't work so well if having to keep the whole thing is the only way to have it work securely though.
763 2011-12-14 21:37:56 <gmaxwell> (thats fine for mining, but I'm talking about a resolver)
764 2011-12-14 21:38:08 <Diablo-D3> dude
765 2011-12-14 21:38:11 <cjdelisle> That's because NMC is fail
766 2011-12-14 21:38:12 <Diablo-D3> by the time namecoin wins
767 2011-12-14 21:38:14 <luke-jr> gmaxwell: a resolver already needs the entire state for DNS
768 2011-12-14 21:38:18 <Diablo-D3> 100gb will be nothing
769 2011-12-14 21:38:19 <Diablo-D3> I mean fuck
770 2011-12-14 21:38:24 <cjdelisle> lol
771 2011-12-14 21:38:26 <Diablo-D3> I can buy tablets and cell phones with like 64 now
772 2011-12-14 21:38:35 <gmaxwell> luke-jr: no, thus recursive resolvers. (which can be secure with DNSSEC too)
773 2011-12-14 21:38:42 <cjdelisle> ^lol
774 2011-12-14 21:39:16 <luke-jr> gmaxwell: obviously only the root level is in the name-state
775 2011-12-14 21:39:20 <gmaxwell> (I'm not saying DNSSEC is puppies and flowers, but unless NMC gets a way to do lite resolvers, its not even as good)
776 2011-12-14 21:39:25 <luke-jr> those have DNSSEC+NS records
777 2011-12-14 21:39:43 <cjdelisle> I really like gmaxwell's proposal to build a hash tree from transactions which have not been spent yet, that should be integratable into the 0trust resolver.
778 2011-12-14 21:39:58 <gmaxwell> cjdelisle: thats why I proposed it.
779 2011-12-14 21:40:05 <cjdelisle> DNSSEC is brilliant -- except for the small problem that it doesn't work.
780 2011-12-14 21:40:34 <luke-jr> ok, Bitcoin-based DNSSEC replacement :P
781 2011-12-14 21:40:38 <cjdelisle> And it won't work until the DNSSEC people stop taking every critique as a personal attack.
782 2011-12-14 21:41:00 <cjdelisle> I like your thinking luke
783 2011-12-14 21:41:20 <Diablo-D3> DNSSEC can be implemented without the DNSSEC people anyhow
784 2011-12-14 21:41:29 <Diablo-D3> once they release a spec, thats it, game over
785 2011-12-14 21:41:36 <luke-jr> each root-level domain would have: serial(only goes up), output controlling it (txnid+index), signing key, and NS records
786 2011-12-14 21:42:08 <luke-jr> verification would only allow changing the control-output if it was spent in the Bitcoin chain, and only to an output of the transaction it was spent to
787 2011-12-14 21:42:11 <gmaxwell> again, if you stuff this stuff into bitcoin directly you increase the chance that both fail we have severe danger of outgrowing our ability to stay decenteralized.  Ideally, the naming cand currency should be seperate but interoperable with shared security.. so that you can scale it by keeping nodes seperate.
788 2011-12-14 21:42:21 <luke-jr> serial could be reset to 0 only when changing control-output
789 2011-12-14 21:42:23 <cjdelisle> I would like to, in so far as possible, keep everything out of the bitcoin chain.
790 2011-12-14 21:42:29 <luke-jr> otherwise only validates upward
791 2011-12-14 21:42:35 <Diablo-D3> I agree with gmaxwell
792 2011-12-14 21:42:46 <Diablo-D3> bitcoin just isnt designed for generic data storage
793 2011-12-14 21:42:53 <Diablo-D3> ie, btc isnt an "app" for the bitcoin chain.
794 2011-12-14 21:42:58 <Diablo-D3> its the primary and only user
795 2011-12-14 21:43:05 <Diablo-D3> nmc leeching off btc the way it does is acceptable.
796 2011-12-14 21:43:10 <luke-jr> oh, the root-level domains also each have signed-with-output-key(serial + NS records)
797 2011-12-14 21:43:11 <cjdelisle> My ideal is to have just a regular transaction which pays to 2 keys, one is the hash of the name and the other is the key which controls that record.
798 2011-12-14 21:43:17 <Diablo-D3> it doesnt harm btc, but it provides the needed security
799 2011-12-14 21:43:37 <Diablo-D3> cjdelisle: yeah, but you still need to store 9 billion GB of trash in the chain
800 2011-12-14 21:43:38 <luke-jr> and the current-state "block" would go in the merged-mining table like namecoin blocks do