On 24 April 2013 16:46, Craig B Agricola 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. 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. > > -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 > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >