--- Log opened Fri Sep 13 00:00:32 2013
00:31 < midnightmagic> uh.. there was an old scientist, old when black and white film could be shot of him, a famous man, who for all the world looked like the early Dr. Who, and there's a video of him on youtube somewhere talking about god and how he's an atheist. i don't remember his name. can so ekne give me a clue?
02:15 < gmaxwell> petertodd: http://sourceforge.net/p/bitcoin/mailman/message/31397880/  < this needs a blog post with some pretty "illustrations" of the scripts.
02:58 < petertodd> yes it does!
02:58  * petertodd needs to get petertodd.org running again
02:58 < gmaxwell> maybe an animation of the stack
02:59 < petertodd> yeah, that'd be good
02:59 < petertodd> webbtc.com actualy can give you step-by-step stack traces, although being bitcoin-ruby it's buggy...
03:22 < amiller> that's cool :)
07:54 < jgarzik> Got "auctionpunk" server skeleton going last night.  It creates auctions for a fee, accepts bids and checks the bids, and reports progress on the auction.  Next step: handle auction ending (which might be off-server, since it requires private keys, and I am trying to create a setup that does not require private keys on the server itself)
07:55 < jgarzik> just got first-price-sealed-bid for now
07:55 < jgarzik> *does
13:09 < nanotube> 112 connections, 749/329 M mem usage. and that's with a  2329 tx pool.
13:12 < gmaxwell> Cool.
13:13 < jgarzik> no-wallet will make that mem usage even smaller :)
13:13 < gmaxwell> http://www.reddit.com/r/Bitcoin/comments/1mavh9/trustless_bitcoin_bounty_for_sha1_sha256_etc/ < responses to the collision bounties has been pretty good.
13:14 < jgarzik> gmaxwell, I forwarded it to Bruce S, though (a) he is probably mega-busy and (b) it requires a lot of bootstrapping introduction, even for knowledgeable tech folks
13:15 < jgarzik> gmaxwell, I see you had to do similar bootstrapping on the reddit post, in fact
13:16 < gmaxwell> jgarzik: yep.
13:51 < nanotube> jgarzik: 50mb doesn't make that much difference to me atm. i recall you said the difference was roughly 50mb?
13:52 < jgarzik> nanotube, 40mb for me.  warren reported upwards of 200mb on some Fedora installs.
13:54 < nanotube> hm, how come such a big difference?
13:54 < nanotube> (also, i'm on debian)
13:55 < jgarzik> nanotube, no one knows but The Shadow
13:55 < gmaxwell> jgarzik: it's only when you run the gitian builds on fedora.
13:55 < gmaxwell> presumably something to do with bdb static linking and The Shadow
13:57 < nanotube> heh
13:58 < jgarzik> meh.  TD's argumentation can be compelling, but json-rpc is more compelling.  JSON Just Works in python and JS, and matches nicely with their native data structures.  protobufs are great for avoiding manual marshalling code drudgery, type checking and other utility, but the hurdles for end users are slightly higher
13:58 < jgarzik> both JS and python handle json without additional downloads, compiles, package installs
13:58 < jgarzik> the downside is… it's JSON
13:59 < jgarzik> no type checking, binary stuff passed as hex, ridiculously strict parsing
13:59 < gmaxwell> Yep. you can write it with a text editor. Like HTTP. It's not pretty but its "accessible"
13:59 < jgarzik> debuggable
14:00 < Luke-Jr> someone should make a protobuf editor
14:00 < Luke-Jr> :P
14:01 < Luke-Jr> then the only problem is that it needs a schema
14:01 < Luke-Jr> but that's mostly unavoidable
14:01 < Luke-Jr> even EBML needs schemas I think
14:03 < jgarzik> Manually written marshalling code is certainly drudgery and bug-prone
14:04 < gmaxwell> Luke-Jr: it does, well, you're free to not define them and make everything an informal adhoc mess (largely whats happened in mkv)
14:04 < jgarzik> I bet somebody somewhere has already done work on JS or python code generation, to eliminate some of that headache
14:05  * Luke-Jr hates how protobuf generates code currently
14:05 < jgarzik> unfortunately the bitcoin world seems to be the largest consumer of JSON-RPC
14:05 < Luke-Jr> with Python at least, it should be more than possible to automatically parse protobuf from a .proto direclty
14:05 < jgarzik> I look around for json-rpc libs in $language, and inevitably find the author a bitcoiner
14:06 < jgarzik> compiling a foo.proto file into json-rpc type-checking code would be nice
14:06 < jgarzik> and optimal
14:07 < jgarzik> (not protobufs data definition strictly; obviously details would change for JSON)
14:12 < Luke-Jr> we really should have hijacked some bits from nVersion for the block nonce..
14:13 < Luke-Jr> with the speeds 28nm are going to do
14:13 < gmaxwell> Luke-Jr: pft nonsense. people should be building miners that can update their work faster than once per 30 seconds.. what a mess.
14:14 < Luke-Jr> gmaxwell: it's already once per second for a single bitfury chip
14:14 < Luke-Jr> and 28nm chips to 600 Gh alone
14:14 < Luke-Jr> do*
14:15 < gmaxwell> Luke-Jr: yea, and? random desktop cpu should be able to do 500,000 roots per second or something loopy like that.
14:15 < Luke-Jr> (or maybe it was 300 Gh, but not important)
14:15 < Luke-Jr> gmaxwell: with up to potentially 1 MB coinbases? :p
14:15 < Luke-Jr> and 10+ MB blocks?
14:15 < gmaxwell> Luke-Jr: yea well, do the p2pool style extranonce.
14:16 < gmaxwell> Luke-Jr: 10mb blocks is irrelevant.
14:16 < Luke-Jr> today.
14:16 < Luke-Jr> do you really want non-scalable mining chips?
14:16 < gmaxwell> No, I mean its forever irrelevant
14:16 < Luke-Jr> …
14:16 < Luke-Jr> explain
14:17 < gmaxwell> log2.. it takes 21 sha256s to compute the root for a 1GByte block.
14:17 < gmaxwell> (assuming 500 byte transactions)
14:18 < gmaxwell> 30 for a 1 TB block.
14:18 < gmaxwell> the coinbase is a bigger issue, but as I mentioned you can do what p2pool does.
14:18 < gmaxwell> OP_RETURN output in the last transaction and do midstate compression.
14:18 < gmaxwell> er OP_RETURN in the last output
14:20 < Luke-Jr> yeah
14:20 < Luke-Jr> but that's with a host generating the work
14:20 < Luke-Jr> if these ASICs get any faster, they will have to generate work internally
14:20 < gmaxwell> I wish the hash tree geometry were different... that coinbases forked off at the top.. I wish that transactions themselves were hash trees, so that you could update one part without the rest, but we've got what we've got. If I were to hard fork, I wouldn't worry about header nonce. We have scarcely few bits in the header.. stealing one for nonce would would do little good but might hurt a lot if we ever need more than a flag there.
14:21 < gmaxwell> Luke-Jr: they can do the same thing that the host does on a little FPGA.
14:21 < gmaxwell> (no need to take the risk of fabricating it directly)
14:22 < Luke-Jr> hmm, so use part of the ASIC die for a FPGA?
14:22 < Luke-Jr> is that R&D-cheap?
14:23 < gmaxwell> Luke-Jr: nah, you just use a seperate fpga which then serves as your MCU (they make fpgas that have small cpus fixed on them, alternatively you just load a cpu onto it)
14:24 < gmaxwell> Seriously, these people are making _tens of millions of dollars_ and yes solving these challenges will take a little work. Tough. Thats business. The nonce already gives them a 4 billion to one work reduction, two or four times that if you're willing to steal a couple of timestamp bits.
14:25 < gmaxwell> Meanwhile taking too long before updating the hashroot is bad for the network, it increases orphaning.
14:25 < gmaxwell> Luke-Jr: any idea why the bitfurry stuff has high stales on p2pool?
14:25 < gmaxwell> Its worse than avalon.
14:25 < Luke-Jr> gmaxwell: I'm afraid they'll gladly make crappy non-scalable chips to get it out the door sooner with more profit :/
14:26 < Luke-Jr> gmaxwell: because the bitfury code people are using sucks?
14:26 < gmaxwell> (I can't say that I'm complaining much, I think I'm now at 105% efficiency with my avalons…)
14:27 < Luke-Jr> I've been basically rewriting it entirely for BFGMiner
14:27 < gmaxwell> (though part of that 105% is the asicminer things ... lol .. can't longpoll)
14:28 < Luke-Jr> bitfury can't longpoll either
14:28 < Luke-Jr> the chip itself
14:28 < Luke-Jr> I think asicminer's chip can longpoll
14:28 < Luke-Jr> (the USB ones in fact seem to work for doing that)
14:30 < Luke-Jr> bitfury's chip CAN return results in realtime (no waiting until the end like BFL)
15:57 < jgarzik> gmaxwell, petertodd: Bruce S says "thanks" for the collision-reward forum link I sent him
19:10 < sipa> jgarzik: THE bruce schneier?
19:11 < sipa> Bruce Schneier can recite pi. Backwards.
19:11 < Luke-Jr> in tonal?
19:12 < sipa> Obviously.
19:13 < Luke-Jr> :D
19:13 < sipa> he's probably to come up with two number systems in which the digit expansion is identical
19:13 < sipa> +able
19:19 < gmaxwell> it's easier to do it backwards in tonal.
19:19 < gmaxwell> (really)
19:20 < Luke-Jr> gmaxwell: easier⁉ maybe if it were even possible!
19:21 < sipa> ba kwards is impossible
19:21 < gmaxwell> Luke-Jr: On the basis of http://en.wikipedia.org/wiki/BBP_formula
19:21 < sipa> but in tonal (well, anything binary or power thereof) there is an efficient algorithm to compute arbitrary digits
19:22 < Luke-Jr> gmaxwell: but the end/!
19:23 < sipa> it's just slightly less impossible
19:23 < sipa> but still impossible really
19:24 < gmaxwell> It's still deeply weird that there is random access to pi. :)
19:55 < nanotube> lol didn't know that - that's awesome
22:32 < petertodd> jgarzik: awesome, forward me the email
23:31 < amiller> okay i solved bitcoin, it's no problem
23:31 < amiller> gmaxwell, i've been stressing out about this anti outsourcing puzzle but it is way simpler than i thought
23:32 < amiller> the trick is that you should not reveal the actual puzzle solution
23:32 < amiller> but a zero knowledge proof that you know a proof of work solution
23:33 < amiller> that's all there is to it really, but i should clarify that it should reveal *nothing* else about the solution, for example you should not reveal that the solution contains a commit to valid transctions or anything like that
23:34 < amiller> if you want to commit some transactions into a block, you must bind those *after* you find the solution,
23:34 < amiller> otherwise there is a 'watermarking attack' that makes hosted mining feasible
--- Log closed Sat Sep 14 00:00:36 2013