--- Log opened Wed Dec 04 00:00:30 2013
00:25 < amiller> omfg i think i finally get the key trick in this paper
00:25 < amiller> gmaxwell, you know how we've been stuck trying to actually do iddo's protocol
00:26 < amiller> because you can't do math on more than 4 byte numbers
00:26 < amiller> and you need to draw more than 4 bytes of randomness to actually get any security?
00:26 < amiller> they get around this in a clever way we totally missed.....   you actually take the SIZE of a string as a choice within a really small range
00:27 < amiller> in other words, each party picks their own number, 0, 1, or 2.... and for which ever number they choose, cal it i, then they choose a random string of 20+i bytes
00:27 < amiller> and hash thath
00:28 < amiller> i'm pissed we didn't come up with that.
00:30 < amiller> aldfaslkdjfaklj
05:14 < Mike_B> hey gmaxwell
05:15 < Mike_B> has there ever been anything published about the behaviors of various money supplies under different circumstances (mining reward halves every x years vs mining reward never halves vs demurrage vs etc)
05:15 < Mike_B> and also factoring things like expected loss of coins
05:15 < Mike_B> i just got in a discussion with keenanpepper in a different channel and it's an interesting thing to analyze
05:17 < Mike_B> i think it works out to basically the convolution of an accumulation function (with a delta function every time new money is created) and a "retention function" (something like u(t)*d^-t where u(t) is a step function and d is a real 0<d<1 specifying decay)
05:17 < Mike_B> i dunno if this is all well-known or whatever
05:17  * Mike_B is totally new to the scene
05:18 < Mike_B> props to keenan for figuring out how to deal with some of the diff eq problems that arise
07:56 < petertodd> amiller: stupidly clever 'eh?
07:57 < petertodd> amiller: I'm really impressed by that trick
08:27 < nsh> hmm?
08:27 < nsh> what trick, petertodd?
08:28 < gmaxwell> petertodd: apparently someone else figured it out, mike linked to a txn using it.
08:29 < gmaxwell> I'm surprised I hadn't noticed the txn before, it's a mess of opcodes used nowhere else on the network.
08:29 < gmaxwell> nsh: how to do a gambling transaction
08:29 < nsh> between two parties? like iddo's committed coin-toss?
08:31 < gmaxwell> right.
08:31  * nsh nods
08:33 < nsh> i wonder if you can use this mutual-deposit-recovery process to create de-facto socially/economically guaranteed timelock encryption
08:33 < nsh> (in the process of everyone recovering their locked funds they reveal the partial information required to decrypt something)
08:33 < gmaxwell> phantomcircuit: shesek has legal advice that says its not an escrow. Who knows.
08:57 < iddo> gmaxwell: i think that my first coin toss protocol doesn't work, and only Adam's improved protocol works, because it said that Alice creates txn that takes equal amount of coins from Alice and Bob as input, so when Bob signs the refund txn for it, he only sees the hash, so Alice can cheat by getting Bob to sign refund that spends all the coins to her address?
08:58 < iddo> or maybe i'm missing something regarding the hash of a transaction?
08:58 < iddo> Adam's protocol works for sure, because it's a refund for coins that belong only to Alice
09:30 < amiller> gmaxwell, that trnasaction was made by the authors of the paper
09:30 < jtimon> iddo someone asked me yesterday for an atomic transaction in which one party gets a decryption key for a file, is that possible?
09:30 < jtimon> because I said no
09:30 < gmaxwell> jtimon: it's possible.
09:30 < jtimon> what's the coin toss protocol?
09:31 < gmaxwell> I described the required protocol a couple years ago.
09:31 < gmaxwell> jtimon: https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked
09:33 < jtimon> but the password gets revealed for everyone right?
09:35 < gmaxwell> jtimon: uh, it can be just a password for a one time encryption for that recipent, no one else gets the encrypted data.  Alterantively, you can apply the "CoinSwap" encoding, so that the only txn that shows up in the blockchain is a 2 of 2 escrow, so long as the participants cooperate.
09:36 < gmaxwell> (basically in coinswap we show how to take any script releasable escrow traction and keep the real release details a secret, so long as the players play fair— if they don't play fair the details get leaked but the funds still go to the right place)
09:36 < jtimon> I see, you can encrypt to certain public key
09:38 < jtimon> well, extro24 wanted to use it for authors to "sell content", DRMed content, I don't like the idea
09:39 < jtimon> but it seems it would be actually possible
09:39 < jtimon> what other use cases do you find interesting?
09:41 < gmaxwell> well it's not usually that interesting for "sell drmed content" since you don't really have a machine test that you'd like the content or something. So you're stuck trusting the seller that the key he gives you is a key for something you want.
09:41 < jtimon> oh, yeah, that's actually what I told him
09:41 < gmaxwell> for things that you can test with a machine my protocol could be used.
09:42 < gmaxwell> For example, "I'd like to buy the master key that cracks the drm scheme on these books"
09:42 < jtimon> how the networkknows that the secret decrypts the content without actually revealing the content to everyone?
09:42 < gmaxwell> jtimon: you prove it out of band.
09:42 < jtimon> with snark/scip no?
09:43 < gmaxwell> Basically I prove to you that X is the hash of the key you want, out of band.  Using some kind of ZKP, doesn't have to be a SNARK but thats one way of course.
09:43 < gmaxwell> Then you make a transaction that can be redeemed if the person reveals a value that hashes to X.
09:44 < jtimon> this is the "I'd like to buy the master key that cracks the drm scheme on these books" use case?
09:44 < jtimon> no, in general
09:45 < gmaxwell> In general.
09:45 < gmaxwell> go read the webpage. :)
09:45 < iddo> gmaxwell: so do you think that it's possible to do a refund txn for a txn that had inputs of both Alice and Bob, i.e. the refund txn redeems (with locktime) both the coins of Alice and the coins of Bob, or Alice can cheat because Bob only sees the hash of what he signs?
09:45 < jtimon> yeah, sorry
09:47 < gmaxwell> iddo: it can be done, but its messy.
09:47 < iddo> how? :)
09:48 < gmaxwell> iddo: bob makes a transaction moving his coins. But doesn't annouce it. He tells alice the txid. ...
09:48 < gmaxwell> iddo: alice writes a txn spending those coins and hes but doesn't announce it,  she writes a refund and gives the refund (only) to bob and has him sign it.
09:48 < gmaxwell> then after he does she gives him her escrow. and if he likes it, he announces his original move.
09:49 < iddo> ahh
09:49 < iddo> not too messy
09:50 < iddo> but more txns that would need to be broadcasted if both parties are honest, that's true
09:50 < gmaxwell> well, not on paper it's not. The problem is that any time you add an extra level of interaction you really make implementation in the real world messier. e.g. more round trips that can time out that you have to handle. :) and yes, more tx data.
09:50 < jtimon> hehe "because we're computer geeks we have no friends who can act as trusted mediators"
09:54 < epscy> gmaxwell: what are your thoughts on Quark?
09:58 < gmaxwell> epscy: that moronic altcoin that just uses every hash function out there? Well. moronic. doing that confers no specific advantage.
09:59 < gmaxwell> Even if you were to say asic resistance was desirable, it doesn't have that result, it increases the NRE but not the marginal costs, which makes an asic monopoly more likely (or a successful attack by a powerful entity who could eat the nre)
10:06 < jtimon> gmaxwell, this is very cool, I'm thinking voluntary computing, what limitations has the function H ?
10:06 < petertodd> gmaxwell: I noticed those txn's ages ago; I hadn't figured out what they were doing however
10:07 < gmaxwell> jtimon: it just has to be able to run inside your proof enviroment.
10:09 < jtimon> like a BOINC program? I doubt gridcoin has a p2p issuance solution, but it would be interesting
10:15 < gmaxwell> jtimon: it doesn't really make sense for boinc though, because the proof systems have quite high overhead. A lot of the theoreticians writing about snarks talk about delegation applications, but as far as I can tell they're on drugs. :)
10:15 < gmaxwell> (e.g. your problem was slow enough you needed to delegate it, so first you embed it in a proof system that makes it 1000x _more_ expensive…)
10:15 < jtimon> yeah, that's what I was asking for with the limitations of H
10:16 < jtimon> ok, it doesn't pays
10:16 < gmaxwell> it works in cases where you have a NP search and you want to pay people for the answer, not the work.
10:16 < gmaxwell> In which case the verification of the answer is fast, but not the search.
10:17 < jtimon> mhmm, maybe scientist could code their voluntary computing programs in a way that people serach for those answers and only prove them when they find them
10:18 < gmaxwell> I suppose, indeed, you can POWize any program by just defining some answers as distinguished.
10:18 < jtimon> but each case would be different, in some cases you won't be able to code those incentives
10:18 < gmaxwell> not necessarily.
10:19 < TD> gmaxwell: the why_hash_locked + scipr protocol should maybe be on the contracts page. as that seems like a very general approach to contracts
10:19 < jtimon> hmm POWize ANY program?
10:19 < TD> gmaxwell: would you mind if i copied it or linked it from the contracts page? any preference as to which?
10:22 < gmaxwell> TD: You can go ahead and link it. There are a bunch of links to it elsewhere, and I don't want to maintain two copies.  I should probably go move it to [[Zero Knoweldge Contingent Payments]] or something like that, and then the original will at least have the move redirect.
10:22 < TD> ok
10:23 < TD> i suppose this is conceptually similar to oracle payments, except if the function you wish to gate the money on is pure then you can avoid the third party
10:27 < gmaxwell> if the oracles inputs are either untrusted or authenticated, then you basically run the payee run the oracle for you and prove he did it right.
10:29 < TD> yeah. but often you want to access some external state. if the state is signed (+timestamped?) then this construction is indeed better. otherwise the third party is still needed.
10:29 < TD> i really wish TLS had an ability to sign traffic streams. sigh.
10:30 < jtimon> gmaxwell we could issue freicoin foundation funds as bouties for "scientific solutions" this seems perfect for the job
10:30 < gmaxwell> Right, an interesting point is that you could seperate out the authentication and computation parts. E.g. have a trusted third party who connected to the site and signed the results.
10:30 < TD> right. that's true.
10:30 < TD> a generic TLS signing gateway would be useful for many things, like the p2p exchange thing too.
10:31 < TD> i guess you quickly get back to the tor issue of how do you stop people abusing you as a generic anonymizing proxy for wiki abuse and things
10:31 < TD> but perhaps simply restricting to HTTP GET fixes 90% of that
10:31 < TD> you don't need POST if you do a login out of band, and then simply do GETs with your cookies to obtain provable statements of things, and http responses already contain timestamps
11:00 < michagogo|cloud> 15:33:42 <gmaxwell> phantomcircuit: shesek has legal advice that says its not an escrow. Who knows.
11:00 < michagogo|cloud> If it matters, I understand he's based in Israel
11:56 < TD> gmaxwell: the pay to certificate idea seems like it can open up a whole bunch of interesting areas, like decentralised insurance schemes ...
11:56 < TD> where actuaries are replaced with market-based mechanisms instead.
11:56 < TD> the only human component becomes actually verifying that a specific event did take place in the real world.
11:58 < TD> pay-to-proof feels like a whole talk waiting to be given, actually
12:01 < gmaxwell> TD: yea, but not with open questions: no one wants to answer the question that will arise when someone points out that decentralised insurance schemes requires a is-someone-dead oracle. And that an assination market and an life insurance market are /very/ nearly the same thing.
12:01 < TD> but those things can be done in the centralised model too. as andy greenberg has shown.
12:03 < TD> i wonder if there are more efficient special case protocols for ZKProving signatures and cert chains
12:03 < TD> than snarks
12:03 < gmaxwell> Its true, I don't actually worry about those uses much— people are actually less evil than we worry they are in general, any case—  but it just makes for some awkward conversations esp if you find yourself in a room that contains people who think that such an application would be a good use.
12:03 < TD> i expect assassination markets to shrivel up once the people running them notice bounties on their own heads ...
12:04 < TD> that's a double edged sword for real, aye
12:04 < andytoshi> i always assumed an assassination market would be set up by a rogue bot
12:04 < andytoshi> not even in a terminator-style encounter, just some stupid bug
12:05 < gmaxwell> Well SNARK basically just means "efficient proof", but you mean are there ZKP that are more efficient for cert chains.. and yes, there are — e.g. signatures in the identity based encrpytion model are basically that.
12:05 < gmaxwell> (and they can even be smaller than our own signatures; assuming you trust pairing crypto)
12:05 < TD> you mean for IBE/ABE and variants?
12:07 < gmaxwell> TD: http://www.larc.usp.br/~pbarreto/pblounge.html e.g. CC02 there.   (Though I don't recall if that one uses short signatures, I think it does)
12:07 < TD> thanks
12:07 < TD> btw, your construction requires a proof of a program that itself runs a program. does that explode the complexity requirements?
12:07 < TD> i mean does the program you prove have to basically be an interpreter for another program?
12:09 < gmaxwell> Nah, it just has to have the function embeded in it. The payer would see the meta program and be happy with it.
12:09 < TD> right. because the secret you're selling is not a program, it's the inputs to the program
12:10 < gmaxwell> right if it is a program you'd have to have the execution inside it. though _technically_ that wouldn't be any harder. In fact thats how tinyram works.
12:10 < gmaxwell> E.g. for tinyram all users use the same validation key, the validation key for the tinyram circuit.
12:10 < TD> yeah, the program it proves is a cpu that runs the real program
12:10 < TD> yeah
12:10 < gmaxwell> well I shouldn't say any, tinyram is a slowdown for many things.
12:10 < TD> well, no, i thought the tinyram circuit was manufactured by a compiler and it is a series of steps customised to the program that has to be run. like in size.
12:11 < TD> so it's somewhat but not completely generic
12:12 < gmaxwell> TD: nah, at least what they're doing right now the tinyram key is constant (at least for a given number of public inputs, and a duration of execution— the later being the big thing). and the hash of the program you want it to run is one of the public inputs on the proof size.
12:13 < TD> right, that's what i meant, it's customised for the execution time.
12:13 < TD> i guess in future an obvious optimisation is to customise it further, so opcodes you know can't be executed at time X aren't emitted
12:14 < gmaxwell> Right and indeed. I was thinking about that in particular related to bitcoin, for our applications we often want proofs of hashtrees (e.g. is this transaction comitted), and implementing sha256 in tinyram is stupidly inefficient compared to a direct circuit.
12:15 < gmaxwell> but such programs could usually be arranged as a set of pre-processing steps where there is no control flow, and then a set of tinyram steps.
12:16 < TD> or you could just microcode SHA256 or other primitives so the compiler emits specialised circuits directly
12:16 < TD> i think that's what eli suggested for RSA modular exponentiation
12:17 < gmaxwell> yes, but then you increase the size of the tinyram machine, which makes all the steps when you won't be running the instructions slower. It might make sense for sha256 since you probably would want it in the middle of control flow for many applications.
12:18 < gmaxwell> in any case, at least for the GGPR zk-snarks the validation keys are pretty small. (similar in size to the proofs) and it would be perfectly reasonable to have circuts customized for many different things.
12:19 < gmaxwell> though I don't know if the same is true for some other systems which don't have the CRS security model limitations, if not then you may really prefer everything use the same circuit.
12:28 < andytoshi> man, this password-locked transaction stuff is brilliant
12:28 < andytoshi> such a simple idea
12:29 < TD> this is a new use of the word "simple" i was previously unfamiliar with
12:30 < sipa> "This obviously some strange usage of the word 'simple' I hadn't been previously aware of."
12:30 < andytoshi> well, the "throw a password into what's being proven" idea is simple
12:30 < andytoshi> everything surrounding it is not, but that's as far as i got trying to tackle the problem
12:30 < gmaxwell> I wrote that why_hash_locked page really as a flight of fancy, at the time I wrote it the construction that all the current work is using to make this stuff tractable hadn't even been invented yet! (well, at least not published yet) The existing ZKP stuff for general circuits that I was aware of appeared to have complexity that was infeasable even as a tech demo. (though, in fact there were some somewhat viable things I just wasn't ...
12:30 < TD> sipa: i forget where that quote is from. hitchhikers guide?
12:30 < sipa> TD: bingo!
12:30 < gmaxwell> ... aware of them)
12:31 < TD> yeah it sounds like Adams :)
12:31 < sipa> (it was 'safe' instead of 'simple')
12:31 < TD> sipa: but it's such a brilliant construction that works with any word :-)
12:32 < gmaxwell> There is also the classic, "You keep using that word. I do not think it means what you think it means."
12:32 < andytoshi> hmm, this is really exciting stuff..
12:32  * andytoshi will look into switching his doctorate to CS
12:34 < gmaxwell> (The Garth2010 paper was out, and I suppose would have worked for this— the proofs involve something like 45 group elements, but the proving process is basically the same as the GGPR stuff. ... of course no implementations, ... now we at least have benchmarks of implementations)
12:35 < andytoshi> what is the stuff that zerocoin uses? i have not read that paper yet..
12:37 < gmaxwell> andytoshi: zerocoin uses a application specific cut and choose zkp, not a general proof for NP.  Their ZC2.0 stuff will be based on a zk-SNARK for NP (like the SCIPR lab stuff).
12:37 < andytoshi> kk, thanks
12:37 < andytoshi> i have not read tho zk-SNARK paper yet either :P
12:38 < andytoshi> i've had students wasting my time all morning
12:49 < TD> it's more of a book than a paper
12:54 < gmaxwell> A lot of the papers in this space are quite long.. e.g. 60 pages is pretty typical.
12:55 < gmaxwell> "I thought this was supposted to be a succinct argument??"
12:56 < zooko> Heh heh
13:01 < gmaxwell> I bumped into a survey paper thats probably a handy reference "Verifying computations without reexecuting them: from theoretical possibility to near practicality" (googling that string yields it)
13:13 < gmaxwell> They don't focus as much on the details around public verification as I would have (since its centeral to most of our applications) but it looks like a reasonable survey.
13:27 < TD> thanks
13:37 < maaku> andytoshi: switching to CS from what?
13:41 < iddo> gmaxwell: i was confused earlier, Bob sees the entire refund txn (he only sees hash of the earlier txn that the refund spends), so Bob can see that he gets the right amount of coins back if the earlier txn had some of his coins as input
13:41 < iddo> TD: gmaxwell: i wrote the coin toss protocol as short note PDF: http://www.cs.technion.ac.il/~idddo/cointossBitcoin.pdf
13:42 < iddo> i asked the guys who wrote the new MPC paper to reference this instead of forum post, they haven't replied yet
13:43 < iddo> it's also less cluttered than the entire forum discussion, i suppose
13:43 < iddo> (also i asked Adam Back to write this short note PDF, he agreed)
13:44 < gmaxwell> iddo: I don't think you were. The refund transaction can't be authored unless bob has already signed the escrow transaction. in which case, alice could go ahead and announce it and tie up bob's funds without a refund.
13:46 < andytoshi> maaku: mathematics
13:46 < iddo> hmm
13:46 < TD> iddo: an opcode that pushed the block hash would cause problems after re-orgs.
13:46 < TD> iddo: a re-org could change the outcome of the toss and invalidate all following transactions. that's why there's a maturity rule on coinbases
13:47 < iddo> ok maybe the opcode can require some sort of maturity?
13:48 < maaku> andytoshi: well doctorate-level CS is really a sub-field of math ;)
13:48 < TD> perhaps. but not being able to spend the results of your bet for 100 blocks or so is awkward. and the 100 block rule is arbitrary. for coinbases we just have to suck it up, but i'm not sure we should be spreading the idea of "mature" coins further
13:48 < TD> i mean people love their fungibility, right ;)
13:48 < iddo> i mean a node will evaluate this opcode as some illegal value, unless the block is mature enough
13:48 < iddo> ok
13:50 < iddo> yes when considering safe maturity rules, this idea of pushing block hash on the stack becomes much less attractive
13:50 < iddo> i'll re-word or delete it
13:51 < andytoshi> maaku: yes, but nobody in the math dept does crypto :)
13:53 < gmaxwell> TD: part of the reason for maturity is to ensure fungibility. :)  Makes it so you don't have to go inspecting the history of every coin you recieve to make sure it's not a recent coinbase.
13:54 < TD> well yes, and as an arbitrary choice it's fine. but we just sort of pretend the 100 block rule doesn't exist. i mean, otherwise we could just auto-checkpoint every 100 blocks and get rid of the maturity rule entirely. and it'd be basically the same
13:54 < TD> it's just yet another magic number. it's worth it, but not conceptually very clean
13:55 < gmaxwell> Yea, not saying it's clean, another number would have worked. At some point in depth a coinbase is like any other input.. is that number 100? 1000? 50?  It's certantly not 12 since we've had reorgs in production that deep— though they were special cases.
13:56 < gmaxwell> Having to worry that 2 tx back there was a bet transaction that will be lost in a reorg is lame though.
13:57 < iddo> gmaxwell: i see about bob having to sign the escrow txn before the refund txn is created, so my first coin toss protocol would indeed need the extra complexity, luckily Adam's protocol makes all of the aspects of it as efficent as possible
13:59 < gmaxwell> maybe someday when we add new checksig operators we'll make sure there is a sighash flag that leaves the input txid:vout out of the signature. It would make a number of refund cases much easier if that was possible.
13:59 < gmaxwell> (because then you could author the refund before authoring the payment)
14:00 < TD> yes
14:00 < TD> that would be nice
14:03 < iddo> hmm i thought that what's needed is that the txid hash doesn't depend on the signature of the txn ?
14:06 < gmaxwell> iddo: being able to not have a later signature depend on prior txids is more general, I think.
14:07 < gmaxwell> making the txid not depend on the signature removes malleability, while masking the input results in malleability indifference.
14:09 < iddo> i probably don't understand what's meant with "leaves the input txid:vout out of the signature" ?
14:09 < gmaxwell> A silly example of how masking the input is more general.  I can compute a timelocked transaction that pays to me in— say— 1 year.  In the signature field I put in a nothing up my sleeve number.
14:09 < gmaxwell> Then I recover the applicable public key.
14:09 < iddo> doesn't that mean something about the signature not depending all the data of the txn, instead of the txn hash not depending on the signature?
14:09 < gmaxwell> And author a transaction which pays funds to that public key.
14:10 < gmaxwell> iddo: we have flags in bitcoin to control what parts of the transaction that the signature depends on.
14:10 < gmaxwell> But the flags are not flexible to express "do not depend on the txid:index of the coin this signature is spending"
14:10 < gmaxwell> er not flexible enough.
14:11 < TD> iddo: see the contracts page on the wiki for an intro
14:11 < iddo> ok i'll look, thanks
14:39 < maaku> Mastercoin is looking for devs to hire fulltime (paid in fiat).
14:40 < maaku> I replied with "Mastercoin is a flawed concept and I have better things to do with my time"
14:40 < maaku> But maybe for someone else here it'd beat whatever your dayjob is
14:40 < maaku> Or maybe you can convince them to pay you to work on something actually useful.
14:41 < _ingsoc> Mastercoin is the Antichrist. There, I said it and I don't care.
14:43 < gmaxwell> I think the postive thing is that mastercoin isn't anything but a bucket of money, wrapped in marketing and hope.
14:43 < gmaxwell> So on the technical side it could probably become something substantially different from whatever it is they've been doing so far.
14:44 < _ingsoc> gmaxwell: Can it realistically mess with Bitcoin?
14:44 < _ingsoc> gmaxwell: The whole issue with dumping things into the block chain.
14:44 < gmaxwell> I expect if it survives it'll stop doing that. Thats what I mean by substantially different.
14:45 < _ingsoc> Right, I see.
14:45 < gmaxwell> its funding model made it competative with the bitcoin currency. Dumping data into the blockchain is very easily censored.
14:45 < _ingsoc> The name is stupid anyway. Great. Let's forgoe our fiat master for a new one. :)
14:45 < gmaxwell> Miners, who recieve bitcoin currency ... and not mastercoins .. have every incentive to censor it, and few to not do so.
14:47 < maaku> I would love to take that offer to implement Freimarkets, or even Bitcoin-X
14:48 < maaku> But mastercoin, specifically, serves no purpose and has no future
14:49 < maaku> and unfortunately they can't switch to something better and carry over the investment structure
14:49 < jgarzik> maaku, <shrug>  perhaps today, but with a huge endowment I would not project that opinion into the future
14:49 < jtimon> bitshares seems a similar "money bucket", and they aren't obsesed with "it has to be in the bitcoin chain without modifying the protocol"
14:50 < jtimon> although they got a lot of funding and now they launch protoshares? I don't undesrtand
14:51 < pigeons> easier to launch another funding mechanism than implement a promised application
14:51 < gmaxwell> jtimon: do they actually have a lot of money?
14:52 < _ingsoc> Looks like they're just spending money left and right on whoever comes up with the promise of something.
14:52 < jtimon> I think so, that's what amir told me
14:52 < _ingsoc> gmaxwell: They do.
14:52 < gmaxwell> Protoshares seemed like it was an exit strategy for someone.
14:52 < _ingsoc> It's like 4k BTC?
14:52 < gmaxwell> But I've only been watching very lightly.
14:52 < jtimon> well, maybe it looked like a lot of money to me, I don't remember how much they got
14:52 < _ingsoc> That was a very long time ago.
14:53 < gmaxwell> okay, well, 4k btc is only a lot of money at a personal scale. (though I guess thats about the scale of mastercoins funds)
14:54 < _ingsoc> http://blockchain.info/address/1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
14:54 < jtimon> I think is a substantial quantiy to fund development
14:54 < _ingsoc> That's them.
14:55 < jtimon> maaku do you think we could implement freimarkets with that? ;)
14:55 < jtimon> with what's left on the address, I mean
14:57 < jtimon> wasn't the exodus address a mastercoin thing?
14:57 < _ingsoc> If maaku would listen to me we could do freimarkets and more, but he's too stubborn. :D
14:58 < jtimon> what's your plan?
14:58 < _ingsoc> Aren't you guys sitting on a few million now anyway with your own dev fund?
14:58 < jtimon> what dev fund?
14:58 < _ingsoc> I thought Freicoin had something set up like that.
14:59 < jtimon> oh, the funds that are going to be issued through the foundation? that's not ours
14:59 < jtimon> we want to experiment with issuance mechanisms that aren't as wasteful as mining
15:00 < jtimon> but we can't take such direct decisions
15:00 < jtimon> we should list freimarkets to receive donations here though: http://foundation.freicoin.org/#/donations
15:01 < _ingsoc> How does the foundation decide what to do? And who's the foundation?
15:01 < jtimon> the foundation it's us and 3 other freicoiners
15:01 < jtimon> but the proposals for issuance mechanisms are discussed publicly in the forum
15:02 < _ingsoc> So it's your fund that you can't use without some mechanism?
15:02 < jtimon> yeah, we can't directly chose an amount and finger to a person to receive them
15:03 < jtimon> that's what was promised and the chain is auditable
15:03 < _ingsoc> Right, so you can put up a proposal for freimarkets and get it funded if there's support for it?
15:03 < jtimon> if we fail our promise people can hard-fork and cancel the foundation funds
15:03 < jtimon> yes
15:03 < _ingsoc> That's interesting.
15:04 < _ingsoc> It's too bad the we get tied into camps. If we were fluid, stuff would get done a lot faster.
15:04 < _ingsoc> that*
15:07 < jtimon> yes, this is specially painful in local currenciessoftware
15:08 < jtimon> it's much simpler, but the efforts are even more divided
15:51 < iddo> anyone looked at bitshares or protoshares whitepaper?  http://static.squarespace.com/static/51fb043ee4b0608e46483caf/t/52654716e4b01acd1ac8a085/1382369046208/MomentumProofOfWork.pdf
15:51 < iddo> seems like these guys never heard of cycle finding algorithms without space complexity blowup, like pollard's rho ?
15:52 < jtimon> I looked at bitshares paper a while ago
15:52 < maaku> gmaxwell: from what I can tell the bitshares people have convinced some investor to bankroll whatever they do
15:52 < jtimon> there's many people that believes all these anti-ASIC arguments
15:52 < maaku> it's not like they're sitting on a pile of irrevocable funds like mastercoin is
15:53 < gmaxwell> yea, also mastercoin funds are bitcoin.
15:53 < gmaxwell> it's possible that if bitcoin goes up further mastercoin will end up with an amount which is impressive even at an instutional level...
15:54 < maaku> jtimon: heh, we could implement freimarkets with private servers at 5% of what's left of the mastercoin bucket of money... and have a better, more robust system
15:55 < iddo> gmaxwell: did you see the claim in that bitshares pdf that birthday collisions are hard to find without space complexity, but easy to verify? it sounds wrong, because you can find collisions with cycle detection?
15:57 < gmaxwell> iddo: yup. We've talked about that here before.
15:57 < gmaxwell> There is a simple time memory tradeoff.
15:57 < iddo> ahh
15:58 < iddo> i think that this channel should be logged+archived too, like #bitcoin-dev :)
15:59 < nsh> +1
15:59 < gmaxwell> iddo: but ::shrugs:: when they first published their stuff I eviscerated their initial "memory hard" PoW, reducing it from 128MB to 8kb, complete with an implementation. And also a probablistic version with no memory required... and I waged my finger to them about novel crypto. And their response was to hastily rewrite it and claim that the old one (which had been slathered with marketing) was "just a placeholder"
15:59 < gmaxwell> And after that point I decided I was never again going to do any technical analysis of their stuff.
16:00 < iddo> i see:)
16:00 < iddo> that whitepaper has wild claims that they don't try to back up
16:07 < pigeons> gmaxwell: i don't know the details but the new version of the PoW actually released which was supposed to require lots of meory usage already has custom mining software out for it bypassing the need for all that memory
16:08 < pigeons> so yeah, no reason to take them seriously
16:08 < pigeons> now the principal Larmier is in favor of GPU mining
16:09 < gmaxwell> My impression was that they felt they had to invent novel crypto for pure marketing mumbojump purposes.
16:09 < pigeons> because his alternative is botnets/AWS
16:09 < gmaxwell> lol, I believe I made that point to them previously.
16:09 < gmaxwell> (I've certantly made it before)
16:09 < pigeons> yes lots of pure marketing mumbojumbo over there
16:13 < iddo> pigeons: why AWS is bad?
16:14 < pigeons> iddo: i'm not making a judgemnt on it
16:15 < pigeons> there are trade-offs as far as accesability and decentralization to all the approaches
16:16 < pigeons> but some say it not requiring capital expense just allowing renting by the hour provides similar weird incentives like cex.io
16:17 < pigeons> some say it allows particpation by only people with funds to access such a platform
16:17 < pigeons> there are valid responses thought to those concerns sure
16:18 < iddo> maybe AWS is bad for decentralization because amazon itself can redirect their idle CPUs to mine cryptocoins?
16:18 < pigeons> but protoshares original marketing ws "cpu so anybody with a home pc can do it" which large server farms ran those people out
16:19 < maaku> iddo: because the premise of a GPU-hard, FPGA-hard, ASIC-hard, CPU-easy proof of work is that the network will be secured by actual users (1 CPU = 1 user)
16:19 < gmaxwell> maaku: except thats a false one too.
16:19 < maaku> when in reality, whoever owns the largest datacenter with idle CPUs (AWS), or argest botnet controls the network
16:20 < gmaxwell> also you can never be "ASIC-hard" you can only reduce the specialization advantage. ... and mining is perfect competition, even if the specialized thing is merely 2:1 it will eventually dominate. .. more realistically you're not getting the specialization gain under 10:1
16:20 < maaku> gmaxwell: yeah I'm definately not defending memory-hard proof-of-work. SHA-256 is perfect
16:21 < gmaxwell> and most efforts to be asic hard are really just NRE hard, which may lead to monopolies.
16:21 < maaku> unless you figure out a practical way to do your time-lock PoW
16:21 < nsh> you can beat individual (and successive) generations of asics by cycling through PoW schemes like a meany
16:22 < maaku> I was just explaining the (flawed) reasoning behind it...
16:22 < jtimon> maaku I don't think sha256 is perfect but I would only replace it if there's practical use for pow
16:22 < gmaxwell> maaku: I think to really do it— beyond a bunch of basic pratical considerations, it really needs an asymetric crypto scheme which doesn't have any attacks better than exponential.
16:22 < jtimon> although I think some people here have problems with that
16:23 < jtimon> I admit I don't understand the problems with a theorical curecoin
16:23 < gmaxwell> (because attacker better than exponential seem to all result in it not being progress free)
16:24 < jtimon> gmaxwell, what could be the problem with say, SETI@coin?
16:24 < jtimon> assuming it is feasible in practice
16:25 < zooko> I love this channel.
16:27 < gmaxwell> jtimon: the standard litany, most of those are not sufficiently cheap to verify (e.g. hurts spv nodes, zero knoweldge proofs of tx data, and initial syncup),  they tend to be inadequately proven to be trapdoor free, high hardware implementation complexity (so may lead to asic monopolies)... if the work is not work you could get paid for, then at least it should be free of some of the incentive concerns.
16:27 < gmaxwell> (though because of merged mining even bitcoin isn't free of POW incentive concerns)
16:28 < gmaxwell> jtimon: those sorts of issues aren't fatal, if there really were some task that was obviously a good enough fit .. it might make sense.
16:28 < jtimon> ok, so if implemented properly and for a task that enables the right incentives, would be ok
16:29 < jtimon> what's wrong with merged mining?
16:30 < jtimon> I'm assuming some ZKP efficient mechanism not to hurt SPV
16:30 < iddo> is there SETI@coin proposal that can work? needs readjustable difficulty, and seeded data so that each block depends on the previous block (so you cannot copy PoW) ?
16:30 < gmaxwell> It's not wrong, but it facilitates a possible bad outcome.  Right now 99% of the incentive in mining comes from getting your work in the best chain.  A rational miner doesn't do work which is doomed to not end up in the best chain, like go mine an earlier fork in order to fool an isolated node.
16:30 < gmaxwell> iddo: you don't need adjustable difficulty.
16:31 < iddo> no adjustable difficulty? how come?
16:31 < gmaxwell> iddo: computes H(seti(H(header)))<TARGET. :P
16:31 < gmaxwell> the seti itself doesn't need adjustable difficulty.
16:31 < iddo> hmm
16:31 < jtimon> gmaxwell I don't see how that changes with merged mining
16:31 < iddo> but then it's the usual hash-based PoW, no?
16:32 < iddo> ahh the hash doesn't have nonce
16:32 < gmaxwell> so w/ merged mining, lets imagine that someday 99% of the incentive instead is coming from a really valuable thing that youre merged mining.. the cost of the attack is only the marginal difference.
16:32 < gmaxwell> iddo: yea you have to grind the seti function.
16:33 < gmaxwell> but the problem is that if seti has a trapdoor, or some instances of seti are fast and you can detect them up front, ... uh oh.
16:33 < gmaxwell> or if seti costs $100 million to put into an asic but once you do it's 1000x faster/more power efficient... then perhaps you get a maker monopoly.
16:34 < jtimon> so let's say we have coins A (50%) B (30%) C (15%) and D (5%) being merged mined together
16:35 < jtimon> the percentages mean how much of the total reward for the merged miner comes from each ones in real terms (ie selling all rewards for bananas)
16:35 < maaku> jtimon: this is the same as the attack-a-merged-mine chain scenario
16:35 < gmaxwell> jtimon: the argument generally applies to making pow do something useful,  mining is nearly perfect competition, it adapts until its barely making a profit.. but it adapts on total income. So you can end up with 99% of your income not being from getting into the best chain, but instead being from finding aliens (assuming the aliens pay).
16:35 < gmaxwell> Merged mining potentially presents the same problem.
16:35 < maaku> if you own a big bitcoin mining pool, you can destroy a merged mined alt coin by overpowering it
16:36 < maaku> you can do the same to bitcoin, by offering to pay more (int altcoins) than a miner is receiving (in bitcoins)
16:36 < gmaxwell> it's not a problem so long as getting into the best chain is overwhelming your priority in your mining work. This is optimized by the work being totally usless except for that outcome.
16:36 < jtimon> but all rational miners will be mining currency D, it has almost the same security as currency A has
16:37 < gmaxwell> jtimon: no because you only lose some small amount of your income to switch from honestly mining D to maliciously mining it— perhaps unsuccessfully.
16:37 < jtimon> no matter that only 5% of the reward comes from D, all miners are putting 100% of their pow in it, just like they put it in A
16:37 < maaku> jtimon: someone with a lot of C doesn't like D, so he offers 6% (in a trustworthy asset) to those miners which participate in an attack on D
16:38 < jtimon> yes, "you only lose some small amount of your income to switch from honestly mining D to maliciously mining it"
16:38 < jtimon> but that doesn't turn you into a D majority
16:38 < gmaxwell> you don't need to be a majority to attack a cryptocurrency.
16:38 < gmaxwell> even a few percent of hashpower is useful for making bogus sidechains for tricking network isolated nodes, for example.
16:38 < maaku> yes it does if you can convince a majority of the miners to go with you (remember, you're paying more than they're earning in D, in hard cash)
16:39 < jtimon> ok, ok
16:39 < gmaxwell> and yea, slippery slope, if miners are rational you can bribe them to attack.
16:39 < jtimon> but if 100% of miners are mining equally all currencies, D is just as secure as A is
16:39 < gmaxwell> In general none of this stuff is safe in a purely rational model, you need at least some alturists to stablize the system.
16:39 < gmaxwell> jtimon: it's really not. your 100% definition is weird.
16:40 < maaku> gmaxwell: of course, to be honest the argument is a little weak - it's basically "if bitcoin becomes undervalued, it could be attacked"
16:40 < maaku> to which my response is, "why was bitcoin undervalued?"
16:40 < jtimon> you mean undervalued with repect to mining costs?
16:41 < jtimon> ok, I see the point that the attack to D is cheaper if you bribe other pools
16:41 < gmaxwell> maaku: to some extent. But it's not just about undervalued, it's more like regardless of how valuable bitcoin is, it's not a big consideration to the miner's income, and that _could_ be the case at any value level.
16:41 < maaku> and if the situation was so dire that bitcoin was being replaced with an alt, hence leading to its undervaluation compared with the currency used to pay the attackers, then why care?
16:42 < gmaxwell> maaku: I've never presented this as an argument against merged mining except to point out honestly that when I talk about the downsides of "useful work" that we're already not completely free of it.
16:42 < maaku> ok, i wasn't considering he tragedy of the commons scenario, with btc txfees
16:42 < maaku> still had my freicoin-perpetual-reward thinking cap on
16:42 < maaku> yeah ok
16:42 < jtimon> because scarce monies are always over-valued, they're really a consented bubble, an implicit agreement
16:43 < gmaxwell> And I don't even know that w/ cancercoin if it's a big deal. I just like to point out that "useful work" is not all roses, that there are interesting complications.
16:44 < maaku> of course, *not* merged mining makes the situation worse
16:44 < gmaxwell> when MM was introduced I cheered saying hurray even if people lost interest in bitcoin then maybe bitcoin could still be secure in the future.
16:44 < jtimon> yeah, I know it is a very hard problem, but I believe it is the future
16:44 < gmaxwell> Having seen things play out I was slightly too enthuastic about it, I think.
16:44 < gmaxwell> But I still think its a good thing.
16:45 < jtimon> and not these "anti-asic"schemes
16:45 < maaku> jtimon: there are desireable properties of a proof-of-work which boinc-like work units don't have
16:46 < jtimon> yeah, I think it's cheaper security for everyone, even if the "bribe attack" makes D less secure than A
16:46 < gmaxwell> again, being confident that the thing is trapdoor and easy-instance free is important and generally hard to achieve.
16:46 < maaku> such as being progress-free, and dependent on the prior block
16:47 < gmaxwell> maaku: there are a lot of stochastic search problems that can be made dependant. Making them easy-instance and trapdoor free is much harder.
16:47 < maaku> yeah
16:47 < jtimon> like I said, I don't think it's an easy problem gridcoin has solved, but I believe an appropiate task will be found
16:49 < gmaxwell> plus, in general, no one wants computing power like this.  It's used very wastefully where it is use. Most of the papers that have come out of folding at home have been "ra ra we can get people to give us computing power, look at the interesting problems we had keeping them busy"  not ... "cancer cured!"
16:49 < jtimon> and by the way, maaku, the FF could buy "proofs of results" with ssomething like https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
16:49 < gmaxwell> I think after a decade folding at home got like .. one actual non-CS result out of the thing.
16:49 < Emcy> wow tahts sad
16:49 < Emcy> wtf
16:50 < iddo> gmaxwell: i'm not completely sure that i understand H(seti(H(header)))<TARGET, you should care both about seti() finding some interesting value, and the hash of it being below the target? if you care only about the hash, the seti() value still needs to be something that's easier to verify than to compute, otherwise it's meaningless?
16:50 < gmaxwell> likewise, seti at home was mostly a marketing thing for seti. The work it was doing could have been done far more cheaply with a $50k stack of fpgas.
16:50 < maaku> yeah the class of problems you can solve with @home style distributed computing is really, really small
16:51 < gmaxwell> iddo: the idea there is that it works for anything where solving randomized instance of the problem is useful.
16:51 < Emcy> i did 5000 seti units :(
16:51 < Emcy> on a penitum
16:51 < gmaxwell> iddo: the idea there is that it works for anything where trying many randomized instance of the problem is useful and where testing a single instance is fast.
16:52 < gmaxwell> iddo: the interesting results other than H(problem())<TARGET can be learned as a side effect.
16:52 < maaku> i converted my university's computer labs to run seti@home in the background over a decade ago ... my sense of morality was less developed as a teenager
16:52 < maaku> we were in the top 10 for 3 months :)
16:52 < Emcy> gmaxwell did you see tht thing that turns protein folding into a 3d game
16:53 < gmaxwell> Emcy: yea, foldit
16:53 < gmaxwell> Are you any good at it?
16:53 < Emcy> turns out humans are better at it than computers, with our intuiation and stuff
16:53 < gmaxwell> unlike folding at home, they had useful medical results fairly quickly.
16:53 < Emcy> yeah i should try it again, it ran like shit on my old computer
16:53 < jtimon> I would love to have many people donating their GPUs to run my neural networks playing go during 1000 generations
16:54 < jtimon> or the same NN learning another task
16:54 < Emcy> did you read the wtory about the quake 3 server running bots that someone forgot about for years
16:54 < iddo> gmaxwell: yes, so is there seti() function that's fast to verify the 'interesting' solution?
16:54 < gmaxwell> Emcy: I only used it when it was very new, I was reasonably good at it, but I understand that it's gotten much deeper since the original release; with things like multiplayer problems.
16:54 < Emcy> quake 3 bots have heuristics
16:55 < Emcy> the bots achieved complete peace.......
16:55 < jtimon> Emcy I can build a q3 bot that plays with the same exactly the same inputs you have
16:55 < jtimon> as a human
16:55 < maaku> i have a boinc design to develop and test molecular nanotechnology pathways via evolutionary search
16:55 < maaku> strangely not much money in that though
16:56 < jtimon> and don't tell him anything about time or space, just about good and bad
16:56 < gmaxwell> iddo: e.g. in the actual seti problems, you're running sinusodial analysis on noisy data looking for chirps. it's not terribly hard to generate random insances of the problem, e.g. adding a small amount of additional noise.. and it could be broken down so that it was cheap to run a single instance.
16:56 < Emcy> http://www.huffingtonpost.co.uk/2013/07/01/quake-3-arena-world-peace_n_3529082.html
16:56 < Emcy> welp reinstalling foldit
16:58 < maaku> that's a good description of what seti@home is doing right now ... but alas we've known for 10+ years that it's probably not what seti@home should be doing
16:59 < jtimon> foldit sounds great, I have though about people getting paid to play games while are solving problems without noticing before
16:59 < Emcy> i heard the air force recruited gamers for thier drone program
16:59 < Emcy> does that count
16:59 < maaku> they're basically looking for giant multi-gigawat omnidirectional beacon in space ... with very little reason to think that one would actually be there
17:00 < iddo> so running a single instance means verifying if the random data has the chirps, ok..
17:00 < gmaxwell> jtimon: fold it also merges in computational techniques, as you play you can as the computer to jiggle, which really runs a rather expensive molecular dynamics annealer in the background to help machine assist your solutions.
17:00 < Emcy> you sound enamoured with foldit
17:00 < gmaxwell> Effectively the human does the global search, which is intractable, and the machine does the local search— which its reasonably good at.
17:00 < jtimon> oh, gmaxwell, I see, you're really donating computing while you play
17:01 < gmaxwell> iddo: right. and getting out some chirp presence indexes.
17:01 < gmaxwell> jtimon: well, indirectly— the cpu is used to assist your own game.
17:01 < Emcy> i think of setI@home (the original) as a proof of concept really.
17:02 < gmaxwell> well distributed.new des cracking was the proof of concept. :P
17:02 < jtimon> yeah the point was getting people to donate their computing to scientists
17:02 < Emcy> you say they could have just made an asic farm but they were skint, always scrubbing for money
17:03 < maaku> Emcy: they have a very large fpga array they use to collect, preprocess and break up the data
17:03 < iddo> i saw that the creator of scrypt said that litecoin doesn't have enough memory usage: https://twitter.com/shamoons/status/311256158658760704?x
17:03 < Emcy> they used to have to get the data out of the dish by tape from the middle of peurto rico........
17:03 < Emcy> maaku they might now but i dont know about before
17:04 < Emcy> i think their receiver on the dish focus assembly broke once and they had a special donation drive to fix it......
17:04 < jtimon> no we have the masses asking for asic-ressistant algorithms like if GPU-mining was a natural right
17:04 < maaku> iddo: the scrypt parameters of litecoin were set by someone it was later shown was doing GPU-mining from the start
17:05 < iddo> there are problems with bigger memory buffer in scrypt, if it takes say 1 seconds to invoke scrypt() then it will take days to sync the blockchain, also regular PCs maybe have disadvantge in propagating blocks vs ASIC
17:05 < iddo> maaku: artforz? how do you know that he did GPU mining from the start?
17:05 < gmaxwell> iddo: yea, in ltc it makes a _visible_ difference in the sync time... and they have a fancy sse optimized scrypt implementation.
17:05 < Emcy> maaku really? i thought that was never proven
17:05 < jtimon> really maaku? so charlie did kind of premine?
17:05 < iddo> if he did then he should be rich now:)
17:06 < gmaxwell> artforz was rich regardless.
17:06 < gmaxwell> :P
17:06 < gmaxwell> artforz came up with the scrypt implementation that ltc used.
17:06 < maaku> not charles
17:07 < gmaxwell> ironically about a month after having an argument with me in #bitcoin-dev where he successfully convinced me that using scrypt for a pow was stupid.
17:07 < maaku> yeah it was artforz
17:07 < jtimon> lolcust was the first one trying  those kind of things, no?
17:07 < gmaxwell> lolcust made it public.
17:07 < jtimon> geist geld
17:07 < iddo> gmaxwell: what was his argument against scrypt? botnets?
17:07 < maaku> lolcust worked with artforz to make a series of scrypt based coins which were accused of premine, then charles made litecoin
17:07 < gmaxwell> iddo: yes. and performance. and blocking custom hardware was irrelevant. same ones I use today.
17:08 < jtimon> oh, I see, charlie didn't changed artforz's gpu-friendly parameters
17:08 < maaku> yes
17:08 < gmaxwell> it was also pointed out that the parameters were dumb, OTOH, I don't think they realistically could have changed them.
17:08 < gmaxwell> If they made it use more memory it would be a _serious_ performance problem in validation.
17:08 < pigeons> well first charles forked lolcust's tenebrix into fairbrix
17:08 < gmaxwell> it's already arguably one.
17:09 < pigeons> which died of hostile forking
17:09 < maaku> and then a few months later, someone did sergio-like analsysis to show that somebody was running a miner with the equivalent of 100's of cpus from the start
17:09 < Emcy> oh dear
17:09 < pigeons> a few parameters were changed from fairbrix to litecoin like max number of coins
17:09 < maaku> and the parameters provided by artforz were conveniently just big small enough to fit in current generation gpus
17:09 < Emcy> how could a premined coin like litecoin get so big
17:10 < pigeons> well that someone providing the analysis accusing artforz of gpu mining was real solid
17:10 < gmaxwell> maaku: yea, during ltcs early life the difficulty was way too high... basically always a loss over power costs to mine, ... until the public gpu miners were release, and then magically the economics changed.
17:10 < phantomcircuit> gmaxwell, i wonder if artforz chose the parameters specifically such that he could gpu mine while everybody else was cpu mining
17:10 < gmaxwell> Yea, I don't think I've seen any convincing evidence art was doing that. But it does make sense.
17:11 < gmaxwell> plus art always was a bit sneaky like that. :)
17:11 < Emcy> artforz was/is the Switzerland of cryptocoins
17:11 < gmaxwell> he's still on irc you know.
17:11 < gmaxwell> just hiding from the bitcoin channels.
17:11 < Emcy> keeps his nose out of pointless shit, skims a tidy living off everyone elses pointless shit
17:12 < iddo> gmaxwell: iirc you said once that scrypt isn't the best choice (to resist ASIC) because it's not so efficient for GPUs ? is there another hash function that works better on GPUs and is hard for ASIC ?
17:13 < Emcy> isnt choosing any hash function that is x arch resisteant only really delaying the inevitable?
17:13 < gmaxwell> iddo: no function is hard for asics in a useful enough sense. I mean, what do you think gpus are made from? :P  At most you can do is try to reduce the specialization gap by making use of "all of the bison".
17:13 < phantomcircuit> <ecurrency> does any one have any idea why the latest version of bitcoind keeps stopping? Been trying to download the blockchain since yesterday and everytime I return I have to restart bitcoind (under ubuntu 12.04 (and 12.10))
17:13 < Emcy> in that if the coin succeeds then it fails cos someone will make hardware for it making it moot
17:13 < phantomcircuit> i've seen a number of people saying the same thing recently
17:13 < phantomcircuit> i wonder if there is someone running nodes that dont serve anything
17:14 < gmaxwell> phantomcircuit: they don't need to restart, they'll continue on the next block but they don't wait that long.
17:14 < Emcy> how simple a change would it be for the p2p to just pull a block each from all your connections in a round robin fashion?
17:14 < gmaxwell> phantomcircuit: presumably they are pulling from nodes whos operators shut them down because they get irritated by 1 second pingtimes.
17:15 < gmaxwell> which is what happens when someone pulls the chain from you and you have consumer DSL today.
17:15 < Emcy> as an interim. I got a feeling lots of nodes never finish bootstrapping which is a crying shame
17:17 < pigeons> this one of Artforz contributions to lolcust's forum a few months back now: http://dpaste.com/1493066/
17:17 < pigeons> I notice the forum isnt up at the moment
17:17 < maaku> phantomcircuit: is your clock synced?
17:17 < phantomcircuit> maaku, not my node :)
17:18 < Emcy> Colin Percival @cperciva 11 Mar
17:18 < Emcy> @shamoons I'd suggest talking to @solardiz about this -- my knowledge of how litecoin misuses scrypt comes mostly from him.
17:18 < Emcy> #iceburn #shotsfired
17:22 < Emcy> aw that quake bot story was fake
17:22 < Emcy> fucking internet
17:37 < jtimon> hehe, the bot world peace?
17:47 < warren> Emcy: Colin Percival is both correct and wrong about misuse.
17:47 < warren> Emcy: scrypt was designed for passwords.  scrypt in Litecoin is crappy for passwords.  It is good for fast validation
17:48 < warren> Emcy: we don't care about passwords
18:03 < Luke-Jr> Emcy: the goal would be to make it *just as easy* for CPUs/GPUs as it is for custom ASICs
18:03 < Luke-Jr> Emcy: but that has some practical concerns still
18:03 < Luke-Jr> you cannot make ASICs hard (relatively), so you just have to make something else just as easy
18:04 < Luke-Jr> now that SHA256d has lots of custom ASICs, it is essentially at that point
18:25 < andytoshi> because schnorr signatures can be used additively, is it true that multisig transactions would look identical to single-sig ones?
18:25 < andytoshi> and in particular, coinswap could be done without anything looking odd
18:25 < andytoshi> (if bitcoin used schnorr)
18:33 < gmaxwell> andytoshi: 12:05 < gmaxwell> petertodd: if we used schnorr than 2 of 2 multisig txn would be indistingushable from regular transactions.
18:33 < gmaxwell> yea, I'd made that same point before.
18:33 < gmaxwell> It's a big advantage for privacy IMO.
18:34 < gmaxwell> somewhere on my todo list I have actually implementing that for ed25519 to confirm that it works, and that nothing in ed25519 breaks it.
19:01  * andytoshis-logge is logging
19:07 < firepacket> wow this channel is pretty awesome. has anyone ever thought of a pow based on some kind of turing test? would it be possible?
19:08  * andytoshi-logbot is logging
19:08 < maaku> firepacket: sorry, that doesn't even make sense
19:08 < sipa> firepacket: that would require a human to validate...
19:09 < andytoshi> firepacket: the closest thing to a turing test used today are captchas, and i think machines are better than humans at that anyway ;)
19:09 < firepacket> yes it would
19:09 < firepacket> machines are better at solving captchas?
19:09 < firepacket> why would it be a problem? it would employ humans for a pay check
19:09 < firepacket> it would prevent consolodation
19:10 < sipa> what is'it' ?
19:10 < sipa> who creates the probkems?
19:10 < andytoshi> also limiting miners to humans with way too much free time would definitely cause consolidation
19:10 < firepacket> a computer would have to generate the problem
19:10 < firepacket> im not sure how
19:10 < sipa> which computer?
19:11 < firepacket> not sure
19:11 < firepacket> it could be generated based on information from the last block
19:11 < sipa> please think aout those things more first :)
19:12 < firepacket> it could also be generated using the chosen nonce
19:12 < sipa> i don't think you understand the problem
19:13 < sipa> the computer that generates the problem can trivially solve it
19:13 < sipa> as it knows the answer
19:13 < sipa> and there is no way to validate that a human-generated solution is right without knowing the real answer already
19:14 < firepacket> maybe validating other peoples tests could be the test itself
19:14 < sipa> come back when you have actual ways to deal with this :)
19:14 < michagogo|cloud> firepacket: Do you know what the properties that a PoW system needs to have are?
19:14 < michagogo|cloud> (I suspect not)
19:15 < sipa> not "maybe we could do something *handwaving* X"
19:16 < firepacket> i was just wondering if anyone had ever thought of it
19:16 < firepacket> i mean captcha still seems to work
19:16 < michagogo|cloud> ...no, because it can't be done
19:17 < firepacket> alright.
19:17 < michagogo|cloud> Yes, captchas are useful for many things
19:17 < michagogo|cloud> PoW isn't one of those things.
19:18 < Luke-Jr> captchas are useful for what exactly?
19:18 < firepacket> ensuring a human is present
19:18 < Luke-Jr> they seem to keep humans out better than bots
19:18 < firepacket> well, in reality it just spawned a captcha solving industry
19:18 < firepacket> that the bots use
19:18 < firepacket> but it still limits you to the number of people on earth at any given time
19:19 < Luke-Jr> I have to try like 4 or 5 times to solve captchas
19:20 < michagogo|cloud> Well, some captchas are better than others
19:20 < firepacket> googles are the worst
19:20 < maaku> firepacket: the point is i don't think you understand the purpose of a proof-of-work
19:20 < michagogo|cloud> I'm usually able to get recaptchas first try
19:20 < maaku> the intent is not to determine if there is a live human on the other side
19:20 < michagogo|cloud> (it helps that recaptcha is also somewhat flexible in certain ways)
19:21 < firepacket> maaku: what don't i understand?
19:21 < maaku> <maaku> the intent is not to determine if there is a live human on the other side
19:21 < firepacket> maaku: I know that is not the primary intent, but it could be helpful if the goal is to resist asics
19:21 < maaku> 1) the goal is not to resist asics
19:21 < maaku> 2) it's not the intent *at all*
19:21 < Luke-Jr> firepacket: that's a bad goal
19:22 < andytoshi> firepacket: why is asic resistance a goal?
19:22 < firepacket> or colsolidation rather
19:22 < andytoshi> i am genuinely curious as to the mindset behind this..
19:22 < firepacket> consolidation*
19:22 < firepacket> if all *humans* in the world were able to help verify bitcoin transactions and get paid to do so from anywhere in the world
19:22 < firepacket> how would not that help promote diversity?
19:23 < firepacket> it also gives us clear sides when the machines attack
19:23 < hno> humans very often fail to follow even basic rules.
19:24 < firepacket> i didnt say we should trust them
20:06 < Mike_B> has anyone thought about forking ripple and turning it into a decentralized forex exchange?
20:06 < Mike_B> like a really decentralized one
20:06 < Mike_B> i guess that'd be really hard to do though
20:07 < Mike_B> given the best way i know to decentralize ripple is to get away from consensus and go back to pow
20:07 < Mike_B> and then trades take 60m to confirm
20:08 < gmaxwell> Mike_B: you can make pow much faster than bitcoin if you don't care about decenteralization of the network... though never as fast as a non-anonymous system.
20:08 < gmaxwell> Mike_B: e.g. you control the difficulty to achieve a constant orphan rate, instead of constant time.
20:09 < gmaxwell> it's still slower because you need settling time because you don't know if there is a hidden majority.
20:09 < gmaxwell> whereas in a non anonymous network the majority can never be hidden.
20:11 < Mike_B> right
20:11 < Mike_B> i was thinking about how a decentralized exchange would work
20:11 < Mike_B> to stop the government from going after gox and bitstamp or whatever
20:12 < Mike_B> and it seems to me that this problem is just as hard as making a cryptocurrency where transactions don't take 10m to hit the blockchain
20:12 < gmaxwell> but you can't really do that in any case.
20:12 < Mike_B> unless you want trades to take place quickly
20:12 < gmaxwell> US is not a cryptocurrency.
20:12 < Mike_B> yeah of course
20:12 < gmaxwell> Creating a US crypto currency is almost certantly unlawful, and anyone issuing US crypto notes in the past has been shut down.
20:12 < gmaxwell> The regulatory point isn't the "exchange" it's the handling usd.
20:13 < Mike_B> i was thinking more about either trading with other cryptocurrencies, or with US "ious" a la ripple or what have you
20:22 < jtimon> Mike_B RippleLab's Ripple is not a very good ripple design (sorry for the redundancy)
20:22 < jtimon> Ryan's two-phase commit was actually scalable
20:22 < jtimon> I extended it to support atomic transactions with bitcoin/freicoin
20:23 < jtimon> and then we merged 2pc ripple with what I previously called "ripplecoin" (basically a ripple implementation on pow)
20:24 < jtimon> but they have several big design flaws even if you change their consensus for SHA256
20:24 < Mike_B> like what?
20:24 < jtimon> I just made a fast enumeration to pigeons this mornging...wait
20:25 < jtimon> they should have never replaced inputs/outputs with accounts
20:25 < jtimon> trust-lines don't have to be in the core, they can be simulated with regular market orders
20:25 < jtimon> and orders don't need to be in the ledger
20:26 < Mike_B> so why does the current setup cause problems
20:26 < Mike_B> like why is it a "flaw"
20:26 < Mike_B> the only problems i know about it come from how consensus claims to be decentralized but it isn't
20:27 < Mike_B> we had a good discussion a while ago about how various network topologies can lead to dishonest nodes winning even if the majority of the network is honest
20:27 < jtimon> having all the open orders in the blockchain requires more validations and bandwith
20:28 < jtimon> yeah, I'm talking about the inner structures, assuming you get their code and replace the consensus with pow
20:28 < gmaxwell> jtimon: is mostly talking about layers of the system I know nothing about. :)
20:28 < Mike_B> ah ok
20:28 < jtimon> instead of inputs and outputs like bitcoin
20:28 < jtimon> an address is actually an account
20:29 < jtimon> and all transactions from a given account must be sequenced qith an ugly seq field
20:29 < jtimon> with
20:29 < Mike_B> wait, so addresses aren't just hashed public keys anymore?
20:29 < jtimon> yes, what is missing is outputs
20:30 < jtimon> they have accounts in a ledger
20:30 < Mike_B> ok i'll have to take a look at it
20:30 < jtimon> there's no utxo
20:30 < Mike_B> yeah that's different than i thought it worked
20:31 < jtimon> tehre's a list of accounts and their balance in "each currency" (by currency meaning a 3 letter code)
20:31 < jtimon> and it's also a bad idea
20:31 < jtimon> imo
20:32 < maaku> Mike_B: i assume you're trying to answer the question "how can we create a Ripple-like system using bitcoin primitives?"
20:32 < Mike_B> jtimon: makes sense, i have to read about it more
20:32 < maaku> we (jtimon and maaku) have addressed this : http://freico.in/freimarkets.pdf
20:32 < Mike_B> maaku: i was attracted to ripple mostly because "consensus" has tx's confirming in a few seconds rather than 10m
20:33 < maaku> er, http://freico.in/docs/freimarkets.pdf
20:33 < Mike_B> but, i'm a bit disillusioned about it now because it has some bad flaws in terms of not being decentralized
20:33 < maaku> ok
20:33 < Mike_B> and i was in a trading channel and people were talking about decentralized exchanges and how they'll be the next big thing
20:33 < maaku> they get that by having a completely centralized transaction processing mechanism
20:33 < jtimon> there was also their negative to properly implement demurrage, ejem, interests
20:34 < Mike_B> but then i realized that making a "decentralized exchange," in which trades execute reasonably quickly, is at least as hard as making a new cryptocurrency that doesn't require blockchain confirmations
20:34 < maaku> yeah freimarkets is an architecture for doing decentralized exchanges using bitcoin protocol, but keeping as much data off the chain as possible
20:34 < jtimon> JoelKatz tried to convince me that it was impossible to have ripple transactions with interest bearing assets
20:34 < jtimon> and I tried to make him read my examples
20:34 < maaku> in fact, in real application we expect most applications to be off chain entirely, on private servers that nevertheless communicate with bitcoin-like messages
20:34 < Mike_B> maaku: how long does it take for a trade to execute?
20:34 < Mike_B> 10 minutes to be confirmed by the network * 6 confirmations?
20:35 < maaku> on-chain, yes, it's like any other transaction
20:35 < jtimon> Mike_B that depnds on the value of the trade
20:35 < maaku> off-chain as fast as the private server can process it
20:35 < Mike_B> yeah so if trades take an hour to execute, it's going to be pretty different from how normal exchanges work
20:35 < jtimon> if you trade 0.01 usd one block may be fine
20:35 < maaku> Mike_B: you're not going to get a decentralized platform like bitcoin to do high frequency trading
20:35 < Mike_B> well fair enough, i'll read it
20:36 < maaku> there are fundamental limitations in play here
20:36 < jtimon> well, actually trades are atomic, so you're not waiting to give something in return like in real payments...the value is irrelevant
20:37 < maaku> for things you need global decentralized concensus on, it'll take time to get global consensus
20:38 < maaku> however you can do things like high frequency micro trades using sequence numbers and transaction replacement
20:38 < Mike_B> yeah i'm trying to see the big picture of that
20:38 < maaku> but you run a serious counter-party risk if you don't wait for confirmations
20:38 < Mike_B> global decentralized consensus
20:38 < Mike_B> you basically are exposing the network to an election
20:39 < Mike_B> and somehow it elects an ordering of events
20:39 < Mike_B> and bitcoin is like using the "random ballot" voting principle
20:39 < jtimon> yeah the chain is a global serializer
20:39 < Mike_B> where 1 share of cpu time = 1 ballot
20:39 < maaku> Mike_B: the thing is for nearly all applications you *don't* need global consensus, particularly when you're talking about trading IOUs or stocks or other assets with an inherent trusted party
20:40 < jtimon> you just can't have p2p dollars
20:40 < jtimon> no matter what mastercoin or bitshares claim ;)
20:40 < maaku> but people instantly jump to "decentralize all the things!" mindset, leading to crazy inefficient orderbook-on-the-blockchain proposals and such
20:40 < Mike_B> haha
20:40 < Mike_B> yeah i was trying to decentralize all the things
20:41 < Mike_B> i think it's a fun academic problem though, at the very least
20:41 < Mike_B> i mean say you have a fleet of starships that are flying around in deep space, and they need to synchronize somehow
20:41 < Mike_B> well, there's no one absolute reference frame that tells you the "correct" ordering of events
20:41 < Mike_B> so the bitcoin approach would be to just pick one guy at random to decide (which is what pow does)
20:41 < Mike_B> i was curious if there were other approaches too
20:42 < Mike_B> consensus seemed promising but that flaw re: a minority of dishonest nodes ruining the network kind of kills it
20:42 < maaku> there are plenty other approaches that could work, but very few that are rooted in fundamental physical laws like proof-of-work is
20:43 < maaku> consensus could probably be made better.. but really it's the ugly child that nobody wants
20:43 < jtimon> hehe, here comes entropy...
20:44 < maaku> heh, i'll let Mike_B figure that one out on his own
20:44 < Mike_B> heh
20:44 < jtimon> in any case, Mike_B whatever the consesnsus mechanism
20:44 < jtimon> all nodes on the p2p netwoek must repeat the same validations
20:45 < jtimon> and you just can't have 10,000 nodes validating nasdaq
20:45 < jtimon> independently
20:45 < maaku> if you want fast transactions, there are ways you can have a centralized serializer without having to trust the central node in any way except availability
20:45 < maaku> see: open-transactions, freimarkets private accounting servers, and others i'm sure
20:46 < jtimon> 2PC ripple
20:46 < maaku> yes, 2PC ripple
20:47 < jtimon> http://archive.ripple-project.org/Protocol/Protocol?from=Protocol.Index
20:47 < jtimon> although that's kind of abandoned
20:47 < maaku> well, we did incorporate it into freimarkets
20:48 < jtimon> yeah
20:48 < jtimon> at least functionally
20:49 < Mike_B> hm ok
20:56 < Mike_B> alright, well thanks for the info
20:56 < Mike_B> i'll look into all that
21:04 < maaku> supposid proof of P=NP : http://arxiv.org/pdf/1208.0954.pdf
21:04 < maaku> dubious of a proof that's only 24 pages long
21:06 < andytoshi> maaku: well, a successful proof could be done with a single reduction, that could be short
21:07 < maaku> well, i mean dubious of a short proof to this problem ;)
21:07 < maaku> i'd expect the nearby inferential space to be completely exhausted by this point
21:10 < gmaxwell> it claims to be constructive.
21:11 < andytoshi> right before sec 2 he outlines the plan
21:11 < andytoshi> i'm having trouble understanding what he's saying..
21:26 < andytoshi> well, it does appear to be constructive, there are explicit algorithm listings everywhere
21:26 < andytoshi> but it is much too elaborate for my poor brain
21:34 < gmaxwell> after it said it was constructed I paged down to the end to see if it had benchmarks for solving some NP problem, even in terms of machine steps... and some boring np problem.
21:34 < gmaxwell> nope.
21:34 < gmaxwell> closed pdf.
21:35 < andytoshi> yeah, he went so far as to claim this was possible
21:36 < andytoshi> very last sentence, "Therefore, the algorithms proposed in the present paper can be used in practice to implement non-deterministic algorithms using deterministic imperative programs.
22:15 < Mike_B> how did this crap get on arxiv.org
22:21 < Mike_B> i'm gonna email the guy and ask him if he can efficiently compute preimages for SHA256 hashes
22:24 < andytoshi> Mike_B: arxiv does not verify or censor anything,
22:24 < Mike_B> andytoshi: to publish something to arxiv you need someone to endorse you
22:24 < andytoshi> yeah, but it's easy to get an endorsement in academia
22:25 < andytoshi> also if you had an account before they started doing endorsements
22:25 < andytoshi> i think you're free
22:25 < Mike_B> http://arxiv.org/find/cs/1/au:+Yakhontov_S/0/1/0/all/0/1
22:25 < Mike_B> heh
22:25 < Mike_B> his first paper was some other random thing
22:26 < Mike_B> he probably was like "can you endorse me for this algorithms paper?" and the guy was like "sure"
22:26 < Mike_B> second paper after that: "P = NP"
22:26 < Mike_B> i'd be pissed if i was the endorser
22:28 < andytoshi> lol yeah, i'd be annoyed
22:28 < andytoshi> tbh i'd probably never bother to find out :P
22:39 < gmaxwell> we find out later it was just created as an effort to manipulate bitcoin prices.
22:40 < gmaxwell> Mike_B: meh, give him an easy one, ask for an md5 second preimage of the all zeros md5sum.
22:41 < Mike_B> ha
22:44 < Mike_B> i wonder how security would change if you replaced the usual 10m blockchain confirm with the following process
22:45 < Mike_B> 1) set difficulty so that each miner can solve the problem in (some shorter amount of time, like 10s)
22:45 < Mike_B> 2) wait for N miners to have declared a solution
22:46 < Mike_B> (assuming N is large)
22:46 < gmaxwell> not progress free.
22:46 < Mike_B> 3) have those miners come to consensus
22:46 < Mike_B> "progress free"?
22:46 < gmaxwell> A large miner has an unfair advantage.
22:46 < gmaxwell> He will mine with his large hashpower, claiming to be M small miners.
22:47 < Mike_B> right but is that just the same 51% vulnerability?
22:47 < gmaxwell> and his partial results for himself, and then come to consensus with himself, and by keeping his partial results to himself he gets a superlinear speedup.
22:47 < gmaxwell> At the extreme the fastest miner always wins.
22:47 < gmaxwell> no its not.
22:49 < Mike_B> so say you have an expected solving time of s, and you need N miners for a quorum, so that s*N = 10 minutes
22:49 < gmaxwell> imagine the extreme version where every hash is a winner. I am 4gh/s you are 3gh/s.  Target is 40giga-shares to solve a block. How many blocks will you solve?
22:50 < Mike_B> what do you mean by "giga-shares?"
22:50 < gmaxwell> hashes.
22:51 < Mike_B> if every hash is a winner, doesn't that mean the target is 1 hash to solve a block?
22:51 < gmaxwell> I mean every hash meets your lower criteria.
22:51 < gmaxwell> I'm using an extreme example where the ratio of the lower criteria to the block criteria is very large.
22:51 < gmaxwell> In those cases mining becomes a race and the fastest miner ~always wins.
22:52 < gmaxwell> it's true when the ratio isn't large, but the advantage is somewhat less.
22:53 < gmaxwell> The method you're describing (breaking up the hashcash into N smaller hashcashes) is suggested in some hashcash papers to reduce variance, but it has the property that it's not progress free, which is why we don't use it.
22:53 < Mike_B> don't understand what you mean by "lower criteria" and "block criteria"
22:53 < gmaxwell> lower criteria is your "solving criteria"
22:54 < gmaxwell> Mike_B: in your own language set N to a large value like a billion.
22:55 < Mike_B> ok, and now what
22:55 < Mike_B> N is a billion, s is tiny, N*s = 10m
22:57 < gmaxwell> now you have some miners and one a good amount faster than the others. instead of sharing his partial solutions he hordes them (or at least hordes them unless he learns of someone else having too many of them).
22:59 < Mike_B> ok
23:05 < Mike_B> gmaxwell: i still don't see the issue, sorry
23:05 < Mike_B> you're talking about a case where a miner has a plurality of hashpower but not a majority?
23:07 < gwillen> Mike_B: I haven't fully understood the issue, but consider that _any_ scheme here you have a threshold of "N miners" can do something by consensus, there's something wrong
23:07 < gwillen> Mike_B: because one miner can always claim to be N miners for any value of N
23:07 < gwillen> so either the threshold is not necessary, or it's broken
23:08 < gwillen> I don't know which is the case here
23:10 < Mike_B> gwillen: i mean N verified proofs of work
23:10 < Mike_B> could be the same miner more than once
23:11 < gwillen> okay, N distinct proofs of work, that defeats my objection
23:11 < gwillen> I don't understand gmaxwell's well enough to know what it does to his
23:12 < gwillen> oh, I think I see
23:12 < gwillen> when it's a single share you need, everybody has a chance proportional to their hashpower, but it's high variance
23:13 < gwillen> if you need N smaller shares, you reduce the variance, but you also reduce the chance of people with low hashpower and increase the chance of people with high hashpower
23:13 < gwillen> if you need 1 share that takes a million seconds on average, winning is proportional to hashpower
23:14 < gwillen> if you need a million shares that take 1 second on average, the guy with the most hashpower will win every time
23:14 < gwillen> (if I'm thinking about this right)
23:14 < gmaxwell> Thats what I'm arguing, yes.
23:14 < gwillen> ok.
23:14 < gmaxwell> It's nor progress free. As you find shares you're making progress.
23:14 < gwillen> oh, interesting
23:14 < gwillen> progress-freedom makes it a poisson process
23:15 < gwillen> and only a poisson process has the right statistics for winning to be proportionate to hashpower
23:15 < Mike_B> gmaxwell, can you link me to a paper that describes this
23:17 < Mike_B> if you're saying one exists, anyway
23:18 < Mike_B> gwillen: what i'm trying to figure out is what the analogue of the 51% vulnerability is as N changes
23:18 < gmaxwell> I thought there was, but I'm not finding it at the moment, I'll look more after dinner. :)
23:18 < gwillen> Mike_B: as I understand it, you could indeed compute an analogous percentage as a function of N
23:18 < gwillen> but I don't know how off the top of my head
23:19 < Mike_B> gmaxwell: alright, well i'd much appreciate it if you do find anything
23:19 < gwillen> I could probably work it out but I have real work I need to be doing
23:20 < Mike_B> gwillen: fair enugh
23:20 < Mike_B> enouh
23:20 < Mike_B> god damn it
23:20 < Mike_B> :(
23:21  * Mike_B "enoughghghghghghghghghghghghg"
23:23 < gmaxwell> new lenovo keyboard?
23:24 < Mike_B> no, i just developed a neuromuscular disorder that lasted 2 seconds
23:26 < gmaxwell> It's been known to happen to bitcoiners. :(
23:27 < Mike_B> bitcoin-related finger tremor
23:28 < Mike_B> ok, so i see your objectionnow
23:28 < Mike_B> so you're saying the target is 0xfffff....
23:28 < Mike_B> so every hash wins, but you need a trillion hashes or whatever
23:29 < Mike_B> so if you have double the hashpower I do, you generate hashes twice as fast
23:30 < Mike_B> and i guess you're saying there's a strategy where you can hoard hashes and i, the poor unsuspecting sap, just broadcasts them to the network
23:30 < Mike_B> is that right?
23:31 < Mike_B> i guess i'm just not sure how you'd use hoarding hashes to have influence more than your hashpower
23:31 < Mike_B> you'd have to wait for me to pass some threshold and thend ump
--- Log closed Thu Dec 05 00:00:32 2013