--- Log opened Sun Oct 27 00:00:48 2013
05:47 < gmaxwell> adam3us: thank you very much for the crypto-anarchy explination on the forum. It's good to have someone post a structured view, instead of responding to that kind of complaint with "omg fight opression!"
10:47 < adam3us> gmaxwell: some people seem to say hal finney is not pro crypto anarchy I saw, but from what I recall of old cypherpunks posts he has really calm principled/reasoned arguments for why privacy is essential, because you need cryptography to enforce what are actually legal rights strongly etc, and he implemented and operated the first PGP based anonymous remailer, and RPOW and he was i think the first PGP employee after zimmermann also, its very
10:48 < sipa> its very[...]
10:48 < K1773R> 512 line limit of IRC :P
10:48 < K1773R> s/512/512 chars per/
10:49 < K1773R> seems like a poor irc client :S
10:49 < sipa> i know few that deal well with overlong lines by default
10:50 < adam3us> its pidgin/linux hmm:... he (Finney) implemented and operated the first PGP based anonymous remailer, and RPOW and he was i think the first PGP employee after zimmermann also, its very hard to argue with things the way he puts them
10:51 < sipa> who is 'he'?
10:51 < adam3us> hal finney
10:51 < sipa> hmm, i don't understand
10:51 < adam3us> sipa: we were talking about explaining motivations for cryptographic privacy and I was saying i thoght hal finney does a nice job
10:51 < sipa> ah, by "hard to argue with" you mean "he is right"?
10:52 < adam3us> sipa: oh yes... i mean it sounds so reasonable and logical and non-controversial that the opponent is going to sound like an idiot or churlsih to disgree :)
10:52 < sipa> right, got it
10:53 < sipa> "hard to argue with" sounded like "so stubborn you don't want to argue with"
10:53 < adam3us> sipa: whereas as gmawell said most people say things like "beat state" and what not and then people with statist view lose sight of reason
10:54 < adam3us> sipa: nah - i never actually met him in person, but net the net he is the nicest fellow, least likely to get in a flame war, and actually doing a lot of privacy useful coding, so productive on the "cypherpunks write code" scale also
10:55 < sipa> scale also[...]
10:55 < sipa> wait, that is actually the end :)
10:55 < sipa> sorry, misparse
11:00 < adam3us> sipa: it was in relation to this bitcointalk thread https://bitcointalk.org/index.php?topic=318279.msg3419734#msg3419734
11:01 < adam3us> sipa: which was about chameleon hashes from greg but rapidly diverged into politics when someone said "what you want to forge a contract?? thats illegal" as a complete mismatch of understanding
11:01 < HM2> Snow Crash is an awesome book
11:01 < sipa> i remember why i stopped reading the forum :)
11:01 < HM2> The Baroque Cycle series is also great
11:03 < HM2> I can't remember if it was one of the BC books or Cryptonomicon that had the offshore data haven project
11:03 < adam3us> sipa: its almost funny, advanced math & bitcoin limits mixed with "doh" level newbies he he
11:04 < adam3us> HM2: i think that might've been cryptonomicon yes - very cool, like the pirate bay they are also jurisdiction hopping seemingly successfully for many years playing whack-a-mole, or havenco was the closest thing on the offshare oilrig/micro-nation-state
11:07 < HM2> this Chameleon hash thing sounds interesting
11:07 < HM2> it effectively turns the terms of the contract in to a key, right?
11:08 < adam3us> HM2: i love the line in snow crash where they run into the "president of the united states" and no one knows who he is or cares - sort of like the token "president" of somalia he's only president in his own mind as the state is a distant memory
11:08 < HM2> lol i don't recall that
11:10 < HM2> hmmm
11:12 < adam3us> HM2: so the idea which was greg's is that alice & bob can have a contract but keep the contract private, and bob cant tell other people the contract because he has the private key to could forge any contact
11:14 < adam3us> HM2: and yet if bob cheats and doesnt fulfill the contract alice can shame him by revealing the contract, it must be true because either that is the contract, or bob forged it; if bob forged it he's renegning on the contract and if he doesnt forge it alice has some proof that can convince others of what bob agreed to
11:15 < adam3us> hm2: its a bit like a non-transferable signature, except then either party could forge the contract, so alice cant prove anything to other people to shame bob and tarnish his reputation for cheating
11:16 < adam3us> hm2: so its forgeable, but only by bob some kind of mix of a hash function on one side and a non-transferable sig on the other; quite a nice building block
11:17 < HM2> How does the public remediate contract disputes exactly?
11:18 < HM2> If Alice is selling Bob something then either Alice can access the wallet and complete the contract or some public action + Bobs proof of contract can
11:18 < adam3us> HM2: they dont exactly, but if bob has a nice ebay-style rating there is a threat that alice can prove things to other people if he cheats, so he has an incentive to play nice
11:19 < adam3us> hm2: oh yes, the relation to the contract hash, is that in order to cash the payment, bob effectively demonstrates he has the hash, because he has to multiply the base address by it
11:19 < HM2> right so it's not a system to prevent you from being screwed over, like a reversal in a blockchain like system? it's just a reputation system
11:20 < adam3us> hm2: so he cant deny all knowledge as everyone can see the cash in his address and the tx which can be seen to hash from the contract to his address
11:20 < adam3us> hm2: yes its interesting because its simultaneously private (because its non-transferable) and yet there is still a threat of revealing the contact
11:20 < adam3us> hm2: contract
11:21 < HM2> right but if Alice sells Bob a TV and Bob claims he he never received it but Alice took the money, and Alice said Bob did receive it. what do you gain? it's still open to dispute
11:21 < adam3us> hm2: its unusual because normally its either non-transferable or its signed (non-repudiable) and yet like OTR you dont want non-repuiable signatures published or the other party to renege on the implied privacy
11:22 < adam3us> hm2: yes greg on the post mentioned if its a physical item or a matter of opinion kind of contract you might add an arbitrator
11:22 < HM2> what kind of contracts actually benefit then?
11:22 < adam3us> hm2: but if its straight up swap 1BTC for 150 LTC
11:23 < adam3us> hm2:  well that could probably be done atomically, but where you are relying on reputation and want contract privacy
11:23 < HM2> hmm
11:23 < adam3us> hm2: i mean the thesis is that private contacting parties should not have to tell anyone about the contents of their contract
11:23 < adam3us> hm2: so maybe alice doesnt know bob that well and doesnt quite trust him not to blab and show everyone else the ebook she bought because its racy
11:24 < adam3us> hm2: with normal signed contracts bob can prove that because alice signed her order, so bob can embarrass her
11:25 < adam3us> hm2: with chameleon hash based sig, bob cant really do that because bob can make that contract say whatever he wants (he can forge it), so no one will necessarily believe him as there is no transferable proof
11:25 < HM2> oh i'm slowly getting it
11:25 < HM2> so you have a transaction that can be shown by one party to be for anything
11:25 < HM2> and by the other for one specific thing
11:25 < HM2> is that about it?
11:25 < Luke-Jr> sounds useless <.<
11:26 < adam3us> hm2: so far thats standard non-transferable sig (opposite of non-repudiable sig), but the interesting new feature is that in addition to that, alice can actually prove bob accepted the contract so the power to prove things is asymmetric
11:26 < adam3us> hm2: yes
11:26 < HM2> big words like repudiable don't do well for me on Sundays
11:26 < Luke-Jr> lol
11:27 < adam3us> luke-jr: spoilsport - actually i think probably it should be the default sig in smart contracts / bitcoin script! you do want the mechanism to not have unintended side effects for the users
11:27 < HM2> oh
11:27 < HM2> so how does one construct a Chameleon hash with ECs? I understand basic EC algebra
11:27 < Luke-Jr> adam3us: a contract you cannot prove the contents of cannot be enforced, thus has no purpose
11:27 < adam3us> hm2: you dont want that should say
11:28 < adam3us> luke-jr: but you can prove it (alice can)
11:28 < adam3us> luke-jr: its just bob that cant
11:28 < Luke-Jr> adam3us: a one-sided contract is nasty enough already
11:29 < adam3us> luke-jr: but one sided properties are commonly in the users interests, because the merchant commonly has more power
11:29 < adam3us> luke-jr: eg payer anonymous ecash is more popular than payee anonymous (or double anonymous) its something analogous
11:30 < HM2> hmmm
11:30 < adam3us> luke-jr: the merchant should not be able to go rogue and out everyone''s ebook purchases or get hacked for the same info
11:30 < Luke-Jr> huh? I've never seen a person<->company contract that's in the person's favour
11:30 < adam3us> luke-jr: and thats a good thing?
11:30 < Luke-Jr> no, but I don't think reversing it is the solution :p
11:31 < adam3us> luke-jr: my point is it is in the users interests to have a chameleon hash signature
11:31 < adam3us> luke-jr: i dont think the merchant loses anything, he's receiving irrevocable bitcoin ecash
11:31 < Luke-Jr> I suppose in this case
11:31 < adam3us> luke-jr: its obvious he got his part of the contract
11:31 < HM2> Why not just take a hash of the contract and sign it. If Bob screws you you can show the world the contract and signature.
11:32 < HM2> err get Bob to sign it rather
11:32 < Luke-Jr> but it wouldn't make sense for long-term contracts
11:32 < adam3us> hm2: thats not a bad idea
11:32 < HM2> if Bob can't prove that there ever was a specific contract, what's the point in getting Alice to sign anything?
11:33 < adam3us> hm2: an interesting question.. maybe gmaxwell's argument is unravelling!
11:34 < adam3us> hm2: absent ecash component youd think bob needs to have an authenticated order or someone could tamper with it or change it
11:34 < HM2> I mean, you're basically after a 3rd party/publicly verifiable signature only when you know 1) the people involved, 2) and the hash of the terms. That just sounds like vanilla Schnorr signature to me.
11:34 < adam3us> hm2: but that could be more easily done, eg encrypt and MAC the message consisting of he order, and the bitcoin payment
11:35 < adam3us> hm2: and send it to bob, job done, no chameleon hash in sight
11:35 < adam3us> hm2: (and upfront demand bob sign the order details as a condition of paying him)
11:36 < adam3us> hm2: well you're also trying to prevent bob proving to third parties what his customers bought for their privacy
11:37 < adam3us> hm2: but it seems unecessary per above to use a chameleon hash, like you said get bob to sign it, then use integrity protection and encryption to prevent order tampering
11:37 < adam3us> hm2: i suppose that doesnt bind the contract to the receipt of the payment
11:37 < HM2> If Bob can't prove that Alice signed an order to someone else, what's to stop someone impersonating Alice and making orders?
11:38 < HM2> Alice can easily prove she did sign something, but how can you prove you didn't if Bob claims she did?
11:38 < adam3us> hm2: well on top of that alice is paying bob binding the hash to bobs payment address
11:39 < adam3us> hm2: alice is not revealing her identity
11:39 < HM2> I'm not following it at all
11:39 < adam3us> hm2: she is just binding a payment to  a contract pseudonymously, so she could prove afterwards that she made this payment, and bob knew the contract terms
11:41 < adam3us> hm2: i mean its like ebay a bit alice pays bob for the ebook, he doesnt deliver or the connection mysteriously 'fails" she gets annoye and posts at least evidence that she paid for the book, and tht bob accepted the money so also saw the order details and accepted them by taking her money
11:42 < HM2> ok
11:42 < HM2> I think I'm with you now
11:43 < adam3us> hm2: i think if we did it the other simpler way, where bob signs the order, bob could deny all knowledge
11:43 < HM2> If a seller has a private key 's', and you have some contract c = Hash(terms). the buyer can pay to c*sG
11:43 < HM2> the buyer then has to know c*s to claim the funds
11:43 < adam3us> hm2: eg no alice owed me $2 personally that payment is unrelated to this disputed ebook as the two re not bound together
11:44 < HM2> at any pointer the seller can publish "terms", c, and sG and prove it
11:44 < HM2> why the complexity?
11:44 < HM2> i got buyer and seller around the wrong way, but still
11:45 < adam3us> hm2: i think you need to bind the things together so bob cant start to tell tall stories about how the payment he did receive (he cant deny as the payment is public) was for something else
11:45 < HM2> how could he?
11:46 < adam3us> hm2:well if there was no chameleon hash sig, just a normal sig from bob on the contract, bob could say "yes, and she never paid for it", and "oh that payment was for something else, i lent her money the other ay"
11:46 < HM2> I guess it becomes public that Alice sends a payment to c*sG so privacy is lost
11:47 < adam3us> hm2: no that can be ok eg c is H(r=random, contact)
11:47 < adam3us> hm2: without either party disclosing r thats indecipherable
11:47 < HM2> but both parties need to know r
11:47 < adam3us> hm2: yes thats where the risk comes because then bob could disclose it and alice doesnt trust him
11:47 < HM2> the contract is really decided by the seller and accepted by the buyer
11:48 < adam3us> hm2: so with the chameleon hash bob can change c after the fact
11:48 < HM2> hmm
11:48 < adam3us> hm2: c is fixed but he can find new r' and contract' that still add up t c because he has the private key so its not very convincing when he says look this payment was for ebook1
11:48 < adam3us> hm2: and then alice says no thats a lie it was for ebook2
11:49 < HM2> right
11:49 < adam3us> hm2: and as everyone presumes alice doesnt have bobs private key, they presume bob is lieing
11:49 < adam3us> hm2: so it seems that it does hang together though its a bit complicated!
11:50 < adam3us> hm2: and if you find another way to do it that has the same properties u probably have invented yet another chameleon hash - apparently there are multiple mechanisms
11:52 < HM2> I'm not convinced
11:54 < HM2> If one party can say "no this transaction wasn't for X, it was <insert anything>!" then they lose the ability to prove it was for any specific thing and the other party can screw them by sending them something else
11:54 < HM2> the burden of proof is then on the sending party to prove they sent the right thing
11:55 < HM2> but if they refuse to do so there's basically no come back
11:55 < HM2> if they screw say 1% of people nobody will find it suspicious
11:55 < HM2> they'll just think the party that can't prove the specific contract terms is the shifty one
11:56 < HM2> even though that may not be the case
11:57 < HM2> surely it's just easier if both parties remain pseudo-anonymous to one another and all contracts are verifiable by all
11:59 < nanotube> <HM2> I can't remember if it was one of the BC books or Cryptonomicon that had the offshore data haven project <- it was cryptonomicon. :)
12:00 < HM2> it appears there are a lot of Neal Stephenson fans in bitcoin :P
12:01 < HM2> who'dve thunk it
12:02 < nanotube> hehe
12:04 < HM2> talking of contracts
12:04 < HM2> i foolishly sold a TV on ebay the other week and the guy picked it up and paid cash. I gave him a receipt but i never got one from him
12:04 < adam3us> hm2: if only bob can forge contracts, whatever alice says is true
12:04 < HM2> no problems yet but he could potentially screw me
12:05 < adam3us> hm2: because there should not exist two contracts unless bob is playing games
12:06 < HM2> I actually offered to accept bitcoin and he looked at me strangely
12:06 < adam3us> hm2: i mean technically bob could change the contract to something of higher value and alice cold then falsely claim that equally plausibly but thts against bobs interests so he probably wont do it
12:09 < adam3us> hm2: "surely it's just easier if both parties remain pseudo-anonymous to one another and all contracts are verifiable by all" yes but unfortunately bitcoin is not payer anonymous
12:10 < adam3us> hm2: otherwise alice could create a new identity for the transaction, as is bitcoin largely links all payments to the true name for anyone who touches an exchang or a physical delivery purchase ever
12:10 < HM2> it is if you establish 2 wallets and don't transfer between them
12:10 < HM2> you just need to figure out a way to create closed loops
12:10 < adam3us> hm2: yes, but hwere are you going to get the money from
12:10 < HM2> I don't know
12:10 < adam3us> hm2: i agree if you have two pseudonyms that are isolated you can do it
12:10 < sipa> obviously from the bitcoin internal economy
12:10 < sipa> without any exchanges involved
12:11 < sipa> (i'm only half joking)
12:12 < HM2> a blind token system wouldn't be that hard to introduce would it? in a new protocol.
12:12 < HM2> withdraw a coin, deposit it a few days later, it's blind so nobody can connect the 2
12:12 < adam3us> sipa: i'm yet to get paid in bitcoin... but yes for bitcoin to become more self sustaining it could have more internal commerce, and a high enough number of people using it, that its easy to do in person cash in / cash out.. eg if everyone knows someone else in their extended friends family with bitcoin
12:13 < adam3us> sipa: i mean to get past a point where it would run fine even if most exchanges went offline, there is a point past which that can happen i think
12:13 < adam3us> sipa: i wonder how far out... a few years?
12:13 < sipa> adam3us: i have no clue
12:13 < sipa> bitcoin may grow there rapidly, or perhaps it runs into scaling issues before we get remotely close to that
12:13 < adam3us> hm2: the anonymous mixes are a bit restricted by the size of the anonymity set
12:14 < sipa> or some other non-technical issue appears (legal?) that pretty kills interest in it
12:14 < adam3us> hm2: you're only as anonymous as the number of other users minus nsa plant traffic
12:14 < HM2> well that goes for current pseudoanonymity as well
12:15 < adam3us> hm2: one idea is to run zerocoin as an alt-coin... nothing but zerocoins
12:15 < HM2> zerocoin is too far outside my knowledge range
12:15 < adam3us> hm2: then everyone is a user (who uses it) but zerocoin is slow, bloated coins, and only one denomination (imagine paying $10k in 1c coins)
12:16 < HM2> i'm sure sipa could cook up something with hash trees
12:16 < adam3us> hm2: if you can follow chameleon hash argument u could grok it
12:16 < HM2> everything in bitcoin is solvable with another tree of hashes
12:16 < sipa> HM2: gmaxwell and petertodd are far more experts at using hashes for everything :)
12:16 < adam3us> hm2: funny u should say that committed transactions potentially hide a lot from the public are also just hashes
12:17  * sipa just implements
12:17 < adam3us> hm2: a different privacy model, where the only people who see who is paying who and how much are the people in the history of the payment (not the public at large)
12:21 < HM2> sipa, it's better for your sanity i'm sure
12:26 < adam3us> someone who knows something about hashes, trees, and tries ought to do something about bitcoin scalability; something concrete like a bip and an implementation
12:27 < adam3us> if bitcoin doesnt scale people will do something stupid offchain eg centralized micropayments with trust me bitcoin backing and when dust reaches $10k all bitcoin transactions will be offchain
12:27 < adam3us> that would be a very rubbish end to bitcoin ecash
12:33 < adam3us> you've got to wonder if accumulators could help also rather than trees, gives a kind of commutative hash tree so it can be rebalanced without changing the root hash
12:35 < sipa> hash(sort([h0,h1]))
12:36 < sipa> ha:
12:36 < adam3us> sipa: thats the effect you'd get but without the sort implication of needing the serializations available
12:36 < sipa> Please remember - don't hoard TestNet coins or try to sell them. TestNet coins are worthless, but useful. They are useful because they are worthless. If you will add value to them, they will be useless, therefore worthless.
12:37 < adam3us> sipa: lol
12:37 < sipa> (from tpfaucet.appspot.com)
12:37 < adam3us> sipa: a(h1,h2)=a(h2,h1) and a(h1,a(h2,h3)) = a(a(h1,h2),h3) etc
12:38 < adam3us> sipa: and what more you can prove hn is in the tree in O(1) space and work rather than O(log2(n)), thats the real bonus
12:38 < sipa> over my head :)
12:39 < sipa> anyone has a testnet address and wants some coins? i need a test
12:39 < HM2> i wonder if anyones managed to trick anyone in to buying testnet coins thinking they're mainnet coins
12:41 < adam3us> sipa: its simple really; just a=g^h1 mod n and to add another hash a2=a^h2 = g^(h1*h2) and repeat user2 can keep g^(h1*h3) (ie with h2 missing) then user 2 proves he's in the accumulator by showing A'=g^(h1*h3)^h2 == A ie A'^h2 = A
12:41 < sipa> oh
12:41 < adam3us> sipa: it only works because its in an RSA group so you cant compute 1/h1 its mod phi(n) which no one knows
12:41 < HM2> except bruce schneier
12:41 < sipa> got it
12:42 < K1773R> sipa: mz1iravK75FhNCyinytJhNCVqxmhFddohn
12:42 < sipa> bruce schneier can recite pi backwards
12:42 < HM2> ;)
12:42 < adam3us> hm2: is this the bruce schneier = crypto chuck norris meme :)
12:42 < adam3us> hm2: he does look a bit like norris
12:43 < HM2> except politically more agreeable
13:03 < adam3us> amiller: about byzantine general and Aspnes et al "exposing computationally challenged byzantine impostors" it occurs to me that bitcoin should not actually need to quite solve the byzantine general problem
13:04 < adam3us> amiller: because you dont really care which tx is first from a set of double spends, just that one is chosen, even at random; maybe that leaves some scope for improvement over the general version of the problem where they actually want to know the correct answer
13:18 < maaku> adam3us: i'm working on the hash-trie thing
13:18 < maaku> and yes, we need it for scalability, especially an address/script indexed tree
13:19 < sipa> that makes non-anonymous non-validating wallets that only maintain a balance and no transaction history indeed scale easily
13:21 < sipa> and with an txid-indexed index, allows validating clients to skip replaying history, assuming they trust it in an SPV way
13:24 < maaku> well, they can validate backwards from the current set, allowing a choice of security in the spectrum between SPV+ and full
13:25 < sipa> if undo data is available over the network, yes
13:27 < amiller> adam3us, so yeah the standard byzantine consensus requires a property like Unanimity, which says the thing chosen is the *one everyone wants* in some sense, but there are a variety of different options people commonly use
13:27 < amiller> one is that it only matters if everyone begins wanting the same thing
13:27 < amiller> another is that it only matters if there are no faults and everyone is honest
13:27 < amiller> another is that the chosen one with high probability has to be close to the plurality
13:28 < amiller> what it means for bitcoin is that if you allow the adversary to always influence the block
13:28 < amiller> a block with no tx's in it is a valid block
13:28 < amiller> so just consensus without some unanimity-like condition would mean you couldn't get a transaction included
13:28 < amiller> something that's bugging me is this concept of, what if you had a transaction that could only be accepted on an even 1000th block
13:29 < amiller> should bitcoin guarantee that you'll get it in quickly?
13:29 < amiller> if the (sub-50%) attacker gets to influence one out of a thousand blocks like that then it could keep that pathological transaction from even getting in
13:54 < maaku> sipa: I suggest commitment of undo blocks in addition to hash roots
13:54 < maaku> and, eventually, some way of querying that data over the network
14:05 < maaku> amiller: I would think that pathological case is the user's fault
14:10 < adam3us> amiller: so what about if the vote is just which transaction is included not whether a tx is included
14:11 < amiller> well there's that edge case where like, you basically can never prove someone *didn't* hear something
14:11 < adam3us> amiller: eg you mine on your own public key to gain voting rights and reward (as a miner) then you exercise those voting rights to say which transactions u like and if there are any dups the highest or th elowest wins
14:11 < amiller> so bitcoin's design is very tolerant of miners pretending they didn't hear a transaction
14:11 < amiller> you never get misbehavior for ignoring a message or playing dumb and not being aware of a tx, etc
14:12 < adam3us> amiller: yes but if the vote is which you like or prefer if there is a dup, an absense of a vote is an abstention, not a dislike
14:12 < adam3us> amiller: attackers can abstain all they like (in fact they're encouraged to)
14:13 < amiller> well if everyone includes all the transactions they've heard...
14:13 < amiller> i dunno, this is tricky, but basically even in the reference client there's miner policy about which valid transactions to include, sort by fee/priority etc
14:13 < amiller> so you don't your transaction in if the miners are all too full and they like others better than yorus
14:14 < adam3us> amiller: i believe its only because of the one-true-chain model to making near 50% attacks difficult (to eventually chose a winning fork if there is a simultaneous block)
14:15 < adam3us> amiller: yes but the concept of a single block as a unified winner is due to a random winner taking 100% of vote
14:17 < adam3us> amiller: if multiple people can vote its more like proportional representation, and all non-dup tx are in by default; and which dup is used is based on the highest (or lowest) voted dup... the vote is mostly for avoiding dups
14:18 < adam3us> amiller: and it doesnt even matter which dup to use, just a random one will do fine (even one chosen by the attacker)
14:19 < amiller> are you saying you'd merge votes
14:19 < amiller> like if i cast 1 vote for {A,B} and you cast 1 vote for {B,C} then that counts as 2 votes for {A,B,C}?
14:20 < adam3us> well the idea is include anything that is not a dup
14:20 < adam3us> so the vote is irrelevant unless there is a dup
14:21 < adam3us> if there is a space limitation take the n highest voted until you're full
14:21 < adam3us> it does have to be somehow consistently serialized however which is the hard part
14:24 < adam3us> adam3us: its only if there are votes (A,B1) and (A,B2) and (B3,C) you need to use the votes to see which of B1,B2,B3 triple spend to use
14:26 < adam3us> adam3us: hypothetically say voting rights are accumulated in one round, to be used during the next round to arbitrate which blocks to include; the hard part is to consistently arrive at the same view of transactions and votes everywhere; maybe the guy who wins the block reward, gets to define the serialization but must provide the vote proofs to justify his decision, or his block serialization is defined as invalid
14:29 < adam3us> amiller: "well there's that edge case where like, you basically can never prove someone *didn't* hear something" well if its in a trie or sorted binary tree you can efficiently prove he received it or not
14:30 < adam3us> amiller: and if you use committed transactions the miners and voters dont know what they're voting on as the sender, recipient and amount is hidden; then ll attacks degenerate to random DoS or blocking all tx but their own
14:35 < adam3us> committed transactions description is https://bitcointalk.org/index.php?topic=206303.15
14:37 < amiller> well committed transaction doesn't mean the transaction is valid
14:37 < adam3us> it does mean its not double spent however
14:37 < amiller> i think i would like the most if you were able to accept zero knowledge proofs of validity without having to learn anything else about the transaction
14:37 < adam3us> which is bitcoins main challenge
14:38 < adam3us> (the users validate the value from the spend history)
14:38 < adam3us> (which is not particularly spv friendly but there you go, maybe maaku & tries could help that)
14:40 < adam3us> amiller: i think you can almost do it (ZKP) - the thing that is eluding me is a blind proof of work where the work survives the unblinding operation and is encoded in representation problem format (like pederson commitment or brands credentials)
14:40 < adam3us> amiller: if you had that you could prove the number of confirmations on a coin > 6 without revealing the block
14:41 < adam3us> amiller: and with homomorphic values you could prove everything adds up before mining
14:44 < adam3us> amiller: there are a number of failed partially useful prototype blind proofs of works on this thread https://bitcointalk.org/index.php?topic=308009.msg3302321#msg3302321
14:46 < adam3us> amiller: and some related ones on this thread for secure offloadable KDF to harden brain wallets or encrypted wallets (that your attaker has the encrypted wallet file) https://bitcointalk.org/index.php?topic=311000.msg3341985#msg3341985
14:48 < adam3us> as close as I got was a "partial discrete log", however its really hard to get the work to survive unblinding like a close schnorr signature forgery (not an actual forgery but a number somehow close to a real one with an arbitrarily closeness metric)
14:51 < adam3us> amiller: "amiller: well committed transaction doesn't mean the transaction is valid ... adam3us: it does mean its not double spent however" i think you might be able to do build on that because committed tx prevents many miner abuses
14:55 < amiller> adam3us, how would you get fees for the committed tx
14:56 < amiller> because the committed tx still takes up utxo space it should have to be paid for
15:05 < adam3us> amiller: yes the commited tx has to include a clear text fee outside, which has to be sent from a clean/taint free address
15:06 < adam3us> in this way you can make tainted tx, fixing the taint problem (at least as far as miner influence)
15:06 < adam3us> curiously even if 99.9% of mining power dislikes and would like to block your tx based on who you are, how much you're paying or who you're paying it to
15:07 < adam3us> they are essentially powerless to do it, because you are using their power against themselves
18:56 < Luke-Jr> https://en.bitcoin.it/wiki/Myths#Bitcoin_makes_self-sufficient_artificial_intelligence_possible.2C_which_will_in_turn_become_self-aware_and_decide_to_exterminate_humanity
18:56 < Luke-Jr> ^ elaboration would be good
18:56 < Luke-Jr> and/or better arguments against it
19:24 < gmaxwell> heh. We should alsk MIRI to write the response to that one.
19:24 < Luke-Jr> MIRI?
19:25 < petertodd> Luke-Jr: lol!
19:25 < gmaxwell> Luke-Jr: http://intelligence.org/research/
19:25 < Luke-Jr> interesting, didn't know that existed
19:26 < petertodd> Luke-Jr: I am a bit worried though, because just the other day an industrial robots safety controls malfunctioned and I got a damn hard kick to the groin... not quite sure what that means
19:28 < Luke-Jr> hmm
19:29 < petertodd> Maybe it's actually Litecoin that becomes self-aware? Or PPCoin?
19:29 < Luke-Jr> then I'd be dead
19:29 < gmaxwell> https://en.bitcoin.it/wiki/Myths#Bitcoin_makes_self-sufficient_artificial_intelligence_possible.2C_which_will_in_turn_become_self-aware_and_decide_to_exterminate_humanity  revised answer.
19:29 < gmaxwell> maybe litecoin is self-aware but suicidal?
19:29 < petertodd> gmaxwell: ooh, maybe?
19:29 < Luke-Jr> lol
19:30 < Luke-Jr> gmaxwell: doh! Satoshi is AI!
19:30 < gmaxwell> (I was going for "Oh. Okay. ... hey, wait a minute! oh shit!" as the response to that response)
19:30 < petertodd> though if I were a self-aware AI, I'd want a PoW algorithm that was more general purpose
19:31  * petertodd is suspicious of NeuroCoin, the one with the neural-net based PoW algorithm
19:31 < Luke-Jr> I must have missed that one :o
19:31 < petertodd> lol, I'm sure if someone makes it it'll get adherents
19:31 < gmaxwell> petertodd: heheh. I'm imagining now an aprilfirst coin whos PoW is translating arabic phrases. :P
19:34 < petertodd> oh that's good...
19:34 < petertodd> or make one who's PoW happens to be running nuclear weapon simulations
19:35 < BlueMatt> brute forces encrypted information downloaded from *.nato.gov...
19:36 < petertodd> or maybe the wikileaks dump?
19:36 < BlueMatt> heh
19:36 < petertodd> prove your trying to crack the key?
19:36  * petertodd wonders if there's a known header that could be used to verify if a crack worked
19:39 < warren> As if this chat room wasn't already on the NSA watch list.
19:39 < petertodd> actually, that'd be interesting: the pow would have to be for you to prove you tried to crack it, using AES similar to how SHA256 works. Except actually cracking the key isn't something you make progress too, so you'd have to add a separate rule that an actual crack is worth a reward.
19:40 < petertodd> So force guesses to be done with a PRNG, and you need to show that your guess was generated by H(pubkey + nonce)
19:40 < petertodd> er, really H(merkle-root + nonce)
19:40 < sipa> warren: watch list?
19:40 < sipa> warren: i expect most of you to be nsa agents
19:41 < BlueMatt> petertodd: find decrypted data that is either the correct value or < target and use that as pow
19:41 < BlueMatt> sipa: you arent? you may be the only one
19:42 < BlueMatt> petertodd: or, better yet, decrypted data who's hamming distance is < target from the real header
19:42 < sipa> BlueMatt: i didn't expect you guys to be so honest about that
19:43 < petertodd> BlueMatt: doh, yeah, that's perfect
19:43 < warren> BlueMatt: compartmentalization
19:43  * BlueMatt goes to code that up for next april
19:43 < warren> who watches the watchers?
19:44 < maaku> warren: i do
19:44 < petertodd> sipa: ha, just the other day I had a TLA agent ask me if I wanted him to set up an interview with another TLA agent he knew. (serious)
19:44 < petertodd> sipa: said TLA agent said "I can't blame you" when I declined, pointing out my answer would have been different six months ago...
19:45 < sipa> wth?
19:46 < BlueMatt> what was the presentation at one of the blackhat-cons like a year ago that went into detail on all the info they were able to get on classified projects from linkedin?
19:46 < BlueMatt> it was really quite comical
19:46 < petertodd> sipa: snowden; it's caused a huge crisis of confidence within all these agencies, they've got a lot of people internally who are reconsidering why they work for the people they do
19:47 < petertodd> sipa: remember that things are sufficiently compartmentalized that it's not "in your face" that the stuff snowden leaked was actually happening, and they're good at putting people with politics more like mine in departments that don't have to know
19:49 < petertodd> sipa: nevermind the outright embarassment... a lot of what's been leaked shows these agencies *aren't* all knowing and all powerful - a big part of the draw at working in places like that is you're working with the best and brightest, but, snowden shows pretty clearly that you aren't
19:50 < sipa> k
19:50 < jrmithdobbs> petertodd: this is not particularly surprising
19:50 < sipa> i can't say i've sufficiently followed it all
19:52 < petertodd> jrmithdobbs: yup, money can only do so much. Something I think is especially striking is how it's been revealed that the NSA relies really heavily on highly scripted checklists so that very average techs can executed attacks without getting into trouble.
19:53 < petertodd> jrmithdobbs: or how the crypto-attacks they do have all involve what people have been suspecting all along, and don't involve math all that beyond what is know publicly
19:53 < jrmithdobbs> petertodd: you're assuming they're paying thatwell, and they're not
19:53 < jrmithdobbs> petertodd: even for the people creating said attacks
19:54 < maaku> hah they definately do not pay well
19:54 < petertodd> maaku: ha, personal experience?
19:55 < maaku> worked for the government / contracting, yes, spy agency no
19:55 < jrmithdobbs> petertodd: eg, the fake "outrage" over snowden's salary is hilarious to me, he was making a little above average for his experience on the west coast, not even that much above really
19:55 < petertodd> What I was told, is that the pay isn't much beyond private sector, but the benefits are very good, esp retirement benefits that really induce people to stay for their whole careers and stay loyal.
19:55 < maaku> if you're a civil servent yes
19:56 < jrmithdobbs> petertodd: those are just rationalizations people make, the benefits aren't that great and haven't been anywhere in the fed gov since reagan
19:56 < sipa> jrmithdobbs: what was his pay?
19:56 < maaku> after 25yrs you get full pension (low six figures), and then you usually 'retire' to a higher paying private job
19:56 < jrmithdobbs> sipa: like 125ish iirc
19:56 < sipa> 125k USD/year?
19:56 < jrmithdobbs> ya
19:56 < sipa> that's all?
19:56 < maaku> yeah you could snag that out of college in silicon valley, in the right industry
19:56 < jrmithdobbs> ya
19:57  * sipa hides
19:57 < jrmithdobbs> exactly
19:57 < petertodd> maaku: sounds like what I was told. Of course, you want to be careful with pay: you don't always want people who are pay oriented, especially in the short term.
19:57 < sipa> jrmithdobbs: wikipedia says 200k
19:58 < petertodd> Note how reports are snowden was paid a heck of a lot fairly early in his career.
19:58 < jrmithdobbs> sipa: meh, so he got the equiv of stock grants
19:58 < jrmithdobbs> good for him
19:58 < maaku> sipa: IIRC he filed an income tax for one year that was closer to 200k, but that was with additional income and was a one-time thing
19:59 < maaku> but nevertheless that's of course what the media quotes
19:59 < jrmithdobbs> maaku: ah
20:01 < maaku> the thing is these jobs are *very* stable. so they usually hire people below market rates, and they stay for the stability
20:02 < jrmithdobbs> ya so long as you can cope with the bs
20:02 < maaku> e.g., it's so expensive to get a security clearance that a contractor would rather hire someone that is already cleared than go through the process of getting someone new
20:02 < petertodd> maaku: exactly, people who like stability are least likely to jump ship and reveal secrets
20:03 < maaku> they're also more responsive to the b.s. legal arguments made to keep them from paying attention to this stuff
20:03 < petertodd> maaku: while the "hard to get new people" thing is a problem, because it means institutionally the system is biased to ignore warning signs
20:03 < jrmithdobbs> maaku: aye
20:05 < maaku> when the wikileaks stuff happened, we were being told that even reading 2nd-hand newspaper articles summarizing it would be violating clearances, even if it wasn't something you were cleared for in the first place
20:05 < petertodd> Air force pilots tend to have the same thing, because training is so horrendously expensive. I've got a family member who's a military pilot, and he said there's a bit of an inflection point during training where it changes from "drop them now because there's lots of expensive training coming up" to "don't drop them, because they've cost us a mint already"
20:05 < maaku> in other words "pay no attention or you will be fired and go to jail"
20:06 < jrmithdobbs> maaku: you got told that too? ;p
20:06 < jrmithdobbs> maaku: was the weirdest fucking conversation ever with my boss
20:06 < adam3us> blumatt, petertodd: i used that kind of search and if fail show closest miss for one of the offloadable kdf things
20:06 < jrmithdobbs> and i wasn't even working for the dod directly (not even contracted to them!)
20:07 < petertodd> jrmithdobbs: ha, good job. Maybe it's just a function of what kind of TLA people I meet, but I get the sense there's a lot of hatred for that crap, especially with snowden showing people are being lied to about the ramifications of what they're doing.
20:08 < petertodd> jrmithdobbs: (part of the discussion I had with that TLA agent was how I needed to know that the work I was doing would lead to ethical outcomes, and he agreed it's not a given)
20:09 < gmaxwell> petertodd: snowden leaks resulted in at least two people I worked with before quitting because they finally believed that the stuff they were working on was being used unethically.
20:09 < adam3us> sadly (for them) the IT security/crypto people in NSA even if now disgusted realizing the risks NSA were creating for society, if they quit are probaby somewhat unemployable as everyone will think they re an NSA mole or double agent, and nothing they say can be taken at face value
20:09 < jrmithdobbs> gmaxwell: oh you left?
20:10 < petertodd> gmaxwell: doesn't surprise me at all. possibly I was getting recruited because they've lost the smart people who tend to understand the bigger world - they need those people.
20:10 < gmaxwell> jrmithdobbs: (Juniper)
20:10 < jrmithdobbs> gmaxwell: ya didn't realise you had
20:11 < gmaxwell> jrmithdobbs: yea, I work for mozilla now.
20:11 < jrmithdobbs> oh nifty
20:11 < petertodd> adam3us: yup, and if you quit sooner rather than later, you miht at least be able to say "I didn't know, and quit the moment I did"
20:11 < jrmithdobbs> petertodd: but sooner was 2004ish
20:12 < petertodd> jrmithdobbs: yeah... though 2013 is still better than nothing
20:12 < jrmithdobbs> we've had 'good enough' evidence that far back.
20:12 < Luke-Jr> petertodd: if you didn't, you might get by keeping the job while you look and say you've been looking since you found out
20:12 < Luke-Jr> otoh, I guess anyone like that would be stupid if they didn't have savings to be able quit right away..
20:12 < jrmithdobbs> Luke-Jr: 9 years?
20:12 < petertodd> jrmithdobbs: see, if you quit now, and people hire you and you act like a paranoid fucker trying to build systems that insiders can't break, well, then maybe you'll keep your job :P
20:12 < jrmithdobbs> heh
20:13 < Luke-Jr> jrmithdobbs: oh, I thought we were talking about when Snowden disclosed whatever
20:13 < jrmithdobbs> Luke-Jr: that was the final confirmation that got everyone paying attention but first leaks re: this were in 2004
20:13 < petertodd> Luke-Jr: heh, the logic at these agencies is simultaneously "fire people who have financial problems
20:13 < petertodd> " and "distrust people who have no financial worries at all"
20:13 < Luke-Jr> jrmithdobbs: yeah, I never figured out why Snowden's stuff was such a big deal
20:14 < jrmithdobbs> Luke-Jr: i'm just saying if you truly took 9 years to figure out the leaks in 2004 were 'true' and you were inside the agency, you were obviously not very important or not very smart
20:14 < jrmithdobbs> so you're stuck there
20:14 < Luke-Jr> heh
20:14 < jrmithdobbs> pretty much how gov jobs work
20:14 < petertodd> Luke-Jr: unlike previous disclosures it was far reaching, and had a clear response from the US government showing it was totally true
20:14 < jrmithdobbs> not isolated to tech
20:15 < jrmithdobbs> Luke-Jr: his leaks were very important though because of exactly how much was confirmed at exactly the same time from the same source, with evidence for all the claims
20:15 < jrmithdobbs> not that it's doing anything.
20:16 < petertodd> jrmithdobbs: IMO it's doing a huge amount, people are quitting at the agencies, and the tech industry is responding with technical measures
20:16 < jrmithdobbs> petertodd: like?
20:17 < petertodd> jrmithdobbs: HTTP v2.0 is likely to have mandatory encryption for instance
20:17 < jrmithdobbs> noone's responding with crap that they weren't already responding with so there's a handful of people doing some good stuff but it's the same people
20:17 < petertodd> jrmithdobbs: people are finally getting rid of the PRNG that was shown to be backdoored
20:17 < jrmithdobbs> these are technical problems and some of them are very hard, after all
20:18 < jrmithdobbs> petertodd: after it was said to be during it's confirmation process, ya, how effective that was!
20:18 < petertodd> jrmithdobbs: yes, but it's not impossible to make widespread ubiquitous survailance impossibly hard
20:18 < jrmithdobbs> petertodd: don't you DARE hold anything about that situation up as an example.
20:18 < jrmithdobbs> including the response.
20:19 < petertodd> jrmithdobbs: indeed, but now that we *know* that the NSA does exactly that, people feel confident enoiugh to stop using it without getting called paranoid! that's a *huge* change
20:19 < jrmithdobbs> petertodd: no but recent events haven't done anything to advance the work
20:19 < jrmithdobbs> and if they do it will be years before practical applications come from it
20:19 < petertodd> jrmithdobbs: proof that you're not a paranoid nutter is a huge change - this stuff now seems reasonable
20:19 < petertodd> jrmithdobbs: practical has already happened, again, people have switched PRNGs as an example
20:19 < jrmithdobbs> ya well, i knew i wasn't, i guess it's nice for the general public to agree now but i wasn't exactly screaming from rooftops about the subject either ;p
20:20 < petertodd> jrmithdobbs: archive.org is one of many sites that have switched to always https, wikipedia too
20:20 < jrmithdobbs> ya but we've had the good people at tor, ssl obsv, etc working with people on that for years now
20:21 < jrmithdobbs> saying it took a completely povable verifiable catastrophy to get people to listen is not a good thing.
20:21 < petertodd> jrmithdobbs: yes, working on, but it's always had pushback and hasn't been all that successful, proof on the other hand is a big boost to those efforts
20:21 < petertodd> meh, people tend to respond to catastophies...
20:21 < petertodd> human nature
20:22 < jrmithdobbs> yes well, we've had proof thanks to ioerror/etc's work from inside syria/china and other place mapping these things for ~3-4 years as well
20:22 < petertodd> yes, and that's syria and china, this is local
20:22 < jrmithdobbs> petertodd: the fact that some actually mostly unrelated leaks convinced them is not exactly a good thing
20:22 < petertodd> this is also on mainstream news, time and time again 
20:22 < jrmithdobbs> petertodd: we've had the confirmation locally since about the time we had it in china ?
20:22 < petertodd> good or not, it's worked
20:22 < jrmithdobbs> (2004ish)
20:22 < jrmithdobbs> ;p
20:22 < petertodd> again, that's china, it's not the US!
20:23 < jrmithdobbs> no it's the us
20:23 < petertodd> how so?
20:23 < jrmithdobbs> us companies, writing software for us companies, covered by us patents, being sold for us dollars
20:23 < jrmithdobbs> how the fuck isn't it the us?
20:23 < jrmithdobbs> (cisco)
20:24 < petertodd> right, but that was being done in china. Snowden's leaks prove to US people that they are a target, that's a huge difference, and they did it in a way that got attention on a wide scale.
20:24 < jrmithdobbs> no
20:24 < jrmithdobbs> it was publically deployed in china
20:24 < jrmithdobbs> it was done in the us.
20:24 < jrmithdobbs> and this has been known.
20:24 < petertodd> Yes, publically deployed against Chinese citizens. That's the difference
20:24 < jrmithdobbs> the distinction is important.
20:25 < petertodd> Snowden made US citizens worried, and made it clear that what the NSA was doing was definitely something that should be illegal.
20:25 < jrmithdobbs> yes and they're not going to look to expand their markets?
20:25 < jrmithdobbs> in what world do you live in?
20:25 < jrmithdobbs> heh
20:25 < petertodd> People find it easy to assume they won't expand their markets locally - that's the difference between a normal person and someone with a touch of paranoia.
20:26 < jrmithdobbs> let's talk when practical results come besides discontinuing a prng that had been in use less than a year to any degree at all
20:26 < jrmithdobbs> and was never even available in most implementations of the spec it was in
20:26 < jrmithdobbs> can we talk about google still advocating rc4?
20:26 < petertodd> That PRNG was used in a *lot* of corporate applications, it's easy to discount how much it was used because public open source stuff knew better.
20:27 < jrmithdobbs> still.
20:27 < jrmithdobbs> now that we KNOW the traffic is being archived for statistical analysis?
20:27 < petertodd> RC4 still hasn't been broken fully...
20:27 < jrmithdobbs> it's been broken enough for the scale of collection we're talking.
20:27 < jrmithdobbs> since the early 90s
20:27 < petertodd> and unlike before, we can argue against RC4 on the "maybe it's actually fully broken" angle without being labeled as paranoid
20:28 < petertodd> we can also argue that opinions of people who argue otherwise should be discounted because we *know* that there are NSA plants out there
20:29 < jrmithdobbs> petertodd: ya and what about new software being implemented using things like cram-md5 because there's just no standards that point them at anything sane?
20:30 < petertodd> bbl
20:30 < jrmithdobbs> petertodd: when we start adressing real problems ... :(
20:38 < gmaxwell> jrmithdobbs: pre-snowden a lot of tech people were letting themselves believe that only ${muslim terrorists} were being targeted with this stuff, snowden leaks show that basically everyone is, including the leaders of allied countries. Compartmentalization kept most people from knowing the scope though they might have guessed they could easily convince themselves that they're paranoid.
20:39 < gmaxwell> jrmithdobbs: there was a massive shift in the IETF, all new standards for at least the next couple years will have people insisting— and winning in their insistance— on opportunistic encryption as mandatory.  The people who used to combat that stuff with "waa waa you're paranoid, and waa waa we need higher speed for commercial purposes" have lost.
20:40 < adam3us> gmax: right; conveniently now the paranoid are proven righ and get a wildcard to fix stupid problems and dismiss stupidity as likely sabotage (and there probably was and remains real sabotage at ietf committee, internal company design, code, NIST on nist side and nsa side and so on.
20:40 < gmaxwell> They stand at the mic and say these things still, but then people put snowden slides up on the projectors and those people sit down.
20:41 < gmaxwell> (This happened in both the webrtc working group and http2.0 working group in the last IETF, and I expect to see more of it in vancouver week after next.
20:41 < gmaxwell> )
20:42 < gmaxwell> adam3us: yea. exactly. The pro-crypto people have a free pass, and they're making some use of it.
20:45 < adam3us> gmax: updated chameleon hash thread with the ecdsa version, found and fixed a few problems, and realized its actually got an extra property - bob cant forge at all if alice reveals the contract
20:47 < adam3us> the other extremely nice thing about the snowden leaks and shaming of NSA for illegal dangerous to society and democracy behavior is it finally swept away the last of the 911 security vs privacy which was a break on privacy tech startup activity; anyone interested in privacy tech has the moral authority for the next decade, and thats a fantastic asset
20:49 < adam3us> it puts the shoe on the other foot; its no longer but wont criminals or terrorists hide; rather its like i was saying the types of tings hal was saying - the onus is n the opposer to explain why they want to bypass the mechanism for exercising of legally protected rights of freedom of speech & association
20:51 < adam3us> and the trump card is lost: they cant say trust us thats only used for terrorists; we know it was used for everyone, and even abused in clearly non-terror cases as an undisclosed source (with some fabricated cover story of accidentally stumbling upon the "crime") judges were not amused to find that, and already there are some decisions informing the accused
20:51 < petertodd> It's also a money thing too: the leaks have shown you can't trust US companies and US cloud computing services, which is already having a very real impact, for instance IBM hardware sales to China have dropped by about 40% already.
20:52 < petertodd> This kind of things sends money to companies that aren't as suspect, and in turn reduces US influence on standards and hardware.
20:53 < adam3us> all the political lobbying and real or faux reaction from euro politicians: i think they should just funnel  a few bil euro of their r&d framework towards end2end encrypt everything (the eur r&d budget is a scary thing - they spend billions and billions on academic / industry demonstrators and "applied research" most of which is crap)
20:54 < petertodd> A similar situation is with the ITAR controls on things like gyroscopes: at work I have to have an ITAR security clearance because we use missile guidance grade gyroscopes, and the system we're building is itself an ITAR controlled good. But the ITAR requirements are sufficiently onerous enough that it's making this tech available from non-itar-signatory countries; we'll soon be able to ditch a lot of our US-made equipment for Russian-made, and even Iranian-made in some cases. (!)
20:54 < petertodd> Push money into non-US hardware companies and you'll be able to buy fully-Chinese made hardware, and setup systems where both the US and China would need to co-operate to break it.
20:54 < adam3us> yes its a bad day to be a us cloud company, and probably a bad day to be  cloud company at all: it has shown the cloud cant be trusted, at least not without end2end encryption which only properly works for dumb storage without efficient FHE (tahoe-lafs is probably about as smart as secured cloud can get without fhe)
20:55 < petertodd> adam3us: yup. Trusted computing can change that of course, and as I said above, we'll hopefully get competing US and Chinese and others implementations of it.
20:57 < adam3us> i am wondering if chinese made cpus, chipsets and network gear is better in fact - the chines dont have anything against me, they're just interested in supressing domestic political agitation and the odd bit of industrial espionage; apparently stallman uses some chinese cpu laptop
20:58 < adam3us> everything i'm doing that i care about is open source and open spec anyway so the chinese have no interest and even seem neutral on bitcoin. vs the us is not to be trusted
20:59 < adam3us> petertodd: problem with trusted computing is trusting the manufacturer, though there are interesting things you can do with it, eg people were talking about a tpm secured remailer, its a toolkit for making arbitrary multi-party-computation
21:00 < petertodd> for sure, and it doesn't need to be better, just different. Even if the US and China were co-operating, it'd be easy to imagine situations where layering both techs would result in unbreakable systems. For instance, a US and Chinese PRNG may be broken by either, but in such a way that the combination can't be broken by either.
21:00 < adam3us> petertodd: which is really hard to do efficiently directly, whre with a tpm you can use remote attestation and tpm key management, trusted non debuggable agents, sealed disk storage and ring -1 protected ram to protect it
21:01 < petertodd> adam3us: I need to write up a paper on my thoughts on how to make useful open-source remote attestation capable gear; I do think it can be done with auditing schemes and careful hardware design.
21:01 < petertodd> too many projects...
21:01 < adam3us> petertodd: and the tpm's are going deeper, on to the cpu die, the embedded mmu, and i presume on the fly encrypted RAM (rather than the external mmu curtain on ring-1)
21:02 < petertodd> adam3us: yup, intels' next gen stuff is going to look like that
21:02 < petertodd> adam3us: basically I think you can make stuff that's just as secure form physical tampering, and make it in such a way that you can still take the device apart and verify the hardware did what it claimed to do.
21:03 < adam3us> petertodd: if one could do those things (open source hw tpm) or mix of chinese & us implementations in a strengthening enforcing way maybe could build a multi party RPOW with bitcoin inflation control :)
21:03 < petertodd> adam3us: for sure, and with such devices you can make my fidelity bonded banking stuff work in practice.
21:03 < adam3us> petertodd: that can solve many problems if the tpm can enforce hard to enforce issues, efficiently, scalably and without broadcast
21:04 < adam3us> petertodd: one generic problem is its hard to defend hw security where the enemy is the hw owner & operator, as DeCSS found out the harway
21:05 < petertodd> adam3us: yup, and with care, you don't need TPM's that are 100% unbreakable, just ones that have useful lower-bounds on how expensive it is to break any individual TPM
21:05 < petertodd> adam3us: right, and manufacturer and assembler should be added to that list too
21:06 < adam3us> petertodd: tpm-world is like a corporate firewall, if the nsa gets its nose inside there via a forged TPM signing key which is actually running in software what was supposed to be in hw, its a squishy insecure interior
21:06 < adam3us> petertodd: i am hoping instead we get fast enough FHE that people can build custom chips to do it in usable speed
21:07 < petertodd> adam3us: yeah, so the trick is build hardware where a third-party can take a whole production run of the hardware, tear some devices apart, verify they do what they claim to do, and sign the rest as authentic
21:07 < adam3us> petertodd: they clearly need something useful to do with 6.2bil transistors of the latest 2816 core amd offering
21:07 < petertodd> FHE?
21:07 < adam3us> fully homomorphic enc
21:07 < petertodd> ah
21:07 < petertodd> FHE can't do things like verify that Tor nodes aren't logging though
21:08 < adam3us> petertodd: it might be able to
21:08 < petertodd> how?
21:09 < adam3us> petertodd: there are some mind bending what ifs if you had it, eg could it do remote attestation, could it do ZKP of what code it ran (SCIP)
21:09 < adam3us> petertodd: not obviously, but maybe i am speaking
21:10 < petertodd> hmm... maybe actually a router could work, in the sense that you might not know what incomprehensible data packet sent to your peers was garbage padding vs. the real data
21:10 < adam3us> petertodd: i was thinking eg an instance generator that results in a FHE program running that knows its own keys and is bound to the program hash that is publicly verifiable like provably fairly generated
21:11 < petertodd> sure
21:12 < petertodd> I'm saying, imagine a model where we have some FHE program, that accepts packets from a set of peers (who sign all their packets) now the FHE program takes those packets, does some hidden computation, and gives a set of new data to send out again. You can't tell if the data is padding or messages, or if what came in was padding or messages.
21:12 < adam3us> petertodd: seems like it can potentially match TPM but purely virtually
21:12 < petertodd> Exactly. Now I don't think this will work if every peer in the system is compromised, but it could be useful if only a subset are.
21:13 < adam3us> but if the instance generator works, you can encrypt msgs for it and only an instance of the verifably fairly generated tor mix program could decrypt the data and sign the result
21:13 < adam3us> like virtual remote attestation
21:14 < petertodd> yup
21:14 < adam3us> i am suspecting such things maybe logically possible, but just to do anything basic is so ridiculously inefficient that people dont look at it uch
21:15 < adam3us> mike hearn gave a ref to some recent eprint fhe but its so hard to decipher what the actual perf is
21:16 < adam3us> they need a benchmark like decrypt one AES block
21:16 < adam3us> if it takes a week on a supercomputer we know to come back in a few years and look what they've optimized
21:16 < petertodd> huh
21:17 < petertodd> yeah, I can't claim to know too much about that stuff
21:17 < adam3us> its just to say, for it to be interesting to go read their stuff in detail, you want to know when they say "more efficient blah blah than x" what we're talking about
21:18 < adam3us> 1GB FHE keys and weeks per AES encryption
21:18 < adam3us> its all done at public key operation per individual and or or gate
21:18 < adam3us> that you have to build a virtual cpu out of
21:18 < adam3us> so its horrendous
21:18 < petertodd> yup
21:33 < adam3us> the other problem with FHE is because its software it can be snapshotted and rolled back and have its network inputs replayed
21:33 < adam3us> like a vm
22:26 < jrmithdobbs> gmaxwell: i'm so annoyed by the haskell documentation ... all of it by anyone basically ;p
22:26 < jrmithdobbs> it's all so academia focused
22:26 < gmaxwell> adam3us: there are some more FHE results claiming much higher performance. (e.g. an AES block in like two seconds)
22:27  * gmaxwell reads backwards
22:29 < gmaxwell> petertodd: yea, codecs I work on are technically munitions, but the ITAR regulations are effectively dead letters for free software in the US thanks to DJB.
22:29 < gmaxwell> (codecs which can code speech at or under 2400 bps are scheduled)
23:28 < realazthat> speaking of SCIP
23:28 < realazthat> I writing an interpreter/assembler/disassembler
23:28 < realazthat> for tinyram
23:29 < realazthat> then hopefully completing the backend
23:29 < realazthat> (I highlight "SCIP" :P)
23:36 < gmaxwell> realazthat: are your tools working yet? :P
23:37 < realazthat> the interpreter is working-ish
23:37 < realazthat> there are no doubt some bugs left, they should be usable in less than a week
23:37 < realazthat> same with the assembler
23:37 < realazthat> I haven't done the disassembler yet
23:38 < realazthat> I have to speak to Eran Tromer to work out some ambiguities I have
23:38 < realazthat> and get some test files
23:38 < realazthat> arithmetic works
23:39 < realazthat> I'll put it all on github
23:39 < realazthat> the LLVM backend is still stalled though
23:39 < realazthat> because it is huge infrastructure
23:40 < gmaxwell> I want to do a SIN-blinder at some point...
23:40 < realazthat> whats that?
23:41 < realazthat> something zero-knowledge?
23:42 < gmaxwell> SIN is the bitcoin passports stuff. E.g. provably throw away bitcoins and then use the proof as an expensive "identity" to get access to stuff (and if you spam your identity gets blacklisted)
23:42 < gmaxwell> The problem with SIN is that you end up giving a linkable identity to the services you use, plus they learn something about your finances by looking at the coin history.
23:42 < realazthat> ah and SCIP can help with that I assume
23:43 < gmaxwell> So the idea is that you run the SIN verification in zero-knoweldge and emit a unique ID which is just the hash of a signature of the service name.
23:43 < realazthat> and you want to see if you can write up the assembly for it
23:43 < realazthat> awesome heh
23:43 < gmaxwell> So the service learns that you have a valid sin, and they get a unique ID for their service that they can blacklist. but they don't learn which sin is yours, and two sites can't correlate their users.
23:44 < realazthat> cool
23:44 < realazthat> actually I had an idea similar to SIN
23:44 < realazthat> but not distributed
23:44 < realazthat> centralized
23:45 < realazthat> I thought that a major problem of FOSS games is that there is little to lose by hacking/spamming
23:45 < gmaxwell> it's also somewhat important to do this now when the SIN idea is not widely deployed... because you want your sins to be constructed in a way that their proof is as cheap as possible to turn into a ZKP.
23:45 < realazthat> the to-pay games have this advantage; so it would be nice for a service to take a deposit and identify ppl, so they are "perma banned"
23:45 < realazthat> but this is similar
23:46 < realazthat> anyway, I can make code available as early as tomorrow, but it would be buggy
23:46 < realazthat> ie. I am not *certain* it implements tinyram
23:47 < realazthat> because I haven't tested it on *real* tinyram
23:47 < realazthat> just what I gleaned from the spec
23:47 < realazthat> and there are several things I am not 100% sure about/found ambiguous
23:48 < realazthat> I'll let you know when there is something usable
23:48 < realazthat> I started this last week
23:48 < realazthat> after speaking to Eli and Eran
23:49 < gmaxwell> yea, I'm not in a super big rush, but I want to do it evenutally. I'd like to drive to some of this technology being usable for something in actual practice, I think sin blinding may be a good early application.
23:50 < realazthat> sure
23:50 < realazthat> mmm I should ask them about their tinyram tools, how ready they are
23:50 < realazthat> I mean the proof generator etc.
--- Log closed Mon Oct 28 00:00:51 2013