Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UW5tr-0000Pu-6t for bitcoin-development@lists.sourceforge.net; Sat, 27 Apr 2013 14:14:51 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.171 as permitted sender) client-ip=209.85.217.171; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f171.google.com; Received: from mail-lb0-f171.google.com ([209.85.217.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UW5tp-0003zb-G0 for bitcoin-development@lists.sourceforge.net; Sat, 27 Apr 2013 14:14:51 +0000 Received: by mail-lb0-f171.google.com with SMTP id r11so158753lbv.16 for ; Sat, 27 Apr 2013 07:14:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.4.40 with SMTP id h8mr23933036lah.34.1367072082725; Sat, 27 Apr 2013 07:14:42 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Sat, 27 Apr 2013 07:14:42 -0700 (PDT) In-Reply-To: <20130424144649.GB29213@theagricolas.org> References: <20130424144649.GB29213@theagricolas.org> Date: Sat, 27 Apr 2013 16:14:42 +0200 Message-ID: From: Melvin Carvalho To: Craig B Agricola Content-Type: multipart/alternative; boundary=089e013d1d92df926a04db5845cc X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UW5tp-0003zb-G0 Cc: Bitcoin Dev , Web Payments , public-rww Subject: Re: [Bitcoin-development] Sending Bitcoins using RSA keys X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 14:14:51 -0000 --089e013d1d92df926a04db5845cc Content-Type: text/plain; charset=ISO-8859-1 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 > > --089e013d1d92df926a04db5845cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 24 April 2013 16:46, Craig B Agricola <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
=A0 =A0this new address
2) Alice exports the private key for that address (there is a well supporte= d
=A0 =A0format 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 i= t to him
=A0 =A0by 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 c= lient address generation algorithm?

I think what I'm = trying to describe is something more akin to the way a shared secret is gen= erated by TLS.

Agree, that the wallet is also shared, ive not yet worked ou= t a way to 'blind' one side of the wallet, but nor have a proved it= 's impossible, so still working onthat :)
=A0

There's no need for sending a whole wallet; just the one key is needed.= =A0Every
bit of infrastructure needed above already exists. =A0And of course, the ab= ove
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 mech= anism.
They now share control of an address; whoever spends that BTC first wins, s= o
until Bob uses the Bitcoin network to spend that BTC to another address tha= t
only he controls, it's still in joint custody. =A0And if ensuring that = he has
control of the BTC is the last (implicit) step in the procedure above, as w= ell
as yours, then they might as well have simply used the Bitcoin network to d= o
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'l= l work on it.=A0 Essentially it's an automated way to bootstrap the RSA= key community together with bitcoin.=A0 e.g. 99% of GPG users probably don= t have a bitcion wallet or address or client.=A0 I think maybe a user story= will help.
=A0

=A0-Craig

PS. Re-reading, I realize that the above might come off sounding snarky or<= br> =A0 =A0 dismissive; it's not intended that way. =A0I'm wondering if= I'm missing the
=A0 =A0 big picture.

Not snarky at all!= =A0 Appreciate the feedback...
=A0

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. =A0Alice wants to send 1 BTC to Bob.
>
> 1. Alice takes Bob's WebID and encrpyts it with her private key (t= o create
> entropy) ...
>
> 2. Alice uses that message as the seed to produce btc address (as per<= br> > http://brainwalle= t.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 se= rvice
> that delivers powerful full stack analytics. Optimize and monitor your=
> browser, app, & servers with just a few lines of code. Try New Rel= ic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr=

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development


--089e013d1d92df926a04db5845cc--