--- Log opened Wed Mar 06 00:00:42 2013
14:54 < HM> Is there a signature algorithm that mainains signer privacy?
14:54 < HM> e.g. where public key recovery isn't possible but you can still verify it if you know the public key
14:56 < HM> the only tweak i can think of is still the public key in as a salt to the message hash
14:57 < HM> Schnorr signatures allow key recovery as well
14:58 < HM> *stick the public key
15:17 <@sipa> HM: just xor the signature with a bit of data that you make part of the pubkey
15:18 <@sipa> or better, symmetrically encrypt it with a key that becomes part of the pubkey
15:19 < HM> yeah i thought about the latter
16:58 < jgarzik> petertodd, gmaxwell: thinking about the irc-bot-as-a-bank (or perhaps N-irc-bots-distributed bank), I think I want a generic identity token service, paid for with bitcoins.  Sort of a "network identity", like an email address or DNS name, but purchased with bitcoins.  Associate with a bitcoin address and/or GPG identity for authenticated access
16:58 < jgarzik> Anybody done that before?
16:58 < petertodd> Nope, IE fidelity bond style or something else.
16:58 < petertodd> ?
16:59 < jgarzik> Then, the IRC bot would just ask for the user's identity token, verify that via ECDSA message, and proceed to add a new user to the bot-bank (or permit that user to access their existing account)
16:59 < jgarzik> i.e. makes identity separate from the service itself
17:00 < jgarzik> separate from the fidelity bonded banks itself, but an IMO necessary component
17:00 < jgarzik> anyway, should be straightforward, just wondered if anybody had done this before
17:02 < petertodd> Ah, cool, yeah seems reasonable.
17:05 < petertodd> jgarzik: Was my stuff on fee's useful?
17:06 <@gmaxwell> jgarzik: make sure you familarize yourself with what mozilla persona is doing wrt email bounded network identity.
17:08 < jgarzik> gmaxwell: will check it out
17:09 < jgarzik> petertodd: Basically, I was considering burning money as public proof that you "made an effort" to create this network identity
17:09 < jgarzik> and as such, those transactions might be fee-only sometimes, if there is no change
17:09 < petertodd> jgarzik: Right, sounds like fidelity bonds exactly.
17:09 < petertodd> fee-only sometimes?
17:10 < jgarzik> petertodd: if the proof (to be paid as fee) is 0.01 BTC, and you have only a 0.01 BTC coin, then (in theory) you have 1 input, 0 outputs
17:10 < jgarzik> but that is not permitted, and zero-value outputs are non-standard.
17:10 <@gmaxwell> jgarzik: I don't think a zero output txn is valid.
17:10 < jgarzik> gmaxwell: hence "that is not permitted"
17:11 < jgarzik> gmaxwell: and "(in theory)"
17:11 < jgarzik> Thus, what I want is not permitted, and a workaround must be found
17:11 < petertodd> So why not add a second input to the transaction?
17:12 < jgarzik> petertodd: it needs an output, not an input
17:12 <@gmaxwell> So, lets permit txn that have a single output, which is zero value, and the output is OP_RETURN (or whatever we want the prunable type to be)
17:12 < jgarzik> gmaxwell: that would work
17:12 < petertodd> jgarzik: The second input to get more funds, so the output is not zero valued.
17:12 <@gmaxwell> basically a UTXO cleaning transaction.
17:12 < petertodd> Or is the output supposed to not be spent or something?
17:13 < jgarzik> petertodd: the purpose -- burn money -- is all I need
17:13 < jgarzik> petertodd: therefore, no outputs are needed
17:13 <@gmaxwell> petertodd: the problem is that if you can have other outputs means that I can't tell you sacrifice from a regular txn fee.
17:13 <@gmaxwell> s/you/your/
17:13 < petertodd> Yeah, and fees in general can be gamed by miners anyway, you really need a publish-wait-confirm sequence.
17:14 < petertodd> Why not just use the fidelity bond protocol directly?
17:14 < jgarzik> still have to digest it, and see if it fits the irc-bot use case
17:14 < jgarzik> I also think a cross-service network identity would be useful
17:15 < petertodd> Well, for the identity case, it's basically proving in a very robust way the fees attached to some hash, so I think it should be fine.
17:15 < petertodd> And if fidelity bonds become a thing, you'll be able to buy them easily enough, and securely, with a tx signed by multiple parties.
17:15 < jgarzik> basically attaching a cost to creating a network identity (though obviously a more centralized service might just charge a fee)
17:15 < petertodd> Well, you know I really think fidelity bonds solves that one very well.
17:16 < jgarzik> your writeup is open in my browser ;p
17:16 < petertodd> Best case possible is you need three tx proofs, proof of publish, proof of txin, and proof of the txout sacrificing the fees.
17:22 < jgarzik> It might also help to describe the use case I was thinking about
17:22 < jgarzik> I obtain a network identify U12345678 (and can pay for any number of network identities)
17:23 < jgarzik> U12345678 messages the Foo Bank Network, which maintains a provable, shared ledger of accounts
17:23 < jgarzik> messages are signed with keys associated with U12345678 network identity
17:24 < jgarzik> messages are "open account, withdraw, deposit" etc.
17:24 < jgarzik> Foo Bank Network might be one entity, but hopefully it is multiple entities
17:24 < petertodd> Right
17:24 < jgarzik> off-chain transactions are then possible, everything is digital signed and secured, and not 100% centralized
17:24 < petertodd> So why do you need to make the client's identity expensive to get?
17:25 < jgarzik> because identity is decoupled
17:25 < petertodd> from what?
17:26 < jgarzik> so you don't need a new login for each service
17:27 < petertodd> Sure, but again, why does the identity have to be expensive?
17:27 < petertodd> (if it's just for banking)
17:37 < HM> I think I prefer Schnorr signatures to DSA
17:37 < jgarzik> I want a semi-decentralized database for the identities, so there needs to be some cost for creating 1,000,000 identities
17:38 < petertodd> Ah, yeah that's totally reasonable
17:38 < jgarzik> another part in this is a layer where you may message easily between two network identities
17:38 < jgarzik> a _little bit_ like bitmessage
17:38 < petertodd> Do you want an identity to essentially give you the right to message a given amount of traffic per day, or what?
17:38 < jgarzik> the identities have some permanance
17:39 < jgarzik> petertodd: at the moment, just "the right to message" is sufficient, but that needs more thinking
17:39 < jgarzik> anyway, gotta tour some real estate, bbiah
17:39 < petertodd> Have fun, say hi to the kid for me. :)
18:21 < HM> actually I don't think you can do public key recovery on Schnorr signatures
18:25 < HM> In DSA you rely on the fact that 'r' can be used to determine kG (to within a few possibilities)
18:25 < HM> under Schnorr you lose r in a hash function
18:27 < HM> it's also cheaper to compute
18:28 < HM> (by one bigint division)
19:03 < HM> bollocks i was right the first time
19:03 < HM> you can recover public keys
19:04 < HM> wait, i have to make my mind up on this for good
19:06 < HM> nope, i was definitely right the 2nd time
19:08 <@sipa> i don't see how you could do key recovery with Schnorr signatures
19:08 < HM> thank you
19:08 < HM> lol
19:08 < HM> what I did was arrange for validation assuming you knew the public key
19:08 < HM> then sub back in the result and arrange for that public key :|
19:10 < HM> twice
19:10 < HM> basic algebra beat me twice
19:12 < HM> ah well, i've done it now. You can arrange for sG in both DSA and Schnorr and show you need to solve the DLP to fake a signature
21:44 < jgarzik> petertodd: MerkleBitcoinTx uses block number rather than block hash.  why?
22:00 < petertodd> jgarzik: The blockchain is linear, so the block hash doesn't let you prove anything.
22:00 < petertodd> jgarzik: Granted, if it wasn't linear, like some sort of merkle skiplist or merkle mountain range, then a hash would make more sense.
22:01 < petertodd> jgarzik: Maybe just a premature optimization... submit a pull req, lol.
22:09 < jgarzik> petertodd: <shrug> maybe just being pedantic.  the text said 'just like CMerkleTx', which is slightly incorrect
22:09 < petertodd> Hey, it's a spec, be pedantic.
22:10 < petertodd> Where did I go wrong?
22:10 < jgarzik> petertodd: "This is the same data that the CMerkleTx class contains"
22:11 < jgarzik> petertodd: CMerkleTx includes block hash not block index
22:11 < petertodd> Yup, you're right, I'll fix it.
22:15 < petertodd> alright, I'll push to the server when I'm back from work and have access to my gpg keys...
22:18 < jgarzik> petertodd: any demo code?
22:19 < petertodd> Not yet sorry; I wanted to add unit tests and better ways to create transactions to pynode, and got distracted...
22:20 < petertodd> BTW: re: cython, I found a compiler bug in it, which kinda scared me off for now...
22:30  * jgarzik ponders.  N bots, cooperating but separate, independent entities (such as managing my identity service).  Service must accept bitcoins from users, and therefore, any one of N bots must be able to generate a "you are authenticated; send X bitcoins to address 1YYY..."
22:31 < jgarzik> Can such a botnet survive a cheater?
22:31  * jgarzik tries to think of ways to centrally generate and share bitcoin addresses
22:31 < jgarzik> and prove a bot is cheating in short order
22:33 < jgarzik> on the other end, need to share service fees to each bot, dividing up service revenue without cheating
22:47 < nanotube> as to using irc bots as money keepers... keep in mind that you also have to trust the irc server operators (and irc server security, and bot security, but these two are obvious)
22:48 < nanotube> an irc oper can send and/or modify and/or block any messages coming through.
23:04 < jgarzik> nod
23:05 < weex> those deterministic wallets should work, the one where you have a public seed and private seed
23:09 < weex> or you just have the head bot sign each address
23:10 < jgarzik> need N-of-M security
23:10 < weex> like shamir's secret sharing?
23:10 < jgarzik> head bot == centralization, not distributed consensus
23:10 < weex> http://en.wikipedia.org/wiki/Secure_multi-party_computation
23:11 < weex> i want to watch this tech talk on it again sometime  http://www.youtube.com/watch?v=LRAN_w1_qmw
23:20 < jgarzik> ok, more generally
23:20 < jgarzik> you have The Fund
23:21 < jgarzik> (a pool of bitcoins)
23:21 < jgarzik> You must generate new bitcoin addresses, to hand out to end users, from The Fund
23:21 < jgarzik> and The Fund must pay out according to pre-described rules
23:22 < jgarzik> The Fund is managed collectively by N parties, cross-checking each other.
23:22 < jgarzik> Can cheating by 1 party be prevented, in either of the two tasks (obtain new btc addr for customers, pay out to investors)
23:24 < jgarzik> One could hand out MITM BTC addrs, but that would be noticed as cheating when the party wanted to claim a payment has entered The Fund
23:25 < jgarzik> But creating the BTC addrs themselves... you still have the problem of private key distribution (or seed)
23:25 < jgarzik> ideally one generates an address for spending, that may only be redeemed by multiple parties.  Smells like P2SH at a minimum.
23:26 < jgarzik> then each party manages one key of a multisig
23:26 < jgarzik> (s/party/bot/ as needed)
23:38  * jgarzik trolls gmaxwell
23:41 < nanotube> jgarzik: if you want to troll gmaxwell, you have to mention DHTs, at least. :)
23:42 < amiller> did someone mention dhts
23:45  * jgarzik guesses...  Bots A, B, and C each generate a key.  When a user requests a fresh pay-to bitcoin address from (randomly selected) Bot B, B collects data from A and C, writes a multi-sig script, uses that script to generate a P2SH bitcoin address, and gives to user.
23:46 < weex> can the user talk to the other bots?
23:47 < jgarzik> possibly, depending on how the bot addresses are discovered
23:47 < jgarzik> shouldn't matter, for the purposes of internally creating bitcoin addresses for The Collective
23:49 < weex> just thinking you want the user to be able to verify any address with a party other than the bot they talked to
23:49 < weex> doesn't really stop B from losing their key though
--- Log closed Thu Mar 07 00:00:43 2013