00:06:32 maaku: yeah, that's the name for doing mathematics that way (e.g. rejecting proofs by contradiction) 00:07:07 there are subsets of logic (which i have ~0 knowledge of) which do things like fuzzy logic and try to make this concrete 00:08:16 my girlfriend was into constructivist math for a short while, not believing in anything that wasn't computable 00:08:28 but it's nearly impossible to do a lot of classical mathematics that way 00:22:21 depends how you define "doing mathematics" 00:22:34 :) 00:23:29 as a pursuit of noble platonic truths, or as a means towards solving practical problems... 00:24:04 i'm not sure there are many engineering artifacts that are based predominently on an existential proof 00:24:42 hmm, not so sure, now i think about it a bit more 00:53:28 they're not unrelated. 00:53:49 if you find some totally abstract "noble platonic truth" it can be a bridge that solves a pratical problem. 00:53:58 * nsh nods 00:55:22 e.g. there is a bunch of NP proof stuff where you can show a proof system is sound by reducing it to a 2d graph coloring problem, and then show that if the system is unsound it would contradict four coloring, which otherwise is kinda useless trivia. 00:56:19 right, came across that recently in a talk, funnily enough 02:44:59 but ultimately you have to reduce it to be constructivist to enter the realm of engineering 02:45:38 e.g. if you look at real numbers constructively, you get this funny think called numerical analysis ... 02:47:16 analysis was pretty practical when it came to aiming canon :) 02:48:10 computers are still named after the art of ordinance in french... 02:55:05 (philosophically, it fascinates me that the assumption of the continuum, even though actual algorithmic infinities are avoided, yields such powerful results in anaylsis. we can calculate things in continuuous sets that would suffer combinatoric explosion over discrete structures...) 02:56:28 Stirling's approximation <3 02:57:30 wtf 02:57:36 being able to answer questions like from an infinite distribution of 50/50 true/false how likely is it you'd draw 30 and get 5 true... answering it combinitorically is impossible. 02:57:42 i just noticed google wallet is still using checkout.google.com 03:00:05 * nsh nods 03:58:23 maaku is now known as Guest20356 04:47:56 Guest20356 is now known as maaku 08:36:03 ccc.de tls 1.0 1024bit rsa 08:36:13 and my browser doesnt trust the CA anyway :/ 08:37:03 "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." 08:37:05 wut 08:39:50 oh fun, something BIP32 like cannot be used with ed25519. 08:40:29 or rather, not with standard implementations. 08:40:31 they rig the multiplier so that the most significant bit must always be 1. 08:41:45 whats ed25519 again 08:50:10 Emcy: DJB's crypto 08:51:33 gmaxwell: can ed25519 be easily modified to make it work? 09:06:04 maaku: the curve is fine, the constant time multipler implementation— no. 09:08:29 Fistful_of_LTC is now known as Fistful_of_AFK 09:21:37 y'all see the deck of cards secret key agreement thing? brillant. 09:24:16 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) 09:31:08 gmaxwell: yeah i posted in the armory thread that a shuffled deck of cards makes a good inconspicous private key 09:31:32 and 51 bits for a shared secret is plenty good enough for many protocols 09:33:13 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) 09:33:31 if i ever worked border security, i'd shuffle any deck of cards I come across 09:33:41 the shuffling isn't required! 09:33:59 if you split a deck then just membership in one person's side or the other is the data! not the permutation! 09:36:56 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) 09:37:01 and the permutation doesn't matter. 09:39:35 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. 09:47:54 gmaxwell: reverse theorientation of one deck 09:48:05 or use different colored back 09:52:27 yea, that gets you some more bits, but I guess it's not so hard to place all the cards face up for photographing. 09:55:08 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 09:55:57 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 09:56:15 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 09:57:00 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 09:57:20 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 09:57:35 gmaxwell: you're use-case is probably more practical though (!) 09:58:40 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. 09:58:56 This card deck thing came from pond, incidentally. 09:59:19 petertodd: well you could do the two-deck trick with a nearly even split, and say it's a brdige deck 09:59:24 ha, pond is a great application 09:59:29 maaku: oh, nice! 10:00:02 maaku: do you have duplicated cards in a bridge deck? 10:00:46 gmaxwell: you have multiple decks iirc, and most players don't bother sorting them back inbetween games 10:01:20 never actually played bridge myself 10:02:07 the other good thing about the deck is that it requires very little prep, every drugstore in the US has cheap playing cards. 10:02:37 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. 10:04:16 ~52-bits is a bit weak, but 32-bits of hardening are pretty easy to obtain to push it back to reasonably secure 10:04:53 pond wants you to do shared password, time, and the card deck. 10:05:08 yeah, that should be enough 10:05:09 and supports one or two card deck modes. two deck is pretty good. 10:05:29 someone needs to add bitcoin transaction support to pond... as it's effectively a high latency mix network (hurrah) 10:06:02 (and supports messages up to 16kb) 10:08:05 and yea, pond uses scrypt kdf on the shared secret... doubt it does 32 bits worth though. 10:13:29 seems to me that pond + bitmessage-style pow would make a lot of sense 10:15:38 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. 10:16:03 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. 10:16:13 you can also revoke contacts. 10:16:50 so you don't really need POW to protect the recipents, which are the most bandwidth starved. 10:17:48 exactly, use pow to bypass the introduction process for things like tx's where you want to be able to send through anyone 10:18:33 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. 10:18:37 or alternatively, pick a random person from your contacts, they pick a random person themselves etc. 10:18:50 go through a few hops of that and spit it out to the network 10:18:55 but yea, TXs don't quite fit directly. 10:18:59 s/person/persons/ 10:19:37 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 10:20:31 right. I wonder if my pond brainwallet attempt will introduce me to any random people 10:23:18 that card deck thing is pretty cool 10:24:44 pond seems to be the secure comms thing that the real crypto nerds talk about the most 10:25:58 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 10:26:27 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. 10:26:52 The relationship in pond is completely symetrical. Meaning you can't just advertise a contact address. 10:27:59 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. 10:28:37 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 10:30:10 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? 10:32:38 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) 10:33:10 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. 10:35:27 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. 10:35:40 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 10:36:33 Emcy: doesn't give you info on customer-to-customer connections within ISPs for instance 10:37:38 true, but thats not the only thing they do. the ATT room from 2006 for eg 10:38:30 Right, tapping lots of links is not the same as tapping all links. 10:38:33 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 10:38:58 A true GPA taps all links. NSA is just an approximation of that. 10:39:39 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 10:39:49 you'd be surprized :p 10:39:52 yes. still too close for comfort and the panopticon effect is on play too 10:40:59 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. 10:41:53 I'm not aware of any scheme which is bidirectional GPA immune... though maybe I can imagine some insanely inefficient thing. 10:43:27 gmaxwell: timelock crypto works if you assume the GPA has a lifespan less than the delay in getting the message read 10:43:47 I was thinking about that.. but yea. thats not too helpful. :P 10:44:08 petertodd: I did come up with a neat bitmessage alternative idea. 10:44:15 gmaxwell: ? 10:44:27 Instead of POW, you use ZKP blinded SIN to ratelimit access to the network. 10:44:43 gmaxwell: oh, we were talking about that at dark wallet 10:44:49 then someone can only dos the network by paying tons of money to fees. 10:44:55 win win 10:45:10 gmaxwell: only sticking point is finding a ZKP implementation... 10:45:58 do you think this can tolerate the CRS limitation? (that there is some hopefully unknown to anyone randomness that would allow fake proofs) 10:46:04 probably can 10:46:12 since it's just a DOS attack 10:46:12 gmaxwell: sure, I'm a good guy :P 10:46:29 i think under the circumstances efficiency just cant be expected 10:46:53 i never needed to skype anyone at 100mbits anyway 10:47:01 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 10:47:49 petertodd: oh interesting point. so you could prove membership in a set which extracted with an eye on efficiency of proof. 10:48:05 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 10:48:09 gmaxwell: yup, and construct the sacrifice tx such that SPV clients can identify it 10:48:22 not least the average net users expectations of efficiency and performance 10:49:40 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 10:50:23 gmaxwell: which of course works best if people actually use their sacrifices to send messages at full rate constantly 10:52:36 I wonder if there would be an interesting way to have users able to pool sacrifices with friends. 10:53:10 gmaxwell: oh it'd be easy: just share the private key 10:53:14 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. 10:53:22 well yea, but thats a little inelegant. :P 10:53:42 I suppose if I have a channel with them I could ask them to sign messages for me. 10:54:13 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 10:54:43 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 10:55:26 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 10:56:14 well, maybe not ok as it might make mapping inter-network connections easier... 10:58:33 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) 10:59:49 can't the blinding be deterministic? IE it maps to one and only one sacrifice from the set of all prior sacrifices 11:00:28 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. 11:00:45 yeah 11:00:52 where time is quantized to get you your rate limit. 11:01:12 (perhaps just divided by the value times some rate control factor set by the system) 11:01:42 sorry for interrupting…but what's a sacrifice? 11:01:57 CodeShark: e.g. https://en.bitcoin.it/wiki/Identity_protocol_v1 11:02:10 CodeShark: underlyng mechanism: https://en.bitcoin.it/wiki/Fidelity_bonds 11:02:15 oh, that :) 11:02:16 yea, perhaps a better page. 11:02:34 gmaxwell: I need to do a specific "proof-of-sacrifice" page 11:02:59 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. 11:06:52 sadly even the fastest ZKP system would still effectively be a POW ratelimit right now. :P 11:06:55 by "parked" you mean something like a reverse timelock? 11:07:16 "coins cannot be spent until after block X" 11:07:16 gmaxwell: lol 11:07:30 CodeShark: that's not yet possible to do in bitcoin 11:07:57 petertodd: I know - but in principle it could be done 11:08:00 gmaxwell: coins in the UTXO set do have the disadvantage of making attacks cheaper, kinda like merge-mining 11:08:01 this is wizards, after all :) 11:08:03 CodeShark: by parked I just mean, e.g. coins that were sitting in place as of time X. ... perhaps moved right after. 11:08:06 CodeShark: true! 11:09:26 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. 11:10:23 so long as the snapshot is atomic there is no double dipping. 11:11:08 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) 11:11:26 probably sins are better though, since they're more easily found, etc. 11:14:03 gmaxwell: I'm very skeptical of systems that allow for re-use across different applications - UTXO-based stuff falls into that category 11:14:48 gmaxwell: thre is the disadvantage of a smaller anonymity set though 11:15:58 yea, using the whole utxo set has the biggest anonymity set. 11:16:45 oh, speaking of, so I came up with a nice scheme for non-interactive stealth addresses 11:17:03 your anonymity set is some configurable subset of all transactions 11:17:26 whats a stealth address? 11:18:06 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 11:18:58 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 11:19:26 stealth address being a publicly known address where funds sent to it are not known publicly 11:19:32 yea, bytecoin suggested something like that a long time ago! 11:19:39 nice! 11:19:50 (he also described how to send an undetectable encrypted message inside it!) 11:20:10 ha, I was just re-reading that post... 11:20:17 obviously not very well :P 11:20:23 or maybe well enough! 11:20:43 anyway it's a pretty decent solution to soemthing amir and co have been worrid about for awhile 11:20:45 yea, in any case, yea .. it's just computationally expensive for the reciever... 11:21:05 and I don't really know that payments with one way communication are really all that interestesting. 11:21:08 not a big deal - so is bitmessage which was (one of) his alternatives 11:21:19 maybe they are. I dunno. 11:21:49 perhaps there should be an address type defined for "donation addresses" which are just that. 11:22:08 I suspect that making stealth addresses well-supported would in practice get rid of a lot of address re-use due to UI constraints 11:22:09 as far as your "analysis bait" I suggest using R as a sidechannel. 11:22:42 yea, I agree, you win. it's an awesome point. 11:22:45 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 11:23:20 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. 11:23:37 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) 11:24:14 and the great thing with prefix-filtering is that stealth addresses done that way are no more bandwidth intensive than the alternative 11:24:17 well it could have its own filtering. 11:24:49 e.g. some servers that tell you about all transactions meeting some criteria. 11:25:14 yeah, although we're not likely to do mined commitments to those lists which kinda sucks 11:25:28 we're very likely to do prefix-filtering compatible commits 11:25:35 *commitments 11:27:42 I'd love to see a CAS which compensates you for providing resources to the network for all these kinds of things 11:28:31 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. 11:28:40 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 11:29:18 gmaxwell: the secret key doesn't need to be the same secret as unlocks the funds though 11:29:43 gmaxwell: doubles the size of the address though 11:29:54 (which is already larger than usual) 11:30:02 petertodd: I think it's okay if the address is kinda big. After all it has to be big just to have a pubkey. 11:30:09 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 11:30:11 gmaxwell: yup 11:30:20 CodeShark: Reality. 11:30:35 CodeShark: it matters a lot because people like to pass around addresses in things like PGP-signed emails 11:30:37 CodeShark: go solve address reuse for things like donation addresses that people slap on forum signatures. :) 11:30:51 CodeShark: requiring payment protocol for that stuff really sucks 11:32:06 ok, granted, that is a reasonable use case 11:33:58 gmaxwell: a cheap trick would be to fail a bit on absolute indistinguishability and reuse, say, nSequence for the prefix-forcing integer 11:34:11 gmaxwell: you could even use the nonce on the signature, but that breaks determinism... 11:34:17 petertodd: I don't know why you didn't like my R grinding. :P 11:34:22 oh thats why 11:34:42 gmaxwell: yeah, this should be compatible with as many wallets as possible 11:36:54 meh, if you don't require any obvious 'bait' then its easy. 11:37:05 what do you mean by that? 11:42:03 I mean the tricky part is adding something distinguishable to the transaction. 11:42:08 oh right 11:42:47 well 11:42:49 should just benchmark and see how expensive it is to do ecdh with every txn in the blockchain. 11:42:56 yeah 11:43:23 can't be much different than syncing the blockchain on a full node... 11:45:26 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 11:46:12 yep. 15:43:19 http://boingboing.net/2013/12/15/bruce-schneier-and-eben-moglen-2.html 15:43:47 can't believe i missed this over the last week 15:50:27 btw the card thing P(52,26) is conveniently > 2^128. course then you have to keep them from getting accidentally shuffled 15:58:02 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 16:36:52 petertodd, gmaxwell: stealth addresses, seems like 3rd-reinvention no? https://bitcointalk.org/index.php?topic=317835.msg3408519#msg3408519 16:42:10 an interesting observation inspired by this card trick is that 2^(2N) appears to be O(N)*C(2N, N) 16:42:32 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? 16:42:51 (here 2N is the size of the deck) 16:45:26 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. 16:49:19 petertodd: i should post that note on the bct thread for reference 16:56:04 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) 16:57:51 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) 17:00:45 i thought it was 257 bits? 17:01:23 oh +/- Y 17:02:05 * 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. 17:16:49 * 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 17:18:12 SN1FF, are you retarded 17:19:59 in wizards? are you serious? 17:20:07 gmaxwell activate 17:26:38 adam3us: I'm just about done a full-writeup for stealth addresses btw 17:26:40 i lied, it's O(sqrt(N)), not O(N) 17:27:22 petertodd, hmm 17:27:44 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 17:28:16 adam3us: glad to hear you reinvented it - it must be a good idea :P 17:29:24 petertodd: i think gmaxwell also mentioned bytecode's prior invention when i bought it up last time on this channel 17:30:20 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 17:30:36 Fistful_of_AFK is now known as Fistful_of_LTC 17:30:38 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 17:31:08 petertodd: sorry that should've been prefed petertodd above line 17:31:47 adam3us: yeah, spit out some kind of tx summary thing, heck, even just the txid is pretty good 17:31:58 adam3us: better yet, txid + height 17:32:31 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) 17:32:59 adam3us: it's not one of my better ideas anyway :P 17:33:41 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) 17:34:37 oh, i'm an idiot, the card trick only gives us the 52-bit numbers with 26 1's 17:34:43 that's where the O(sqrt(N)) comes from 17:36:48 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 17:38:11 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 17:38:30 adam3us: yeah, well the prefix business works decently well for that I think 17:38:59 petertodd: u mean to put an explicit marker that you search for? 17:39:24 adam3us: yes, or brute-forcing addresses to match some prefix 17:39:43 adam3us: the latter giving you the anonymity set of everyone in bitcoin right now 17:40:30 petertodd: yes i saw above, grind address or signature (modulo determinstic DSA removing grinding from R) 17:41:10 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 17:41:15 adam3us: deterministic DSA isn't an issue actually 17:41:36 adam3us: you can throw in an extra nonce tot he det DSA algorithm and grind that 17:41:52 petertodd: you'd have to var someting further in... right like time, high precision value etc 17:42:08 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 17:42:45 adam3us: no, if the det DSA algorithm spits out R, you can instead use R' = H(R + nonce) 17:42:50 petertodd: oh isee you are aiming for backwards compatible marker hiding amongst non-stealth keys got it 17:43:00 adam3us: it's not deterministic, but the underlying reason why you use det dsa is still preserved 17:43:13 adam3us: exactly 17:43:15 petertodd: ys but that is verifiable to all 17:43:40 adam3us: sure it is, consider a hardware wallet: you know what nonce you gave the algorithm, so just recalculate R' yourself 17:43:40 petertodd: ie R',S when recovered doesn not match Q, and Q is included explicitly in the tx format 17:44:05 adam3us: you calculate R' first, the signature is only calculated later 17:44:39 adam3us: oh right, I see... 17:45:22 petertodd: however the recipient doesnt know d so he cant verify k=H(d,m) so you can play gaes in there 17:45:49 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 17:46:17 petertodd: reinvention is good - each new person adds a new featurette and move the concept forward :) 17:46:43 adam3us: that'll be tricky to make work with coinjoin - you often need to know the address in advance prior to generating your signature 17:46:53 petertodd: (i did not trouble myself with trying to make it indistinuishable from existing payments) 17:47:28 adam3us: and you won't necessarily know all the addresses, so your deterministic DSA isn't over all the data being signed anymore 17:47:29 petertodd: no thats ok. the address Q is fixed, its just you are cheating in hw you produce k 17:47:49 adam3us: wait, who'se address is Q? the recipient? 17:48:19 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 17:48:50 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 17:49:16 petertodd: and probably against advice anyway most wallets are not using deterministic k selection! (grrr) 17:51:22 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 17:52:24 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 17:54:04 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 17:54:53 adam3us: right, well I'm only assuming that you can do prefix searches on H(script 17:55:06 H(scriptPubKey), assuming anything more may not be easily possible 17:55:35 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) 17:56:23 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 17:57:41 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 17:58:04 adam3us: (if u did actually send it to the network, but didnt realize and do it again) 17:58:54 yup, I've got a simple hack solution, which is to use nSequence as the nonce, but that does reduce your anonymity set 17:58:58 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 17:59:25 adam3us: yeah, the risk is pretty low even with a broken prng 18:00:10 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 18:00:38 petertodd: but idempotency anyway still works if the prefix target is deterministic 18:01:02 adam3us: but remember my point about coinjoin: you don't know m at the point when you want to specify the address 18:01:44 petertodd: i see. didnt get you before 18:04:07 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 18:06:14 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 18:06:35 adam3us: it's encoded in the address of course 18:07:01 petertodd: which address? sender, recipient base, or recipient randomized? 18:07:11 adam3us: the stealth address 18:07:35 adam3us: or more accurately, the scriptPubKey creation instructions making use of stealth 18:08:48 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 18:09:22 petertodd: (which are hidden before spend because Saddr = H(S)) 18:09:54 adam3us: huh? spent or not the derived one-time-only address is indistinguishable from any other random address modulo the prefix 18:10:53 petertodd: what i mean is spending reveals the pubkey hidden inside the address. 18:11:35 adam3us: prefixes would be on H(pubkey) or more likely H(scriptPubKey) 18:11:49 adam3us: only that is likely to be indexed for other purposes 18:11:52 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 18:13:06 adam3us: I don't see how that makes it distinguishable to an obverser who only knows P and Q 18:14:22 what's the topic? 18:15:13 nsh: stealth addresses, address is public, but only the recipient knows what payments are made to them 18:15:52 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. 18:15:55 oh, interesting 18:16:21 petertodd: then he can ask for prefix of H(S) 18:16:42 petertodd: but how does he know d*d' he needs taht otherwise he has an unspendable addr 18:17:00 adam3us: no, you've got it backwards, recipient asks for all txs matching a specific prefix, and then for the matching transactions he scans 18:17:17 petertodd: how does the recipient know the prefix 18:17:28 adam3us: the recipient *specifies* the prefix 18:17:39 petertodd: how.. there is no comms channel 18:18:03 petertodd: the sender has only a compressed public key Q in QR form on a bizcad 18:18:13 adam3us: there doesn't have to be: the recipient specified it in conjunction with their pubkey 18:18:37 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 18:18:44 petertodd: ok; and now everyone who he gives that bizcard to can also link his payments? 18:18:59 petertodd: (within the anonymity set of people with the same prefix) 18:19:31 adam3us: NO! because sender and recivers pubkey/seckey are combined with ECDH so the only parties who can calculate the shared secret are them 18:19:49 for any given sender/receiver pair there is exactly one shared secret, that only they know 18:21:04 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 18:21:47 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 18:22:10 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. 18:22:49 petertodd: not trying to be obtuse btw - i want this to work too. 18:22:55 adam3us: heh 18:23:31 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; 18:24:14 adam3us: right, so x=eQ=dP, x is the shared secret 18:24:16 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 18:24:42 adam3us: right 18:24:54 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 18:25:23 adam3us: well, this secret could be hashed and used as the private key for the one-time-only address 18:25:28 petertodd: ok say S=xQ=x*d*G 18:25:49 adam3us: more sophisticated is to do the BIP32 trick to derive a pubkey using that shared secret as a nonce 18:26:06 adam3us: now only the recipient can spend the funds and we're all good 18:26:23 petertodd: and yes actually x=H(eQ)=H(dP) 18:26:34 adam3us: right 18:27:16 petertodd: alrighty. i am glossing over BIP 32 HDness but yes. they can treat x as a chain code if they want. 18:27:24 adam3us: yup 18:27:43 adam3us: and you can use a nonce to grind until the resulting address has the right prefix 18:28:07 petertodd: grind address or signature? either could be done 18:28:33 adam3us: no, it has to be grinding the address because we can only count on address indexes existing 18:28:52 gmaxwell has kicked SN1FF from #bitcoin-wizards 18:28:59 petertodd: ok its good for existing infra agreed 18:29:19 adam3us: well, infrastructure that can be reasonably expected to exist in the near future :p 18:30:24 petertodd: nevemind; call me a spherical cow. so point is now the prefix is linkable modulo overlap if it small enough 18:30:54 adam3us: yeah, e.g. if it's an 8-bit prefix your anonymity set is 1/256th of all addresses 18:31:28 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 18:31:48 adam3us: yup, and the *sender* needs to do it which kinda sucks 18:31:52 petertodd: and the generator maybe a smart phone 18:32:23 adam3us: you can be a bit clever, and abuse multisignature w/ fake pubkeys, but that's the best you can do 18:32:35 adam3us: (that makes the inner-loop SHA256) 18:33:19 petertodd: yes or maybe p2sh with random unused value on stack 18:33:33 adam3us: well, that's no longer a standard transaction format 18:33:53 petertodd: p2sh restricted that much? 18:33:53 adam3us: might as well just do a marker explicitly 18:34:07 adam3us: that too... IsStandard() is applied to P2SH inner scriptPubKeys 18:35:06 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 18:35:33 petertodd: so i view the encoding as more a way to do it without introducing a new format 18:35:40 petertodd: and without requiring a new index 18:35:46 adam3us: with regard to coinjoin you're better if you stick to something standard 18:36:33 adam3us: a subtle point with that too is you probably want to make your change look like a stealth payment if you are distinguishable 18:37:06 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 18:37:29 ^ the case where you care about the permutation is kinda lame because you'd have to capture the data twice. 18:38:02 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. 18:38:33 If you exchange via a permutation you have to shuffle and digitize without breaking the permutation. 18:40:34 gmaxwell: slide the deck on a flat surface 18:41:12 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 18:41:35 hm 18:41:39 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. 18:42:37 petertodd: so full nodes are no problem anyway. 1 byte was my guess for 'bloom bait' also. is that small enough for SPV efficiency? 18:42:59 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). 18:43:28 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 18:44:02 adam3us: 1/256th is ~4KB/block, not a big deal at all 18:44:37 petertodd: yeah but say scan a few weeks worth. 18:44:53 petertodd: (since you last synced your smart phone) 18:44:56 petertodd: yea but not a shared secret unless you digitize twice. 18:45:07 adam3us: that's still just over half a mb per day, not bad 18:45:19 gmaxwell: I know, I'm not solving that problem with that idea 18:46:40 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 18:46:49 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. 18:47:02 adam3us: yea, double pack fixes the entropy problem well enough. 18:47:12 petertodd: so the main thing is how does that compare to SPV 18:47:29 adam3us: thing is, I'm expecting SPV to work like that anyway with prefix filters 18:47:44 adam3us: so the cost is only in the ECC computations, not extra bandwidth 18:47:45 petertodd: if 1byte is SPV compatible in overhead, i think we are closer to an spv killer. 18:48:31 petertodd: spv doesnt have prefix filters, it does fuzzy bloom fetches for requester address set 18:48:34 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 18:48:58 adam3us: SPV will be with prefix filters in the future; bloom has shit scalability 18:49:18 adam3us: also electrum implements them, it's just that the prefix has to be the a full 20 bytes :P 18:49:39 adam3us: electrum will have proper variable-length prefixes sooner or later 18:49:40 petertodd: ugh. I don't agree. requring all uses to grind addresses is kinda crazy. 18:49:44 petertodd: there maybe a small win lurking in there (stealth more plausible for spv more limited scan) 18:50:16 gmaxwell: maybe better to put the prefix somewhere else, a new field, or a harmless unused/overloadable field 18:50:25 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 18:50:50 petertodd: yes but the steath part has to be ground to setup the backup 18:51:10 petertodd: no, because it screws up wallet determinism or loading random keys from a determinstic wallet. 18:51:23 petertodd: if you give the data directly, then you can just use a bip32 wallet. 18:51:49 gmaxwell: no it doesn't, the data required to recover the wallet is still fully deterministic 18:52:04 petertodd: yes but only with a non-trivial computational cost per address. 18:52:08 gmaxwell: based on a seed I can regenerate my master pubkey and from that scan the blockchain to find my transactions 18:52:26 With a _lot_ of computation, which— of course— will encourage address reuse. 18:52:42 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 18:52:45 gmaxwell: the computational cost isn't per address you use, it's per address in the blockchain 18:52:59 gmaxwell: if you don't use your wallet at all the cost is the exact same based on whatever prefix length you chose 18:53:08 petertodd: you have to do the computation to even know what to look for. 18:53:45 gmaxwell: what do you mean? you have to do computation to check if every address matching your prefix is one you own 18:53:47 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. 18:54:13 petertodd: no you have to do computation for ever index you possibly used to figure out if its your own. 18:54:27 gmaxwell: i think he is assuming the prefix target is static eg communicated as part of the base address encoding 18:54:34 gmaxwell: suppose bitcoin has 1,000,000 users, 1/256 is ~4000 users 18:55:00 gmaxwell: you only have a single master pubkey in the most simple case 18:55:22 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. 18:55:38 adam3us: no he's talking about using this not just for donation addresses, and I think thats horiffic. 18:56:01 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 18:56:20 gmaxwell: best case is you use a payment protocol like this so normally you don't scan the blockchain at all 18:56:57 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 18:57:08 this is bullshit garbage rubbish 18:57:17 * gmaxwell spits in the general direction of the idea 18:57:50 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)" 18:58:00 gmaxwell: he he.. dont mince your words there greg :) 18:58:05 gmaxwell: LOL 18:58:32 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 18:58:35 petertodd: great, now your online system fails and you have to do this very expensive computation to enumerate your determinstic keys. 18:58:39 gmaxwell: if you fuck up and have to restore from backups, well, then you scan the whole damn blockchain (or some subset) 18:58:56 or you could just use BIP32. 18:59:21 gmaxwell: the point is you don't have deterministic keys! the computation is O(1) per tx, or O(n) for the blockchain 19:00:30 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 19:00:53 gmaxwell: (remember I tend to assume full nodes are out to break my anonymity and figure out what's in my wallet) 19:01:17 petertodd: if you wanted to give up your privacy then you could generically have bloom bait in _any_ transaction. 19:01:37 gmaxwell: huh? 19:02:39 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. 19:03:01 imagine a coinjoin where the input owners are the same as outputs. 8 bits is completely deanonymizing. 19:03:07 gmaxwell: first of all I never said that the 1/256 is set in stone 19:03:34 gmaxwell: secondly for your change addresses you can easily deterministicly dervive them in a way that is not subject to the 1/256th business 19:03:41 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. 19:03:42 gmaxwell: (per transaction) 19:04:16 petertodd: yea sure you can use a smaller distinguisher, I agree. but then you lose the filtering advantage. 19:04:22 gmaxwell: yes, but computers are fast and bandwidht isn't... needs soem proper numbers, but the difference isn't huge 19:04:50 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. 19:05:11 just for the sake of correctness, I'm pretty sure it will be worse than 2x full sync cpu. :) 19:05:31 esp if you have more than one of they keys for privacy among the people you asked to pay you too. 19:05:47 since then it grows like n*m. 19:06:36 gmaxwell: why would you have more than one? every payment using this thing is completely independent 19:06:58 gmaxwell: you only need more than one if you want to maintain multiple *identities* 19:06:59 petertodd: no, its not independant to the people you asked to pay you. 19:07:06 and they can even transfer that evidence. 19:07:51 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!!" 19:08:10 gmaxwell: which they can do with bip32 19:08:21 petertodd: only if you actually give them extended public keys. 19:08:40 gmaxwell: and if you don't, then the user experience for recurring payments sucks 19:08:41 which you don't need to if your website (the thing recieving a payment protocol receipt) is issuing them one use regular addresses. 19:08:54 gmaxwell: yeah, and that's a whole bunch of overhead 19:09:04 gmaxwell: for instance I just can't do that on freenet... 19:09:15 not just that BIP32 lets you give each seperate user a sub-chain. and those are not linkable. 19:10:16 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) 19:10:17 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 19:10:45 gmaxwell: pragmaticly speaking the window where it matters, say you were all talking on OTR chat, is pretty small 19:11:02 petertodd: because you can do things like go around and demand people identify all the stealt payments they made. 19:11:46 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 19:12:07 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. 19:12:08 gmaxwell: rarely does it matter that someone is alleging I received money at one bitcoin wallet or more than one 19:12:58 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. 19:13:21 petertodd: people make allegations about people being the same person all the time. 19:13:41 gmaxwell: yes I know, which is why you should use a different stealth address for each of your alts 19:13:43 even when the parties in question weren't really trying to be one or two identites. 19:14:17 Bitcoin used well today in the bidirectional communication case creates none of that linkage ever. This is adding a vulnerabity where none exists. 19:15:06 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 19:15:07 and it scales like n*m so there is a disincentive to use a new stealth address whereever you can. 19:15:37 petertodd: all of my complaints are stemming because you started suggesting that this is somehow a _general_ replacement for bloom for spv. 19:15:54 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. 19:16:07 Other then perhaps you'll never get bitcoinj to implement. :P 19:16:28 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 19:17:10 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 19:17:24 gmaxwell: bitcoinj no, darkwallet more likely 19:17:56 if bitcoinj doesn't implement it no one will use it for donations... since you need to implement it merely to _send_ to it. 19:18:11 and no one wants a donation address that a non-trivial number of people can't send to. 19:18:44 (I've gotten so many complaints about CJ bounty being unpaytoable) 19:18:44 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 19:19:17 gmaxwell: equally, replace PGP with whatever CA system you want 19:20:09 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 19:20:39 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. 19:21:39 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 19:22:15 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. 19:23:28 (e.g. if we introduce a new signature system in the future) 19:24:00 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 19:24:09 gmaxwell: but that's costly for now, so we avoid it 19:24:30 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 19:24:43 gmaxwell: losing payment is very bad after all... 19:24:49 *payments 19:25:04 well you make the exact nature of the current usage more of a suicide pact, it makes all of bitcoin more brittle. 19:25:11 though this may be avoidable. 19:25:29 think of it this way: it's an optimization of "encrypted blob" 19:25:30 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. 19:25:39 sure, that's easy to do 19:25:49 then it's less of a fixation on how things are currently done. 19:25:51 although breaks coinjoin because we only allow a single op_return 19:26:06 no, they could all use the same nonce. 19:26:17 you'd just have to agree on it in a CJ. 19:26:33 right, which breaks the moment someone needs to upgrade something... 19:26:43 CJ's already break, since presumably you're going to ask people to only check with the first pubkey in the txn. 19:27:15 CJ mixer needs to recieve the full stealth address. 19:27:17 not at all, that's why I expect an actual spec to put a limit on tx size (or more likely # of tx inputs) 19:27:38 ugh! thats a multiplicative increase in the computational cost, usually for no gain. 19:27:47 getting less interesting. 19:28:20 yes well, that's life, the alternative is marking the possible txins with nSequence 19:28:48 which can easily be an info leak - tells you how many "actual" outputs there are 19:28:53 yuck. 19:29:06 or you could just give CJ mixers the stealth address ... 19:29:31 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 19:29:54 I'm expecting most CJ to be two party mixes anyway 19:30:13 oh but then you have the problem I was griping about earlier... where people get a transferable proof of who someone was. yuck 19:30:15 it's reasonable to ask that the relevant txins be placed at the top two slots 19:30:37 petertodd: huh? what if all txins are relevant? 19:30:57 and if the reciever isn't guarenteed that its at the top they have to check all of them. 19:31:23 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 19:32:21 oh this also totally screws up offline signing. 19:32:37 because you won't be able to author a transaction without access to the secret. 19:33:18 gmaxwell: OTOH offline signing that's for multisig is not affected 19:33:42 use the online secret 19:33:48 sure but if you're increasing the transaction size, might as well just start adding the nonce to an OP_RETURN or txout. 19:34:31 And expecting multisig to save this is not compatible with schnorr threshold signing. 19:34:51 well it needs to be more than just a nonce unfortunately, it has to be encrypted to the recipient 19:36:17 huh? you need a nonce to do the encryption. 19:36:48 I mean it's not a short nonce, e.g. for ECDH you need a x byte nonce + a 33 byte emphemeral pubkey 19:36:59 no you don't. 19:37:06 you need an ephemeral pubkey. 19:37:08 oh, actually the pubkey is your nonce... 19:37:11 right. 19:37:24 it's not short though it can be safely shared. 19:37:33 ? 19:37:47 oh, you mean it's 33 bytes but can be safely shared 19:38:08 see, my other idea was to use bare multisig destinations for this 19:39:02 but all that's just details to make it compatible with what we have now, obviously OP_DROP works too 19:41:03 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 19:41:11 drop support for the old mechanism later 19:41:40 you can always use the ugly hack of keeping a few txouts of low value for backwards compatibility 19:42:33 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. 19:42:45 (obviously the senders have already updated or they couldn't be doing schnorr signing) 19:42:57 yeah, then add that to the standard on day 1 19:43:37 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. 19:44:14 overhead is ~17% for OP_RETURN, not all that small 19:44:32 yup, which gives you insight into what kind of filter ratio works 19:45:14 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. 19:45:34 (or breaks keeping all your signing keys offline) 19:46:09 yup, but it does reduce the anonymity set... 19:46:51 well, way less than methods of inserting an explicit identifier byte do! :P but it's only an option. 19:47:08 that prevents this from totally screwing up offline signing. 19:47:27 and from giving us a secp256k1 suicide pact. 19:47:42 right, although again, you can always keep a few txouts kicking around with low value 19:48:02 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 19:49:35 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 19:51:51 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 19:52:51 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 19:53:19 gmaxwell, petertodd: we just need a better method to do it, the requirement is good, the solutions all suffer limitations 19:54:06 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 19:54:26 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. 19:54:32 adam3us: which gets you to using the blockchain as a messaging thing, which forces you into the filtered anonymity set concept 19:54:59 petertodd: agreed. anything short of encrypting the info i the same bitstring as the payment is going to lead to brittleness and disaster stories 19:55:53 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" 19:56:12 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?) 19:56:23 adam3us: *that* was the problem were were trying to solve, for an offline recipient 19:56:55 petertodd: yes. i reckon all present understand the nice requirement. problem is its real hard to solve. 19:57:11 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 19:57:36 adam3us: also note how the communication and computation requirements for this proposal are *very* similar to bitmessage 19:57:46 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) 19:58:35 petertodd: hence the repeated attempts to sabotage, or just fall back to single use that people end up doing thru comprehension issues 19:58:41 adam3us: yup 19:59:41 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 20:00:26 more to the point, bitmessage works fine on desktops... so I already know the performance isn't all that bad 20:00:27 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 20:00:53 adam3us: ? 20:01:08 petertodd: the problem is to know to look for the first payment 20:01:57 adam3us: ah, interesting point: the first payment could be a BIP32 chain code basically, the rest happens regularly 20:01:59 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 20:02:30 adam3us: right, but no reason to make the address static vs. hiding it in some anonymity set 20:02:46 petertodd: well if it had no inputs, no loss eh 20:02:58 petertodd: its just a message. the remaining issue is the fees for it. 20:02:59 adam3us: huh? no inputs? 20:03:30 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 20:03:31 petertodd: two messages. an inputless one to communicate teh chain code (its sender anonyous) step2 an unlinkable payment to a bip32 address 20:04:11 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 20:04:52 petertodd: so the recipient can go ask for chain code pairing msgs encrypted to his expanded address 20:04:53 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 20:06:37 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 20:06:56 petertodd: following which they can send a BIP 32 payment normally 20:07:24 adam3us: right, that's the easy bit 20:07:28 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 20:08:01 nah, just use coinjoin for that 20:08:03 petertodd: wasnt easy until a few mins ago. i dont think i saw this pattern before discussed 20:08:19 adam3us: well it *was* my original idea you know :) 20:08:35 adam3us: though I hadn't thought to make it a full chain, I was still thinking on an individual tx level 20:08:54 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) 20:09:16 petertodd: first with no inputs, msg only. i mean. 20:09:18 adam3us: right, but see with coinjoin 2 txs are the same thing as 1 tx 20:09:20 petertodd: anyway, onwards 20:10:22 petertodd: transferable proof of chain code issues & ZK potentials to fix 20:10:37 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 20:13:39 adam3us: see, the problem is the communication is inherently timestamped, so most tricks with revealing keys and the liek don't work 20:15:25 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 20:15:39 petertodd: messes compound and impact future flexibility 20:17:53 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 20:18:30 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 20:19:00 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 20:19:41 also note that you can't guarantee two separate txs will get mined in any particular order other than by waiting, which users hate... 20:20:24 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 20:21:53 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 20:22:28 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. 20:22:30 this chaincode stuff has a lot of state too on the wallet side... 20:22:54 I agree having more private one way addresses is good, but the question is how to prevnet them from being generally awful to implement. 20:23:50 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. 20:23:54 oh you went on to say the same stuff, agreed. 20:23:56 *comparisons to bitmessage 20:24:58 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 20:25:29 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 20:25:44 not all of it, but a lot 20:26:23 that does imply we have indexes of op-return scriptPubKeys on a per-block basis, but I have no objection to that 20:40:18 andytoshi: so when is your coinjoiner going to go back on mainnet? 20:43:33 gmaxwell: as soon as i get a SSL cert 20:43:42 by end of day today, i didn't realize there was any demand :} 20:44:05 actually, i can put it on mainnet now.. it'd just be non-https 20:44:40 andytoshi: ah, yea, I'd like to try to get some people around #bitcoin-otc doing a weekly organized coinjoin 20:45:16 cool, it's just sync'ing now 20:45:19 andytoshi: as far as the cert goes.. startssl... if you have any problems lemme know and I'll help out. 20:45:21 there was a power outage 36 hours ago 20:45:25 cool, thx 20:52:31 ok, i think in 15 minutes it'll switch to mainnet 20:52:48 we'll be able to tell because the donation address will switch over 21:08:13 andytoshi: Will it also be tor-accessible? 21:08:20 (hidden service, I mean) 21:13:31 michagogo|cloud: yeah, i'll set that up 21:14:05 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 21:18:11 i hate ASN1 with a passion 21:34:34 andytoshi: what's the url for your coinjoiner? 21:35:19 http://testing.wpsoftware.net/coinjoin/ 21:35:40 it says testnet but it is not anymore 21:38:48 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. 21:48:45 cool, andytoshi 21:49:54 lol - 1ForFeesAndDonationsSpendHer 21:50:27 I tried…she didn't like it 21:50:39 :P damn checksum.. 21:59:33 andytoshi: s/Spend/Send/ 21:59:37 does it support multisignature transactions, andy? 21:59:38 one solution 22:00:22 CodeShark: pretty sure, yes, it just validates it with bitcoind and my own coinjoin software 22:00:41 and both of those are fine with it 22:00:54 but to the best of my knowledge nobody has tested it 22:01:00 I just did :) 22:01:15 well, I submitted one 22:01:16 oh, cool, i'll through a tx in then to join you 22:05:31 done 22:05:50 thx gmaxwell for the 'force inputs to match outputs' idea, i almost screwed myself 22:05:57 and donated too much to my own joiner.. 22:06:35 so now we wait for 10 minutes? 22:07:18 yup 22:07:52 i can speed it up by prodding around in the db, but i'd probably fat-finger it, sorry 22:08:06 presumably if we had higher volume we could reduce the wait time :) 22:08:22 yeah 22:08:52 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 22:09:17 but i suppose i could write a client for my thing too 22:09:37 I'm speaking theoretically, of course - this specific implementation needn't be the one that ends up taking off 22:10:29 has anyone figured out a solution that doesn't require a server? 22:14:58 is there any cryptographic transform that is invertible and commutative? 22:15:17 so that ABA^(-1)B^(-1) = Identity? 22:16:34 and applying A and A^(-1) requires knowledge of a secret 22:17:18 ok, time's up 22:17:29 CodeShark: ok, there is a donation to 1ForFeesAndDonationsSpendHerdtWbWy still in there <.< 22:17:33 sorry, i'll fix that.. 22:17:36 hehe 22:18:52 we can donate 0.000025 to the vacuum of space :) 22:20:38 hmm, we're donating 0.00005 to the vacuum of space, it looks like 22:21:19 yeah, it adds all donations to the same output 22:21:32 hmm and the scriptSigs have been cleared completely 22:21:46 that breaks my multisigner :p 22:21:48 yeah, it drops everything when it's merging unsigned transactions 22:21:50 really? 22:21:52 hmm 22:22:16 so, the way it tells when all the signatures have come in is that none of the scriptsigs are blank anymore 22:22:45 hmmm - my multisigner cannot, in general, know whether it can sign any transactions unless the public keys are available 22:23:04 also, it uses placeholders for signatures so different signers can add signatures 22:23:36 I just use a 0-length signature to indicate "unsigned" 22:24:04 but keep the keys/redeemscripts 22:26:50 the reason for this is that different signing nodes could participate without having to know anything about how the p2sh addresses were generated 22:28:04 if you can replace the scriptSig of my input with what I had originally submitted, I'll sign it:) 22:28:26 I guess I could replace it on my end 22:29:06 well, i've gotta fix the donation address thing 22:30:12 then i'll think about what to do about scriptsigs...my assumption was that anything in there was just noise 22:30:23 since if somebody had signed something, the signature would be invalid after joining 22:31:01 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 22:31:20 this is especially true for p2sh transactions 22:31:56 yeah, bad assumption on my part 22:36:42 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. 22:40:59 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 22:41:06 so the length is wrong and i'm also missing a byte 22:41:20 but the logic looks correct and it worked with testnet <.< 22:42:04 so it occurs to me that the behavior of IsConfirmed is already broken 22:42:16 and simply removing the unconfirmed dependency checking is probably optimal 22:44:22 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 22:48:36 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? :) 22:49:17 I guess exponentiation... 22:49:38 i think what you're asking describes blind signature schemes 22:49:44 yeah :) 22:50:17 so yeah, I suppose we can use exponentiation, where the inverses here are modulo phi(field modulus) 22:50:19 so, the wiki article on that has an example using RSA, and there is an entry on matthew green's blog about ecc 22:50:54 http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html 22:50:55 CodeShark: just addition in EC groups works. (with the modular inverse to undo) 22:51:02 right 22:54:15 andytoshi: there is an ec schnorr blind sig also 22:54:37 andytoshi: but no ecdsa one. there is a horrendously complex dsa one. 22:54:46 so the only part remaining to solve for decentralized coinjoin is peer discovery 22:54:47 adam3us: did you see my commends about the ed25519 multupliers apparently requiring the scalar to have the high bit set?! 22:55:03 gmaxwell: fwiw we can remove that requirement 22:55:12 and even maintain timing resistence 22:55:28 sure we can, but we lose their good existing implementation and become formally incomaptible, which is lame. 22:56:25 andytoshi: there was also something about requiring the scalars to be a multiple of 8 which I didn't understand at all. 22:56:34 and I assume its just confused. 22:56:40 yeah, i didn't get that either, i was hoping a wizard would be able to clarify 22:56:47 or that somebody on crypto.SE would step in 22:56:58 somebody not confused * 22:56:58 where is this discussed? 22:57:06 (or specified) 22:57:12 nsh: http://crypto.stackexchange.com/questions/12425/why-are-the-lower-3-bits-of-curve25519-ed25519-secret-keys-cleared-during-creati 22:57:17 ty 22:57:21 i posted that a few days ago, gmaxwell is continuing without context :P 22:57:26 * nsh smiles 22:57:50 andytoshi: I didn't remember you posted it, it got left up in a tab. 22:58:11 the responses there are just confused. 22:58:31 gmaxwell: the internet only works when you respond and correct them :) 23:00:14 well I can correct the highest bit thing I know why it does that, though it's crappy and overoptimized. 23:00:26 the *8 thing I have no freeking idea 23:10:22 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? 23:13:54 -- 23:13:57 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 23:13:58 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”. 23:14:01 -- https://www.readability.com/articles/gswpw12d 23:14:27 just quite blaze "massaged into ... by setting and clearing a few .. bits" 23:15:12 so no particular indication the author (Brian Warner from Mozilla) thought much of the reasoning 23:17:21 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. 23:18:10 gmaxwell: its kind of remiss that they dont explain in the paper really 23:43:39 gmaxwell: https://www.wpsoftware.net/coinjoin/ should be working 23:44:13 as discussed with CodeShark, it strips scriptSigs, which may cause problems for complex use cases 23:46:55 andytoshi: cool, just submitted a tx 23:48:13 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 23:48:45 andytoshi: hmm, got " Sorry, this session was not found. " 23:48:59 petertodd: yeah, and it's claiming that the session is -92 minutes old 23:49:03 sorry, one moment 23:49:18 andytoshi: now -94 minutes :p 23:49:40 oops, permission error 23:50:15 should be good now 23:50:37 but you'll have to resubmit 23:50:40 just did 23:52:24 cool, anyone else want to submit? 23:52:58 sure, i'll submit one 23:53:11 andytoshi: "The most popular output value is 0.0005" <- treating the fee as popular 23:53:19 yeah, i noticed that :P 23:53:29 probably not a useful behavior 23:53:37 yeah 23:55:55 adam3us: the number of the points isn't @#$@#$@#$@ prime. it has a @#$@#$@ cofactor of 8. 23:56:10 petertodd: wtf. no. the r value is _exactly_ like your public key. 23:56:16 K is the cooresponding private key.