--- Log opened Sat Mar 09 00:00:46 2013
15:58 < petertodd> gmaxwell: Sounds like a reasonable idea.
15:59 < petertodd> gmaxwell: I was thinking, a good first prototype might actually be an easywallet type site that's auditable via a merkle sum fee tree.
15:59 < petertodd> Just something really simple, but real.
17:37 <@gmaxwell> well, go a step further than that and approach instawallet and put it on a real site.
17:38 < petertodd> gmaxwell: Oh, that's exactly what I meant.
17:39 < petertodd> easywallet seems like a better target, purely because they're targeting slightly mroe techsavvy users from what I can see
17:39 < petertodd> w/ a javascript verifier would be great
17:40 <@gmaxwell> one challenge is that these sizes have a kazillion utxo... not really compatible with small proofs.
17:40 <@gmaxwell> thats why I thought a micropayment system was better than a wallet provider.
17:40 < petertodd> yeah, currently they do, that'll have to be part of the question of how to do it
17:40 <@gmaxwell> Because a micropayment system could quite reasonably just have a few utxo.
17:40 < petertodd> I like your suggestion of having a "backing balance"
17:41 < petertodd> Yup, uc too, although none yet exist, well, sorta.
17:41 <@gmaxwell> well it may be the case that they could easily aggregate 95% of their funds in a few utxo, and then provide the other 5% out of pocket in a single utxo.
17:41 < petertodd> In practice easywallet and instawallet are also upayment systems.
17:41 < petertodd> Yup, instawallet is already known to have a cold storage with about a million dollars in it.
17:42 < petertodd> Anyway, regardless of proving they have funds, even just the merkle-sum-tree of account balances is a big improvement.
17:42 <@gmaxwell> on a total tangent— talking about the existance of micropayment systems. It would sure be nice if all these systems had a way to discover that they can use a system to system transfer vs a bitcoin payment for random user provided addresses....
17:42 <@gmaxwell> and if they could do so without disclosing what service owns which addresses in advance.
17:43 < petertodd> Yeah, I'm thinking an email-like basic address sytem is a good idea, and ensure that all payments are encrypted or signed or somesuch, so only the recipient holding the seckey can do anything.
17:43 < petertodd> trustbits:pubkey@example.com?
17:52 < jgarzik> a nice identity system, mayhap ;p
17:53 < jgarzik> perhaps one that requires cost to acquire an identity
17:53 < petertodd> ....that's what the pubkey is for, to ensure that we don't need an identity system!
17:53 < petertodd> basically it should act kinda like a cheque, so that only if the receiver can then actually prove they have the seckey does the sender relase the fudns
17:53 < petertodd> *fudns
17:53 < petertodd> *funds
17:53 < petertodd> IE, if the DNS is hacked.
18:10  * jgarzik wants a global SIN (system id number) system.  Anyone may acquire one anonymously.  Perhaps it costs money, paid to a bot network, perhaps it requires a sacrifice.  The main point is to -not- be able to generate millions of these identity records a day.
18:10 < jgarzik> Attach bitcoin addresses (for signmessage verification), GPG fingerprints/pubkeys, etc. to a SIN
18:11 < jgarzik> or anything else, like a nickname or fingerprint
18:11 < petertodd> I like the idea; can we call it garzik-sins?
18:11 < petertodd> Or garzik's sins?
18:11 < jgarzik> The act of obtaining one could be SIN'ing
18:11 < petertodd> This can be the public in-joke we tell the press, instead of the one about puppies...
18:55 <@gmaxwell> petertodd: well what I'd like is something like  "I want to pay 1 BTC to 1jgarzik. So I consult a distributed hash table (ahh!) to find the public key for 1jgarzik, pJgarzik.  Then I post to 1jgarzik E(pJgarzik, I am instawallet, reach me at xxy || I also can make mtgox payments || bitcoin_txn_paying_1btc). Then the controller of 1jgarzik responds back and says "oh, hi instawallet, I instead of this bitcoin payment, you can make a ...
18:55 <@gmaxwell> ... payment to mtgox account foo --pJgarzik"
18:55 <@gmaxwell> petertodd: so the idea is that any time you want to pay someone you can privately send them a proposed transaction and they can respond back, "no thanks, pay me some other way instead"
18:56 <@gmaxwell> and no one but the recipent learns of this offer.
18:56 <@gmaxwell> And unless they accept the offer you don't learn what their alternative accounts are.
18:56 <@gmaxwell> And the offer comes with a real transaction so you can't make fake offers to people to uncover their mtgox account numbers.
18:57 <@gmaxwell> (though even better: when jgarzik gets that offer he asks mtgox for a one time use account number and thats what he responds with)
19:47 < jgarzik> offer spam
20:08 < jgarzik> anyway, besides SIN'ing
20:10  * jgarzik wonders if anybody has come up with a good way to charge for an overlay network/darknet usage, i.e. a decentralized private network that is self-supporting (provided there are interested users who pay)
22:20 <@sipa> a*P + b*G: 110us !
22:49 < jgarzik> it also strikes me that bitcoin-enabled bots, SIN'ing all over the place, would want a market for automatically bidding on things like storage space, CPU resources, ...
22:49 < jgarzik> (thus could reliable providers have well known SINs that grow respected over time)
22:50 < jgarzik> the market -- buyers, sellers and items being bought/sold -- are as private, or not, as you like
23:20 <@gmaxwell> jgarzik: so one way to do your decentralized private network thing is to have a whole bunch of not-decenteralized bitcoin denominated micropayment systems. And then people advertise which kinds of micropayments they accept... including supporting trading between two accepted kinds so that you can interwork two hosts that don't mutually trust a common micropayment system.
23:27 <@gmaxwell> sipa: so an interesting node... a script that says  PUSH_DATA_TO_BE_SIGNED LSHIFT_AND_PUSH_BIT_OFF_END IF{push R1_1}{push R1_0} POP LSHIFT_AND_PUSH_BIT_OFF_END IF{push R2_1}{push R2_0} POP... RETURN TRUE  when used as an AST-P2SH encodes a lamport checksig. 0_o
23:27 <@gmaxwell> s/node/note/
23:27 <@gmaxwell> using 'no computation' just the AST branches.
23:29 <@gmaxwell> (the data being signed tells you which script-branch preimages you must disclose.
23:29 <@gmaxwell> )
--- Log closed Sun Mar 10 00:00:47 2013