--- Log opened Sun Sep 08 00:00:17 2013
08:56 < gmaxwell> oh come on. I just actually looked at the random ecdsa curves in FIPS.. and sure, they're determistically generated... but the seed values are implausably high.
08:58 < sipa> ?
08:58 < sipa> veing?
08:58 < sipa> being?
08:59 < gmaxwell> e.g. for P-256r
09:00 < gmaxwell> SEED
09:00 < gmaxwell> =
09:00 < gmaxwell> c49d3608 86e70493 6a6678e1 139d26b7 819f7e90
09:04 < gmaxwell> the determinstic procedure is basically sha1(the seed) to generate a bunch of random numbers, pull out the parameters and check the curve order.
09:06 < gmaxwell> As least the prime is uses is the largest prime less than 2^256.
09:06 < gmaxwell> but the other paremeters could be freely cooked. :(
10:37 < HM> then Schneier is right
10:44 < gmaxwell> I think its even worse than if they hadn't done the "verifibly random" procedure. :-/
10:49 < HM> The way I'd do it is announce you're going to use the hash of the front page headlines of 12 internationally renowned newspapers ahead of time :P
10:51 < HM> Completely original I swear
11:05 < gmaxwell> nah, you have a bunch of resepected people commit to secrets. Then you hash the commitments and commit to in a bitcoin block. Then everyone reveals their secrets and you hash that them up with the block hash and feed to to some quite-expensive KDF.
11:05 < gmaxwell> What http://tools.ietf.org/html/rfc5639 also looks basically reasonable, if not quite as good.
11:06 < HM> 'respectable' is personal
11:06 < HM> using news events has the advantage that if the headline is "Aliens arrive on Earth and win poker tournament", you can be reasonably sure it wasn't rigged
11:10 < gmaxwell> HM: the reason to use the bitcoin step in my example is to make it computationally infeasable to cheat even if you think all the respected people potentially conspired.
11:11 < gmaxwell> all your requires is someone to control a couple newspaper headlines.
11:11 < gmaxwell> And the use of the people step in my example is to make it hard for someone to dismiss it as "oh nsa can instantly do sha256 so the bitcoin part is pointless"
11:11 < HM> not so, it also requires they be able to select 12 inconspicuous and consistent (with current event) headlines within whatever window you allow that hash to what you require
11:11 < gmaxwell> "respected" might also be hundreds or thousands of people.
11:12 < gmaxwell> HM: bullshit, if you only care about picking a few bits of the final version then you just need to control the phrasing or typesetting.
11:12 < gmaxwell> of a single headline too, assuming that you simply know the other ones.
11:13 < HM> sure...i guess, but if you only require a couple of bits then i think that weakness would be easier to discover in whatever algorithm you're using
11:14 < HM> i mean, if all even seeds were crackable then you're probably not going to pass inspection
11:15 < gmaxwell> who says? you're talking about embedding a property which isn't known to the public.. it might exist only in one in thirty two curves. You could easily pick that with your newspaper headlines.
11:16 < gmaxwell> besides, if you're really fixated on them you could just add them to my scheme too. :P
11:16 < HM> if it exists in only 32 curves, you'd need to fix, say, 251 bits of your 256 bit hash
11:17 < gmaxwell> HM: one in thirty two.
11:17 < gmaxwell> 1/32
11:17 < gmaxwell> as a rate.
11:18 < HM> *shrug*
12:01 < sipa> gmaxwell: they are perhaps optimized for certain weakness, but not more than a an exhaustive search can find
12:01 < sipa> as the sha1 in the deterministic procdure is assumed to be irreversible
12:02 < sipa> if there is a weakness that appears in a very high frequency of curves, a small number or a large number as seed doesn't make a difference
12:05 < HM> We used the 160bit sequence from pi offset N, where N is totally random. Promise.
12:07 < gmaxwell> sipa: sure. The distinction there is they could have chosen for weaknesses which were as rare as-say- 1:2^40 through this method without hypotizing enormous expenditures on the project.
12:07 < gmaxwell> (or strenghts, for that matter)
12:07 < gmaxwell> Effectively they've failed to show that they weren't selecting for additional criteria which might have made it stronger or weaker.
12:08 < sipa> right
12:08 < sipa> but they do show that whatever selection criterion was used, it cannot be faster than exhaustive search
12:10 < sipa> if there exists a weakness that is present in 1 in 2**128 curves, if the parameters were given without any alhorithms, they could have been found through a algebraic method
12:10 < sipa> and be vulnerable to it
12:14 < gmaxwell> Yes, having this scheme is better than just giving the parmeters and saying "here you go"
12:15 < gmaxwell> The scheme reduces the space of attacks, but at the same time leaves the space of attacks unnecessarily wide, which is curious since they did go through the trouble of acknowledging the concern.
12:34 < jrmithdobbs> nsa dhe/ec speculation/theories (don't mean that dismissively) or did i miss something else?
12:37 < jrmithdobbs> if the former, on a related note, i really like how it's starting to look like nsa really is decrypting rc4 ... between djb's recent paper and the recent snowden/etc publications ...
12:37 < jrmithdobbs> or at least, are close enough to being able to do so that it's worth storing
16:58 < gmaxwell> jrmithdobbs: you would be interested in http://eprint.iacr.org/2013/525
16:58 < gmaxwell> jrmithdobbs: I like it because the memory access pattern is constant, not only would it avoid leaking data via timing, but it sould be harder to optimize out than scrypt's memory accesses.
17:16 < amiller> that looks awesome
17:18 < amiller> "Catena supports client-independent updates by increasing the garlic or by turning salt bits into pepper."
17:31 < amiller> yeah i guess it makes sense
20:35 < maaku> holy cow, how did i not know about this channel
20:35 < maaku> are there logs?
20:36 < gmaxwell> I could send you them... though I don't know that they're that interesting.
20:38 < gmaxwell> You should be in here though. Mostly we discuss cryptographic rocket science in here, and stuff.. which may only have applications to bitcoin in the (far?) future.
20:39 < gmaxwell> basically lots of us have interest in things like zero knoweldge proofs, fancy and speculative crypto, changes to the bitcoin protocol which are not near term (or ever?) viable, etc.. and it was crufting up #bitcoin-dev which should try to stay on-topic for transparency reasons.
20:40 < gmaxwell> (and I was a major source of the offtopic stuff. :( )
20:48  * phantomcircuit puts on his wizard hat
20:51 < gmaxwell> phantomcircuit: Awesome. So the old proof of non-fractionality had the bank commit to a tree over its outputs, and allowing for randomized checking that it did indeed have the balance it claimed. And then a hashtree over balances, to show users that their balance was in the balances proof and that the sum of balances was <= the sum of funds.
20:51 < gmaxwell> This leaked information about the distribution of balances, ... with the right tree contstruction the leak could be reduced, but it still leaked.. and this is perhaps commercially interesting data.
20:52 < gmaxwell> So instead: You make a sum-tree over the funds you can spend, which commits to all your spendable coins and their sum value... and you commit to this in a super public way so that all customers get the same value.
20:53 < gmaxwell> oh @#$#@ I forgot it now darnit.
20:54 < phantomcircuit> gmaxwell, :)
20:55 < phantomcircuit> gmaxwell, is there already a branch which doesn't keep archived blocks?
20:56 < phantomcircuit> (or rather doesn't ever save the info at all)
20:56 < phantomcircuit> i'd like to see how well it works on my raspberry pi with it's terribly slow sd card
20:56 < gmaxwell> phantomcircuit: no. Needs fairly minor p2p changes to be correct.  (also, you will need to keep the recent blocks for reorgs, since their is no promise that you can fetch them again once the network has reorged... so not saving at all isn't really an option)
20:57 < phantomcircuit> gmaxwell, yeah the idea here is more of a poc than a production ready example
20:58 < phantomcircuit> it would be connecting directly to a node i control such that it can guarantee having 100% of the previous blocks for a reorg
20:59 < phantomcircuit> dont worry i wont be going around telling people they should all switch to my brilliant code
20:59 < phantomcircuit> :)
20:59 < gmaxwell> ohohoh right. so you sort all if your spendable outputs... and then assign contigious ranges of spendable outputs to each customer equal to their balances.   You build a tree which commits to the the output<->customer correspondance. Make it highly public. And then when customers connect you give them proof that they have coin assigned to them in this proof.
21:00 < gmaxwell> phantomcircuit: we've been talking about completely inhibiting serving blocks which aren't on the main chain. though it works now.. I mean for POC.. just go delete the files ... if nothing requests them it works (if something does it'll crash. :P )
21:01 < gmaxwell> phantomcircuit: so the service has committed to one set of coins and one set of user<>coin mappings the actual mapping is irrelevant, so long as there only exists one at a time and you're not giving a custom one to each user.
21:01 < gmaxwell> This way people do not learn how much funds the service has (except very roughly be the size of the tree), and they do not learn anything about the balances of other users, except a tiny amount where a single coin owned by the service has to be split between two users.
21:02 < gmaxwell> and users only learn the identity of coins owned by the service ~proportional to their own balances.
21:03 < gmaxwell> you could prefer mappings to use coins that were deposited to the user in question to— so in the case where it isn't behaving as a shared wallet (where you really don't need the proof) the proof teaches you ~nothing you don't know from the blockchain.
21:47 < amiller> i have a really good idea, it uses a lot of fancy generic zero knowledge though
21:47 < amiller> i've been trying to make an anti-outsourcing proof of work puzzle
21:47 < amiller> one that would make something like gpumax totally implausible
21:48 < gmaxwell> amiller: one problem I had thinking about that space is that I wasn't sure that I could really define outsourcing.
21:48 < amiller> the idea is that doing the mining necessarily requires knowledge of a secret key, such that that knowledge acts like a trap door that can be used to steal the reward somehow
21:48 < gmaxwell> yea, thats the best idea I've seen here. where you do signing in the innerloop of the POW.  But how does one then make the proof small?
21:49 < amiller> maybe if we're already doing lamport signatures then that's okay
21:49 < amiller> well yeah that's the best idea so far but it's also not neouhg
21:49 < gmaxwell> if there are few signatures then the communication overhead will not be great enough to prevent outsourcing?
21:49 < amiller> the problem is that just having that secret key doesn't make the trapdoor necessarily easy to use
21:49 < amiller> gmaxwell, imagine you need to do a signature to scratch off a single attempt
21:49 < amiller> mining requires lots of attempts and therefore it's hard to outsource that without leaking the key
21:50 < amiller> etiher way give me a pass for that part, it's the relatively easy part
21:50 < amiller> the thing is even without outsourcing and leaking that key, in any ordinary scheme that looks like hash cash but with signatures, it's not obvious that the centralized service provider can't just promise not to use the trapdoor
21:51 < amiller> if the service provider could steal from one client but then would be found out, then it would be easy to believe it's not in the service provider's best interest to do so
21:51 < gmaxwell> interesting: so don't pool the payments and then this is outsourcable. :(
21:51 < gmaxwell> actually I kinda have a solution for that.
21:51 < amiller> so what i really need is a kind of silent trapdoor that can be used to steal the reward and money if it's known, but that doesn't leave any trace whether it was used or not
21:52 < amiller> something like this would create the perfect environment of distrust, which is exactly what's needed for bitcoin mining resources to be decentralized
21:53 < amiller> i have a scheme in mind to do this but it sounds a bit ridiculous, i'm going to explain it anyway and maybe it can be simplified
21:53 < gmaxwell> OKAY
21:55 < amiller> the way it works is that a successfully mined block doesn't result in a bonus immediately, instead the bonus is learned later, and it's drawn from some lottery probability distribution
21:55 < amiller> the drawing depends on information in future blocks
21:55 < amiller> in particular the drawing is influenced by statements in some future block that looks like:
21:58 < amiller> "the block reward bonus from several blocks ago is X, which is drawn from probability distribution p, and either: a) the probability is p0, or a) I know the trapdoor private key, Y, in which case the probability is only p0/3, and with separately probability p/3 if it wins then some of that sneaks out a secret channel to pubkey Z"
21:58 < gmaxwell> This may be a sign I've read too many papers, but why not use a signature scheme specifically constructed to have this vulnerablity: http://link.springer.com/content/pdf/10.1007/s10207-005-0071-2.pdf#page-1
21:59 < gmaxwell> The idea is that you would have the work definition. like H(header) and then the payee would sign the header. Then the miner would UTXO hard work on it.. and if it's a winner the miner could use the weakness to change himself to be the payee.
22:00 < gmaxwell> E.g. UTXO hard mining and making it so the miner can steal the work... but they could still pass back unstolen shares to get credited.  The trick is making it so no one else can steal the block. :P
22:00 < amiller> i don't see how that prevents the service provider from basically promising that won't happen and preventing the client from detecting it
22:00 < gmaxwell> amiller:  no no UTXO hard work, and you make the client the theif not the provider.
22:01 < gmaxwell> amiller: you can solve your problem by making so that either side can cheat.
22:01 < amiller> i don't think that's enough because the client doesn't necessarily have to be paid out directly to his own key
22:01 < phantomcircuit> gmaxwell, pst pm
22:01 < gmaxwell> A lot of people spaz out thinking "omg what if the miner keeps the block for himself!" when talking about pooling. ... so make that possible.
22:04 < amiller> hm.
22:04 < amiller> well one problem with the key substitution vulnerable signatures is that the signature has to be deterministic, in order for it to be suitable for use as part of a PoW puzzle
22:05 < amiller> well maybe that's not exactly true
22:05 < amiller> hm
22:05 < gmaxwell> if the signature is before the POW hard part (E.g. it isn't the hard part itself) it doesn't have to be.
22:05 < amiller> yeah but if it's not part of the PoW hard part then it's really easy to outsource the rest
22:05 < amiller> to outsource the hard part i mean
22:06 < amiller> but anyway that's not a problem
22:06 < amiller> with this substitutable signature i mean
22:06 < gmaxwell> Right but the idea is that you make it so the solver of the hard part can retrospectively replace the address that it's paying to.  But I'm not quite sure if its possible to make it so that he and only he can do it while at the same time make it impossible for him to tie his hands.
22:06 < gmaxwell> (e.g. and prove that he's arranged it so that he can't do it)
22:07 < amiller> so one key about my scheme is that the trapdoor holder is able to reduce the probability distribution arbitrarily
22:07 < amiller> that means he can choose any small amount that avoids detection
22:07 < amiller> or for example, only skim from the 'rare' events
22:08 < amiller> which are less likely to be detected given a lot of samples
22:08 < gmaxwell> one way to do it would be with some kind of commitment scheme to decide who a block pays to. E.g. instead of the block specifying woh it pays to, you instead announce to the network the ID of a winning block and who it should pay to. And once thats propagated enough you announce the block. but then we need a blockchain to secure our blockchain, yo dawg.
22:09 < amiller> none of that prevents the mining service provider from promising to commit the winnings to the client
22:09 < amiller> it doesn't prevent the mining service provider from being detected doing that
22:09 < gmaxwell> Yep but its the user you have to worry about doing that.
22:10 < amiller> the mining provider doens't have to share the mining key with the user
22:10 < gmaxwell> What mining key?
22:10 < amiller> the mining provider generates his own keypair, and promises the user that anything won with a partiuclar public key will be transferred to him later
22:10 < gmaxwell> so in the simplified version I just suggested there is no keypair in the block.
22:10 < amiller> ah okay
22:11 < amiller> still it's easy for the service provider to make an equivalent promise
22:11 < gmaxwell> No.
22:11 < amiller> the service provider can create a sentinel tranasction or something
22:11 < gmaxwell> We should come to one mind for this.
22:11 < amiller> and say that the reward from any block mined containing a transaction like that should be given to the client
22:11 < amiller> that's a simple enforceable contract
22:11 < gmaxwell> I think you're stuck in thinking about solving it one way, and I have another direction that might be helpful for you. You can solve this by trying to make it so the provider can be non-faithful but as you note that sucks, so instead make it so the client can be non-faitful.
22:12 < gmaxwell> You make a block. It doesn't specify who it pays to.  When you find a block you announce "I found block XYZ and stake my claim for the key Spain."  The network accepts this, and when block XYZ finally shows up they'll only accept it when its paying spain.
22:12 < gmaxwell> (this is a toy version of the idea, I think it needs to be stronger)
22:13 < gmaxwell> now lets say you want to buy hashing power from people. You start paying them.. but every time they find a block, they keep it for themselves (and then go get a new identity)
22:14 < gmaxwell> since block finds are rare, this makes it uneconomical to buy outsourced hashpower.
22:14 < amiller> i can attack this by showing you a stronger contract.
22:14 < amiller> i don't just pay them for shares they're working on a block
22:14 < amiller> i pay them for shares that they're working on a block that has a watermark in it so that i know that even if they rededicate the block arbitrarily, they can't remove the watermark so i can still prove i was entitled to the reward
22:15 < gmaxwell> amiller: but the network has a rule that doesn't give a shit about your watermark: after all, outsourcing is an existential risk to the network.
22:15 < gmaxwell> You can detect that the user screwed you, sure. But their identities are cheap esp since a single user may only find a block once a year.
22:15 < amiller> yes but i don't think it makes sense to rule out any other form of contract enforcement
22:16 < gmaxwell> I suppose so, only outsource to people who give you the note to their home....
22:17 < amiller> so the way to prevent any form of contract enforcement is to make the trapdoor invisible
22:17 < gmaxwell> though I do wonder if we could make agreements like that generally unenforcable. (but we start delving into sociology and law and not crypto there. e.g. if the rules of the system expressly forbid its participants from outsourcing, any such contract would be legally unenforcable... so you'd only be left with kneecap busting security, which doesn't scale well)
22:17 < amiller> it shouldn't be externally discernible whether the trapdoor was used or not
22:21 < gmaxwell> so can you go back and tell me about the threat model we're trying to solve with outsourcing here? I think the interesting one is that I pay remote computing agents to mine malicious chains, and they prove to me that they're working on it. I think that one is actually unsolvable.
22:22 < gmaxwell> If our concern is just that outsourcing lets people do POW without even being able to tell that the work is malicious or not, then thats solved by UTXO hard work. They can tell. They might not care.. but they can tell.
22:23 < amiller> ok let me back up and clarify
22:23 < amiller> the threat model is outsourcing, we're trying to solve that by coming up with an anti-outsourcing PoW+reward scheme
22:23 < amiller> by outsourcing i mean
22:24 < amiller> a client that would otherwise choose to mine by paying $x per month for some probability distribution of rewards (not just expected value, more likely a lottery with somewhat high variance)
22:24 < amiller> instead takes an equal or better deal from a mining service provider
22:24 < gmaxwell> Why is this a threat?  I don't think we at all care about people pooling their payments, except that it lays the groundwork for the other two kinds of outsourcing I enumerated just now?
22:25 < amiller> if people can pool their payments then it's plausible that the rational trend is for one big mining datacenter
22:25 < amiller> which is an existential risk
22:25 < amiller> even if the mining datacenter can't do malicious attacks without anyone noticing, it's still a more central point of failure
22:26 < gmaxwell> if they are only pooling their payments but they still independantly check the validity and can not outsource that, then what is the threat?
22:26 < amiller> because taking over that datacenter (even if it causes alarms to sound) is easier than taking over a million gpus in homes
22:27 < gmaxwell> If they know (or could _costlessly_ know but choose to ignore it) the work is moronic or evil but are complicit then thats isomorphic to the users being complicit.
22:27 < gmaxwell> amiller: why would the data center have any control at all about anything important?
22:27 < gmaxwell> oh dear are you not aware of coinbase-only pooling?
22:27 < amiller> because it is in physical possession of the mining apparatus
22:27 < amiller> this is like the opposite of pooled mining btw
22:28 < gmaxwell> I know it is and I actually think you're confused now. :( or I'm confused. I'd like to fix this.
22:28 < gmaxwell> amiller: huh? no. utxo hard work prevents the datacenter from having the mining apparatus.
22:28 < amiller> no i don't think it does....
22:29 < amiller> but yeah definitely lets get on the same page before going back into the difficult stuff
22:29 < gmaxwell> lets imagine an alternative world where the mining is "Validation hard": the inner loop of the POW is doing all the work required to validate recent blocks and requires the user to have all the recent block data in order to pratically mine.
22:30 < gmaxwell> (ignore the details on how this is accomplished)
22:30 < amiller> sure
22:30 < amiller> that makes it less appealing to outsource *validation*
22:30 < gmaxwell> Now miners don't like the unstable payments...
22:31 < gmaxwell> so instead they have a deal with aggregators where they attempt to mine blocks that pays according to the aggregators instructions. The block is otherwise generated by themselves according to their own validation (which they have to do anyways as part of the pow)
22:31 < amiller> (this is standard pooled mining so far)
22:31 < gmaxwell> It's not.
22:31 < gmaxwell> they send the aggergator near miss solutions, and the aggregators use that to update their own records on who should gets paid what.
22:32 < gmaxwell> It's coinbase-only mining, which I think you're not familar with yet because it's not deployed yet. :) (well p2pool is a superset of it)
22:33 < gmaxwell> This differs from pooled mining in that the aggregator is not the source of the content of the blocks, and the miners can't be tricked into mining a cheating block without their knoweldge.
22:33 < amiller> okay fair enough, i guess that's not standard pooled mining
22:33 < amiller> it is basically p2pool though
22:33 < gmaxwell> because they only get the place(s) where the funds go from the aggregator.. the rest they invent on their own.
22:33 < gmaxwell> Yes, kinda p2pool makes the aggregator a distributed consensus. Though in what I'm describing it could just be a single person.
22:34 < gmaxwell> (p2pool has payout scheme flexibility limitations because the distributed consensus is inefficient and can also not maintain a bank account)
22:34 < amiller> ok
22:34 < gmaxwell> In any case, so where is the the risk in what I'm describing?
22:34 < amiller> there's none, that's not the outsourcing threat model
22:34 < amiller> that's A-OK, pooled mining is fine
22:34 < amiller> GPUMAX is the threat model
22:35 < gmaxwell> okay, so lets say that we take that model and say a GPU max shows up
22:35 < gmaxwell> He says, I'll pay you 110% to work on this mystery work.
22:35 < amiller> oh, crap
22:35 < amiller> i think i misunderstand gpumax :o
22:36 < gmaxwell> ah, were you thinking that GPUMAX was "cloud mining" where gpumax had the miners?
22:36 < amiller> yeah, exactly
22:36 < amiller> even ASICs aren't the problem because the asics are mostly easy to distributed in small packages
22:36 < amiller> "cloud mining" is definitely the threat i'm talking about
22:36 < gmaxwell> If so— I think thats a seperat thing which is worth solving!  I'd call that the "hosted mining" problem.
22:36 < amiller> hosted mining, ok
22:37 < amiller> because by economy of scale, it's conceivable that there's some ASIC set up that's cheaper if all the asics are in one big data center, so it's cheaper to buy a share of a hosted asic mining operation than to buy and care for your own asic
22:37 < gmaxwell> OKAY great. whew. Well thats also kind of an emerging threat now too... gpumax and things like it seem to be dead but there are a bunch of hosted mining things cropping up.
22:37 < amiller> name a couple?
22:37 < amiller> i guess i can search for "hosted mining"
22:37 < gmaxwell> ASICMINER for one.
22:38 < gmaxwell> They sell hardware too, but mostly only because of some .. uh. Non-technical mechenisms.
22:38 < amiller> okay, so.... anti-hosted-mining
22:38 < gmaxwell> Yes perhaps .. though this is far from clear: low level waste heat is better distributed.   but it's a risk simply because the labor of maintaining mining has some scaling, and there are lots of people who are super lazy and just want to pay and get goin.
22:39 < gmaxwell> coin.
22:39 < amiller> it's difficult because nothing stops someone from hosting their own separate lottery
22:39 < amiller> i actually think that higher variance mining makes more sense here
22:39 < gmaxwell> GIGAVPS, asicminer, "cloud mining" are all examples of hosted mining, and there will be many more. Buzzdave (megabigpower) and BFL have their own hosted mining offerings, etc.
22:40 < amiller> a mining operation that has a lottery interface on one side to its clients and does bitcoin mining on its other would really want low variance
22:40 < amiller> because it could easily promise more money than it can afford to payout
22:40 < gmaxwell> Basically even though the current technical scaling factors strongly discourage big datacenter operations, there are social factors that encourage them.  "derp derp I'm too dumb to run a miner, but I have money and want to make profit mining!"
22:40 < gmaxwell> amiller: you can just make your customers take the mining risk.
22:41 < amiller> right
22:41 < amiller> so that's where the trapdoor thing comes in
22:41 < amiller> i should make it so that any attempt to tie a customer's outcome to the outcome of a particular attempt at mining on the chain
22:42 < HM> the startup risk is large, if you get no customers then you've invested a lot for buggar all
22:42 < amiller> involves a trapdoor that makes it really easy to obscure the actual probability distribution of the chain's payout
22:43 < gmaxwell> HM: sadly preorders in the bitcoin world are ubiquitous, asicminer was entirely funded by selling hundreds of thousands of dollars in shares on the bct forum. They then rigged it up so they'd continue to own a ~majority of the shares. used the funds they raised to fab asics.. and put them online.
22:43 < HM> heh
22:43 < gmaxwell> HM: a lot of the other hosted offerings leave it to the customers responsibility for the mining hardware to show up at their door. Once its their they rack and stack and configure and start sending the user coins.
22:44 < gmaxwell> amiller: okay so your solution is basically to make it so that the hosting company can very easily hide their income, so they can steal from the miners.
22:44 < amiller> yes that's right
22:45 < gmaxwell> amiller: the challenge I see here is that the mining has an expected income, so the amount they can steal is bounded by that probability distribution model. I would also point out that _none_ of these services do any kind of proof at all that they aren't stealing, even though they could today, people don't ask for it.
22:45 < gmaxwell> E.g. ASICMINER could have easily built 50% more chips than they claim to have, and could be running them not as asicminer and no one would know.
22:46 < amiller> sure, i guess they only have shares
22:46 < amiller> my assumption is that a client pays a fixed price for a certain payoff distirbution
22:46 < amiller> like i pay for 10 shares some fraction of them should win
22:46 < amiller> but suppose there is a high variance option
22:47 < amiller> like one out of every hundred blocks wins an extra large amount of bonus or something like that
22:47 < amiller> then you can steal that bonus without raising much suspicion
22:47 < amiller> because it happens very infrequently anyway
22:48 < gmaxwell> Yea, I mean you could send shares to the cutomers to prove that their device was trying to mine in a publically validatable way. But no one asks for that today.  And yes, shares + high variance would make the miner's secure against cheating. (make the shares frequent enough that if the host was stealing more than a tiny amount of work it would be obvious)
22:48 < amiller> i agree no one asks for that today, but they should, perhaps in the future they will
22:48 < gmaxwell> but okay I get the idea. So if there were big bonus blocks periodically... that were blinded.. then the users couldn't tell if they were being robbed.
22:48 < amiller> after people start implementing encryption correctly etc
22:49 < HM> Don't datacenters typically charge by the amp? or say 1 U = X amps and then charge mostly on power consumption?
22:49 < amiller> yeah that's the idea
22:49 < gmaxwell> amiller: I'm ... very concerned they won't. but thats an aside. We can't cure humanity, lets fix the technology at least.
22:50 < amiller> yeah. also etc etc it helps promote general confidence in cryptocurrency to have technical answers especially to the big questions, like, does rational behavior inevitably trend towards centralization, etc.
22:50 < amiller> even if the technical answers to that involve things that aren't even close to implemented yet
22:50 < gmaxwell> (in particular, miners could be using BFGminer with their centeralized pools and BFGminer will prevent a pool from ever "eating its own tail": it will refuse to mine a fork against work the pool had it previously do. Totally kills a broad class of pool-op network attack. But basically no miners deploy bfg for this purpose (many use it but for other reasons))
22:51 < gmaxwell> amiller: a lot of users really have absolutely no clue about the security model, or they're wrong about it in frightening ways. E.g. they think that only the miners validate transactions, and that the miners can pay to whomever they want, however much they want.  E.g. a model where there would be no incentive alignment at all.
22:51 < gmaxwell> And I think this kind of misunderstanding is nearly the majority understanding or not too far from it. Yet they use bitcoin anyways because of, presumably, social proof.
22:52 < gmaxwell> (they also use other altcoins like ppcoin where the developer broadcasts checkpoints that select the network state)
22:52 < gmaxwell> (ppcoin is nominally POS but for "extra security" it has checkpoints broadcast in the network by its creator for ~every block which ultimately dominates the consensus)
22:54 < amiller> people also trust service providers unconditionally for all sorts of stuff
22:54 < HM> amiller, example?
22:54 < amiller> passwords in google docs?
22:55 < gmaxwell> right, part of the problem there is that you can get away with trusting paypal or ebay like that, they have conspicious assets you can send to jail if they cheat and regulation. But people also trust $anonymous_pool_operator because they don't reason about why it's okay to trust ebay.
22:55 < amiller> sure, so i admit that this is a construction of theoretical interest mostly
22:55 < gmaxwell> worse, since even when everything is vulnerable attacks tend to be somewhat rare.... when the shit does hit the fan they blame the specifics rather than the general practices. but oh well.
22:56 < gmaxwell> yea, sorry for the tangent.
22:56 < gmaxwell> We can't fix the social problems unless there are technical solutions in any case.
22:56 < amiller> i agree with 100% of the content of the tangent
22:56 < amiller> but yeah
22:56 < gmaxwell> I just get a bit depressed because even where the technical solutions exist we're not using them yet.. if ever.
22:56 < HM> amiller, the kind of people who put passwords in google docs are likely ignorant of the risk
22:57 < HM> or dismissive of the consequences
22:57 < HM> i wouldn't call that trust
22:58 < amiller> HM the way i think of it is that everyone who ignorantly or whatever is willing to make themselves fully vulnerable to a cloud provider or whatever, i just assume they've already done so
22:58 < amiller> and i effectively treat that as one wealthy entity
22:59 < amiller> the thing to aim for is people who are making rational risk-aware decisions
22:59 < gmaxwell> HM: people leave large amounts of bitcoin in blockchain.info mywallet, which is protected only by the users password, which can be bruteforced by bc.i (or anyone with access to the user's email), at >10 million passwords per second per gpu (and there is no salt, so bc.i or their hacker could attack all customers at once)
22:59 < gmaxwell> and BC.i wallets could be stolen at login time by anyone who injects JS in the pages.
22:59 < amiller> who will take the offer if it's cheaper and they have a good guarantee, in particular regardless of the 'systemic' risk of centralization which affects bitcoin as a whole but doesn't make you earn less
22:59 < gmaxwell> And yet they have hundreds of thousands of users.
22:59 < HM> bc.i don't need to bruteforce the wallets
22:59 < HM> they can just take them
23:00 < gmaxwell> HM: BC.i is a bit misleading about the threat model there, because the private keys are "only in the browser" ... until they give you some JS injection and take them or attack the password.  I mention the password attacks because even if you believe their misleading claims the password stuff is upheld.
23:01 < HM> yes, it's the same with MEGA with files
23:01 < HM> but tangents...
23:01 < gmaxwell> I mean I can go on all day there is countless amounts of misplaced trust.
23:02 < HM> well that's why the financial system being full of systemic risk is a *good* thing
23:02 < HM> everyone knows when it reaaally gets bad, something will be done
23:03 < HM> and nobody cares if it's good as long as everybody suffers
23:04 < HM> if the majority of people use blockchain.info then the impact on Bitcoin as a whole if the entire site vanished would be so huge as to effect us all anyway
23:08 < HM> It's kinda like email. Gmail has something like half a billion monthly active gmail accounts
23:09 < HM> some people don't even realise that email is a decentralised thing anymore
23:09 < gmaxwell> it's not even decentralised so much anymore. if you host your own email you have major major problems with anti-spam filters.
23:10 < HM> right
23:10 < gmaxwell> a lot of corporations have been moving to having msft or google host their domains for this reason alone... the other savings are just a perk.
23:11 < gmaxwell> (amusingly, I understand that Mike Hearn may have some personal culpability in this outcome ... :P )
23:11  * sipa whistles
23:11 < HM> lol what?
23:12 < gmaxwell> another googler. Though I don't know that sipa works on anti-spam. :P
23:12 < HM> ah bitcoin and bitcoinfoundy.org are both Gapps
23:14 < sipa> gmaxwell: i don't
23:14 < sipa> mike worked on anti-abuse
23:19 < HM> I'm fairly bitter about Goog giving personal domains with Gmail the brush
23:20 < HM> I don't really see how the loss of "@gmail.com" mindshare is harmful to their brand at this point.
23:21 < HM> Let's hope people hosting their own bitcoin wallet isn't as bizarre as running their own email server, or at least using their own domain for email, in future
23:23 < gmaxwell> we have some say in that future... if the only way to get good wallet software is through a website ... welllllll.
23:27 < HM> I don't use the desktop client anymore. I just use Andreas' droid app
23:27 < HM> there's no real reason either
23:28 < gmaxwell> yea, so what you're telling me is that bitcoin is doomed. :(
23:28 < gmaxwell> oh well.
23:28 < HM> ikr
23:29  * gmaxwell wishes they taught kant's categorical imperative in school.
23:32 < HM> gmaxwell, Wikipedia can't teach it to me now, so I think school kids would struggle.
23:33 < HM> something like only do something according to some rule, if you would like to see that rule become the social norm
23:34 < amiller> do what you want everyone else to do too
23:38 < HM> that's kind of vague
23:40 < sipa> heh, i knew that summary
23:40 < sipa> though not the name or whom it came from
23:45 < gmaxwell> the WP article is confusing.
23:45 < gmaxwell> It's basically suggested as a basis for morality, though you can use it more pragmatically than that.
23:46 < gmaxwell> The idea is that you shouldn't do something that would produce bad outcomes if everyone did it.  Even if you don't buy into it as a basis for morality (I dunno if I do), it has a lot of pratical usefulness.
23:47 < gmaxwell> For the case of a SPV wallet: "I'll run both a SPV wallet (on my phone) and a regular one elsewhere"  and "I'll run a SPV wallet only, if and only if I honestly don't have the resources to run a full node"  both pass the catagorical imperative .. in that if everyone follows the same rules things should be okay.
23:48 < gmaxwell> vs, I think "SPV is easier for me, I'll just run that" I think does not, because it suggests a world where basically google (sorry googlers, you get to be the deathstar this week) runs the only full node. :P Once too many people run SPV nodes you're actually at more risk if you run a full node, since you want to be part of the majority of users consensus.
23:48 < gmaxwell> and the whole set of economic incentives around bitcoin start to break down. :(
23:49 < gmaxwell> unless their breakdown triggers people to run full nodes. But I'm not sure that works.. being the one full node against the world isn't a position anyone wants to be in.
23:49 < amiller> depends also on how specific you're willing to make your rule, like "i'll behave altruistically, unless i'm amiller, in which case i'll behave selfishly"
23:50 < gmaxwell> amiller: hahah indeed. well I don't personally really buy CI as a basis for all morality. It only works for that in contrived models, but as you note only ones with finite levels of being contrived. :P   But I think it's a useful way to think about things that have externalized costs/risks.
23:51 < HM> I won't steal this ladies hambag because if everyone stole everyones hambag life would suck
23:51 < HM> oh wait...i don't have a hambag...
23:51 < gmaxwell> HM: even if you don't... a world where handbags were stolen very frequently would suck in a bunch of ways that would harm you.
23:52 < HM> i really did type 'hambags'
23:52 < gmaxwell> twice!
23:52 < gmaxwell> I corrected it in my reading!
23:53 < HM> it's almost 5am
23:54 < sipa> 6am!
23:54 < gmaxwell> for example, people might not carry handbags anymore, and then they couldn't shop at your local businesses. Or they might carry exploding handbags which sometimes exploded accidentally. :P CI is not the golden rule, it's a generalization of it in some sense. It basically proposes a rule that if everyone follows it then as a whole society playing a gigantic prisoners dilemma game, we all choose to not-defect without any coordination ...
23:54 < HM> if everyone went to sleep at 5am....
23:54 < gmaxwell> ... beyond the CI rule.
23:55 < HM> what if I advocate CI publically, but ignore it in private?
23:55 < gmaxwell> HM: it's fine so long as your rule is something like "I'll stay up to 5 am, but only if doing so doesn't make a mess for other people"
23:56 < HM> publicly* sigh
23:56 < gmaxwell> HM: that fails CI. It's not intended to be some maxim you hold people to (well, maybe Kant thought otherwise).  But it at least gives you a way to think about a consistent moral system, "if you were god", that helps seperate some of the subjectivity out of morality.
23:56 < HM> right
23:57 < HM> but it's not clear if everyone using SPVs would be bad. I mean it might force you guys to come up with a better solution that has many of the same advantages :P
23:57 < HM> and that would be good for everyone
23:58 < HM> likewise, handbag theft could spur on great innovation in other fashionable accessories
23:59 < sipa> hard to quantify those evolutions though
23:59 < HM> i don't see how you can apply CI without making a decision about what's better globally
23:59 < sipa> and certainly hard to ascribe them causally to handbag theft
--- Log closed Mon Sep 09 00:00:20 2013