--- Log opened Sun Dec 22 00:00:17 2013
03:36 < Emcy> ccc.de tls 1.0 1024bit rsa
03:36 < Emcy> and my browser doesnt trust the CA anyway :/
03:37 < Emcy> "Besides the usual digital infrastructure with Wifi, telephone etc., 30C3 will feature for the first time a pneumatic tube system, with the pretty name Seidenstrasse."
03:37 < Emcy> wut
03:39 <@gmaxwell> oh fun, something BIP32 like cannot be used with ed25519.
03:40 <@gmaxwell> or rather, not with standard implementations.
03:40 <@gmaxwell> they rig the multiplier so that the most significant bit must always be 1.
03:41 < Emcy> whats ed25519 again
03:50 < maaku> Emcy: DJB's crypto
03:51 < maaku> gmaxwell: can ed25519 be easily modified to make it work?
04:06 <@gmaxwell> maaku: the curve is fine, the constant time multipler implementation— no.
04:21 <@gmaxwell> y'all see the deck of cards secret key agreement thing? brillant.
04:24 <@gmaxwell> Take a regular deck of cards. Shuffle it.  Then split the deck in half. I give you one half, I take the other. Tada. We now have a ~51 bit shared secret— each card either ended up with you or me (we lose a bit from the definition of who is 1/0 being arbritary)
04:31 < maaku> gmaxwell: yeah i posted in the armory thread that a shuffled deck of cards makes a good inconspicous private key
04:31 < maaku> and 51 bits for a shared secret is plenty good enough for many protocols
04:33 <@gmaxwell> maaku: damn, and when I moved I think I tossed a box with like 50 decks of cards in it. (marketing swag from my prior employer, two corporate brandings old)
04:33 < maaku> if i ever worked border security, i'd shuffle any deck of cards I come across
04:33 <@gmaxwell> the shuffling isn't required!
04:33 <@gmaxwell> if you split a deck then just membership in one person's side or the other is the data! not the permutation!
04:36 <@gmaxwell> works with two decks too. e.g. take two decks shuffle and split. then membership in one side or another is the key though you lose a quite a few bits there due to dupes. (e.g. log2(3^52)=82.4 minus 1 bit for parity... three states, because both cards ended up on one side, or both on the other, or each person had a card)
04:37 <@gmaxwell> and the permutation doesn't matter.
04:39 <@gmaxwell> the bummer is that cards aren't printed on both sides. if they were inputting your key would be easy: just spew the cards out on a table and take a picture.
04:47 < maaku> gmaxwell: reverse theorientation of one deck
04:48 < maaku> or use different colored back
04:52 <@gmaxwell> yea, that gets you some more bits, but I guess it's not so hard to place all the cards face up for photographing.
04:55 < petertodd> also worth considering that there are tonnes of common games in card format that can be used for this stuff, IE magic the gathering cards have well-defined "multiverseid's" worth at least a few bits each, and a deck's contents can be turned into the key based on a sorted list of all such card ids
04:55 < petertodd> though the border guards would probably be wondering why a guy as cool looking as myself has MTG cards; I'd have to explain it was for a friend
04:56 <@gmaxwell> petertodd: the thing that I found neat was just that you could convey so many bits by which side got the card, and be completely robust to ordering
04:57 <@gmaxwell> it means that I can keep a stack of sealed cards in by bag. meet you, totally unprepapred, open the cards shuffle split, and we walk away with a relatively easily entered shared secret that doesn't look too conspicious
04:57 < petertodd> gmaxwell: for sure, what's neat about other card games is you can pull off the same trick without even having a oddly half-empty deck
04:57 < petertodd> gmaxwell: you're use-case is probably more practical though (!)
04:58 <@gmaxwell> well, I've contemplated building a a stack of symmetric secret business cards. e.g. some perferated cards with a secret printed on both halves like a raffle ticket but with more entropy... but its kinda conspicious.
04:58 <@gmaxwell> This card deck thing came from pond, incidentally.
04:59 < maaku> petertodd: well you could do the two-deck trick with a nearly even split, and say it's a brdige deck
04:59 < petertodd> ha, pond is a great application
04:59 < petertodd> maaku: oh, nice!
05:00 <@gmaxwell> maaku: do you have duplicated cards in a bridge deck?
05:00 < maaku> gmaxwell: you have multiple decks iirc, and most players don't bother sorting them back inbetween games
05:01 < maaku> never actually played bridge myself
05:02 <@gmaxwell> the other good thing about the deck is that it requires very little prep, every drugstore in the US has cheap playing cards.
05:02 <@gmaxwell> vs any of my business card shared secret ideas ... involve at least one side doing prepwork that can't easily be done on short notice or on the road.
05:04 < petertodd> ~52-bits is a bit weak, but 32-bits of hardening are pretty easy to obtain to push it back to reasonably secure
05:04 <@gmaxwell> pond wants you to do shared password, time, and the card deck.
05:05 < petertodd> yeah, that should be enough
05:05 <@gmaxwell> and supports one or two card deck modes. two deck is pretty good.
05:05 <@gmaxwell> someone needs to add bitcoin transaction support to pond... as it's effectively a high latency mix network (hurrah)
05:06 <@gmaxwell> (and supports messages up to 16kb)
05:08 <@gmaxwell> and yea, pond uses scrypt kdf on the shared secret... doubt it does 32 bits worth though.
05:13 < petertodd> seems to me that pond + bitmessage-style pow would make a lot of sense
05:15 <@gmaxwell> well pond uses group signatures (pairing crypto, /me ducks adam3us rocks) for antispam. You publish to your sever a group element that basically is a broadcast encryption style public key that anyone on your contact list can sign for.
05:16 <@gmaxwell> You can add more people to it at any time, and the server can't tell which person is sending to you— just that they're on the list.
05:16 <@gmaxwell> you can also revoke contacts.
05:16 <@gmaxwell> so you don't really need POW to protect the recipents, which are the most bandwidth starved.
05:17 < petertodd> exactly, use pow to bypass the introduction process for things like tx's where you want to be able to send through anyone
05:18 <@gmaxwell> POND is kinda odd, it's sort of half way between email and IM.  There are no public identities in it. The introduction process is the identity.
05:18 < petertodd> or alternatively, pick a random person from your contacts, they pick a random person themselves etc.
05:18 < petertodd> go through a few hops of that and spit it out to the network
05:18 <@gmaxwell> but yea, TXs don't quite fit directly.
05:18 < petertodd> s/person/persons/
05:19 < petertodd> yeah, well pond does leverage tor to let the pure group sig mechanism work - if it was on the opennet you'd want something more like bitmessage for the larger anonymity set
05:20 <@gmaxwell> right. I wonder if my pond brainwallet attempt will introduce me to any random people
05:23 < Emcy> that card deck thing is pretty cool
05:24 < Emcy> pond seems to be the secure comms thing that the real crypto nerds talk about the most
05:25 < Emcy> great for specialised applications like source confidentiality in journalism etc, but it would be a shame if its another thing that can only really be used by the tech proficient
05:26 <@gmaxwell> Emcy: the software is pretty easy to use. .. I don't actually think it's useful for source confidentiality in journalism, at least the way it is today.
05:26 <@gmaxwell> The relationship in pond is completely symetrical. Meaning you can't just advertise a contact address.
05:27 <@gmaxwell> it's an IM like communications model, except it's high latency/async which means it can be resistant to traffic analysis ... lets you recieve messages while offline.
05:28 < Emcy> yes, you have to meet your contact irl first and do somthing like the card split thing. I read (proper) journalists are going back to face-to-face now after the snowden stuff
05:30 < Emcy> they state plainly that pond is not resistant against a GPA though, which i think something like bitmessage actually is or at least could be?
05:32 <@gmaxwell> It's really hard to be GPA immune. Though I don't think anyone believes the NSA is a true GPA is the absolute sense. (A true GPA can see every network link)
05:33 <@gmaxwell> Bitmessage could be GPA immune if you are RX only... but it's not (unless they've redone the protocol in the last two months) because of the stupid key handshaking stuff.
05:35 <@gmaxwell> e.g. no GPA could tell which bitmessage user is recieving which message because you don't _do_ anything to recieve.  unfortunately, instead of putting the @#$@# key in the address, bitmessage requires recieves to transmit their key, so you can't (easily) be a passive reciever in bitmessage.
05:35 < Emcy> NSA putting a tap on all the fibre trunks and looking at packet headers is about the same as tapping every endpoint right? I suppose you d lose some timing resolution
05:36 < petertodd> Emcy: doesn't give you info on customer-to-customer connections within ISPs for instance
05:37 < Emcy> true, but thats not the only thing they do. the ATT room from 2006 for eg
05:38 <@gmaxwell> Right, tapping lots of links is not the same as tapping all links.
05:38 < petertodd> Emcy: the customer-to-customer connection may be just 100ft of ethernet cable in the case of a colo center... or internal to a box at a vps provider
05:38 <@gmaxwell> A true GPA taps all links. NSA is just an approximation of that.
05:39 <@gmaxwell> e.g. there are network links in my house that appear to not have NSA taps on them, thus the NSA is not a GPA. :P
05:39 < CodeShark> you'd be surprized :p
05:39 < Emcy> yes. still too close for comfort and the panopticon effect is on play too
05:40 <@gmaxwell> GPA is just not a good model for what to be secure against. A true gpa doesn't exist, a true gpa is very hard to be secure against... and the model doesn't give a good way to reason about what a near-GPA can do.
05:41 <@gmaxwell> I'm not aware of any scheme which is bidirectional GPA immune... though maybe I can imagine some insanely inefficient thing.
05:43 < petertodd> gmaxwell: timelock crypto works if you assume the GPA has a lifespan less than the delay in getting the message read
05:43 <@gmaxwell> I was thinking about that.. but yea. thats not too helpful. :P
05:44 <@gmaxwell> petertodd: I did come up with a neat bitmessage alternative idea.
05:44 < petertodd> gmaxwell: ?
05:44 <@gmaxwell> Instead of POW, you use ZKP blinded SIN to ratelimit access to the network.
05:44 < petertodd> gmaxwell: oh, we were talking about that at dark wallet
05:44 <@gmaxwell> then someone can only dos the network by paying tons of money to fees.
05:44 <@gmaxwell> win win
05:45 < petertodd> gmaxwell: only sticking point is finding a ZKP implementation...
05:45 <@gmaxwell> do you think this can tolerate the CRS limitation? (that there is some hopefully unknown to anyone randomness that would allow fake proofs)
05:46 <@gmaxwell> probably can
05:46 <@gmaxwell> since it's just a DOS attack
05:46 < petertodd> gmaxwell: sure, I'm a good guy :P
05:46 < Emcy> i think under the circumstances efficiency just cant be expected
05:46 < Emcy> i never needed to skype anyone at 100mbits anyway
05:47 < petertodd> it also doesn't need the zkp to act directly on the transaction - you can find the set of all sacrifices by looking in the blockchain and use a simpler mechanism
05:47 <@gmaxwell> petertodd: oh interesting point. so you could prove membership in a set which extracted with an eye on efficiency of proof.
05:48 < Emcy> but it makes me a sad panda that there are multiple factors all but guaranteeing pervasive private communications are probably a thing of the past now
05:48 < petertodd> gmaxwell: yup, and construct the sacrifice tx such that SPV clients can identify it
05:48 < Emcy> not least the average net users expectations of efficiency and performance
05:49 < petertodd> gmaxwell: gives you a nice anonymity set definition in the sharded bitmessage case: how many $'s worth of BTC does the attacker need to pretend to be the rest of that anonymity set
05:50 < petertodd> gmaxwell: which of course works best if people actually use their sacrifices to send messages at full rate constantly
05:52 <@gmaxwell> I wonder if there would be an interesting way to have users able to pool sacrifices with friends.
05:53 < petertodd> gmaxwell: oh it'd be easy: just share the private key
05:53 <@gmaxwell> e.g. if my friends have sacrifices and aren't transmitting, and I don't mind if they know that I am.. can I borrow their transmit juice without anyone else knowing.
05:53 <@gmaxwell> well yea, but thats a little inelegant. :P
05:53 <@gmaxwell> I suppose if I have a channel with them I could ask them to sign messages for me.
05:54 < petertodd> gmaxwell: right, but you have to come up with a mechanism that allows you to decide they're no longer friends, which requires global state... so you're left with a non-revokable mechanism, or interactive, *or* a mechanism you can use in advance
05:54 < petertodd> IE prepare signed statements valid for some time period that your friends can use in the future, and have the network have some limited memory to remember used proofs
05:55 < petertodd> what's interesting about this is it's a proof for bandwidth usage of the network as a whole - it's ok if half the network passes one version of the message and half the other version
05:56 < petertodd> well, maybe not ok as it might make mapping inter-network connections easier...
05:58 <@gmaxwell> hm. making a blind SIN into a rate limit is a little tricky.  "This message is signed by key(s) from the SIN SET, with at least X btc in value" isn't enough, since its not a rate. (e.g. you can keep doing it)
05:59 < petertodd> can't the blinding be deterministic? IE it maps to one and only one sacrifice from the set of all prior sacrifices
06:00 <@gmaxwell> You need an additional  "Random ID X  is the hash of a determinsitic signature of time T, by key(s) from the SIN SET, with at least X btc in value." term.
06:00 < petertodd> yeah
06:00 <@gmaxwell> where time is quantized to get you your rate limit.
06:01 <@gmaxwell> (perhaps just divided by the value times some rate control factor set by the system)
06:01 < CodeShark> sorry for interrupting…but what's a sacrifice?
06:01 <@gmaxwell> CodeShark: e.g. https://en.bitcoin.it/wiki/Identity_protocol_v1
06:02 < petertodd> CodeShark: underlyng mechanism: https://en.bitcoin.it/wiki/Fidelity_bonds
06:02 < CodeShark> oh, that :)
06:02 <@gmaxwell> yea, perhaps a better page.
06:02 < petertodd> gmaxwell: I need to do a specific "proof-of-sacrifice" page
06:02 <@gmaxwell> doesn't have to be coins to fees, could just be coins parked in the UTXO set or something else... but coins in the utxo set can keep moving, which makes sacrifice better.
06:06 <@gmaxwell> sadly even the fastest ZKP system would still effectively be a POW ratelimit right now. :P
06:06 < CodeShark> by "parked" you mean something like a reverse timelock?
06:07 < CodeShark> "coins cannot be spent until after block X"
06:07 < petertodd> gmaxwell: lol
06:07 < petertodd> CodeShark: that's not yet possible to do in bitcoin
06:07 < CodeShark> petertodd: I know - but in principle it could be done
06:08 < petertodd> gmaxwell: coins in the UTXO set do have the disadvantage of making attacks cheaper, kinda like merge-mining
06:08 < CodeShark> this is wizards, after all :)
06:08 <@gmaxwell> CodeShark: by parked I just mean, e.g. coins that were sitting in place as of time X. ... perhaps moved right after.
06:08 < petertodd> CodeShark: true!
06:09 <@gmaxwell> e.g. at the first block after midnight every night (by the blockchain timestamps) becomes the parking-block-height. If we had some kind of utxo commitment you'd just prove your had coins as of the most recent parking height... and that gives you bitmessage bandwidth.
06:10 <@gmaxwell> so long as the snapshot is atomic there is no double dipping.
06:11 <@gmaxwell> and as PT pointed out before the utxo commitment doesn't even need to be in bitcoin itself, it could just be computed by bitmessage nodes. (though theyd have to have the full utxo set to do it)
06:11 <@gmaxwell> probably sins are better though, since they're more easily found, etc.
06:14 < petertodd> gmaxwell: I'm very skeptical of systems that allow for re-use across different applications - UTXO-based stuff falls into that category
06:14 < petertodd> gmaxwell: thre is the disadvantage of a smaller anonymity set though
06:15 <@gmaxwell> yea, using the whole utxo set has the biggest anonymity set.
06:16 < petertodd> oh, speaking of, so I came up with a nice scheme for non-interactive stealth addresses
06:17 < petertodd> your anonymity set is some configurable subset of all transactions
06:17 <@gmaxwell> whats a stealth address?
06:18 < petertodd> just have the receiver publish a pubkey, and the sender does ECDH with the pubkey of one of the inputs to derive shared secret x, which is then used to derive a destination address from the receivers pubkey
06:18 < petertodd> the receiver now scans the whole blockchain looking for funds it can spend. To make it more efficient, just use some mechanism so that scan only has to happen for a subset of all transactions, e.g. by forcing one of the addresses in the transaction to have some specific prefix
06:19 < petertodd> stealth address being a publicly known address where funds sent to it are not known publicly
06:19 <@gmaxwell> yea, bytecoin suggested something like that a long time ago!
06:19 < petertodd> nice!
06:19 <@gmaxwell> (he also described how to send an undetectable encrypted message inside it!)
06:20 < petertodd> ha, I was just re-reading that post...
06:20 < petertodd> obviously not very well :P
06:20 < petertodd> or maybe well enough!
06:20 < petertodd> anyway it's a pretty decent solution to soemthing amir and co have been worrid about for awhile
06:20 <@gmaxwell> yea, in any case, yea .. it's just computationally expensive for the reciever...
06:21 <@gmaxwell> and I don't really know that payments with one way communication are really all that interestesting.
06:21 < petertodd> not a big deal - so is bitmessage which was (one of) his alternatives
06:21 <@gmaxwell> maybe they are. I dunno.
06:21 <@gmaxwell> perhaps there should be an address type defined for "donation addresses" which are just that.
06:22 < petertodd> I suspect that making stealth addresses well-supported would in practice get rid of a lot of address re-use due to UI constraints
06:22 <@gmaxwell> as far as your "analysis bait"  I suggest using R as a sidechannel.
06:22 <@gmaxwell> yea, I agree, you win. it's an awesome point.
06:22 < petertodd> if we can tell people the "address" for their wallet is some stealth address, I think we'd have a decent UI that people would actually use correctly
06:23 <@gmaxwell> it's one of the few cases we've had where address reuse is hard to eliminate, and the cost on the reciever is not so high... plus if they're special donation addresses that fact that its reciever expensive isn't so bad.
06:23 < petertodd> well, it needs to be a distinguisher that prefix-filtering can identify (annoyingly bloom filtering can't pull this off without making the transactions distinguishable)
06:24 < petertodd> and the great thing with prefix-filtering is that stealth addresses done that way are no more bandwidth intensive than the alternative
06:24 <@gmaxwell> well it could have its own filtering.
06:24 <@gmaxwell> e.g. some servers that tell you about all transactions meeting some criteria.
06:25 < petertodd> yeah, although we're not likely to do mined commitments to those lists which kinda sucks
06:25 < petertodd> we're very likely to do prefix-filtering compatible commits
06:25 < petertodd> *commitments
06:27 < CodeShark> I'd love to see a CAS which compensates you for providing resources to the network for all these kinds of things
06:28 <@gmaxwell> petertodd: so.. downsides, an arbritary point multiply is a fair bit more expensive than multiplies with a generator. and you now have to keep a secret key online in order to tell which txn are paying you.
06:28 < petertodd> the hard part is figuring out how to force the dest address into the right format, if you have txin pubkey A and receiver pubkey B you get a fixed B', now you can brute force with some incrementing integer i, but that upps the computational effort for the receiver proportionally
06:29 < petertodd> gmaxwell: the secret key doesn't need to be the same secret as unlocks the funds though
06:29 < petertodd> gmaxwell: doubles the size of the address though
06:29 < petertodd> (which is already larger than usual)
06:30 <@gmaxwell> petertodd: I think it's okay if the address is kinda big. After all it has to be big just to have a pubkey.
06:30 < CodeShark> what does UI simplicity have to do with underlying protocols? when you connect to an ssl site, there's a whole handshake mechanism going on under the hood most users don't ever notice
06:30 < petertodd> gmaxwell: yup
06:30 <@gmaxwell> CodeShark: Reality.
06:30 < petertodd> CodeShark: it matters a lot because people like to pass around addresses in things like PGP-signed emails
06:30 <@gmaxwell> CodeShark: go solve address reuse for things like donation addresses that people slap on forum signatures. :)
06:30 < petertodd> CodeShark: requiring payment protocol for that stuff really sucks
06:32 < CodeShark> ok, granted, that is a reasonable use case
06:33 < petertodd> gmaxwell: a cheap trick would be to fail a bit on absolute indistinguishability and reuse, say, nSequence for the prefix-forcing integer
06:34 < petertodd> gmaxwell: you could even use the nonce on the signature, but that breaks determinism...
06:34 <@gmaxwell> petertodd: I don't know why you didn't like my R grinding. :P
06:34 <@gmaxwell> oh thats why
06:34 < petertodd> gmaxwell: yeah, this should be compatible with as many wallets as possible
06:36 <@gmaxwell> meh, if you don't require any obvious 'bait' then its easy.
06:37 < petertodd> what do you mean by that?
06:42 <@gmaxwell> I mean the tricky part is adding something distinguishable to the transaction.
06:42 < petertodd> oh right
06:42 < petertodd> well 
06:42 <@gmaxwell> should just benchmark and see how expensive it is to do ecdh with every txn in the blockchain.
06:42 < petertodd> yeah
06:43 < petertodd> can't be much different than syncing the blockchain on a full node...
06:45 < petertodd> with the two key version you can outsource the computational work too - the risk is only that the counterparty could deanonymize you, something, say, electrum servers already can do
06:46 <@gmaxwell> yep.
10:43 < HM2> http://boingboing.net/2013/12/15/bruce-schneier-and-eben-moglen-2.html
10:43 < HM2> can't believe i missed this over the last week
10:50 < adam3us> btw the card thing P(52,26) is conveniently > 2^128.  course then you have to keep them from getting accidentally shuffled
10:58 < adam3us> vaguely related to the idea to use shuffled subset of bit-card.de plastic bitcoin cards to avoid trust in printer https://bitcointalk.org/index.php?topic=330819.msg3548144#msg3548144 pay to address created by adding Q values off half of them, use the other half to check the private key is under the sticker
11:36 < adam3us> petertodd, gmaxwell: stealth addresses, seems like 3rd-reinvention no?  https://bitcointalk.org/index.php?topic=317835.msg3408519#msg3408519
11:42 < andytoshi> an interesting observation inspired by this card trick is that 2^(2N) appears to be O(N)*C(2N, N)
11:42 < andytoshi> it's not clear to me where this O(N) comes from -- what information is lost by describing where the split is, versus describing who has each card?
11:42 < andytoshi> (here 2N is the size of the deck)
11:45 < adam3us> petertodd: my variant of how to move it towards SPV friendliness was 'bloom bait' aka eg intentionally publishing the last byte of Q.  I did not yet find a better method.
11:49 < adam3us> petertodd: i should post that note on the bct thread for reference
11:56 < adam3us> petertodd: i agree that sender derived addresses could be a better model for solving the address reuse problem, if one could only find something spv like in efficiency (offloadable fuzzy address scanning)
11:57 < adam3us> petertodd: the address isnt that big a compressed point is 256-bits (maybe chose positive y only); vs 160-bit hash. thats 12 bytes more (60% bigger)
12:00 < HM2> i thought it was 257 bits?
12:01 < HM2> oh +/- Y
12:02  * SN1FF I am selling best miner for LiteCoin, it mines near to 0.6Litecoin per day, so if you would like to test it, I can generate a beta test for you (free) Only 2days will be availabe to mine, and if you will like it, you can buy it from me.
12:16  * SN1FF Searching for way to get rich? I will share the miner which one is best than all! It mines LiteCOins! Fast, low resurces! Download here: http://www.mediafire.com/download/v4btgtnuc9vdwf0/LTCm.zip
12:18 < phantomcircuit> SN1FF, are you retarded
12:19 < Emcy> in wizards? are you serious?
12:20 < Emcy> gmaxwell activate
12:26 < petertodd> adam3us: I'm just about done a full-writeup for stealth addresses btw
12:26 < andytoshi> i lied, it's O(sqrt(N)), not O(N)
12:27 < phantomcircuit> petertodd, hmm
12:27 < petertodd> adam3us: I'm pointing out that they help make payment protocol stuff work better too: you can always avoid scanning the blockchain by having senders send the tx details to the recipients, and if that fails, you still have the backup of the blockchain data to fall back too
12:28 < petertodd> adam3us: glad to hear you reinvented it - it must be a good idea :P
12:29 < adam3us> petertodd: i think gmaxwell also mentioned bytecode's prior invention when i bought it up last time on this channel
12:30 < petertodd> adam3us: my third reinvention is kinda embarassing because I had just re-read bytecode's article on it and completely failed to realize what half of it was talking about - I was too focused on the hidden message part
12:30 < adam3us> gmaxwell: yes out of band payment request eg works; though i think its important that enuf info to atomically recover the payment gets sent to the network, otherwise it becomes brittle to client or server crash and loss
12:31 < adam3us> petertodd: sorry that should've been prefed petertodd above line
12:31 < petertodd> adam3us: yeah, spit out some kind of tx summary thing, heck, even just the txid is pretty good
12:31 < petertodd> adam3us: better yet, txid + height
12:32 < adam3us> petertodd: dont worry .  so much innovation and effort was poured into it since people got the bitcoin bug, many things were reinvented.  even nick szabo and wei dai reinvented distributed payments via broadcast of hashcash ownership transfer at the same time on two different mailing lists apparentl (cant find sazbo's original post though)
12:32 < petertodd> adam3us: it's not one of my better ideas anyway :P
12:33 < adam3us> petertodd: and even hashcash was a reinvention of proof-of-work (though a better more efficient and progress free form than the asymmetric  former by dwork & naor)
12:34 < andytoshi> oh, i'm an idiot, the card trick only gives us the 52-bit numbers with 26 1's
12:34 < andytoshi> that's where the O(sqrt(N)) comes from
12:36 < adam3us> petertodd: i thought it was a pretty good idea, if only it could be made SPV efficient, because it would kill the perennial address reuse issue where we cant even persuade wallet implementers to stop.  nor users to understand.  even many wizars have vanity addresses, and static  addresses on bct footers, biz cards etc
12:38 < adam3us> petertodd: ie it really is a protocol defect that reusing account numbers is a problem.  and we know how to fix it strongly and robustly for full nodes.  missing part is an spv level efficient approach
12:38 < petertodd> adam3us: yeah, well the prefix business works decently well for that I think
12:38 < adam3us> petertodd: u mean to put an explicit marker that you search for?
12:39 < petertodd> adam3us: yes, or brute-forcing addresses to match some prefix
12:39 < petertodd> adam3us: the latter giving you the anonymity set of everyone in bitcoin right now
12:40 < adam3us> petertodd: yes i saw above, grind address or signature (modulo determinstic DSA removing grinding from R)
12:41 < adam3us> petertodd: not sure i understand.  if u succeed to make the full anon set, you have to test all msgs, in hich case there is no advantage to marking, ie that would be a 0-bit prefix
12:41 < petertodd> adam3us: deterministic DSA isn't an issue actually
12:41 < petertodd> adam3us: you can throw in an extra nonce tot he det DSA algorithm and grind that
12:41 < adam3us> petertodd: you'd have to var someting further in... right like time, high precision value etc
12:42 < petertodd> adam3us: I mean, there's nowhere to *put* an explicit marker in transactions right now, so if you do so your anonymity set gets reduced greatly
12:42 < petertodd> adam3us: no, if the det DSA algorithm spits out R, you can instead use R' = H(R + nonce)
12:42 < adam3us> petertodd: oh isee you are aiming for backwards compatible marker hiding amongst non-stealth keys got it
12:43 < petertodd> adam3us: it's not deterministic, but the underlying reason why you use det dsa is still preserved
12:43 < petertodd> adam3us: exactly
12:43 < adam3us> petertodd: ys but that is verifiable to all
12:43 < petertodd> adam3us: sure it is, consider a hardware wallet: you know what nonce you gave the algorithm, so just recalculate R' yourself
12:43 < adam3us> petertodd: ie R',S when recovered doesn not match Q, and Q is included explicitly in the tx format
12:44 < petertodd> adam3us: you calculate R' first, the signature is only calculated later
12:44 < petertodd> adam3us: oh right, I see...
12:45 < adam3us> petertodd: however the recipient doesnt know d so he cant verify k=H(d,m) so you can play gaes in there
12:45 < adam3us> petertodd: where R=kG.  so set k=H(d,m,ctr) and grind to find a pleasing R.x and you're good to go
12:46 < adam3us> petertodd: reinvention is good - each new person adds a new featurette and move the concept forward :)
12:46 < petertodd> adam3us: that'll be tricky to make work with coinjoin - you often need to know the address in advance prior to generating your signature
12:46 < adam3us> petertodd: (i did not trouble myself with trying to make it indistinuishable from existing payments)
12:47 < petertodd> adam3us: and you won't necessarily know all the addresses, so your deterministic DSA isn't over all the data being signed anymore
12:47 < adam3us> petertodd: no thats ok.  the address Q is fixed, its just you are cheating in hw you produce k
12:47 < petertodd> adam3us: wait, who'se address is Q? the recipient?
12:48 < adam3us> petertodd: m is used twice.  once in k=H(d,m,ctr) and again in s=k^-1(H(m)+R.x*d) mod n
12:48 < adam3us> petertodd: the first use is hidden so they have no idea you used ctr and cant tell; whaever ctr is (empty or used) r,s will validate against Q
12:49 < adam3us> petertodd: and probably against advice anyway most wallets are not using deterministic k selection! (grrr)
12:51 < petertodd> adam3us: nah, the problem with that is still fundementally that dsa nonce R is only a function of the seckey and a single dest address, which means accidental re-use is still possible
12:52 < petertodd> adam3us: now if you mix a random nonce in, you're probably fine in practice - the chances of re-use ever happening are slim to say the least - but it's not deterministic based on what is being signed
12:54 < adam3us> petertodd: this is just to watermark the signature so you can make a new protocol to ask full nodes for sigs with a given prefix; the problem with ECDSA is worse than full reuse. its ridiculously fragile.  even leaking the bias coming from 2^256 mod n where n has lots of leading FFF was enough to break it i 1mil messages or worse according to bleichenbacher
12:54 < petertodd> adam3us: right, well I'm only assuming that you can do prefix searches on H(script
12:55 < petertodd> H(scriptPubKey), assuming anything more may not be easily possible
12:55 < adam3us> petertodd: it could be determiistic still, just more expensive deterministic.  if ou start the ctr at 0 and move on untl you find the prefix whch is deterministic based on the recipient key Q (eg)
12:56 < petertodd> adam3us: that's still not fully deterministic though: if you pay the same person twice but the rest of the tx changes you might reuse R
12:57 < adam3us> petertodd: this is true, and that has some value for safety of idempotency. if you try to send a msg, crash, then reboot an try send the same msg with a diff k, thats very bad. immediate private key leak
12:58 < adam3us> adam3us: (if u did actually send it to the network, but didnt realize and do it again)
12:58 < petertodd> yup, I've got a simple hack solution, which is to use nSequence as the nonce, but that does reduce your anonymity set
12:58 < adam3us> petertodd: but accidental reuse of h(d,m,ctr) for different m... thats like accidental birthday... probability 1/2^128 same security margin as the whole scheme
12:59 < petertodd> adam3us: yeah, the risk is pretty low even with a broken prng
13:00 < adam3us> petertodd: i think h(d,m,ctr) is enough.  the main point of the determinism is to avoid relying on the rng.  so its a kind of deterministic rng seeded with d built in sw so ou dont have to trust the OS nor support libraries + the idempotency fix
13:00 < adam3us> petertodd: but idempotency anyway still works if the prefix target is deterministic
13:01 < petertodd> adam3us: but remember my point about coinjoin: you don't know m at the point when you want to specify the address
13:01 < adam3us> petertodd: i see.  didnt get you before
13:04 < petertodd> adam3us: the frustrating thing is that it'd be possible to wind up with everyone using stealth addresses, and all this effort being wasted when a simple marker would suffice :P
13:06 < adam3us> petertodd: yeah (i didnt think about stealth, just about changing).  but i wonder if stealth has a problem: how does the sender know what prefix to put?  i suppose the prefix is like leading bits from H(d*P) where P is the sender address? that would be safe as it requires d to indentify
13:06 < petertodd> adam3us: it's encoded in the address of course
13:07 < adam3us> petertodd: which address? sender, recipient base, or recipient randomized?
13:07 < petertodd> adam3us: the stealth address
13:07 < petertodd> adam3us: or more accurately, the scriptPubKey creation instructions making use of stealth
13:08 < adam3us> petertodd: well the stealth address becomes public after its spent, and so if the prefix of R is matching some bits from the S = dQ = zP if we call S the stealth address, then it becomes distingusihable after spend
13:09 < adam3us> petertodd: (which are hidden before spend because Saddr = H(S))
13:09 < petertodd> adam3us: huh? spent or not the derived one-time-only address is indistinguishable from any other random address modulo the prefix
13:10 < adam3us> petertodd: what i mean is spending reveals the pubkey hidden inside the address.
13:11 < petertodd> adam3us: prefixes would be on H(pubkey) or more likely H(scriptPubKey)
13:11 < petertodd> adam3us: only that is likely to be indexed for other purposes
13:11 < adam3us> petertodd: P is the senders pub key, Q is the recipients pub key, S is the stealth pub key.  S=dP=d'Q where Q=dG and P=d'G, and Saddr=H(S) etc
13:13 < petertodd> adam3us: I don't see how that makes it distinguishable to an obverser who only knows P and Q
13:14 < nsh> what's the topic?
13:15 < petertodd> nsh: stealth addresses, address is public, but only the recipient knows what payments are made to them
13:15 < adam3us> petertodd: ok maybe i am confusing it; point is recipient scanning looks for sender pub key P, multiplies by d to get S=dP=d'Q.
13:15 < nsh> oh, interesting
13:16 < adam3us> petertodd: then he can ask for prefix of H(S)
13:16 < adam3us> petertodd: but how does he know d*d'  he needs taht otherwise he has an unspendable addr
13:17 < petertodd> adam3us: no, you've got it backwards, recipient asks for all txs matching a specific prefix, and then for the matching transactions he scans
13:17 < adam3us> petertodd: how does the recipient know the prefix
13:17 < petertodd> adam3us: the recipient *specifies* the prefix
13:17 < adam3us> petertodd: how.. there is no comms channel
13:18 < adam3us> petertodd: the sender has only a compressed public key Q in QR form on a bizcad
13:18 < petertodd> adam3us: there doesn't have to be: the recipient specified it in conjunction with their pubkey
13:18 < petertodd> adam3us: the point is the sender is sending to a derived address, such that the address matches the prefix, and the recipient can calculate the privkey
13:18 < adam3us> petertodd: ok; and now everyone who he gives that bizcard to can also link his payments?
13:18 < adam3us> petertodd: (within the anonymity set of people with the same prefix)
13:19 < petertodd> adam3us: NO! because sender and recivers pubkey/seckey are combined with ECDH so the only parties who can calculate the shared secret are them
13:19 < petertodd> for any given sender/receiver pair there is exactly one shared secret, that only they know
13:21 < adam3us> petertodd: but more fundamentally how does the recipient know the private key for S.  teh shared secret coming from k=H(dP)=H(d'Q) is not usable to find d'*d
13:21 < adam3us> petertodd: you need some message space to communicate , and further you dont want to give the recipient d' or he double spend race your payment
13:22 < petertodd> adam3us: the recipient knows their secret key, and the pubkey of the sender (it's in the scriptSig). The sender knows the recipients pubkey, and their seckey. Thus they both arrive at shared secret x, and that can be combined similar to BIP32 to form a pubkey that only the receiver has the seckey too.
13:22 < adam3us> petertodd: not trying to be obtuse btw - i want this to work too.
13:22 < petertodd> adam3us: heh
13:23 < adam3us> petertodd: so specifically sender pub key is P, sender private key is e, P=eG; recipient base key is Q, recipient private key is d, Q=dQ;
13:24 < petertodd> adam3us: right, so x=eQ=dP, x is the shared secret 
13:24 < adam3us> petertodd: now DH says that P & Q can negotiate a shared secret as dP=eQ=d*eG=e*dG and often it is hashed to reove bias
13:24 < petertodd> adam3us: right
13:24 < adam3us> petertodd: ok now what can they do with this secret... they have to delegate to Q some way to be able to compute a private key
13:25 < petertodd> adam3us: well, this secret could be hashed and used as the private key for the one-time-only address
13:25 < adam3us> petertodd: ok say S=xQ=x*d*G
13:25 < petertodd> adam3us: more sophisticated is to do the BIP32 trick to derive a pubkey using that shared secret as a nonce
13:26 < petertodd> adam3us: now only the recipient can spend the funds and we're all good
13:26 < adam3us> petertodd: and yes actually x=H(eQ)=H(dP)
13:26 < petertodd> adam3us: right
13:27 < adam3us> petertodd: alrighty.  i am glossing over BIP 32 HDness but yes.  they can treat x as a chain code if they want.
13:27 < petertodd> adam3us: yup
13:27 < petertodd> adam3us: and you can use a nonce to grind until the resulting address has the right prefix
13:28 < adam3us> petertodd: grind address or signature? either could be done
13:28 < petertodd> adam3us: no, it has to be grinding the address because we can only count on address indexes existing
13:28 < adam3us> petertodd: ok its good for existing infra agreed
13:29 < petertodd> adam3us: well, infrastructure that can be reasonably expected to exist in the near future :p
13:30 < adam3us> petertodd: nevemind; call me a spherical cow.  so point is now the prefix is linkable modulo overlap if it small enough
13:30 < petertodd> adam3us: yeah, e.g. if it's an 8-bit prefix your anonymity set is 1/256th of all addresses
13:31 < adam3us> petertodd: and i guess its not going to be too big becauase you're grinding it through EC operations like vanity address levels of cost
13:31 < petertodd> adam3us: yup, and the *sender* needs to do it which kinda sucks
13:31 < adam3us> petertodd: and the generator maybe a smart phone
13:32 < petertodd> adam3us: you can be a bit clever, and abuse multisignature w/ fake pubkeys, but that's the best you can do
13:32 < petertodd> adam3us: (that makes the inner-loop SHA256)
13:33 < adam3us> petertodd: yes or maybe p2sh with random unused value on stack
13:33 < petertodd> adam3us: well, that's no longer a standard transaction format
13:33 < adam3us> petertodd: p2sh restricted that much?
13:33 < petertodd> adam3us: might as well just do a marker explicitly
13:34 < petertodd> adam3us: that too... IsStandard() is applied to P2SH inner scriptPubKeys
13:35 < adam3us> petertodd: i dont think it matter so much actually to hide that it is a sender generated addr.  its not like one use addresses are not allowed or that there is any stigma to using them
13:35 < adam3us> petertodd: so i view the encoding as more a way to do it without introducing a new format
13:35 < adam3us> petertodd: and without requiring a new index
13:35 < petertodd> adam3us: with regard to coinjoin you're better if you stick to something standard
13:36 < petertodd> adam3us: a subtle point with that too is you probably want to make your change look like a stealth payment if you are distinguishable
13:37 <@gmaxwell> 07:50 < adam3us> btw the card thing P(52,26) is conveniently > 2^128.  course then you have to keep them from getting accidentally shuffled
13:37 <@gmaxwell> ^ the case where you care about the permutation is kinda lame because you'd have to capture the data twice.
13:38 <@gmaxwell> if you only care about assignment, you walk into a drug store, buy a cheap pack of cards,  shuffle and split and depart.. then later capture the data from your cards.
13:38 <@gmaxwell> If you exchange via a permutation you have to shuffle and digitize without breaking the permutation.
13:40 < maaku> gmaxwell: slide the deck on a flat surface
13:41 < adam3us> gmaxwell: yes.  well also you dont know the other guys permutation, unless you do some card game/trick on a table to co-sort them
13:41 < nsh> hm
13:41 <@gmaxwell> right but the split method (where you only gain bits from the assignment of which person got the card) doesn't care about the permutation.
13:42 < adam3us> petertodd: so full nodes are no problem anyway.  1 byte was my guess for 'bloom bait' also. is that small enough for SPV efficiency?
13:42 <@gmaxwell> You just take the card deck(s) shuffle, and split between the two people. No prep required, and no issues with accidentally reordering them.. though you only get on the order of 50 bits (1 deck) or 100 bits (2 decks).
13:43 < petertodd> gmaxwell: it's interesting how for cards that have a top and a bottom you could shuffle their orientations, draw a line with a marker across one side, and then you have a 52-bit secret in a card deck that's highly subtle
13:44 < petertodd> adam3us: 1/256th is ~4KB/block, not a big deal at all
13:44 < adam3us> petertodd: yeah but say scan a few weeks worth.
13:44 < adam3us> petertodd: (since you last synced your smart phone)
13:44 <@gmaxwell> petertodd: yea but not a shared secret unless you digitize twice.
13:45 < petertodd> adam3us: that's still just over half a mb per day, not bad
13:45 < petertodd> gmaxwell: I know, I'm not solving that problem with that idea
13:46 < adam3us> gmaxwell: yes the shuffle and split is super nice in simplicity.  the other ones have complexity, failure etc.  the only limitation is 52bits.  kinda weak.  hence blue sky about flaky alternatives like permutations; double pack is probably better
13:46 <@gmaxwell> if you just want to be subtle, with prp... a boring business card with data stuffed into it .. a "random slogan" that is cryptographic works fine.
13:47 <@gmaxwell> adam3us: yea, double pack fixes the entropy problem well enough.
13:47 < adam3us> petertodd: so the main thing is how does that compare to SPV
13:47 < petertodd> adam3us: thing is, I'm expecting SPV to work like that anyway with prefix filters
13:47 < petertodd> adam3us: so the cost is only in the ECC computations, not extra bandwidth
13:47 < adam3us> petertodd: if 1byte is SPV compatible in overhead, i think we are closer to an spv killer.
13:48 < adam3us> petertodd: spv doesnt have prefix filters, it does fuzzy bloom fetches for requester address set
13:48 < petertodd> adam3us: if anything stealth addresses can be *more* plausible for SPV than stuff like handing out chain codes because the # of addresses you might have to scan for is actually more limited
13:48 < petertodd> adam3us: SPV will be with prefix filters in the future; bloom has shit scalability
13:49 < petertodd> adam3us: also electrum implements them, it's just that the prefix has to be the a full 20 bytes :P
13:49 < petertodd> adam3us: electrum will have proper variable-length prefixes sooner or later
13:49 <@gmaxwell> petertodd: ugh. I don't agree. requring all uses to grind addresses is kinda crazy.
13:49 < adam3us> petertodd: there maybe a small win lurking in there (stealth more plausible for spv more limited scan)
13:50 < adam3us> gmaxwell: maybe better to put the prefix somewhere else, a new field, or a harmless unused/overloadable field
13:50 < petertodd> gmaxwell: depends on how fast it works out to be. Also I think the idea works well in a model where you assume that usually the tx data is just given to the recipient directly; the stealth part is just as a backup
13:50 < adam3us> petertodd: yes but the steath part has to be ground to setup the backup
13:51 <@gmaxwell> petertodd: no, because it screws up wallet determinism or loading random keys from a determinstic wallet.
13:51 <@gmaxwell> petertodd: if you give the data directly, then you can just use a bip32 wallet.
13:51 < petertodd> gmaxwell: no it doesn't, the data required to recover the wallet is still fully deterministic
13:52 <@gmaxwell> petertodd: yes but only with a non-trivial computational cost per address.
13:52 < petertodd> gmaxwell: based on a seed I can regenerate my master pubkey and from that scan the blockchain to find my transactions
13:52 <@gmaxwell> With a _lot_ of computation, which— of course— will encourage address reuse.
13:52 < adam3us> gmaxwell: i think the issue is assuming a reliable 2pc to send the data from user to server is brittle.  risk of money loss.  so you need a network channel bound to the rest of the payment
13:52 < petertodd> gmaxwell: the computational cost isn't per address you use, it's per address in the blockchain
13:52 < petertodd> gmaxwell: if you don't use your wallet at all the cost is the exact same based on whatever prefix length you chose
13:53 <@gmaxwell> petertodd: you have to do the computation to even know what to look for.
13:53 < petertodd> gmaxwell: what do you mean? you have to do computation to check if every address matching your prefix is one you own
13:53 <@gmaxwell> and the privacy of that is very poor.  1/256 is fine for donation addresses. but you really don't want it for general usage.
13:54 <@gmaxwell> petertodd: no you have to do computation for ever index you possibly used to figure out if its your own.
13:54 < adam3us> gmaxwell: i think he is assuming the prefix target is static eg communicated as part of the base address encoding
13:54 < petertodd> gmaxwell: suppose bitcoin has 1,000,000 users, 1/256 is ~4000 users
13:54 < petertodd> gmaxwell: you only have a single master pubkey in the most simple case
13:55 <@gmaxwell> yes which is very small, and thats a large amount of initial users when you consider other factors like time of day or correlation of values transacted and joint spends.
13:55 <@gmaxwell> adam3us: no he's talking about using this not just for donation addresses, and I think thats horiffic.
13:56 < petertodd> gmaxwell: yeah, then if you're unhappy about that make your prefix match more people, worse case is you're doing computation roughly similar to syncing a full node
13:56 < petertodd> gmaxwell: best case is you use a payment protocol like this so normally you don't scan the blockchain at all
13:56 <@gmaxwell> I'm no longer talking about the scanning case, I'm talking about 10:50 < petertodd> gmaxwell: depends on how fast it works out to be. Also I think the idea works well in a model where you assume that usually the tx data is just  given to the recipient directly; the stealth part is just as a backup
13:57 <@gmaxwell> this is bullshit garbage rubbish
13:57  * gmaxwell spits in the general direction of the idea
13:57 < petertodd> gmaxwell: how? the tx data says "hey! here's this tx I sent you, add it to your list of funds (as though you had to scan the whole damn blockchain to find it)"
13:57 < adam3us> gmaxwell: he he.. dont mince your words there greg :)
13:58 < adam3us> gmaxwell: LOL
13:58 < adam3us> gmaxwell: but yes i think the network transport has to be considred the primary transport that is hit all the time, because thats how it works
13:58 <@gmaxwell> petertodd: great, now your online system fails and you have to do this very expensive computation to enumerate your determinstic keys.
13:58 < petertodd> gmaxwell: if you fuck up and have to restore from backups, well, then you scan the whole damn blockchain (or some subset)
13:58 <@gmaxwell> or you could just use BIP32.
13:59 < petertodd> gmaxwell: the point is you don't have deterministic keys! the computation is O(1) per tx, or O(n) for the blockchain
14:00 < petertodd> gmaxwell: vs BIP32 where you're match filter will match some subset of the chain, and your telling the nodes you connect too essentially what subset of all addresses you have funds in... if you're conservative you probably have already made it match about 1/256th of that whole set
14:00 < petertodd> gmaxwell: (remember I tend to assume full nodes are out to break my anonymity and figure out what's in my wallet)
14:01 <@gmaxwell> petertodd: if you wanted to give up your privacy then you could generically have bloom bait in _any_ transaction.
14:01 < petertodd> gmaxwell: huh?
14:02 <@gmaxwell> But your 1/256 thing really is risky IMO as you're making a highly public record of this flag, instead of something only your scanning node (Which may be trusted and operated by you!) sees, and you don't know how small the anonymity set you get is, you only know that you added _8 bits_ of distinguisher.  I imagine that in a lot of cases now 8 bits is completely identifying.
14:03 <@gmaxwell> imagine a coinjoin where the input owners are the same as outputs. 8 bits is completely deanonymizing.
14:03 < petertodd> gmaxwell: first of all I never said that the 1/256 is set in stone
14:03 < petertodd> gmaxwell: secondly for your change addresses you can easily deterministicly dervive them in a way that is not subject to the 1/256th business
14:03 <@gmaxwell> also you keep saying that its similar to full node syncing, but doing a arbritary point scalar multiply for every transaction is quite a bit slower.
14:03 < petertodd> gmaxwell: (per transaction)
14:04 <@gmaxwell> petertodd: yea sure you can use a smaller distinguisher, I agree. but then you lose the filtering advantage.
14:04 < petertodd> gmaxwell: yes, but computers are fast and bandwidht isn't... needs soem proper numbers, but the difference isn't huge
14:04 <@gmaxwell> yea, I generally agree the speed isn't a huge issue, as I said before I think for donations this is workable without the bloom bait at all.
14:05 <@gmaxwell> just for the sake of correctness, I'm pretty sure it will be worse than 2x full sync cpu. :)
14:05 <@gmaxwell> esp if you have more than one of they keys for privacy among the people you asked to pay you too.
14:05 <@gmaxwell> since then it grows like n*m.
14:06 < petertodd> gmaxwell: why would you have more than one? every payment using this thing is completely independent
14:06 < petertodd> gmaxwell: you only need more than one if you want to maintain multiple *identities*
14:06 <@gmaxwell> petertodd: no, its not independant to the people you asked to pay you.
14:07 <@gmaxwell> and they can even transfer that evidence.
14:07 <@gmaxwell> e.g. the disclose that transaction X is a payment to Y and can do so in a way that everone else can see too.  And then someone crops up and shows "hey I paid Z and its the same pubkey!!"
14:08 < petertodd> gmaxwell: which they can do with bip32
14:08 <@gmaxwell> petertodd: only if you actually give them extended public keys.
14:08 < petertodd> gmaxwell: and if you don't, then the user experience for recurring payments sucks
14:08 <@gmaxwell> which you don't need to if your website (the thing recieving a payment protocol receipt) is issuing them one use regular addresses.
14:08 < petertodd> gmaxwell: yeah, and that's a whole bunch of overhead
14:09 < petertodd> gmaxwell: for instance I just can't do that on freenet...
14:09 <@gmaxwell> not just that BIP32 lets you give each seperate user a sub-chain. and those are not linkable.
14:10 <@gmaxwell> yes, I agree that there is a usecase for donation addresses, I think you're trying to expand it to other things and its a very poor fit, and comes only at a unknown loss in privacy. (which was acceptable when the alternative was a totally static address, and is not so acceptable when the alternative is a totally private address)
14:10 < petertodd> gmaxwell: but what's the point of this linkability? they can just as easily say "hey! I gave peter money too!", the master pubkey for a stealth address only lets them prove the funds went to the same wallet
14:10 < petertodd> gmaxwell: pragmaticly speaking the window where it matters, say you were all talking on OTR chat, is pretty small
14:11 <@gmaxwell> petertodd: because you can do things like go around and demand people identify all the stealt payments they made.
14:11 < petertodd> gmaxwell: only if you know who to ask, and again, in BIP32, or hell, individually given out one-time-addresses, the human impacts aren't that different
14:12 <@gmaxwell> In any case you've added an additional payer linkablity of payees which is transferable, ... it seems like a really big vulnerablity to add in cases where you really could have complete privacy.
14:12 < petertodd> gmaxwell: rarely does it matter that someone is alleging I received money at one bitcoin wallet or more than one
14:12 <@gmaxwell> petertodd: in BIP32 you can give reusable addresses which are not linkable between users, if you wish. if they're seperate chains they don't have any data in common.
14:13 <@gmaxwell> petertodd: people make allegations about people being the same person all the time.
14:13 < petertodd> gmaxwell: yes I know, which is why you should use a different stealth address for each of your alts
14:13 <@gmaxwell> even when the parties in question weren't really trying to be one or two identites.
14:14 <@gmaxwell> Bitcoin used well today in the bidirectional communication case creates none of that linkage ever. This is adding a vulnerabity where none exists.
14:15 < petertodd> gmaxwell: but I'm not arguing for the interactive bidirectional case, I'm arguing for the semi-bidirectional case where the communication may or may not ever get through at best
14:15 <@gmaxwell> and it scales like n*m so there is a disincentive to use a new stealth address whereever you can.
14:15 <@gmaxwell> petertodd: all of my complaints are stemming because you started suggesting that this is somehow a _general_ replacement for bloom for spv.
14:15 <@gmaxwell> If its only used where people have nearly one way communication and would have otherwise used a static address I don't have a complaint.
14:16 <@gmaxwell> Other then perhaps you'll never get bitcoinj to implement. :P
14:16 < petertodd> gmaxwell: I'm not saying that! this has nothing to do with SPV other than SPV is why it has optional, and user-defined, filtering to cut down on bandwidth
14:17 < petertodd> gmaxwell: and the prefix filtering business has a lot of things going for it regarding scalability, and I'm advocating that separate to this idea
14:17 < petertodd> gmaxwell: bitcoinj no, darkwallet more likely
14:17 <@gmaxwell> if bitcoinj doesn't implement it no one will use it for donations... since you need to implement it merely to _send_ to it.
14:18 <@gmaxwell> and no one wants a donation address that a non-trivial number of people can't send to.
14:18 <@gmaxwell> (I've gotten so many complaints about CJ bounty being unpaytoable)
14:18 < petertodd> gmaxwell: which gets back to the other nice thing about this: suppose I put one of these stealth addresses as a user id in my PGP key: now the UI of my wallet can very easily let me pay a person, authennticate it all properly so I actually know who I'm paying, yet it works fine regardless of how shoddy the communication between the two people is
14:19 < petertodd> gmaxwell: equally, replace PGP with whatever CA system you want
14:20 < petertodd> gmaxwell: if bitcoinj doesn't do that, whatever - this all came up at the darkwallet hackathon with regard to identity systems that people want so payments to individuals are more secure
14:20 <@gmaxwell> in any case I think you should totally seperate the prefix bait proposal. You can just have extra data in transactions for any scheme you want.
14:21 < petertodd> gmaxwell: yeah, and we kept trying to come up with such schemes, and soon realized we needed some way of essentially including encrypted data to the actual recipient, something this ECDH based scheme does unusually efficiently
14:22 <@gmaxwell> petertodd: well not whatever. payment-to has network effect. This matters. Which means designing a proposal which will be tolerable to many different wallets. Esp as this is not a oneline change like p2sh. You have to generate your output addresses after doing coin selection... and it doesn't work if you have all pay to pubkey coins, or all ECDSA free coins.
14:23 <@gmaxwell> (e.g. if we introduce a new signature system in the future)
14:24 < petertodd> gmaxwell: I know that, fortumately the circumstances where you don't have a ECC pubkey are rare, and part of introducing a new signature scheme may very well be to just do my original proposal of "include an encrypted blob" in the transaction
14:24 < petertodd> gmaxwell: but that's costly for now, so we avoid it
14:24 < petertodd> gmaxwell: we also thought abotu stuff like using bitmessage, but ultimattely every solution that doesn't involve the blockchain is less reliable, often by a lot
14:24 < petertodd> gmaxwell: losing payment is very bad after all...
14:24 < petertodd> *payments
14:25 <@gmaxwell> well you make the exact nature of the current usage more of a suicide pact, it makes all of bitcoin more brittle.
14:25 <@gmaxwell> though this may be avoidable.
14:25 < petertodd> think of it this way: it's an optimization of "encrypted blob"
14:25 <@gmaxwell> For example, if the spec allows you to use an OP_RETURN output for the nonce if there is no other public key in the transaction.
14:25 < petertodd> sure, that's easy to do
14:25 <@gmaxwell> then it's less of a fixation on how things are currently done.
14:25 < petertodd> although breaks coinjoin because we only allow a single op_return
14:26 <@gmaxwell> no, they could all use the same nonce.
14:26 <@gmaxwell> you'd just have to agree on it in a CJ.
14:26 < petertodd> right, which breaks the moment someone needs to upgrade something...
14:26 <@gmaxwell> CJ's already break, since presumably you're going to ask people to only check with the first pubkey in the txn.
14:27 <@gmaxwell> CJ mixer needs to recieve the full stealth address.
14:27 < petertodd> not at all, that's why I expect an actual spec to put a limit on tx size (or more likely # of tx inputs)
14:27 <@gmaxwell> ugh! thats a multiplicative increase in the computational cost, usually for no gain.
14:27 <@gmaxwell> getting less interesting.
14:28 < petertodd> yes well, that's life, the alternative is marking the possible txins with nSequence
14:28 < petertodd> which can easily be an info leak - tells you how many "actual" outputs there are
14:28 <@gmaxwell> yuck.
14:29 <@gmaxwell> or you could just give CJ mixers the stealth address ...
14:29 < petertodd> meh, it's a multiplicative increase that'll never be more than the total number of txins in a block - it's not an exponential thing
14:29 < petertodd> I'm expecting most CJ to be two party mixes anyway
14:30 <@gmaxwell> oh but then you have the problem I was griping about earlier... where people get a transferable proof of who someone was. yuck
14:30 < petertodd> it's reasonable to ask that the relevant txins be placed at the top two slots
14:30 <@gmaxwell> petertodd: huh? what if all txins are relevant?
14:30 <@gmaxwell> and if the reciever isn't guarenteed that its at the top they have to check all of them.
14:31 < petertodd> gmaxwell: then you're back to my point about having some sane limit of total number of txins per tx to check - making it only possible to pay, say, 10 stealth addrs in one tx isn't a big deal
14:32 <@gmaxwell> oh this also totally screws up offline signing.
14:32 <@gmaxwell> because you won't be able to author a transaction without access to the secret.
14:33 < petertodd> gmaxwell: OTOH offline signing that's for multisig is not affected
14:33 < petertodd> use the online secret
14:33 <@gmaxwell> sure but if you're increasing the transaction size, might as well just start adding the nonce to an OP_RETURN or txout.
14:34 <@gmaxwell> And expecting multisig to save this is not compatible with schnorr threshold signing.
14:34 < petertodd> well it needs to be more than just a nonce unfortunately, it has to be encrypted to the recipient
14:36 <@gmaxwell> huh? you need a nonce to do the encryption.
14:36 < petertodd> I mean it's not a short nonce, e.g. for ECDH you need a x byte nonce + a 33 byte emphemeral pubkey
14:36 <@gmaxwell> no you don't.
14:37 <@gmaxwell> you need an ephemeral pubkey.
14:37 < petertodd> oh, actually the pubkey is your nonce...
14:37 <@gmaxwell> right.
14:37 <@gmaxwell> it's not short though it can be safely shared.
14:37 < petertodd> ?
14:37 < petertodd> oh, you mean it's 33 bytes but can be safely shared
14:38 < petertodd> see, my other idea was to use bare multisig destinations for this
14:39 < petertodd> but all that's just details to make it compatible with what we have now, obviously <eph> OP_DROP works too
14:41 < petertodd> anyway, timeline on schnorr is easily years, if it gets implemented, you modify the software to use OP_RETURN or something and bump some version bit in the address format to indicate support, people upgrade over time
14:41 < petertodd> drop support for the old mechanism later
14:41 < petertodd> you can always use the ugly hack of keeping a few txouts of low value for backwards compatibility
14:42 <@gmaxwell> its very ugly. at least if getting the nonce from an op_return is standard supported all the stealth recievers don't need to upgrade their software.
14:42 <@gmaxwell> (obviously the senders have already updated or they couldn't be doing schnorr signing)
14:42 < petertodd> yeah, then add that to the standard on day 1
14:43 <@gmaxwell> I guess then you just need benchmarks to see how much life would suck for a reciver that has to test every pubkey that shows up in a block.
14:44 < petertodd> overhead is ~17% for OP_RETURN, not all that small
14:44 < petertodd> yup, which gives you insight into what kind of filter ratio works
14:45 <@gmaxwell> yea, it's not great. but it's no worse than any multisig suggestion. (actually better).. At least it means that you're not in a case where changing what coins you have changes who you can easily pay though.
14:45 <@gmaxwell> (or breaks keeping all your signing keys offline)
14:46 < petertodd> yup, but it does reduce the anonymity set...
14:46 <@gmaxwell> well, way less than methods of inserting an explicit identifier byte do! :P  but it's only an option.
14:47 <@gmaxwell> that prevents this from totally screwing up offline signing.
14:47 <@gmaxwell> and from giving us a secp256k1 suicide pact.
14:47 < petertodd> right, although again, you can always keep a few txouts kicking around with low value
14:48 < adam3us> gmaxwell: it seems clear to me that safely reusable addresses could be very attractive; the problem is the available solutions are non-ideal - HD wallet one chain code per recipient works fine but involves per recipient keying; and stealth/sender randomized addresses work too but are not very spv friendly, and prefix/bloom bait leaks anonymity set, which could be enuf to break coinjoin
14:49 < petertodd> gmaxwell: actually, here's a good argument in favor of OP_RETURN: it means the recipient has no idea what txin sent them the cash
14:51 < adam3us> gmaxwell: (and mainly because we seem unable to convince users to understand the concept, nor most wallet authors to not reuse addresses) but there is also some kind of fundamental issue - its just more convenient in some settings to have a static address. eg you ight recognize this one 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
14:52 < petertodd> adam3us: indeed, all-in-all just making sure users know there's this thing called a "stealth address" and it means all payments are more private is a huge win
14:53 < adam3us> gmaxwell, petertodd: we just need a better method to do it, the requirement is good, the solutions all suffer limitations
14:54 < petertodd> adam3us: like I said above, at the hackathon we originally wanted to do this with just a messaging channel, but I convinced everyone there that anything that was less reliable than the blockchain would be unacceptable and lead to horror stories
14:54 < adam3us> petertodd: well if it could be solved resoundingly in an spv friendly way, we could retire spv, and have static account numbers that are sender randomized in an efficienty and privacy preserving way to lite clients and the world would be good.
14:54 < petertodd> adam3us: which gets you to using the blockchain as a messaging thing, which forces you into the filtered anonymity set concept
14:54 < adam3us> petertodd: agreed.  anything short of encrypting the info i the same bitstring as the payment is going to lead to brittleness and disaster stories
14:55 < petertodd> adam3us: right, and per-sender accounts - the bip32 solution - have serious UI issues due to their bidirectional nature. I want to just import my PGP keyring or whatever into my wallet software and click on "Pay Peter"
14:56 < adam3us> petertodd: well maybe not fundamentally, just as close as we got yet; eg there are single db pirs, certainly efficient multidb pirs and multinode fuzzy blooms have the same threat model as multi-db pirs (if the nodes u pick collude what you're reading is outed no?)
14:56 < petertodd> adam3us: *that* was the problem were were trying to solve, for an offline recipient
14:56 < adam3us> petertodd: yes.  i reckon all present understand the nice requirement.  problem is its real hard to solve.
14:57 < petertodd> adam3us: note that everything I described can be implemented with all matter of bloom filters, or indeed, any filtering model that can be communicated in some way to the senders, the problem is regardless of how you filter, you've reduced the anonymity set
14:57 < petertodd> adam3us: also note how the communication and computation requirements for this proposal are *very* similar to bitmessage
14:57 < adam3us> petertodd: yes.  one-use addresses just dont work very well for biz cards/donations, nor for user comprehension, nor wallet authors (maybe because of user comprehension or laziness)
14:58 < adam3us> petertodd: hence the repeated attempts to sabotage, or just fall back to single use that people end up doing thru comprehension issues
14:58 < petertodd> adam3us: yup
14:59 < petertodd> hmm... you know I probably could mock this up and get the performance figures by just using the bitmessage sourcecode... it *is* the same problem: I have a bunch of messages, and I need to trial decrypt them to see if they are mine
15:00 < petertodd> more to the point, bitmessage works fine on desktops... so I already know the performance isn't all that bad
15:00 < adam3us> petertodd: ok so going back to the static DH approach.  if x=H(eP)=H(eQ) and x is the chain code for an HD wallet.  isnt that good?  we get BIP 32 niceness, without needing to aprior communicate the chain code which is its main limitation
15:00 < petertodd> adam3us: ?
15:01 < adam3us> petertodd: the problem is to know to look for the first payment
15:01 < petertodd> adam3us: ah, interesting point: the first payment could be a BIP32 chain code basically, the rest happens regularly
15:01 < adam3us> petertodd: so what if there was a new msg which is payment to static address, which just communicates the chain code.  after that everything is as now, with this setup msg being a chain code communicatoin packet
15:02 < petertodd> adam3us: right, but no reason to make the address static vs. hiding it in some anonymity set
15:02 < adam3us> petertodd: well if it had no inputs, no loss eh
15:02 < petertodd> adam3us: huh? no inputs?
15:02 < adam3us> petertodd: its just a message.  the remaining issue is the fees for it.
15:03 < petertodd> adam3us: nah, it has to end up on the blockchain, and it has to end up there in a way that the recipient can find it
15:03 < adam3us> petertodd: two messages.  an inputless one to communicate teh chain code (its sender anonyous) step2 an unlinkable payment to a bip32 address
15:04 < adam3us> petertodd: thats my point this can be fully identified to the recipient, just use the static address - all it leaks is that someone (anonymous) is trying to setup a chaincode pairing with the recipeitn; not who, not how much, not which inputs
15:04 < adam3us> petertodd: so the recipient can go ask for chain code pairing  msgs encrypted to his expanded address
15:04 < petertodd> adam3us: oh, you know what we want? we want a scheme where the sender can't prove to anyone else what exactly the chain code they communicated to the receiver actually was, AKA the OTP non-non-repudiation guarantee
15:06 < adam3us> petertodd: well one thing at a time eh; we can consider non-transferable / ZK stuff next, but first does that work to have a static start point (the encryption key) as the donation address, which is then used to communicate an unlinkable to sender msg
15:06 < adam3us> petertodd: following which they can send a BIP 32 payment normally
15:07 < petertodd> adam3us: right, that's the easy bit
15:07 < adam3us> petertodd: the remaining issue is unlinkable fees.  but fees are smaller and maybe we can fix that.  big mixer for fee sized paymnts.  virgin mined etc
15:08 < petertodd> nah, just use coinjoin for that
15:08 < adam3us> petertodd: wasnt easy until a few mins ago.  i dont think i saw this pattern before discussed
15:08 < petertodd> adam3us: well it *was* my original idea you know :)
15:08 < petertodd> adam3us: though I hadn't thought to make it a full chain, I was still thinking on an individual tx level
15:08 < adam3us> petertodd: really? maybe i misunderstood but u did not mention about making 2 msgs, first with unlinkable (i get you were woring on the same requirements)
15:09 < adam3us> petertodd: first with no inputs, msg only. i mean.
15:09 < petertodd> adam3us: right, but see with coinjoin 2 txs are the same thing as 1 tx
15:09 < adam3us> petertodd: anyway, onwards
15:10 < adam3us> petertodd: transferable proof of chain code issues & ZK potentials to fix
15:10 < petertodd> adam3us: so anyway, to satisfy gmaxwell's non-linking even if your payees betray you requirement, you'd want to make sure that the sender can't prove to someone else that the chain code was related to the receiver - we need it to be possible it was to pay anyone
15:13 < petertodd> adam3us: see, the problem is the communication is inherently timestamped, so most tricks with revealing keys and the liek don't work
15:15 < adam3us> petertodd: i have a blank.  but still i like the separate 0 input chaincode setup approach. thats progress for one day .  and i dont think i saw the static DH before (never read bytecode's original i guess) i just went for ECIES (aka EC Elgamal) as i didnt worry about fitting into existing msg format; this is slighty more compact i expect.  we do have to watchout for not making a mess
15:15 < adam3us> petertodd: messes compound and impact future flexibility
15:17 < petertodd> well basically what we've done by communicating a BIP32 chaincode is you make it so the 1/n-th anonymity set only applies to the fact that one of these exchanges was setup at all with a given recipient. The amount of funds transferred is completely opaque
15:18 < petertodd> now the first transfer of funds *can* happen in the first tx - with coinjoin what happens means little, especially as the rule is it doesn't have too
15:18 < petertodd> in practice for user acceptance you probably want to usually send it in the same or follow-up tx - we can't make this stuff have barriers to usage
15:19 < petertodd> also note that you can't guarantee two separate txs will get mined in any particular order other than by waiting, which users hate...
15:20 < petertodd> and more generally, re-orgs have some nasty traps with this - you probably want to rescan starting at least a dozen blocks behind when you learn of a new chaincode
15:21 < petertodd> I also have my suspicions that for wallets with a lot of keys the original scheme of a straight 1/n-th anonymity set might actually be more scalable - if you end up with 500 incoming payments, all from different people, now you've really got to scan for 500 chain codes + some number of extras; gets ugly quick
15:22 <@gmaxwell> adam3us: yea, but that address was used mostly for computation bragging, not convenience... I don't use it for convenience... but I don't disagree with the argument and even repeated it above.
15:22 < petertodd> this chaincode stuff has a lot of state too on the wallet side...
15:22 <@gmaxwell> I agree having more private one way addresses is good, but the question is how to prevnet them from being generally awful to implement.
15:23 < petertodd> gmaxwell: well keep in mind the comparisons to bitcoin: we're using the blockchain as a communications channel, and you have an anonymity set of some fixed % of all traffic.
15:23 <@gmaxwell> oh you went on to say the same stuff, agreed.
15:23 < petertodd> *comparisons to bitmessage
15:24 < petertodd> see, one thing that might help is if you use the op-return ephemeral key as the selector as well, and then communicate a totally random nonce with that to generate a totally random address
15:25 < petertodd> even without fancy chaincodes, and putting the payment in the same tx, with coinjoin you've achived a lot of your goal of non-linkability via that anonymity set
15:25 < petertodd> not all of it, but a lot
15:26 < petertodd> that does imply we have indexes of op-return scriptPubKeys on a per-block basis, but I have no objection to that
15:40 <@gmaxwell> andytoshi: so when is your coinjoiner going to go back on mainnet?
15:43 < andytoshi> gmaxwell: as soon as i get a SSL cert
15:43 < andytoshi> by end of day today, i didn't realize there was any demand :}
15:44 < andytoshi> actually, i can put it on mainnet now.. it'd just be non-https
15:44 <@gmaxwell> andytoshi: ah, yea, I'd like to try to get some people around #bitcoin-otc doing a weekly organized coinjoin
15:45 < andytoshi> cool, it's just sync'ing now
15:45 <@gmaxwell> andytoshi: as far as the cert goes.. startssl... if you have any problems lemme know and I'll help out.
15:45 < andytoshi> there was a power outage 36 hours ago
15:45 < andytoshi> cool, thx
15:52 < andytoshi> ok, i think in 15 minutes it'll switch to mainnet
15:52 < andytoshi> we'll be able to tell because the donation address will switch over
16:08 < michagogo|cloud> andytoshi: Will it also be tor-accessible?
16:08 < michagogo|cloud> (hidden service, I mean)
16:13 < andytoshi> michagogo|cloud: yeah, i'll set that up
16:14 < andytoshi> the whole testing.wpsoftware.net domain used to be a hidden service actually..i think i didn't set that up when i replaced the server last year tho
16:18 < HM2> i hate ASN1 with a passion
16:34 < kinlo> andytoshi: what's the url for your coinjoiner?
16:35 < andytoshi> http://testing.wpsoftware.net/coinjoin/
16:35 < andytoshi> it says testnet but it is not anymore
16:38 < adam3us> petertodd: "ommunicating a BIP32 chaincode is you make it so the 1/n-th anonymity set only applies to the fact that one of these exchanges was setup at all with a given recipient" yes well that just reveals someone anonymous setup  a payment association (chain code) to the identified recipient; doesnt say who did it.
16:48 < CodeShark> cool, andytoshi
16:49 < CodeShark> lol - 1ForFeesAndDonationsSpendHer
16:50 < CodeShark> I tried…she didn't like it
16:50 < andytoshi> :P damn checksum..
16:59 < michagogo|cloud> andytoshi: s/Spend/Send/
16:59 < CodeShark> does it support multisignature transactions, andy?
16:59 < michagogo|cloud> one solution
17:00 < andytoshi> CodeShark: pretty sure, yes, it just validates it with bitcoind and my own coinjoin software
17:00 < andytoshi> and both of those are fine with it
17:00 < andytoshi> but to the best of my knowledge nobody has tested it
17:01 < CodeShark> I just did :)
17:01 < CodeShark> well, I submitted one
17:01 < andytoshi> oh, cool, i'll through a tx in then to join you
17:05 < andytoshi> done
17:05 < andytoshi> thx gmaxwell for the 'force inputs to match outputs' idea, i almost screwed myself
17:05 < andytoshi> and donated too much to my own joiner..
17:06 < CodeShark> so now we wait for 10 minutes?
17:07 < andytoshi> yup
17:07 < andytoshi> i can speed it up by prodding around in the db, but i'd probably fat-finger it, sorry
17:08 < CodeShark> presumably if we had higher volume we could reduce the wait time :)
17:08 < andytoshi> yeah
17:08 < andytoshi> idk if we'll get higher volume, maaku for example is developing a joiner that does automatic negotiation, so users don't have to be fiddling with rawtx's
17:09 < andytoshi> but i suppose i could write a client for my thing too
17:09 < CodeShark> I'm speaking theoretically, of course - this specific implementation needn't be the one that ends up taking off
17:10 < CodeShark> has anyone figured out a solution that doesn't require a server?
17:14 < CodeShark> is there any cryptographic transform that is invertible and commutative?
17:15 < CodeShark> so that ABA^(-1)B^(-1) = Identity?
17:16 < CodeShark> and applying A and A^(-1) requires knowledge of a secret
17:17 < CodeShark> ok, time's up
17:17 < andytoshi> CodeShark: ok, there is a donation to 1ForFeesAndDonationsSpendHerdtWbWy still in there <.<
17:17 < andytoshi> sorry, i'll fix that..
17:17 < CodeShark> hehe
17:18 < CodeShark> we can donate 0.000025 to the vacuum of space :)
17:20 < CodeShark> hmm, we're donating 0.00005 to the vacuum of space, it looks like
17:21 < andytoshi> yeah, it adds all donations to the same output
17:21 < CodeShark> hmm and the scriptSigs have been cleared completely
17:21 < CodeShark> that breaks my multisigner :p
17:21 < andytoshi> yeah, it drops everything when it's merging unsigned transactions
17:21 < andytoshi> really?
17:21 < andytoshi> hmm
17:22 < andytoshi> so, the way it tells when all the signatures have come in is that none of the scriptsigs are blank anymore
17:22 < CodeShark> hmmm - my multisigner cannot, in general, know whether it can sign any transactions unless the public keys are available
17:23 < CodeShark> also, it uses placeholders for signatures so different signers can add signatures
17:23 < CodeShark> I just use a 0-length signature to indicate "unsigned"
17:24 < CodeShark> but keep the keys/redeemscripts
17:26 < CodeShark> the reason for this is that different signing nodes could participate without having to know anything about how the p2sh addresses were generated
17:28 < CodeShark> if you can replace the scriptSig of my input with what I had originally submitted, I'll sign it:)
17:28 < CodeShark> I guess I could replace it on my end
17:29 < andytoshi> well, i've gotta fix the donation address thing
17:30 < andytoshi> then i'll think about what to do about scriptsigs...my assumption was that anything in there was just noise
17:30 < andytoshi> since if somebody had signed something, the signature would be invalid after joining
17:31 < CodeShark> inputs in general contain more than just signatures - it would be nice to have a separate field in the input just for signatures rather than just pushing them on a stack
17:31 < CodeShark> this is especially true for p2sh transactions
17:31 < andytoshi> yeah, bad assumption on my part
17:36 <@gmaxwell> petertodd: instead of using the signer's public key, perhaps use his r value (as its the x corrid for k*G). This has an advantage of working for more transaction types, and also if the sender is reusing addresses it wouldn't case reuse for payments to the same thing.
17:40 < andytoshi> CodeShark: this is a weird bug, it is failing to read the last byte of the address when it calculates the scriptpubkey of the donation address
17:41 < andytoshi> so the length is wrong and i'm also missing a byte
17:41 < andytoshi> but the logic looks correct and it worked with testnet <.<
17:42 < phantomcircuit> so it occurs to me that the behavior of IsConfirmed is already broken
17:42 < phantomcircuit> and simply removing the unconfirmed dependency checking is probably optimal
17:44 < andytoshi> oh, i see, i'm popping an entire byte to remove the version field .. but i guess that's not right .. i need to look up what i'm doing with these addresses
17:48 < CodeShark> so nobody has an answer for my earlier question? is there a cryptographic transform that has an inverse and is commutative such that ABA^(-1)B^(-1) = identity? gmaxwell? petertodd? :)
17:49 < CodeShark> I guess exponentiation...
17:49 < andytoshi> i think what you're asking describes blind signature schemes
17:49 < CodeShark> yeah :)
17:50 < CodeShark> so yeah, I suppose we can use exponentiation, where the inverses here are modulo phi(field modulus)
17:50 < andytoshi> so, the wiki article on that has an example using RSA, and there is an entry on matthew green's blog about ecc
17:50 < andytoshi> http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html
17:50 <@gmaxwell> CodeShark: just addition in EC groups works. (with the modular inverse to undo)
17:51 < CodeShark> right
17:54 < adam3us> andytoshi: there is an ec schnorr blind sig also
17:54 < adam3us> andytoshi: but no ecdsa one.  there is a horrendously complex dsa one.
17:54 < CodeShark> so the only part remaining to solve for decentralized coinjoin is peer discovery
17:54 <@gmaxwell> adam3us: did you see my commends about the ed25519 multupliers apparently requiring the scalar to have the high bit set?!
17:55 < andytoshi> gmaxwell: fwiw we can remove that requirement
17:55 < andytoshi> and even maintain timing resistence
17:55 <@gmaxwell> sure we can, but we lose their good existing implementation and become formally incomaptible, which is lame.
17:56 <@gmaxwell> andytoshi: there was also something about requiring the scalars to be a multiple of 8 which I didn't understand at all.
17:56 <@gmaxwell> and I assume its just confused.
17:56 < andytoshi> yeah, i didn't get that either, i was hoping a wizard would be able to clarify
17:56 < andytoshi> or that somebody on crypto.SE would step in
17:56 < andytoshi> somebody not confused *
17:56 < nsh> where is this discussed?
17:57 < nsh> (or specified)
17:57 < andytoshi> nsh: http://crypto.stackexchange.com/questions/12425/why-are-the-lower-3-bits-of-curve25519-ed25519-secret-keys-cleared-during-creati
17:57 < nsh> ty
17:57 < andytoshi> i posted that a few days ago, gmaxwell is continuing without context :P
17:57  * nsh smiles
17:57 <@gmaxwell> andytoshi: I didn't remember you posted it, it got left up in a tab.
17:58 <@gmaxwell> the responses there are just confused.
17:58 < BlueMatt> gmaxwell: the internet only works when you respond and correct them :)
18:00 <@gmaxwell> well I can correct the highest bit thing I know why it does that, though it's crappy and overoptimized.
18:00 <@gmaxwell> the *8 thing I have no freeking idea
18:10 < adam3us> gmaxwell: yes i am also not sure what the formula is achieving... djb paper is obtuse, but i guess he does answer email.  or we should ask on sci crypt cc him or they have some dev resources for the lib?
18:13 < nsh> --
18:13 < nsh> Ed25519 keys start life as a 32-byte (256-bit) uniformly random binary seed (e.g. the output of SHA256 on some random input). The seed is then hashed using SHA512, which gets you 64 bytes (512 bits), which is then split into a “left half” (the first 32 bytes) and a “right half”. The left half is massaged into a curve25519 private scalar “a” by setting and clearing a few
18:13 < nsh> high/low-order bits. The pubkey is generated by multiplying this secret scalar by “B” (the generator), which yields a 32-byte/256-bit group element “A”.
18:14 < nsh> -- https://www.readability.com/articles/gswpw12d
18:14 < nsh> just quite blaze "massaged into ... by setting and clearing a few .. bits"
18:15 < nsh> so no particular indication the author (Brian Warner from Mozilla) thought much of the reasoning
18:17 <@gmaxwell> it's not surprising that points have a special form, it's very surprising that scalars have a special form. The high bit set is for timing attack resistance in the multipler. I can only assume that the low bits is some other psycho performance optimization.
18:18 < adam3us> gmaxwell: its kind of remiss that they dont explain in the paper really
18:43 < andytoshi> gmaxwell: https://www.wpsoftware.net/coinjoin/ should be working
18:44 < andytoshi> as discussed with CodeShark, it strips scriptSigs, which may cause problems for complex use cases
18:46 < petertodd> andytoshi: cool, just submitted a tx
18:48 < petertodd> gmaxwell: yeah, but the r value is public, which lets anyone who knows the stealth address deanonymize you - you might as well just use the txid:vout
18:48 < petertodd> andytoshi: hmm, got " Sorry, this session was not found. "
18:48 < andytoshi> petertodd: yeah, and it's claiming that the session is -92 minutes old
18:49 < andytoshi> sorry, one moment
18:49 < petertodd> andytoshi: now -94 minutes :p
18:49 < andytoshi> oops, permission error
18:50 < andytoshi> should be good now
18:50 < andytoshi> but you'll have to resubmit
18:50 < petertodd> just did
18:52 < petertodd> cool, anyone else want to submit?
18:52 < andytoshi> sure, i'll submit one
18:53 < petertodd> andytoshi: "The most popular output value is 0.0005" <- treating the fee as popular
18:53 < andytoshi> yeah, i noticed that :P
18:53 < andytoshi> probably not a useful behavior
18:53 < petertodd> yeah
18:55 <@gmaxwell> adam3us: the number of the points isn't @#$@#$@#$@ prime. it has a @#$@#$@ cofactor of 8.
18:56 <@gmaxwell> petertodd: wtf. no. the r value is _exactly_ like your public key.
18:56 <@gmaxwell> K is the cooresponding private key.
19:00 < petertodd> gmaxwell: ah I see what you mean, that works
19:02 < andytoshi> petertodd: cool, i joined you
19:02 < petertodd> andytoshi: cool, so I sign when the tx closes right?
19:02 < andytoshi> yeah, if the window is open it should play a chime
19:02 < andytoshi> in 5 minutes
19:04 < petertodd> andytoshi: a nice feature would be to list not just popular output values, but also combinations of input values that you might want to match
19:04 < andytoshi> in future, it will not use donations in computing the popular outputs
19:04 < petertodd> andytoshi: though obviously that gets complex :)
19:04 < andytoshi> petertodd: yeah, agreed, the devil is in the details
19:04 < amiller> andytoshi, that's cool
19:04 < andytoshi> gmaxwell suggested just showing all the output values which appear at least twice
19:05 < andytoshi> or an arbitrary one, if none do
19:05 < CodeShark> you could also use a second transaction to further split outputs
19:06 < CodeShark> hmmm, although if not careful, that can leak information
19:06 < petertodd> andytoshi: "The current session is open for -0 more minutes."
19:06 <@gmaxwell> The current session is open for -0 more minutes.
19:07 < andytoshi> petertodd: lol, it won't go actually negative
19:07 < andytoshi> agreed, i should fix that bug
19:08 < petertodd> andytoshi: signed and submitted
19:08 < CodeShark> you could have all inputs be the same value, then have each submitter send a change output
19:08 < andytoshi> cool, one sec, i'll just verify
19:09 < CodeShark> participants could create specifically denominated outputs beforehand
19:09 < CodeShark> to use as inputs in this transaction
19:09 < andytoshi> i submitted too, in a minute it should give us a txid
19:09 < andytoshi> CodeShark: also a good idea
19:10 < andytoshi> it's hard to say what would be best, and all the ideas proposed involve a lot of work ;)
19:11 < petertodd> andytoshi: fee is a bit low
19:12 < petertodd> andytoshi: off by one digit
19:12 < andytoshi> really?
19:12 < CodeShark> requiring specifically denominated outputs should be easy to implement from your perspective - you just need to have multiple "rooms" for different denominations, ensure the inputs are the same value. you do need a txindexed database to query against to get input values, though
19:12 < CodeShark> err, specifically denominated inputs
19:13 < andytoshi> petertodd: the code uses 1500 satoshi / kb
19:13 < petertodd> andytoshi: it's 688 bytes, so the fee should be at least 0.0000688 BTC
19:14 < andytoshi> oh, i am off by a power of ten
19:14 < andytoshi> shit
19:14 < petertodd> heh
19:14 < CodeShark> the 0.1 room, the 1.0 room, the 10.0 room, etc.. :)
19:15 < andytoshi> really
19:15 < andytoshi> ? 15000 seems wrong
19:15 < andytoshi> 10000*
19:15 < CodeShark> you might also want to charge the fee proportional to the number of bytes contributed
19:16 < CodeShark> for each participant
19:16 <@gmaxwell> you don't know the bytes in advance, alas.
19:16 < CodeShark> well, you don't know the signatures
19:16 <@gmaxwell> though you can compute a conservative estimate but it makes it hard to use.
19:16 < petertodd> andytoshi: int64 CTransaction::nMinRelayTxFee = 10000
19:16 <@gmaxwell> CodeShark: which is almost all the bytes.
19:16 < andytoshi> i'm already using a conservative estimate
19:16 < petertodd> andytoshi: 15000 is a good value
19:16 < CodeShark> but you can estimate the signature size
19:16 < andytoshi> ok, that's what i'm going to use then
19:17 < andytoshi> i'll have to jack up the minimum donation
19:17 < petertodd> andytoshi: I wouldn't worry about maybe too high fees myself
19:18 < andytoshi> ok, so the site now demands 10000 satoshi from each participant
19:18 < andytoshi> from that, it submits 15000/kb to network fees, and keeps the rest (if any)
19:18 < petertodd> andytoshi: heck, scriptSigs are limited to 520 bytes or something IsStandard - that's not that much more than the usual scriptSig size, so just assuming that with absolute min fees wouldn't be a big deal
19:18 < CodeShark> another way to deal with the fee calculation is have each participant specify a change output - then you calculate fees on your end and set the value accordingly
19:20 < CodeShark> as a convention, for instance, the first output of the transaction can always be treated as the change output
19:20 < CodeShark> or the last
19:20 < andytoshi> CodeShark: i don't think that much complexity is needed
19:20 < CodeShark> of course, you should shuffle it on your end before signing is done
19:20 < CodeShark> point is you could set the fees yourself
19:20 < andytoshi> yes, there is shuffling done
19:21 < CodeShark> without requiring the participants to calculate the fee
19:21 < CodeShark> makes it easier to use :)
19:21 < andytoshi> CodeShark: if they want ease of use they can just send a ton to the donation address ;)
19:21 < CodeShark> lol
19:22 < andytoshi> petertodd: should i fix our transaction and try to resubmit it? my node has not seen it yet for example
19:22 < andytoshi> i'd have to pm you for a new signature
19:22 < petertodd> andytoshi: sure
19:22 < petertodd> andytoshi: or fix the site and I'll just do another join
19:23 < andytoshi> the site is fixed, but it won't let you put the same inputs in
19:23 < petertodd> ah
19:24 < andytoshi> yeah, quite frustrating
19:24 < andytoshi> gimme a couple minutes..
19:30 < petertodd> just started a fresh tx if anyone wants to join
19:31 <@gmaxwell> pretty high minfee now.
19:32 < petertodd> gmaxwell: low compared to the value of my time :P
19:33 <@gmaxwell> yea, its not bad.
19:34 < andytoshi> sorry, i can't join, all my money is in the one i just did with petertodd :P
19:34 < petertodd> andytoshi: ha
19:39 <@gmaxwell> andytoshi: heh one lame thing with the rotation is that if you only get one other player the timer really doesn't have time to go solicit more.
19:40 < andytoshi> yeah, my original plan was to make it be open for 24 or 48 hours
19:41 <@gmaxwell> thats so long people will lose attention though.
19:41 < andytoshi> i joined this one with a small 0.008 input and spent it all to the donation address..
19:42 < andytoshi> gmaxwell: yeah, it's a tough balance
19:42 <@gmaxwell> hah. I guess thats something you have the ability to do! :P
19:42 <@gmaxwell> easier if in the future there is a autosigner.
19:42 < andytoshi> :P i am actually doing the spent-through-coinjoin trick we talk about
19:48 <@gmaxwell> andytoshi: the sound thing works, no color change? :P
19:49 <@gmaxwell> I feel like window 3.1 encountered an error.
19:50 < nsh> ehehe
19:51 < petertodd> andytoshi: looks good this time
19:51 < petertodd> andytoshi: dunno why it says "this transation has a non-standard input" on bc.i though
19:52 <@gmaxwell> it does?
19:52 < petertodd> gmaxwell: https://blockchain.info/tx/33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1
19:54 < CodeShark> someone could run a bot that constantly submits transactions at specific demoninations for inputs with random outputs
19:54 < CodeShark> so that there are always enough "participants" :)
19:54 < petertodd> CodeShark: the bot to run is one that matches other peoples outputs and/or input combinations on demand
19:54 < CodeShark> right :)
19:55 <@gmaxwell> petertodd: doesn't say that for me.
19:55 < CodeShark> so you could specify a minimum number of participants and a maximum amount of time to wait - if in that time, the number of participants is below what you asked for, a bot fills in the rest
19:55 < petertodd> gmaxwell: the little triangle thing in "estimated confirmation time"
19:56 <@gmaxwell> what is a "_none_ standard input"
19:56 < petertodd> beats me
19:57 < CodeShark> you'd want the bot to fill each of the remaining slots using a separate wallet
19:57 <@gmaxwell> isn't the fee a bit high?
19:57 < petertodd> no, 1.5x minimum
19:57 <@gmaxwell> got it.
20:15 <@gmaxwell> petertodd: it seems to me that pond could be combined with bitmessage ... where bitmessage was used for small messages and notifications that you had messages waiting ... so that it didn't have to constantly poll.
20:16 <@gmaxwell> the polling probably makes parties substantially more vulnerable to traffic analysis should their pond server be compromised.
20:16 < petertodd> gmaxwell: makes sense, better bandwidth utilization too
20:17 < BlueMatt> gmaxwell: wasnt pond supposed to be constant-bandwidth?
20:17 < nsh> what's this pond thing now?
20:17 < BlueMatt> or am I thinking of a different one?
20:17 < BlueMatt> nsh: https://pond.imperialviolet.org
20:17 < nsh> ty
20:18 <@gmaxwell> BlueMatt: it doesn't appear to be but if it is that still doesn't prevent traffic analysis. E.g. if your pond server is compromised it still knows when you (by your group ID) poll.  and the fact that you keep polling over and over and over again (10 minutes appears to be the default) makes tracing the tor a lot easier.
20:19 <@gmaxwell> petertodd: depends on usage patterns. ... you'd have to have a very high number of users who never had any traffic then perhaps a flooding network for you-have-new-messages may well indeed be more efficient. Certantly pond for large objects is way more efficient than bitmessage.
20:19 < BlueMatt> well, yes, if your server is compromised, but at least thats stronger than if the encrypted links to your server are compromised
20:20 <@gmaxwell> pond also doesn't seem to have any real way of handling "your server got taken down" that I can see, it looks like you have to start a totally new identity and rebuild your contacts?
20:24 < BlueMatt> are there any actually good products for having secure group messaging today?
20:24 < andytoshi> gmaxwell: that chime is actually me on the piano
20:24 < petertodd> BlueMatt: oh, interesting bugs in bloom FWIW
20:24 < andytoshi> i was quite sad to discover it was the win3.1 chime :P
20:25 < petertodd> BlueMatt: define "secure" and "group" :P
20:25 < nsh> you should sure microsoft for retroactively stealing your chimetulectual property
20:25 < BlueMatt> petertodd: oh?
20:25 < nsh> *sue
20:25 < petertodd> BlueMatt: I mean, what you were telling me - I need to think about that stuff some more
20:26 < BlueMatt> petertodd: oh, yes
20:26 < BlueMatt> its possible to fix, but not in a clean way afaict
20:26  * BlueMatt fucked it up...suppose thats what I get for running out of time and just trying to get it done...
20:26 < CodeShark> could coinjoin be defeated by someone who inserts the vast majority of requests?
20:27 < CodeShark> you join a transaction, think there are 10 participants, when actually 9 of them are an attacker
20:27 < BlueMatt> petertodd: secure: otr-like security, group: >= 3 technically-minded people
20:27 < petertodd> BlueMatt: yeah, good example of how important analysis is up front :(
20:27 < petertodd> BlueMatt: right, where the group can trust each other not to leak
20:28 < BlueMatt> petertodd: well, I did analyse it, and had a good design....then it needed tweaking to make it more useable, but I was out of time, so I tweaked it until it worked
20:28 < BlueMatt> now I realize I tweaked it until it broke...but it works
20:28 < petertodd> BlueMatt: do you have that original analysis written up somewhere? good starting point for fixing it
20:29 < BlueMatt> writeup? noooo
20:29 < petertodd> BlueMatt: stained napkin?
20:29 < BlueMatt> stained braincells, sure
20:30 < BlueMatt> anyway, my brief thoughts over the past two days dont indicate any clear way of keeping the "efficiency" (ie not making it worse than it already is for serving nodes) while improving the privacy
20:30 <@gmaxwell> andytoshi: where is the actual url to your chime?
20:31  * nsh is starting to think computers should not ever have access to plaintext
20:31 < nsh> that decoding of anything into human-comprehensible form should only be done by an input-only device you wear as glasses or something
20:31 < CodeShark> homomorphic encryption? :)
20:32 < nsh> aye, it's at least a weekend project :)
20:32 < petertodd> BlueMatt: figures
20:32 < petertodd> BlueMatt: I think it's just a fundemental problem where it's a tradeoff between efficiency and anonymity set size
20:33 < petertodd> BlueMatt: I'm actually thinking we might be better off with this stealth address idea/reinvention of mine and just using a fixed % of all addresses as your anonymity set
20:33 < BlueMatt> petertodd: no, I mean its very possible to get that tradeoff decent, you just have to do something like make the server Hash256^2 all elements tested against the filter as well as the element itself
20:33 < BlueMatt> or push the hash160 of the pubkey onto the scriptSig as an extra element
20:34 < BlueMatt> s/Hash256^2/hash160/
20:34 < BlueMatt> you can get verry good download speeds with a fp rate of like 0.005% or so, which gives you a pretty big anonymity set
20:34 < BlueMatt> or even 0.01%
20:34 < BlueMatt> hell, a desktop does fine higher than that
20:35 < petertodd> andytoshi: interesting, I did a tx where I was all parties, and sent it on my own node, and it just said "invalidated"
20:35 < BlueMatt> should have you a litecoinj as a christmas present...
20:35 < petertodd> BlueMatt: maybe we're thinking of different things; I'm more talking about a perfect bloom filter with optimal behavior
20:35 < BlueMatt> ehhh, damn missing /msg
20:36 < petertodd> BlueMatt: heh, I could go for that
20:36 < petertodd> BlueMatt: maybe a mastercoinj while we're at it
20:36  * petertodd ducks
20:36 < CodeShark> haha
20:36  * BlueMatt kicks petertodd's ducking head
20:36 < CodeShark> that's not very nice...
20:37 < CodeShark> I mean, to bring up mastercoin :p
20:37 < petertodd> CodeShark: lol
20:37 < BlueMatt> petertodd: well, ok, but as far as I'm concerned, having an anonymity set of a few thousand addresses besides your own is perfectly reasonable for 99% of people
20:38 < BlueMatt> the rest can damn well run full nodes
20:38 <@gmaxwell> it's not quite that simple, because there are usually several other bits of deanonymizing data available.
20:38 <@gmaxwell> and so a set of thousands is quite often a set of 1.
20:39 < petertodd> for instance the nTweak itself can be a deanonymizer...
20:39 <@gmaxwell> at least bloom only reveals it to your servers.
20:39 < BlueMatt> I dont think its nearly /that/ bad, sure you can get rid of lots of fps with some analysis, but getting it down to 1 would require as much (or far less) effort than just breaking in and stealing a computer...
20:39 < BlueMatt> petertodd: how?
20:39 <@gmaxwell> BlueMatt: getting it down to a few is how you figure out which computers to go steal. :)
20:40 <@gmaxwell> (go look at that bomb threat moron.  They simply enumerated all the people on campus who had used tor near the time in question and went and intimidated them all and the guilty party confessed)
20:41 < petertodd> BlueMatt: by reusing it multiple times you have a 32-bit unique value that identifies you across multiple connections
20:41 < BlueMatt> petertodd: so...dont use it multiple times?
20:42 <@gmaxwell> I don't know why you'd reuse it?
20:42 < BlueMatt> gmaxwell: I'm not sure we're thinking of the same threat model here...
20:43 < BlueMatt> the main threat model a bloom filter addresses is your upstream nodes finding out who you are
20:43 < petertodd> gmaxwell: if you don't reuse it, and someone matches multiple instances of bloom filters to you, they can AND all the addresses matched by the filters to narrow down the actual ones in your wallet
20:43 < BlueMatt> not the network tracking down where given addresses lie
20:43 <@gmaxwell> petertodd: ah. point, right I knew this before.
20:44 < petertodd> gmaxwell: damned if you do, damned if you don't, unless everyone just uses the same nTweak, but then you have DoS attacks
20:44 < petertodd> gmaxwell: I mean, prefix-filtering has those DoS attacks too of course, but at least we know they're expensive
20:44 < BlueMatt> petertodd: this is why you dont use the same nodes multiple times (but mitm?: no, at that point you already know your target, whats the point?)
20:44 < petertodd> BlueMatt: your target can easily run a high % of the nodes on the network
20:44 <@gmaxwell> [OT] http://www.gwern.net/Blackmail   I'm amused by this both because of gwern whining about people thinking he's satoshi while he's been super agressively trying to deanonymize satoshi elsewhere, and also accusing random people of being satoshi.  Also amused by the moron he's talking to who _cant_ get pgp right.
20:45 < petertodd> BlueMatt: s/target/attacker/
20:45 < petertodd> BlueMatt: less relevant given that bitcoinj doesn't do Tor yet, but one day...
20:45 < BlueMatt> petertodd: yes, at this point you're fucked anyway...
20:46 < BlueMatt> petertodd: (note the model here is a phone who's ip changes every 10 minutes)
20:46 < BlueMatt> petertodd: bitcoinj /does/ do tor now
20:46 < BlueMatt> (on master, no support for hidden services)
20:47 < BlueMatt> sure, with enough nodes you can AND everything together and find results which have large intersections, but that should be very expensive
20:47 < petertodd> BlueMatt: no, I don't think you necessarily are. e.g. many scalability schemes spread the work out over multiple shards, which means a client can just subscribe to some subset
20:47 < petertodd> BlueMatt: why? running nodes is cheap - all you need is ip addresses
20:47 < petertodd> BlueMatt: they don't actually need to even be unique nodes...
20:47  * gmaxwell waits for one of you guys to find http://percy.sourceforge.net/
20:48 < petertodd> gmaxwell: meh, that's the kind of thing only a wizard would understand, oh wait...
20:48 < andytoshi> gmaxwell: wpsoftware.net/coinjoin/chime.wav
20:49 < andytoshi> it is actually a MIDI of a c chord run through the fluid soundfont that came from fedra
20:49 < andytoshi> fedora*
20:49 < petertodd> BlueMatt: with payment protocols you're doing especially well, because fixed filters (prefix or bloom) mean it's basically like a well design bitmessage: all the adversary knows is you keep on getting some consistent % of the transaction space
20:49 < petertodd> BlueMatt: they can't do any better than that to deanonymize you
20:50 < petertodd> BlueMatt: (ie, you never actually send a transaction) Handling sends can be done via special-purpose mixnets and what not too
20:50 <@gmaxwell> petertodd: except you suggest making the data visible to everybody instead of a finite number of possibly evil servers.
20:50 < BlueMatt> petertodd: I didnt say it wasnt possible, I know its very possible to become some large % of network nodes
20:51 < petertodd> gmaxwell: not necessarily: remember the version where all you leak is the fact that *a* payment was made, not the details of what txout in the transaction was involved, which is doubly hidden via coinjoin
20:51 < BlueMatt> petertodd: I was saying that if you're a client who's ip changes regularly (ie you cant identify one client from one session to the next), then the AND attack is difficult due to the large cost of ANDing together all combinations of filters you've ever seen....
20:52 < BlueMatt> s/large/impossibly large/
20:52 < BlueMatt> generally the "ip changes regularly" part is quite ugly, but its realistic on many networks, especially mobile ones
20:52 < petertodd> BlueMatt: problem is IP's don't neccessarily change like that - NAT maps things to the same IP, and the clients leak a bunch of info because they give version strings
20:53 < BlueMatt> on android the upgrades happen at ~the same time, so version string doesnt leak much there
20:53 < petertodd> BlueMatt: sure in a perfect world the ANDs are hard, but that's a perfect world...
20:54 < nsh> 1. make perfect world
20:54 < nsh> 2. build cryptosystems
20:54 < BlueMatt> petertodd: agreed, there are certainly cases where its not good...my point is just that coming up with a realistic threat model where these things break down and where the attack is still realistic is pretty hard
20:54 < petertodd> BlueMatt: heh, that's in some ways worse: you probably can use update lags to start tracking down your target, although at least that's a NSA adversary
20:54 < BlueMatt> (if you already know who it is, just go hit them with a wrench instead...)
20:55 < BlueMatt> easier for an nsa adversary to just hack your baseband :p
20:55 < BlueMatt> and, again, anyone who's concerned about an nsa adversary probably wants an anonymity set of the whole network, not any subset thereof
20:55 < petertodd> BlueMatt: maybe... they don't like using their sophisticated exploits if they can help it
20:56 < petertodd> BlueMatt: anyway, my main point is there's a shitload of tradeoffs involved here, and there probably are good designs that we haven't considered carefully enough
20:56 < BlueMatt> yes, certainly
20:56 < BlueMatt> my point is that there are more pressing issues as what we have is ~workable
20:56 < petertodd> BlueMatt: that there isn't a master tradeoffs document outlining the thought process isn't a good sign...
20:56 < BlueMatt> maybe with some small tweaks
20:57 < BlueMatt> petertodd: lol, what in bitcoin has such a doc?
20:57  * nsh imagines compropedia -- the definitive interactive animated guide to trade-offs in security models
20:57 < nsh> with sliders
20:57 < nsh> mmmm, sliders
20:57 < petertodd> BlueMatt: well, remember that it looks like electrum will be implementing prefix filtering because of how it fits there model well, so I'd like to understand that well, and this stealth address stuff involves a similar set of considerations
20:58 < petertodd> BlueMatt: gee, I dunno: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03508.html
20:59 < BlueMatt> petertodd: ok, what before very recent stuff in bitcoin has master tradeoff docs like that?
20:59 < petertodd> BlueMatt: heh, fuck all
21:00 < BlueMatt> petertodd: :)
21:00 < petertodd> BlueMatt: I also gotta do one up for, dare I say it, mastercoin...
21:00 < BlueMatt> ewwwwww
21:01 < petertodd> BlueMatt: so much disgust as blank canvases, just waiting to be filled with beautiful consensus systems...
21:01 < petertodd> BlueMatt: s/as/about/
21:01 < BlueMatt> petertodd: anyway, the analysis for bloom filters was largely started on an original version that looked up input scriptPubKeys (which was a bit disk expensive, surprise, surprise...) and the privacy provided vs efficiency tradeoff on the client side was really quite good
21:02 < BlueMatt> petertodd: yes, I would like it if it were 1:1 pegged to bitcoin and on its own merged-mined chain
21:02 < BlueMatt> until then, ewwwwwww
21:03 < BlueMatt> petertodd: if you can come up with a script type that is easily matched by one element in both the scriptPubKey of an output and the scriptSig spending that output, the bloom filter model would go back to that
21:03 < petertodd> BlueMatt: it's not going to be merge-mined unless some major advances in crypto-coin theory are made
21:03 < BlueMatt> and the anonymity set could be ramped up with tiny thin clients being able to handle it fine
21:03 < BlueMatt> (eg, push the hash160(pubkey) to the back of the scriptSig after the pubkey/sig)
21:04 < BlueMatt> well, ok, if you can come up with a way to do it so that you dont risk missing txn if a key is imported to a different client (or block that?) and a good upgrade path
21:04 < BlueMatt> petertodd: why not?
21:06  * BlueMatt hurtles at a runway a few hundred mph and decides to get off irc
21:07 < petertodd> BlueMatt: isn't just defining bloom v2 that matches H(element) and element simultaneously enough?
21:07 < petertodd> BlueMatt: merge-mining is insecure
21:07 < petertodd> BlueMatt: ha, have fun
21:08 < BlueMatt> petertodd: too expensive for servers, I think
21:08 < BlueMatt> needs further testing, I suppose
21:08 < petertodd> BlueMatt: why? it's just one extra hash and comaprison per element
21:08 < BlueMatt> petertodd: yes, a 1:1 pegged merged-mined coin can be more secure
21:08 < BlueMatt> there are currently 0 cryptographic hashes per element right now
21:08 < petertodd> BlueMatt: no it can't - merge-mining means the cost to attack is near zero
21:08 < BlueMatt> youre now making it 2
21:08 < petertodd> BlueMatt: hashes are fast...
21:09 < petertodd> BlueMatt: gurantee you disk io is a bigger problem
21:09 < petertodd> BlueMatt: also, those hashes can be cached easily and re-used for multiple clients
21:11 < BlueMatt> petertodd: yes, disk io is currently the problem, I'm not entirely convinced that the hashes arent also expensive if you assume nodes are only serving some small section of the chain (ie the past 1k blocks served out of memory)
21:11 < BlueMatt> petertodd: if you're gonna cache them on disk, you should just match both scriptSig and the scriptPubKey its spending
21:11 < BlueMatt> thats more general and as easily cached
21:11 < BlueMatt> anyway, actually landing
21:11 < petertodd> BlueMatt: heh, have fun
21:12 < petertodd> BlueMatt: That is a good point: any per block index of scriptPubKeys should have a per-block index of scriptPubKey's spent.
21:12 < petertodd> *of scriptPubKeys created
22:10 <@gmaxwell> andytoshi: can you setup a simple http page that gives a one line coinjoin status? e.g. something we could ask nanotube to have gribble query?
22:11 <@gmaxwell> andytoshi: e.g. the number of txn in the queue, popular output(s), time remaining.
22:12 < andytoshi> sure, one moment
22:14 < andytoshi> plain text?
22:16 <@gmaxwell> nanotube: what would be useful for gribble?
22:16 <@gmaxwell> I assume plaintext is fine, since thats what the old blockexplorer api was.
22:17 < andytoshi> https://www.wpsoftware.net/coinjoin/status.php
22:18 < andytoshi> when there is a transaction in there, it is pretty verbose..
22:18 < andytoshi>     echo 'The current session is open for ', Session::time_to_switch(), ' more minutes. There ',
22:18 < andytoshi>          'are currently ', Bitcoin::unsigned_tx_count(), 'transactions in the pot. The most ',
22:18 < andytoshi>          'popular output value is ', Bitcoin::most_popular_output(), '.';
22:19 <@gmaxwell> does the way it works now have a session 'close' and open for signing?  e.g. is there also a need for a status.php?id=deadbeef  to find out if a past session is still in need of signatures?
22:19 < andytoshi> yeah, there is a flag in the database which sets the "active" session
22:20 < andytoshi> one moment..
22:21 <@gmaxwell> (might be useful in harassing people to finish signing in an IRC join)
22:25 < andytoshi> see eg https://www.wpsoftware.net/coinjoin/status.php?session=fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63
22:26 <@gmaxwell> andytoshi: maybe a lark you'll think is stupid. But I think it should display a "round name" from the session ID, which is converted to english using a spookwords list (e.g. http://attrition.org/misc/keywords.html ) so it tells you that "session fissionable Indigo speedbump is live in three signatures."
22:27 <@gmaxwell> I have no idea where a good name generator is though, the link there was a random google result.
22:27 < andytoshi> :P i think that'd be awesome
22:27 < andytoshi> i'll look into it
22:27 < Luke-Jr> Is there a reason alex_fun hasn't had at least a kick or warning in #bitcoin-dev yet? He seems to intentionally flaunt being off-topic :/
22:28 < andytoshi> my brainwallet uses six random words from Great Expectations, and they always come out as stories
22:28 < andytoshi> in fact, i never use it as a brainwallet, just for making passwords
22:28 <@gmaxwell> Luke-Jr: I prodded him in PM which promoted
22:28 <@gmaxwell> 19:07 < alex_fun> guys and girls whatever really , u feel rigid its u choise
22:28 < andytoshi> nanotube: the source for status.php is here: http://pastebin.com/ra8NTFxA
22:29 < andytoshi> nanotube: i'm happy to change the formatting however you see fit
22:30 <@gmaxwell> andytoshi: there doesn't seem to be any good "topsecret codeword" generators though there are lots of lists of sutiable words.
22:33 < maaku> CodeShark: the joiner I'm working on 100% p2p
22:33 < maaku> but it's not something I'm spending a lot of time working on ...
22:34 <@gmaxwell> I think of andy's thing as something fun that people can use right now. It's obviously not what we need long term, and (at least right now) doesn't really overlap or compete with better ways of doing it.
22:35 < andytoshi> to Luke-Jr's point, alex_fun has been around for many months (years?)
22:35 < andytoshi> i thought luke was yelling at ghosts, and it turned out that there was in fact some alex_fun in my /ignore list, which i'd put there so long ago i'd forgotten
22:36 < maaku> yeah he's a troll that's been around a while
22:36 <@gmaxwell> I think he's just another yibbering idiot.
22:36 < maaku> gmaxwell: i don't mean to imply anything negative. CodeShark just asked earlier if anyone is working on a server-less joiner
22:36 <@gmaxwell> ah!
22:38 < andytoshi> maaku, gmaxwell: i agree with gmaxwell's opinion of my joiner, i'm glad it's usable but it's mostly a way for me to learn rust
22:46 < maaku> it's good work andytoshi, and better to have something working than the perfect unimplemented whiteboard design
22:46 < maaku> my weakness is that I spend too much time on the latter (see: freimarkets)
23:23 < nanotube> ;;alias add cjs web fetch https://www.wpsoftware.net/coinjoin/status.php
23:23 < gribble> The operation succeeded.
23:23 < nanotube> ;;cjs
23:23 < gribble> Error: This url is not on the whitelist.
23:23 < nanotube> >_>
23:23 < nanotube> just a sec lol
23:23 < Luke-Jr> lol
23:24 < nanotube> ;;cjs
23:24 < gribble> There is no currently open session.
23:24 < nanotube> there :P
23:24 < nanotube> ;;alias add coinjoinstatus cjs
23:24 < gribble> The operation succeeded.
23:24 < nanotube> for those who prefer a more verbose command. :)
23:24 <@gmaxwell> nanotube: hurrah
23:25 < andytoshi> nanotube: can we make ;;cjs fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 go to status.php?session=fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63
23:25 < andytoshi> ?
23:26 < andytoshi> also, thanks! :)
23:26 < nanotube> yes, technically speaking. :) question is, if session id is blank, will it still work?
23:26 < nanotube> ;; web fetch https://www.wpsoftware.net/coinjoin/status.php?session=
23:26 < gribble> There is no such session.
23:26 < andytoshi> nope, one moment..
23:26 < nanotube> ;; web fetch https://www.wpsoftware.net/coinjoin/status.php?session=fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63
23:26 < gribble> This session is complete. The submitted transaction ID was 33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1.
23:27 < andytoshi> ;; web fetch https://www.wpsoftware.net/coinjoin/status.php?session=
23:27 < gribble> There is no currently open session.
23:27 < andytoshi> there we go
23:27 < nanotube> nice. :) i could do it either way, but it would be more trivially easy if empty sessionid defaulted to general query.
23:28 < andytoshi> yeah, this is probably the better behavior for when users put a blank session= anyway
23:28 <@gmaxwell> ;;cjs Halcon Capricorn
23:28 < gribble> Coinjoin Status: There is no such session.
23:28 <@gmaxwell> aww
23:28 < andytoshi> i've got a python script which converts to codewords, but not the other direction
23:29 < nanotube> ;;cjs fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63
23:29 < gribble> Coinjoin Status: This session is complete. The submitted transaction ID was 33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1.
23:29 < nanotube> ;;cjs
23:29 < gribble> Coinjoin Status: There is no currently open session.
23:29 < andytoshi> :D
23:29 < nanotube> there we go. :)
23:29 < nanotube> ;;help cjs
23:29 < gribble> (cjs <an alias, 0 arguments>) -- Alias for "echo Coinjoin Status: [web fetch https://www.wpsoftware.net/coinjoin/status.php?session=@1]".
23:29 < nanotube> ;;cjs Halcon Capricorn
23:29 < gribble> Coinjoin Status: There is no such session.
23:29 < nanotube> heh
23:30 < nanotube> ;;sl halcon capricorn
23:30 < gribble> http://www.youtube.com/watch?v=DITktReXJpI | 4 Dic 2011 ... Horoscopo Maya 2012 KosmosErika HALCON, para los nacidos del 7 de ... CAPRICORN Horoscope for JANUARY 2014 - Karen Lustrupby ...
23:30 < nanotube> >_>
23:30 < andytoshi> right now this fd1d19 guy turns into "DIA sorot van 1071 JSOFC3IP Cornflower Electron PBX Ionosphere CSC EG&G MKNAOMI PBX Iris WWSP RSO MD5 USACIL JCE NSWC IACIS LEASAT Yukon GGL NAIA"
23:30 < andytoshi> so it should be a bit shorter :P
23:30 < nanotube> heh yea... but it is a pretty long string....
23:31 < andytoshi> so, the sessid is actually only 32 bits from /dev/urandom right now
23:31 < andytoshi> i just run it through sha256 :P
23:31 < andytoshi> it has lots of room to go shorter
23:31 < nanotube> ah good old sha2
23:34 <@gmaxwell> making the small big and the big small since 2001.
23:35 < andytoshi> ok, future sessions will use 8 bytes of randomness and output the first 16 chars of the hash
23:35 < andytoshi> that translates to 7-8 words, which looks good
23:35 < andytoshi> [username@titanic spookwords]$ ./main.py fd1d19c88eaa675d
23:35 < andytoshi> FID DDP Embassy Bluebird GEO Canine 1911
--- Log closed Mon Dec 23 00:00:19 2013