--- Log opened Mon Oct 28 00:00:51 2013
05:35 < gmaxwell> petertodd: got any more transactions in dust-b-gone?
06:39 < TD> this channel grew quite a bit since I last saw it
08:56 < petertodd> gmaxwell: nope
12:00 < amiller> realazthat, not to distract you but consider looking at pantry too
12:01 < amiller> realazthat, it's a competitor of tinyram basically that was just opensourced https://github.com/srinathtv/pantry/
12:02 < amiller> http://eprint.iacr.org/2013/356.pdf
12:02 < TD> is tinyram even going to be open sourced? i thought it was, but that doesn't seem to be happening ....
12:03 < TD> ah i think i remember this paper
12:03 < TD> this is not quite a tinyram competitor
12:04 < TD> like most of these setups, it has to fully unroll all loops, can't do pointers and so on
12:04 < TD> calling it a "subset of C" is being generous
12:04 < amiller> that's true of all of them tinyram included
12:06 < amiller> there's probably a way around that, even, applicable to all of the above, it's just that no one knows how to make the security proofs work out in theory for unbounded computation
12:06 < TD> no, i am pretty sure the point of tinyram is it emulates a real CPU. the size of a loop can depend on the input to the program
12:06 < TD> whereas that is not true in pantry
12:07 < TD> obviously the computation still has to be bounded, but the program itself doesn't have to be fully unrolled ahead of time
12:11 < amiller> i'm like 95% positive you have to provide a bound on the number of steps at compile time
12:12 < TD> yes. you have to tell it how many steps to simulate when running the program (upper bound), BUT the program does not require all loop iterations to be constant. the program can terminate early, too. i think :)
12:12 < TD> basically what tinyram runs is much closer to "real" programs
12:13 < TD> you can also use pointers
12:16 < amiller> you can use pointers in pinocchio and pantry
12:16 < amiller> you can't malloc in any of them
12:16 < amiller> i know that pinocchio/pantry require each internal loop to be unrolled to some bound so that might be a significant benefit to tinyram
12:19 < TD> "pointers must be compile time constants"
12:20 < TD> that's a pretty tight constraint on the notion of a pointer
12:20 < TD> so far AFAICT tinyram is probably the easiest for mere mortals to work with. also AFAIK tinyram can be an entirely offline system, pantry seems to be online-only. that said, actually being available is a pretty big notch in pantrys favour
12:24 < amiller> shit, you're right, pantry is interactive (and single user) only
12:25 < gmaxwell> Why do you say it's interactive? that implementation is full of crazy stuff, but AFAIK it was using the same ZKP as pinocchio, the pairing crypto one.
12:26 < gmaxwell> TD: they'd made sounds that it would be open sourced, but they haven't done so yet. I haven't personally nagged about it because I just don't have the free cycles to do anything really cool with it myself.
12:26 < TD> yeah, same
12:27 < TD> why interactive - just a guess based on figure 1 of their paper. you may be right that it's not really a requirement, but the whole setup of their paper is very strongly client/server oriented
12:27 < TD> (figure 1 shows lots of bouncing arrows between verifier and prover)
12:29 < gmaxwell> yea, okay, I hadn't seen their paper, just the code. Without looking I'm going to guess that their "contribution" was some interactive thing, but their source code appears to include basically pinocchio with the missing parts restored. (the pinocchio source code is incomplete: they used some microsoft internal pairing crypto library which they didn't release)
12:30 < TD> ah yes
12:30 < amiller> pantry seems to be based on an earlier protocol they built zataar which is pinocchio from scratch
12:30 < amiller> i think they mostly only used the c-to-circuits compiler frontend from zataar
12:31 < gmaxwell> I spent 5 minutes looking at their code ... didn't get as far as trying it because of the insane dependencies.
12:52 < amiller> from the paper it looks like there's only one round of interaction because all the pcp queries are in a batch, but it is private coin so you wouldn't be able to trust someone else's transcript
12:52 < amiller> that's way lamer than pinocchio unfortunately
12:52 < amiller> so tinyram is better yeah
13:53 < realazthat> amiller: mmm interesting
13:53 < realazthat> I'll look at it
13:54 < realazthat> TD[away]: I am not sure if tinyram base code is ready yet
13:54 < realazthat> but it is supposed to be available
13:54 < realazthat> I am unsure on licencing
13:54 < realazthat> you can mail eli
15:22 < sipa> petertodd: maybe better here
15:23 < petertodd> sure
15:31 < petertodd> sipa: parasitic consensus systems are going to be interesting, it's so damn easy to make them SPV compatible.
15:33 < petertodd> w/ TXO commitments, it'd be worth it to mak sure such systems have nice blockchain interaction libraries, that do some validation while they get their data, and can spit out approprite fraud proofs.
20:23 < gmaxwell> Damn. I really wish all those OP codes weren't disabled.
20:24  * sipa enabled OP_TURINGMACHINE
20:25 < sipa> *enables
20:26 < gmaxwell> (per Murphant on the forum)  you could construct a transaction where alice pays to one of {alice in two weeks (nlock refund), alice + bob, bob but only if the signature provides a spv proof that a specifc transaction was mined}
20:26 < gmaxwell> such a proof would be pretty easy to construct with the splice operators. and not terribly huge by any means.
20:27 < gmaxwell> The idea being that alice pays bob to make publically disconnected transaction paying mallory. And if bob does, alice+bob sign and there is no linkage.  If bob tries to cheat alice times it out and gets the refund. If alice tries to cheat bob blows her privacy by revealing he kept up his side of the deal.
20:30 < gmaxwell> It only needs script powerful enough to verify a SPV proof. e.g. provide txid X  such that H(X|| non-public nonce) = Value in script, then a SPV proof that X was mined.
20:31 < gmaxwell> (of course with an AST script you wouldn't even reveal that the untaken branch of the script had a reveal-verifier, so no one could even tell that there was an airgapped payment made.
20:31 < gmaxwell> )
20:59 < gmaxwell> I wonder how awful it would be if we added a hashtree opcode.
21:01 < gmaxwell> inputs: [hash] [tree size] [position of hash in tree] [bunch of branch hashes packed up] ... and it emits a root.
21:02 < gmaxwell> it could be used for spv-secure cross chain transactions. With an extra opcode to check a header against the chain, it could be used to do proof of another transaction to allow those airgapped transfers.
21:10 < amiller> script powerful enough to do spv-secure is the basic idea of P2PTradeX
21:13 < gmaxwell> I know. (if you noted in that thread I wasn't all that excited about that, over what you can do with a simple two-hashlock transaction)
21:14 < gmaxwell> I suppose there is a hashlock version of the an airgap payment too.
21:29 < gmaxwell> amiller: whos ya daddy? https://bitcointalk.org/index.php?topic=318122.msg3431242#msg3431242
21:32 < amiller> whoa
21:32 < amiller> that's neatttttt
21:34 < gmaxwell> (I just made some tweaks to make it more readable)
21:47 < gmaxwell> petertodd: https://bitcointalk.org/index.php?topic=318122.msg3431242#msg3431242  < can we try this protocol sometime? I believe I owe you some coin. :)
22:20 < amiller> i guess i don't see what the point of it is exactly, if you had an ordinary trusted mixer to use you could send the thing to own fake address and then to bob
22:21 < amiller> i guess it reduces the cost of using a mixer that way
22:21 < amiller> er reduces the time by one transaction
22:21 < gmaxwell> amiller: there is no linkage in the transaction graph between alice and bob at all. They can be forever completely disjoint.
22:21 < amiller> although there are still transactions just one is an escrow
22:21 < amiller> they both interact with carol
22:22 < amiller> carol can use different addresses but this is true of any mixing service
22:22 < gmaxwell> e.g. no amount of coin-flow analysis would show coins from alice end up at bob.  Sure. But carol doesn't need to be trusted, and presumably carol keeps her funds seperated.
22:23 < gmaxwell> amiller: yea, compared to j-random-mixer the mixer cannot steal (which means that the mixer can be strongly anonymous, which makes it less vulnerable to coercion: log or we break your fingers)
22:23 < gmaxwell> compared to coinjoin the transaction flow can be completely disconnected.
22:23 < amiller> so i can use this to mix with myself
22:24 < gmaxwell> yea, you could be alice and bob.
22:24 < amiller> i have to trust the mixer for anonymity but yes it can't steal my funds
22:24 < gmaxwell> Downside compared to coinjoin is that you can't blind the mixer, it learns the linkage.
22:24 < gmaxwell> since the transaction pattern is identifyable your anonymity set can't be bigger than all the people using similar transactions, alas.
22:26 < gmaxwell> (CJ has the benefit that the transactions are not distinguishable, except to the extent that they have unusual values or numbers of inputs/outputs... disadvantage that it can't produce a truly disjoint graph ... though arguable this doesn't either unless widely used)
23:04 < warren> petertodd: jdillon wrote to me.  I'm still not convinced he's a real person.
23:06 < gmaxwell> I wondered for a bit if he might not be DPR until he seems to have showed back up.
23:07 < warren> huh.  He did indeed disappear for a while.
23:08 < Luke-Jr> is it PGP signed? :P
23:08 < warren> PGP signed and encrypted
23:10 < Luke-Jr> anyone can encrypt :p
23:10 < warren> yes, signed
23:10 < warren> perhaps someone else got his key with the $5 wrench attack
23:10 < warren> to ask me if petertodd and gavin are the same person
23:11 < warren> *Some parts of the above are a joke.
23:12 < gavinandresen> ok, ok, I'll fess up.  I am peter todd and jdillon and satoshi.
23:12 < gavinandresen> … hired an actor to PRETEND to be peter at the bitcoin conference....
23:12 < Luke-Jr> :P
23:12 < gmaxwell> hm. Have I ever seen gavin and PT at the same time?!?
23:12 < warren> gavinandresen: must be very confusing to keep all the opposing positions straight.
23:12 < Luke-Jr> gavinandresen: it'd be more belivable if the actor was playing Gavin <.<
23:13 < gavinandresen> warren: gets easier all the time, this project will make you crazy
23:13 < warren> gavinandresen: too late...
23:13 < gmaxwell> HAH
23:13 < gavinandresen> good point, you have to be crazy from the start to seriously consider getting involved
23:13 < warren> it turns out that gluing together coin control and watchonly isn't easy.
23:15  * warren quotes gavin on twitter.
23:15 < Luke-Jr> gavinandresen: wait, you're not warren too?
23:15 < gavinandresen> Luke-Jr: no.  But I am RealSolid.
23:15 < warren> wow, I knew it!
23:16 < gmaxwell> We knew that.
23:16 < Luke-Jr> gavinandresen: then you're slacking. I haven't heard from you as RealSolid in a few weeks.\
23:16 < gavinandresen> lol
23:16 < gmaxwell> Next time get brad pitt to play you in the conference too.
23:17  * Luke-Jr wonders if RealSolid ever finished his rewrite of SolidCoin/MicroCash/whatever-it-is-now
23:17 < warren> Luke-Jr: his exchange is too profitable to waste time on yet another coin
23:17 < warren> I expect one day everyone's deposits will be stolen when he disappears.
23:18 < warren> Or is arrested for some unrelated reason.
23:18 < Luke-Jr> heh
23:19 < warren> Would Bitcoin people sue for copyright infringement if he's ever identified?
23:19 < gmaxwell> Maybe RS is a social expirement I'm conducting in how disreputable a counterparty can appear before people will stop giving him their money. Current (revised) hypothesis is that it's unbounded.
23:19 < Luke-Jr> warren: doubt it
23:20 < gmaxwell> warren: poor guys has enough of his own problems.
23:20 < warren> Luke-Jr: I mean ... why not?  You sue people with deep pockets.
23:20 < Luke-Jr> although that'd be entertaining to see
23:20 < Luke-Jr> warren: he has deep pockets? :p
23:20 < warren> Luke-Jr: have you seen his exchange recently?  omgwtfbbq.  very clever how he attracted a ton of deposits and grew to a massive size overnight.
23:21 < gmaxwell> well technically a pocket with a hole in it has no bottom.
23:21  * Luke-Jr wonders if any MIT licenses have been in court as a plaintiff
23:21 < gmaxwell> warren: what did he do?
23:21 < Luke-Jr> warren: I actually didn't know he *had* an exchange
23:21 < Luke-Jr> actually, I vaguely remember him asking me if I hacked it or something a few months ago
23:21 < Luke-Jr> but I never bothered to figure out what exchange he started
23:22 < gmaxwell> Luke-Jr: yea.. :( I was shocked to find this out about a month ago when he started posting around telling people to change their passwords, I ... though he was trying to trick people into giving up their passwords or something.
23:22 < Luke-Jr> so what exchange is it? :o
23:22 < gavinandresen> RealSolid and Zhou Tong both have exchanges, supporting gmaxwell's hypothesis
23:23 < gmaxwell> Luke-Jr: mcxnow
23:24 < warren> gmaxwell: the "mcxfee" are sort-of like preferred stock entitled to a proportion of fees paid by customers.  You can buy and sell mcxfee's as yet another BTC/something pair on his exchange.  A portion of the mcxfees were sold to finance interest payments on deposits in the exchange.  Interest coming from that pseudo-equity sales made people feel that it isn't a ponzi scheme.  So in came a ton of deposits and lots of crypto/crypto pair tradin
23:24 < warren> g.
23:24 < gmaxwell> Luke-Jr: https://mcxnow.com/exchange/SC < how you can tell
23:25 < Luke-Jr> lol
23:25 < warren> The exchange is notorious for "excitement" of pump and dumps, and payban ... pay a fee to make someone unable to talk in the trollbox for a duration of time.
23:27 < warren> Hence, deep pockets.  It's a good time to identify and sue him for copyright infringement, as he has something to lose now.
23:27 < warren> and it would be very entertaining
23:27 < Luke-Jr> warren: afaik he ceased
23:27 < warren> Luke-Jr: how long did he infringe after notice?
23:28 < gmaxwell> https://coinjar.io/ < zhoutong,
23:29 < Luke-Jr> warren: no idea
23:31 < gavinandresen> I'm a happy coinjar.io customer, by the way-- cheapest / most convenient way to sell bitcoins here in Australia right now.
23:32 < Luke-Jr> >_<
23:39 < gmaxwell> Plus you get bonus chinese antiques absolutely free!
23:41 < Luke-Jr> this guy wants to do CPU mining on an average PC, using javascript throttled to not make the computer slow.
23:41 < Luke-Jr> am I being fair estimating longer than Earth's existence for $10 worth?
23:43 < warren> Luke-Jr: if enough people do it, Earth's habitable duration might shorten, complicating your calculation.
23:45 < Luke-Jr> I mean past existence.
--- Log closed Tue Oct 29 00:00:56 2013