--- Log opened Tue Jan 21 00:00:48 2014
10:10 < jtimon_> fund Jamaican bobsled, such pump. fund dogemarket, to the moon http://maaku.github.io/dogemarket.org/
10:21 < _ingsoc> Hahaha. Nice.
12:02 < petertodd> jtimon_: the amoral marketer in me thinks maaku's use of dogecoin to pump freidmarkets is very shewed
12:03 < jtimon_> can't find shewed...
12:04 < helo> shrewd
12:04  * petertodd hooked on fonics worked for me
12:04 < jtimon_> we have more stuff in mind "Litemarkets: like gold to colored coin's silver"
12:05 < petertodd> jtimon_: I think you need a cheese analogy, because you can find that kind of thing on the moon
12:06 < jtimon_> apparently people didn't undesrtood what free software means and kept complaining about freicoin's demurrage and foundation when talking freimarkets
12:06 < jtimon_> so maybe people get it this way...
12:07 < petertodd> jtimon_: lol, though speaking of, I noticed that doge's issuing scheme is bugged and results in 5% inflation forever (notied == saw on reddit)
12:07 < petertodd> jtimon_: hilarious that actually matches almost what how I think crypto-currencies should workd!
12:07 < jtimon_> and if those dogs are funding the jamaican bosleigh team...
12:07 < petertodd> heh
12:07 < petertodd> I'll have to buy some
12:08 < jtimon_> maybe the perpetual inflation was on purpose, some other alts have it
12:08 < petertodd> well the github discussion seems to indicate it wasn't, but anyway, happy accident
12:08 < sipa> petertodd: that means the int64 amounts should overflow at some point?
12:08 < petertodd> (pity it'll probably be removed in a hard fork...)
12:09 < petertodd> sipa: what amounts though? there's no "total coins" amount in the consensus code
12:09 < jtimon_> petertodd: I think what sipa means is that you could cause overflows at some point
12:09 < petertodd> sipa: I think the tx code is probably safe because of MAX_MONEY (which the doge team apparently thought was what set the max amount of money)
12:10 < sipa> petertodd: right, i mean more that MAX_MONEY may at some point in the future become uselessly low
12:10 < petertodd> jtimon_: sure, but if no consensus critical code is affected they're ok, and anyway, checked again and it's not 5% inflation, but a linear coin # increase, so it'll take awhile
12:10 < sipa> oh
12:10 < sipa> boring :)
12:11 < petertodd> sipa: well, saying "inflation" was bad of me, so I think they're ok
12:11 < jtimon_> it's monetary inflation
12:11 < jtimon_> not necessarily price inflation
12:11 < petertodd> jtimon_: yup, just not numerical inflation :P
12:11 < sipa> yeah, it's money inflation not price inflation
12:11 < sipa> not what i meant
12:11 < sipa> just that linear increase and not exponential is boring
12:12 < petertodd> sipa: yeah, well, time to make expocoin...
12:12 < petertodd> sipa: e-coin!
12:12 < sipa> exp(coin)
12:12 < petertodd> e^coin!
12:12 < sipa> actually, it's O(coin) - the inflation is proportional to the amount in circulation
12:12 < jtimon_> most people believe freicoin and expocoin are equivalent
12:12 < sipa> jtimon_: aren't they (apart from psychology) ?
12:13 < petertodd> sipa: heh, well, why not e^coin! with ! as factorial...
12:13 < jtimon_> people forked our diff filter, but nobody forked our demurrage
12:13 < petertodd> jtimon_: I think it's a marketing problem; I would have called it "a shared coin security fund"
12:14 < jtimon_> sipa: we believe they influence intrest differently ie: price inflation just rises nominal interest, demurrage makes REAL intereset fall
12:14 < jtimon_> https://www.community-exchange.org/docs/Gesell/en/neo/part5/7.htm
12:15 < sipa> right, but that's just a psychological difference, no?
12:15 < jtimon_> "Hausse-Premium" is usually known as "inflation premium"
12:15 < sipa> the % of coins you own doesn't change
12:15  * petertodd can't believe he just read "support for KYC regulatory compliance" in comic sans
12:15 < jtimon_> sipa think of loans
12:15 < jtimon_> and real capital
12:16 < sipa> jtimon_: define on top of your client a layer that shows every amount as ($VALUE / $TOTAL_IN_CIRCULATION)
12:16 < sipa> jtimon_: expocoin and freicoin do become equivalent then, no?
12:16 < sipa> (honest question, i don't know enough about freicoin)
12:18 < jtimon_> well, not exactly at the low level (don't have refHeights) but yes, I guess economically would be the same if everybody uses the freicoin unit instead of the expocoin one
12:19 < petertodd> sipa, jtimon_: lost coins makes expocoin and freicoin act differently
12:19 < jtimon_> petertodd yes, that's true too
12:20 < sipa> petertodd: how so?
12:20 < jtimon_> freicoin recycles lost coins
12:20 < sipa> how do you detect lost coins?
12:20 < jtimon_> you don't detect them, you destroy all coins and reissue them
12:21 < sipa> i don't understand
12:21 < jtimon_> freicoin is constantly destroying coins, lost wallets or not, and then re-issuing through the miners
12:21 < sipa> i may misunderstand some implementation issues on freicoin
12:21 < jtimon_> we explain it as "demurrage fees go to miners" to simplify
12:21 < petertodd> sipa: demurrage affects you regardless of what other coins are availalble, expocoin just introduces more coins into the economy
12:22 < petertodd> sipa: the result is roughly the same, but the exact amount of economic inflaton can differ in practice
12:22 < petertodd> sipa: never mind that demurrage has other implications, such as how it affects things like colored coins
12:26 < jtimon_> sipa these are probably the more relevant commits https://github.com/freicoin/freicoin/commit/4025098c05c351d72c8a0916ec6010e821d288d6
12:26 < jtimon_> https://github.com/freicoin/freicoin/commit/cee818350d857029e0e7148fece35646d479aea1
12:56 < gmaxwell> This is the puzzle I thought some people here might enjoy: http://web.mit.edu/puzzle/www/2014/puzzle/puzzle_with_answer_cronin/  (don't click solution unless you want to be spoiled)   Yes, it's supposted to say that its solved, the theme of this section is that puzzles were written backwards, where you got a 'solution' first and had to derrive the title.
13:09 < nsh> gmaxwell, is the title supposed to be a question that leads to the answer 'CRONIN'?
13:12 < petertodd> nsh: 'round here we'd ask 'Find N such that H(n)=<garbage>' and would have been clever to bruteforce the nonce rather than the PoW solution.
13:13 < nsh> hmm
13:14 < gmaxwell> nsh: well kinda, actually the title is a single word.
13:16  * nsh muses
13:16 < gmaxwell> nsh: make you click the card in the page.
13:18 < nsh> well, cheshire nyan is fun, but i'm still confused :/
13:21 < gmaxwell> You have to go deeper.
13:21 < nsh> oka y:)
13:22 < nsh> yay, loads of hex
14:39 < maaku> sipa: inflation moves slowly through the economy giving preferential benefit to those near its source when prices are sticky
14:40 < maaku> and love the O(coin) name
15:16 < maaku> suggestion to jgarzik: crowd-fund in dogecoins your cubesat project. you can send it on L-50 which is taking 50 units to the moon
15:16 < maaku> I think you can drum up enough support to actually send a dogecoin node to the moon (and put a bitcoin node on there too, of course)
15:18 < jgarzik> heh
15:19 < nsh> that would probably work
15:19 < nsh> i wanna send something to the moon
15:20 < nsh> (a robot that tracks down and destroys the american flag)
15:20 < nsh> ((joke. there's no american flag))
15:22 < nsh> maaku, what is this L-50?
15:22 < maaku> jgarzik: i'm serious : http://www.lunarcubes.com/
15:22 < nsh> ah ty
15:23 < nsh> is there a definite launch planned?
15:23 < maaku> nsh: V-50 is a 50-unit housing module attached to centaur upper stages, which go through Earth-Moon L4/L5 on their way out of cislunar space
15:24 < maaku> L-50 is a project to buy one of these to send cubes to the moon
15:24 < nsh> ah, i see
15:24 < maaku> there's also plans to use them for Mars exploration, but that requires a relay spacecraft
15:25 < BigBitz> Heh, cool quiz, gmaxwell :) or puzzle, whatever. :)
15:25 < nsh> would it be feasible to book passage on a regular comsat launch for that? or would it require a special trajectory?
15:25 < maaku> (once you're at Earth-Moon or Earth-Sun lagrange points, it's basically downhill to anywhere in the inner solar system, with the right orbit)
15:25  * nsh nods
15:26 < maaku> nsh: the Centaur stages are what take comsats to GEO, then for satallite safety reasons they use their latent fuel to eject themselves from cislunar space
15:26 < nsh> oooh
15:26 < nsh> that's convenient
15:26 < maaku> so every. single. launch. of a GEO bird sends a centaur stage (or equiv) through one of these trajectories
15:27  * nsh crosses out all his ambitions and replaces with "write code that ends up orbiting moon"
15:27 < nsh> :)
15:49  * petertodd crosses out all his ambitions and replaces them with "write code that exploits code orbiting the moon"
15:51 < maaku> that you coudl do now...
15:52 < brisque> working on software on the moon would be awful. imagine the cost of getting somebody to go there and power cycle your server because you killed the wrong process.
16:00 < CodeShark> keep someone there at all times just in case
16:03 < CodeShark> the most annoying thing about working on software on the moon would be the latency
16:04 < brisque> probably get better latency to the moon than on a 3G connection, it's not all that far away
16:04 < CodeShark> a quarter of a million miles
16:04 < brisque> little over a second then?
16:05 < CodeShark> in each direction, yes
16:05 < brisque> just use a client with local echo, it'd be just as usable a SSH over GPRS
16:08 < jgarzik> maaku, not implying you were not being serious.  just fun :)  dogecoin has a lot of cute marketing, like the bobsled thing.
16:10 < CodeShark> SSH over GPRS is usable? hell, anything over GPRS is usable?
16:12 < brisque> http://mosh.mit.edu/
16:12 < brisque> I used a phone with a GPRS connection for a few years, it was incredibly painful.
16:19 < CodeShark> many of us did
20:25 < adam3us1> letstalkbitcoin tech interview :) (never like sound of own voice, cringe)
20:27 < adam3us1> (committed tx, fungibility, coinjoin, homomorphic values, centralization, 1-way peg... its long and tech heavy)
21:03 < nsh> let stalk = bitcoin;
21:09 < andytoshi> am i correct that the site requires flash to listen?
21:11 < andytoshi> nope, youtube-dl handles the soundcloud URL correctly: https://w.soundcloud.com/player/?url=http://api.soundcloud.com/tracks/130711534
21:22 < gmaxwell> I dunno if y'all have been paying attention, but the gridseed ltc asics are claiming that they'll do 60KH/s for a power consumption of 0.44 watts. This is an improvement relative to gpus very similar to what bitcoin asics had relative to gpus.
21:23 < brisque> gmaxwell: we'll see, I ordered one just out of curiosity.
21:25 < brisque> gmaxwell: they're apparently very unstable, from what I've read.
21:25 < brisque> I still don't get why they paired an scrypt core with a very inefficient sha256d one though.
21:25 < gmaxwell> What I'm hearing is that the dual sha256/scrypt mode is flaky.
21:26 < brisque> mm, same.
21:26 < gmaxwell> brisque: why do you think it's inefficient? it's ~2W/GH for sha256 which is about as good as it gets on 55nm.
21:27 < gmaxwell> What I think their design is doing is taking advantage of the fact that the scrypt engine is area limited while the bitcoin work is thermally limited... so they get a part thats basically does both for the costs of one. (well, their prices are high, but thats markup)
21:28 < brisque> gmaxwell: oh I totally misread the email from the seller, I thought it was over 10W/gh for the sha256 side.
21:28 < andytoshi> nice interview adam3us1, i wasn't familiar at all with hashcash
21:28 < andytoshi> ..except there was a discover article which mentioned it in passing in 2004 or so
21:38 < gmaxwell> hm... this actually suggests a flaw in the scrypt paper. The argument for scrypt it based on chip area. But it really should be based on total costs including energy.
21:39 < gmaxwell> since a cracking chip ends up being thermally limited, increasing the area required may not actually increase costs much at all.
21:42 < brisque> rather than being thermally limited, couldn't it be that they just couldn't fit a second scrypt scratch pad in and just put a sha256d core there to fill the space?
21:42 < andytoshi> increasing the die size should increase the cost/unit proportionally, no? the wafers are a fixed size
21:51 < gmaxwell> andytoshi: no, not when you need to waste area just to act as heat spreading, and not when your total costs for your cracking infrastrcuture are dominated by energy.
21:51 < gmaxwell> In fact, it may even be counterproductive (e.g. reducing the energy ratio between attacker and defender enough that the attacker's advantage increases)
21:53 < gmaxwell> it's currently the case that any piece of high performance computing's energy costs surpasses manufacturing if its operated for more than a few months.
21:54 < brisque> is a piece of bitcoin mining gear worthwhile after a few months?
21:54 < brisque> currently it's not.
21:54 < gmaxwell> brisque: sure. lol. careful with those exponential extrapolations.
21:55 < brisque> gmaxwell: oh I'm not predicting based on them, just observing that it's currently fairly vertical.
21:55 < gmaxwell> my b1 avalons still mine 3x their power cost, ... and keep in mind that decrease in returns is exclusively driven by competition from more power efficient devices.
21:55 < gmaxwell> I'm not talking about mining now in any case, I'm talking about KDFs.
21:56 < brisque> any sensible KDF wouldn't have used the settings Litecoin picked though
21:57 < gmaxwell> yes, but the 'sensible' settings would make this discrepency worse, not better.
21:57 < gmaxwell> e.g. you can choose between two KDFs that take 500ms (user tolerance threshold). It's possible that the memory hard one is actually cheaper to attack once you've factored in power costs because it performed far fewer operations in that time because it was spending time waiting on memory.
21:58 < gmaxwell> the scrypt paper computed costs purely based on area, not power. This is clearly incorrect thinking because on any fixed computing infrastructure the power costs are greater. Though I don't know if it happens to break their conclusions.
21:58 < gmaxwell> The gridseed parts suggest its a wash at the parameters ltc used.
21:59 < brisque> if not memory hard, what is the ideal KDF?
21:59 < gmaxwell> But I'd expected that more memory usage would not increase power usage, but would make it slower on desktops (e.g. fewer operations within the user tolerance window). But that would be interesting to crunch through and see how the numbers work out.
22:01 < gmaxwell> brisque: well the correct question is given the commodity hardware the users have, the user delay budget, and the most optimal possible attacker hardware, what parameters minimize the attacker's advantage.
22:03 < brisque> 500ms is probably on the low side of what a user could tolerate. it's amazing what spinning indicators and progress bars can do to alter the perception a user has of a slow operation.
22:03 < gmaxwell> The Scrypt paper argues that very memory hard things minimize the attackers advantage because it forces the attacker to spend more mm of silicon. I now think this is suspect because mm of silicon is a minority of a large scale attacker's costs... though that doesn't mean that there isn't some particular non-zero memory hardness level that produces the smallest ratio.
22:04 < gmaxwell> It was a random number, it doesn't actually matter.
22:04 < gmaxwell> and fwiw, 500ms w/ bitcoind to authorize a transaction is actually irritating when its in the foreground.
22:05 < brisque> I know, but I've always found it fascinating how users perceive different delays. in a shell a few milisecond delay is horrible, yet people wait 20 seconds for microsoft word to start.
22:05 < gmaxwell> (our kdf is 100ms by default which is pretty much imperceptable... there seems to be a somewhat sharp wall on delay between imperceptable and annoying somewhere around .5s.)
22:05 < brisque> if the signing happened in the background and took half a minute it wouldn't matter in the slightest.
22:06 < gmaxwell> brisque: well except that it can't even tell you if you typed the key wrong until after the delay.
22:06 < brisque> well it would if the password was typed incorrectly, but it's the fact that the interface shows the latency rather than hiding it.
22:06 < gmaxwell> the fact that you need to be sure you can get the users attention again and that you can't report success until after its done makes it harder to hide.
22:07 < gmaxwell> in any case, as I said— it's irrelevant. There is some budget, whever it is. The question is how do you best use it to increase the attacker's total cost.
22:09 < brisque> probably by avoiding both cases. a very complex algorithm would be a hindrance to hardware implementations, wouldn't it? you avoid the energy saved by waiting around for memory, and you avoid making very simple hashing cores like for sha256d.
22:10 < brisque> that is, you have the best of both worlds. high power cost for the attacker and massive die space.
22:15 < gmaxwell> brisque: no. a very complex algorithim just increases the engineering work, but thats probably small compared to other costs for a large scale attacker.
22:15 < gmaxwell> After all, your own computer runs the complicated algorithim.
22:19 < brisque> gmaxwell: right.
--- Log closed Wed Jan 22 00:00:50 2014