Melvin Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2013-04-27 📝 Original message:On 24 April 2013 16:46, ...
📅 Original date posted:2013-04-27
📝 Original message:On 24 April 2013 16:46, Craig B Agricola <craig at 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.
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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130427/cf515b60/attachment.html>;
📝 Original message:On 24 April 2013 16:46, Craig B Agricola <craig at 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.
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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130427/cf515b60/attachment.html>;