--- Log opened Sun Sep 01 00:00:58 2013
00:52 < amiller> gmaxwell, why ban him?
00:54 < gmaxwell> because he's been going on and on forever in all the other bitcoin channels begging for money.
00:55 < gmaxwell> amiller: if you want to debate him, I'll invite him back. :P that would be fun.
00:55 < amiller> i missed the part where he's begging for money
00:57 < amiller> anyway i think of this channel as less regulated than -dev
00:57 < gmaxwell> yea, I just didn't want me (or anyone else) to lose another two hours debating with him.
01:01 < amiller> meh, don't ban him for that, just tell him he sucks
01:05 < gmaxwell> (weird, didn't work the first time)
01:11 < Luke-Jr> gmaxwell: too late XD
01:12 < Luke-Jr> gmaxwell: ever hear of Gross-Pitaevskii?
01:12 < Luke-Jr> that's what he's claiming breaks SHA-2 entirely
01:14 < gmaxwell> as I said, dudes a net kook. He's not only arguing that he can do quantum computation on a classical computer, but something more powerful than quantum computation. (If only you'll pay him 5 million dollars to hire the researchers to make it work)
01:15 < amiller> he must have adapted to just probe the room with buzzwords before making it clear he's asking for money
01:15 < amiller> i can't find the panhandling in my scrollbacks
01:16 < gmaxwell> I wasted about two hours on him in #bitcoin and, before I realized that he didn't think _he_ could do that but was just a "business guy", I even offered to pay someone a subsistence living (but not zillions of dollars) to work on BQP in P if he thought he could make concrete progress on it. But he doesn't want ramen, he wants rolex. :P
01:17 < Luke-Jr> he "only" wants 2000 BTC :P
01:18 < Luke-Jr> tempted to email these people on his R&D team and get their perspective
01:19 < gmaxwell> oh, he told me 50k btc.
01:19 < Luke-Jr> cute
01:19 < Luke-Jr> did he send you a budget plan too?
01:20 < gmaxwell> Luke-Jr: no!
01:20 < amiller> ah i found it, here's the grep jorash scrollback from #bitcoin https://gist.github.com/amiller/e6ecfd166a19c6fcecf2
01:20 < amiller> <jorash>	the only thing we disprove is the *hubris* of scientific *assumption*
01:21 < amiller> that's a good business plan tagline :o
01:21 < amiller> <jorash>	*excuse me, human assupmtion!
01:26 < amiller> so i've been working on this problem that's a really stylized version of bitcoin consensus
01:26 < amiller> it's meant not to resemble bitcoin closely but to resemble the standard distributed systems models as closely as possible, with the only difference being the lack of PKI assumption
01:27 < amiller> where in every standard setup there's n parties and they all know each other's names and can set up secure channels triviailly
01:28 < amiller> rather than consensus, i'm basically saying that the problem is to build a PKI from scratch by agreeing on a set of public keys to be included
01:29 < amiller> to make it as simple as possible just for the first go at this, i'm using pretty strong/unrealistic assumptions, like that there are exactly n players and everyone knows that
01:29 < amiller> also each player has exactly the same hashpower
01:29 < amiller> and no communication latency
01:30 < amiller> and that a puzzle of difficulty d takes *exactly* d units of time to solve for one party and costs nothing at all to verify
01:32 < amiller> i *think* that given all this, there should be a simple deterministic algorithm that does this, but i haven't been able to work it out
01:33 < amiller> then like the realistic versions that are randomized and more efficient would resemble bitcoin more
01:35 < amiller> so this is just a curiosity but it would help me make my argument that the real reason bitcoin is novel / caught everyone by surprise is that almost everything else assumes a PKI, not assuming a PKI is important but really difficult, and adding computational power assumptions is a suitable substitute
01:35 < amiller> i'm frustrated because i've tried to work this out for over a week and haven't gotten it :(
02:07 < gmaxwell> so.. N players, each has a marble factory that produces marbled at exactly 1 marble per second. The marbles can have things written on them, so they write their public key on them.
02:08 < gmaxwell> After X units of time, where X is some number which is large with respect to both n and the respective jitters of your clock, you expect to have ~X/n marbles from each player. For those you do, you've learned their pubkeys.
02:09 < gmaxwell> I don't think you can ever learn a cheating player's pubkey, but he can't fake it under your assumptions, I think.
02:42 < amiller> the problem is you might see ~X/n from the attacker, but someone else might see fewer
02:43 < amiller> basically the attacker gets to selectively pass his messages to some nodes but not others
02:44 < gmaxwell> oh, I see, his marbles might not be uniformly distributed to other players.
02:44 < amiller> i have a procedure that i think works but i haven't been able to explain why clearly
02:45 < amiller> basically you want to make sure that the attacker hasn't just produced enough signatures, but that he's gotten his signatures included in everyone else's signatures too
02:47 < gmaxwell> I can sort of wave my arms and start making a argument that if the honest clique is larger and they recursively include the marbles they've seen in their marbles (analogy fail) then the honest clique will be able to correctly assign keys.
02:47 < amiller> yeah that's about where i'mat
23:04 < gmaxwell> Anyone see anything stupid in this simple idea for oracle enabled instant transactions: http://0bin.net/paste/JCtxYmKrRXfGE6jw#M2b+70sG971rHdEmDKIDgz2PT/zlgSDa8zCTLHE1xbM=
23:07 < jgarzik> gmaxwell, identity key?  sounds like it would work great with https://en.bitcoin.it/wiki/Identity_protocol_v1  ;p
23:07 < gmaxwell> jgarzik: yup. I'd expect the oracle itself to be bonded.. and anyone could show that an oracle screwed up just by showing people a bogus extra signature.
23:08 < jgarzik> gmaxwell, BTW the SIN record was recently specified, and looks suspiciously like the merkle pattern employed by CBlock
23:08 < gmaxwell> Main ideas there are (1) precomputed refunds so you're never stuck if the oracle dies,  and (2) oracle doesn't need to understand or parse bitcoin transactions.. just a few lines of calls to ecc functions.
23:09  * jgarzik always thought about being N semi-trusted oracles
23:09 < jgarzik> then if one dies, no problem
23:10 < gmaxwell> Yea, you could do that too— but in this case, you don't even need it: before you pay into your escrow you've already computed your refund. The cost is the oracle will need about 512 bits of storage per user for the life of each short term key.
23:11 < jgarzik> gmaxwell, this scheme seems sane at first glance
23:11 < gmaxwell> Alternatively instead of the oracle remembering the first singing, you could reduce the oracle's storage to more like 256 bits (for anti-replay) if you made it parse transactions and be willing to sign unlimited transactions with nlocktimes past the expiration date.
23:11  * jgarzik finished reading
23:11 < gmaxwell> But I thought making the oracle see and parse transactions was kinda lame.
23:12 < jgarzik> nah, great anti-velocity measure
23:15 < amiller> is there anything this oracle is supposed to do that couldn't be built into the blockchain?
23:16 < amiller> i guess it's just like a green address
23:17 < gmaxwell> amiller: it's a "green address" anyone can have. Also: unlike a stupid green address it doesn't deanonymize your usage. (the key it signs with looks random to people who aren't party to the transaction)
23:17 < gmaxwell> (the oracle could tell it signed though, but presumably you contact the oracle anonymously)
23:18 < gmaxwell> you can do this same protocol using the counterparty of your transaction as your "oracle", but that only works if you know who you might be paying in advance.
23:19 < gmaxwell> this lets you lock up some spending money to be controlled with the help of some signer who is trusted to not replay, and thus pay instantly... but never transfering the funds to someone who could lose or steal them.
23:19 < amiller> i don't see why we don't just call the oracle a trusted or semitrusted third party
23:19 < amiller> since that's what it is
23:19 < amiller> but yeah that makes sense
23:20 < amiller> this is basically similar to an escrow transaction but for the purpose of immediate confirmation if the third party is trusted
23:21 < gmaxwell> amiller: sure, thats what they are.  There are engineering considerations that are being incorporated in this, e.g. I think that oracle can be <1kloc in straight C (except for the ecc signing code)
23:21 < gmaxwell> amiller: the precomputed refunds are somewhat special to the "immediate confirmation" case.
23:21 < gmaxwell> As they remove escrow risk, but don't break 'immediate confirmation' so long as they're far enough out in the future.
23:22 < amiller> i like that actually
23:23 < gmaxwell> that the oracle could only tell who he was signing for at most after it was all over also may reduce the motivation to try to censor the third party.
23:24 < gmaxwell> (and the small code size makes it easier to be confident that it's secure, and easier to run it in special remote-attest hardware)
23:25 < gmaxwell> (the remote attest hardware also protecting privacy, you could make it so the remote-attest has to be violated for the oracle operator to learn which transactions were the oracle's)
23:25 < gmaxwell> at least would damper curious operators somewhat.
23:28 < gmaxwell> amiller: for the green address case where you actually do trust the proximal sender, they should just be giving you a signmessage "I promise I won't doublespend txid 12345 with something not paying output 1abcde"--well_known_key  out of band. :(
23:28 < gmaxwell> mtgox wouldn't implement that for near incomprehensibly stupid reasons.
23:28 < amiller> well you'd also need to have set the prior transaction old enough
23:28 < gmaxwell> yep. Sure.
23:28 < amiller> like you have to arm the proximal spender with a lot of time in advance, even if you don't know its destination
23:29 < gmaxwell> but thats why this is better than the version where the payee is the 'oracle': the spender could reasonable do this in advance if it were a common practice.
23:30 < gmaxwell> (Magicaltux got it in his mind that recovering the y coorid from the x in ecc was patented. Nevermind that this was disclosed in the original ecc paper, that the patents related to it are specific to specific performance optimizations on binary fields, and that you can't validate the bitcoin blockchain without doing recovery because of compressed keys... but because of this he won't implement signmessage)
23:31 < gmaxwell> (and he's uninterested in most other green-address type approaches because they require something like the payment protcol where the proximal payee communicates with the paid, and his real motivation for "green" addresses was silk road whom he doesn't want to connect to)
--- Log closed Mon Sep 02 00:00:00 2013