--- Log opened Sun Jan 19 00:00:43 2014
05:23 < adam3us> petertodd: your time-lock stego for msc non payment msgs, why not make keys available, then time-lock decrypt is just a reactive fail-safe plan in event of blocking, the fast/normal path would be to reveal keys via msc only sub-net, or even reveal of previous keys (in a committed tx like way) with later msgs.  consensus is preserved, speed & cpu efficiency is improved
05:23 < adam3us> petertodd: (not that i think stego spamming btc network is a good idea, just because of the interesting theoretical question:)
11:57 < tacotime_> Hey guys.  I'm going on stealth transactions right now and I'm trying to wrap my head around them.  To fully anonymize, do you also need another protocol on top of it like coinjoin to anonymize inputs and outputs?
11:57 < tacotime_> *on=over
11:59 < sipa> tacotime_: don't confuse privacy with anonimity
12:00 < sipa> bitcoin doesn't provide anonimity at all, and stealth addresses nor coinjoin help with that
12:00 < sipa> both do improve privacy though, and in different ways
12:00 < tacotime_> Okay.
12:00 < sipa> but apart from that, yes, you likely want both
12:01 < sipa> stealth addresses helps preventing address reuse - you could do it without stealth addresses too
12:02 < orperelman> I agree with Sipa, on that - bitcoin doesn't provide anonimity
12:05 < tacotime_> Does it require a hardfork to implement (is the stealth address itself published to the blockchain)?  I understand the generation of a secret and secret sharing to generate a private key for the receiver to spend the funds at the sender's public address, but I'm fuzzy on the way things go on in the actual blockchain for this.
12:07 < sipa> stealth addresses don't require any change to the protocol
12:09 < tacotime_> OK
12:17 < tacotime_> The payee's address never actually receives inputs under this system, but is just used to generate addresses for a payer to send to?
12:19  * nsh wonders...
12:21 < nsh> could a payer and a payee use some kind of asymmetric diffie-hellman exchange to arrive at a payment address with the payee having enough information to construct the corresponding private key...
12:22 < tacotime_> (or, I guess, the address corresponding to the pubkey Q)
12:25 < tacotime_> Oh, OP_RETURN is used to publish the pubkey to the blockchain.  And you can't associate these with any given payments because they have no outputs other than fees.
12:27 < tacotime_> The reddit ELI5 is really helpful for this, heh.
12:35 < tacotime_> Neat.  Is OP_RETURN used very much at the moment?
12:39  * andytoshi-logbot is logging
12:43 < tacotime_> And, do I have it right? Okay, payer sends funds to some address generated from stealth address of payee, plus an OP_RETURN that publishes a secret (nonce).  Payee scans blockchain looking for a pubkey and secret that will allow him to spend from some address.  Payee finds said address, regenerates privkey from secret and pubkey, and then spends funds.
12:43 < sipa> correct
12:44 < tacotime_> Excellent.  Thanks.
13:26 < petertodd> tacotime_: all correct. An interesting question is if it would be better to at least have the option for the payment to be recoverable from information purely in the txout - it's plausible that in the future it'd work better once you can get a miner proof of a txout's existence.
13:27 < petertodd> tacotime_: I'm waiting on some Javacsript ECDH benchmarks FWIW before I make any kind of decision - it'd be nice if web-wallets like coinpunk could receive stealth payments entirely in the browser with at least some privacy.
13:28 < petertodd> tacotime_: On the bright side, javacsript SHA256 grinding is plenty fast enough to support stealth + prefixes.
13:29 < petertodd> adam3us: that's exactly what I suggested actually, which leads to an interesting question that BlueMatt(?) brought up: Can you prove to a third party that a given transaction does *not* contain a stego-encoded data packet? With SCIP it's easy to see how that could be possible in principle, but I dunno if it can be made efficient enough to be practical.
13:32 < nsh> you can always upper-bound the redundancy
13:32 < petertodd> nsh: ?
13:33 < nsh> the "spare" information in the transaction after you discount the necessary
13:33 < petertodd> nsh: oh, this isn't standard stego really: you're hiding encrypted data in random junk, so there's no measure of spare to talk about
13:33 < nsh> oh, hmm
13:33 < sipa> well obviously the amount of data that can be stored is limited to the size of the transaction
13:35 < petertodd> the real question is can you prove the execution of a timelock crypto sequence, which is something as simple as 10,000 SHA256 invocations, such that you can prove the end result cheaply to a third party that can evaluate that proof cheaply
13:35 < petertodd> it's obviously possible in principle, but how can it be made practical?
13:38 < nsh> perhaps in the future there will be a market for verify-farms, like compile/render-farms, that perform some computation and provide short/cheap verification proofs for it and its inputs
13:38 < petertodd> nsh: right, that's the "in principle" part :P
13:38  * nsh smiles
13:39 < petertodd> nsh: remember the Blub programmer principle: If Peter can't understand the crypto, it's obviously not practical.
13:39 < nsh> aye
13:39 < sipa> s/Pe/Pie/
13:40 < petertodd> lol
13:40 < nsh> hehe
13:40 < petertodd> and actually, in practice I use a scricter standard: If Peter can't teach the crypto to someone else, it's not practical
13:42 < sipa> it's not necessarily stricter; you often learn things exactly by trying to explain them to others
13:43  * nsh nods
13:44 < nsh> understanding-in-motion has a value above and beyond understanding-in-stasis
13:44 < petertodd> sipa: very true! in uni my smarter calculus classmates were always confused as to why my marks were so much worse than theirs given I was the guy always leading the study sessions :P
13:44 < nsh> like currency in some ways
13:45 < kinlo> blub programmer principle, does that require peter to be smart? :p
13:47 < petertodd> kinlo: the exact opposite :)
14:02 < gmaxwell> 21:45 < jron> slides from RWC if you haven't seen them yet: https://www.youtube.com/watch?v=Uh6erfE9HYE
14:03 < gmaxwell> (zerocash slides)
14:04 < nsh> the audio is almost comprehensible in that recording :)
14:12 < justanotheruser> What is the most interesting development in the cryptocurrency world?
14:12 < justanotheruser> Preferably something I haven't heard about
14:19 < maaku> Jeb donating 25M XRP to MIRI?
14:19 < maaku> kinda hard to guess what you haven't heard about
14:19 < maaku> also, #bitcoin
14:28 < nsh> wrt zerocash, i wonder if you could have some weird cypherpunk ritualized inaugeration event, with some carefully-selected and mutually-audited public parameter generation set-up, then everyone stands around it in robes looking solemn as the priests generate them and the machinery is then ritually destroyed
14:29 < nsh> some cross between the mimbari gray council and burning man
14:30 < sipa> #bitcoin-priests plz
14:31  * nsh smiles
14:32  * maaku joins #bitcoin-priests
14:32 < orperelman> lol
14:32 < maaku> make it happen nsh
14:32 < nsh> i'll start work on the liturgy
14:35 < justanotheruser> maaku: minecraft jeb?
14:36 < maaku> minecraft? no the guy who started MtGox and Ripple Labs
14:36 < justanotheruser> Is jeb magicaltux?
14:37 < justanotheruser> oh, reading the wiki. Looks like jeb sold it to magicaltux
14:38 < sipa> jed, you mean?
--- Log closed Mon Jan 20 00:00:41 2014