- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sat, 27 Apr 2013 13:26:45 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Craig B Agricola <craig@theagricolas.org>, public-rww <public-rww@w3.org>, Web Payments <public-webpayments@w3.org>, Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
- Message-ID: <517C0A55.702@openlinksw.com>
On 4/27/13 10:14 AM, Melvin Carvalho wrote: > > > > On 24 April 2013 16:46, Craig B Agricola <craig@theagricolas.org > <mailto:craig@theagricolas.org>> wrote: > > Maybe I'm missing something crucial, but what benefit does this > dance give over > the slightly more obvious mechanism of simply: > 1) Alice generates a new address with her bitcoin client and sends > the BTC to > this new address > 2) Alice exports the private key for that address (there is a well > supported > format for that) > 3) Alice writes a nice email to Bob, including that exported > private key > 4) Alice encrypts the email with Bob's public key using GPG and > sends it to him > by email > 5) Bob decrypts the email > 6) Bob imports the private key into his wallet > > > Yes this works too. This is exactly what S/MIME, an existing protocol facilitates right now. A Certificate with a WebID in its SAN enables anyone get this going without artificial dependencies on CA networks. > > However is it dependent on the bitcoin client address generation > algorithm? > > I think what I'm trying to describe is something more akin to the way > a shared secret is generated by TLS. > > Agree, that the wallet is also shared, ive not yet worked out a way to > 'blind' one side of the wallet, but nor have a proved it's impossible, > so still working onthat :) > > > There's no need for sending a whole wallet; just the one key is > needed. Every > bit of infrastructure needed above already exists. And of course, > the above > has the same issue as your proposal; this is a way for two > trusting parties to > send BTC without using the Bitcoin network, but it's not a payment > mechanism. > They now share control of an address; whoever spends that BTC > first wins, so > until Bob uses the Bitcoin network to spend that BTC to another > address that > only he controls, it's still in joint custody. And if ensuring > that he has > control of the BTC is the last (implicit) step in the procedure > above, as well > as yours, then they might as well have simply used the Bitcoin > network to do > the transfer in the first place. > > Did I miss the point entirely? > > > Perhaps I've not described the problem statement as clearly as I > could, I'll work on it. Essentially it's an automated way to > bootstrap the RSA key community together with bitcoin. e.g. 99% of > GPG users probably dont have a bitcion wallet or address or client. I > think maybe a user story will help. Not just GPG, remember S/MIME too :-) Anyway, best to spell out the problem in as simple a manner possible. Then align with the solution you are trying to create which (in my eyes) boils down to using standards based components that already exist. Kingsley > > -Craig > > PS. Re-reading, I realize that the above might come off sounding > snarky or > dismissive; it's not intended that way. I'm wondering if I'm > missing the > big picture. > > > Not snarky at all! Appreciate the feedback... > > > On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote: > > So there's a slight world divide in digital payments with > bitcoin using > > ECDSA and GPG, payswarm / webid etc using largely RSA > > > > Here's how to bring the two worlds together and enable bitcoins > be sent > > over webid or payswarm > > > > > > Problem: Alice and Bob have RSA key pairs, but no public bitcoin > > addresses. Alice wants to send 1 BTC to Bob. > > > > 1. Alice takes Bob's WebID and encrpyts it with her private key > (to create > > entropy) ... > > > > 2. Alice uses that message as the seed to produce btc address > (as per > > http://brainwallet.org ) with ECDSA key pair > > > > 3. Alice sends coins to this address > > > > 4. Alice and then encrypts the seed again with Bob's public key > > > > 5. Bob decrypts the seed using his private key > > > > 6. Bob can now use the seed to recreate the wallet and spend the > coins > > > > Unless I've made an error, I believe this unites the web > paradigm and > > crypto currency paradigm into one potentially giant eco system ... > > > > ------------------------------------------------------------------------------ > > Try New Relic Now & We'll Send You this Cool Shirt > > New Relic is the only SaaS-based application performance > monitoring service > > that delivers powerful full stack analytics. Optimize and > monitor your > > browser, app, & servers with just a few lines of code. Try New Relic > > and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_apr > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > <mailto:Bitcoin-development@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Saturday, 27 April 2013 17:27:08 UTC