Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

2013-08-09 Thread Alan Reiner 
That's fine.  I just want to make sure it's considered for inclusion at
some point, because I really hope to leverage the "identity" mechanism I
just described, and it's much easier if it's part of a standard instead
of convincing others to go around the standard with us.

I have not spent much time looking at the payment protocol itself.  I
didn't feel like I'd have much to contribute (besides requesting a
feature I know isn't there).  I was planning to wait until it was
complete before fully grokking and implementing it in Armory.


On 08/09/2013 03:58 PM, Mike Hearn wrote:
> Payment protocol is locked down for v1 already. But did you read it?
> It doesn't use addresses anywhere. Payments are specified in terms of
> a list of outputs which can contain any script. Of course it could be
> a pay-to-address script, but pay-to-address uses more bytes in the
> chain and there isn't any typeability benefit.
>
> The multiplication trick for deterministic keys is a nice one and
> worth doing, but it has to be a v2 feature by this point. It's more
> important to get v1 widely implemented and deployed first.
>
>
> On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner  > wrote:
>
> Guys,
>
> I'd like to reiterate my previous request to support this
> alternate address serialization in the payment protocol.  We got
> caught up in the specifics of one use case, but didn't acknowledge
> that it's still a valid address representation that will provide
> value to those who wish to use it and can be safely ignored by others.
>
> Current address format:   binary_to_base58( idbyte +
> hash160(pubkey) + checksum)
> Alternate format: binary_to_base58( idbyte + parentpubkey
> + multiplier + checksum)
>
> The receiving party will multiply the pubkey by the multiplier,
> and then hash it to get the 20-byte address to send to.  The idea
> is that you use your BIP 32 parent public key, and then you
> generate whatever child you want, and only send them the
> multiplier used (not the chaincode).  This preserves privacy, but
> if the recipient has your parent public key already, they can
> identify that address being linked to you, but cannot determine
> any other addresses in your wallet.
>
> This form has no drawbacks to the existing address format except
> for being longer and requiring an extra EC multiplication by the
> person sending to that address.  But the advantage is that it
> optionally allows the sender to provide more information than
> currently contained in the 25-byte hash160 form.  The discussion
> about this got side-tracked with the use case I presented, but I
> believe there are plenty of other uses for this.
>
> The particular use case I had in mind was that certain services
> could be setup (pre-arranged), say between wallet software and a
> business/exchange.  The exchange would like to be able to reliably
> send addresses to the user for deposit, without risk of MITM, or
> even if their own public server is compromised.  The author of
> wallet software pre-verifies the public key portion of the
> service, and either hardcodes it into the software, or hardcodes
> their own public key into the software and makes the service's
> signed public key available through query server (allowing the
> software author to offline-sign replacement keys, or add keys for
> new service providers, as needed). 
>
> When the user's software receives a payment address, the software
> can verify it belongs to that service.  You can't use dedicated
> chain technique, because it would either have to be exchanged with
> the user on first transaction which half defeats the purpose, or
> they give them the full public key and chaincode which allows the
> user to see /all /addresses ever used by the service.  Neither one
> is a reasonable solution.
>
> This use case doesn't necessarily scale, but it doesn't have to. 
> It simply allows service providers to skip the SSL and go right to
> public key exchange/verification for a few of the important
> services they provide access to, and will provide better security
> than relying on SSL/PKI.  This would simply be one, coexisting
> option for providing payment details in the absence (or in
> addition to) SSL/PKI infrastructure.
>
> I'm sure there's other use cases, but it seems simple enough and
> non-disruptive enough that it could be supported easily for no
> other reason than to support that use case (which I intend to
> implement in Armory to help verify high-volume services).
>
> -Alan
>
>
>
>
>
> On 06/26/2013 11:29 AM, Alan Reiner wrote:
>> Although I'd still prefer my original request, I get much of what
>> I want from your guys' recommendation.  It complicates the wallet
>> design, because it requires tracking and associatin

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

2013-08-09 Thread Gavin Andresen 
As Mike said: the payment protocol doesn't use bitcoin addresses under
the covers.

It is also designed to be easily extensible, so if you want the server
to send the wallet software a public key and multiplier, then add
"publickey" and "multiplier" optional fields to the PaymentDetails (or
maybe Output) message.

-- 
--
Gavin Andresen

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BitMail.sf.net - encrypted p2p email

2013-08-09 Thread Wendell 
Jesus, please stop this. :(

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 9, 2013, at 9:01 PM, Randolph D. wrote:

> anyone tested the secure encrypted p2p email: http://bitmail.sf.net
>  
> SVN here:
> 
> svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code
> 
> http://sourceforge.net/p/spot-on/code/commit_browser

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

2013-08-09 Thread Mike Hearn 
It's BIP specified and implemented in Bitcoin-Qt so now is the time to
start :) I'm hoping that most wallets can announce support near
simultaneously 


On Fri, Aug 9, 2013 at 10:12 PM, Alan Reiner  wrote:

>  That's fine.  I just want to make sure it's considered for inclusion at
> some point, because I really hope to leverage the "identity" mechanism I
> just described, and it's much easier if it's part of a standard instead of
> convincing others to go around the standard with us.
>
> I have not spent much time looking at the payment protocol itself.  I
> didn't feel like I'd have much to contribute (besides requesting a feature
> I know isn't there).  I was planning to wait until it was complete before
> fully grokking and implementing it in Armory.
>
>
>
> On 08/09/2013 03:58 PM, Mike Hearn wrote:
>
> Payment protocol is locked down for v1 already. But did you read it? It
> doesn't use addresses anywhere. Payments are specified in terms of a list
> of outputs which can contain any script. Of course it could be a
> pay-to-address script, but pay-to-address uses more bytes in the chain and
> there isn't any typeability benefit.
>
>  The multiplication trick for deterministic keys is a nice one and worth
> doing, but it has to be a v2 feature by this point. It's more important to
> get v1 widely implemented and deployed first.
>
>
> On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner  wrote:
>
>>  Guys,
>>
>> I'd like to reiterate my previous request to support this alternate
>> address serialization in the payment protocol.  We got caught up in the
>> specifics of one use case, but didn't acknowledge that it's still a valid
>> address representation that will provide value to those who wish to use it
>> and can be safely ignored by others.
>>
>> Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
>> checksum)
>> Alternate format: binary_to_base58( idbyte + parentpubkey +
>> multiplier + checksum)
>>
>> The receiving party will multiply the pubkey by the multiplier, and then
>> hash it to get the 20-byte address to send to.  The idea is that you use
>> your BIP 32 parent public key, and then you generate whatever child you
>> want, and only send them the multiplier used (not the chaincode).  This
>> preserves privacy, but if the recipient has your parent public key already,
>> they can identify that address being linked to you, but cannot determine
>> any other addresses in your wallet.
>>
>> This form has no drawbacks to the existing address format except for
>> being longer and requiring an extra EC multiplication by the person sending
>> to that address.  But the advantage is that it optionally allows the sender
>> to provide more information than currently contained in the 25-byte hash160
>> form.  The discussion about this got side-tracked with the use case I
>> presented, but I believe there are plenty of other uses for this.
>>
>> The particular use case I had in mind was that certain services could be
>> setup (pre-arranged), say between wallet software and a business/exchange.
>> The exchange would like to be able to reliably send addresses to the user
>> for deposit, without risk of MITM, or even if their own public server is
>> compromised.  The author of wallet software pre-verifies the public key
>> portion of the service, and either hardcodes it into the software, or
>> hardcodes their own public key into the software and makes the service's
>> signed public key available through query server (allowing the software
>> author to offline-sign replacement keys, or add keys for new service
>> providers, as needed).
>>
>> When the user's software receives a payment address, the software can
>> verify it belongs to that service.  You can't use dedicated chain
>> technique, because it would either have to be exchanged with the user on
>> first transaction which half defeats the purpose, or they give them the
>> full public key and chaincode which allows the user to see *all *addresses
>> ever used by the service.  Neither one is a reasonable solution.
>>
>> This use case doesn't necessarily scale, but it doesn't have to.  It
>> simply allows service providers to skip the SSL and go right to public key
>> exchange/verification for a few of the important services they provide
>> access to, and will provide better security than relying on SSL/PKI.  This
>> would simply be one, coexisting option for providing payment details in the
>> absence (or in addition to) SSL/PKI infrastructure.
>>
>> I'm sure there's other use cases, but it seems simple enough and
>> non-disruptive enough that it could be supported easily for no other reason
>> than to support that use case (which I intend to implement in Armory to
>> help verify high-volume services).
>>
>> -Alan
>>
>>
>>
>>
>>
>> On 06/26/2013 11:29 AM, Alan Reiner wrote:
>>
>> Although I'd still prefer my original request, I get much of what I want
>> from your guys' recommendation.  It complicates the wallet design, because
>> it req

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

2013-08-09 Thread Mike Hearn 
Payment protocol is locked down for v1 already. But did you read it? It
doesn't use addresses anywhere. Payments are specified in terms of a list
of outputs which can contain any script. Of course it could be a
pay-to-address script, but pay-to-address uses more bytes in the chain and
there isn't any typeability benefit.

The multiplication trick for deterministic keys is a nice one and worth
doing, but it has to be a v2 feature by this point. It's more important to
get v1 widely implemented and deployed first.


On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner  wrote:

>  Guys,
>
> I'd like to reiterate my previous request to support this alternate
> address serialization in the payment protocol.  We got caught up in the
> specifics of one use case, but didn't acknowledge that it's still a valid
> address representation that will provide value to those who wish to use it
> and can be safely ignored by others.
>
> Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
> checksum)
> Alternate format: binary_to_base58( idbyte + parentpubkey +
> multiplier + checksum)
>
> The receiving party will multiply the pubkey by the multiplier, and then
> hash it to get the 20-byte address to send to.  The idea is that you use
> your BIP 32 parent public key, and then you generate whatever child you
> want, and only send them the multiplier used (not the chaincode).  This
> preserves privacy, but if the recipient has your parent public key already,
> they can identify that address being linked to you, but cannot determine
> any other addresses in your wallet.
>
> This form has no drawbacks to the existing address format except for being
> longer and requiring an extra EC multiplication by the person sending to
> that address.  But the advantage is that it optionally allows the sender to
> provide more information than currently contained in the 25-byte hash160
> form.  The discussion about this got side-tracked with the use case I
> presented, but I believe there are plenty of other uses for this.
>
> The particular use case I had in mind was that certain services could be
> setup (pre-arranged), say between wallet software and a business/exchange.
> The exchange would like to be able to reliably send addresses to the user
> for deposit, without risk of MITM, or even if their own public server is
> compromised.  The author of wallet software pre-verifies the public key
> portion of the service, and either hardcodes it into the software, or
> hardcodes their own public key into the software and makes the service's
> signed public key available through query server (allowing the software
> author to offline-sign replacement keys, or add keys for new service
> providers, as needed).
>
> When the user's software receives a payment address, the software can
> verify it belongs to that service.  You can't use dedicated chain
> technique, because it would either have to be exchanged with the user on
> first transaction which half defeats the purpose, or they give them the
> full public key and chaincode which allows the user to see *all *addresses
> ever used by the service.  Neither one is a reasonable solution.
>
> This use case doesn't necessarily scale, but it doesn't have to.  It
> simply allows service providers to skip the SSL and go right to public key
> exchange/verification for a few of the important services they provide
> access to, and will provide better security than relying on SSL/PKI.  This
> would simply be one, coexisting option for providing payment details in the
> absence (or in addition to) SSL/PKI infrastructure.
>
> I'm sure there's other use cases, but it seems simple enough and
> non-disruptive enough that it could be supported easily for no other reason
> than to support that use case (which I intend to implement in Armory to
> help verify high-volume services).
>
> -Alan
>
>
>
>
>
> On 06/26/2013 11:29 AM, Alan Reiner wrote:
>
> Although I'd still prefer my original request, I get much of what I want
> from your guys' recommendation.  It complicates the wallet design, because
> it requires tracking and associating a matrix of addresses for each wallet,
> instead of a single linear list.  But if this is what it's going to take
> then I will go along.
>
> Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain used
> for distributing addresses, and j=1 is the "internal" chain for sending
> change.  The CONOPs (concept of operations) for the extended wallet would
> be like Jeremy described:
>
> - Chains with j>=2 would be independent address chains carved out for
> individuals relationships
> - Add wallet code to individually associate each j-value with a particular
> identity
> - Update the wallet code to pool all the addresses in all j-chains when
> calculating the balance of the wallet and/or creating transactions
> - When choosing to generically "Receive Bitcoins", will pick the next
> address from the j=0 chain
> - Will have to add extra function to "Receive Bitc

[Bitcoin-development] BitMail.sf.net - encrypted p2p email

2013-08-09 Thread Randolph D. 
anyone tested the secure encrypted p2p email: http://bitmail.sf.net

SVN here:

svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code

http://sourceforge.net/p/spot-on/code/commit_browser
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Jeff Garzik 
On Fri, Aug 9, 2013 at 1:58 PM, Wendell  wrote:
> No, it's not -- but that's certainly very cool to see Jeff.
>
> How is BitPay going to put this to use?

Well, "wally" is just a demo application, a command line client to
prove a technology.

The main development is in places like "node-libcoin", where a wallet
platform is being developed.  While maintaining a strong commitment to
the blockchain engine side of bitcoind, BitPay has enterprise wallet
needs that do not necessarily mesh well with the standard bitcoind
wallet.  Multi-sig, P2SH and other advanced features are key to the
future use of bitcoin in large enterprises.  Managers, CEOs and other
functionaries at a corporation may each have their own wallets /
keyrings, and cooperate to sign large value, high security bitcoin
multi-sig transactions, for example.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Wendell 
No, it's not -- but that's certainly very cool to see Jeff.

How is BitPay going to put this to use?

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 9, 2013, at 3:08 PM, Jeff Garzik wrote:

> Certainly.  BitPay is working on such a wallet:
> https://github.com/jgarzik/wally
> 
> wally uses node.js JavaScript, and not browser JavaScript, so not
> exactly what you're talking about...


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

2013-08-09 Thread Alan Reiner 
Guys,

I'd like to reiterate my previous request to support this alternate
address serialization in the payment protocol.  We got caught up in the
specifics of one use case, but didn't acknowledge that it's still a
valid address representation that will provide value to those who wish
to use it and can be safely ignored by others.

Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
checksum)
Alternate format: binary_to_base58( idbyte + parentpubkey +
multiplier + checksum)

The receiving party will multiply the pubkey by the multiplier, and then
hash it to get the 20-byte address to send to.  The idea is that you use
your BIP 32 parent public key, and then you generate whatever child you
want, and only send them the multiplier used (not the chaincode).  This
preserves privacy, but if the recipient has your parent public key
already, they can identify that address being linked to you, but cannot
determine any other addresses in your wallet.

This form has no drawbacks to the existing address format except for
being longer and requiring an extra EC multiplication by the person
sending to that address.  But the advantage is that it optionally allows
the sender to provide more information than currently contained in the
25-byte hash160 form.  The discussion about this got side-tracked with
the use case I presented, but I believe there are plenty of other uses
for this.

The particular use case I had in mind was that certain services could be
setup (pre-arranged), say between wallet software and a
business/exchange.  The exchange would like to be able to reliably send
addresses to the user for deposit, without risk of MITM, or even if
their own public server is compromised.  The author of wallet software
pre-verifies the public key portion of the service, and either hardcodes
it into the software, or hardcodes their own public key into the
software and makes the service's signed public key available through
query server (allowing the software author to offline-sign replacement
keys, or add keys for new service providers, as needed). 

When the user's software receives a payment address, the software can
verify it belongs to that service.  You can't use dedicated chain
technique, because it would either have to be exchanged with the user on
first transaction which half defeats the purpose, or they give them the
full public key and chaincode which allows the user to see /all
/addresses ever used by the service.  Neither one is a reasonable solution.

This use case doesn't necessarily scale, but it doesn't have to.  It
simply allows service providers to skip the SSL and go right to public
key exchange/verification for a few of the important services they
provide access to, and will provide better security than relying on
SSL/PKI.  This would simply be one, coexisting option for providing
payment details in the absence (or in addition to) SSL/PKI infrastructure.

I'm sure there's other use cases, but it seems simple enough and
non-disruptive enough that it could be supported easily for no other
reason than to support that use case (which I intend to implement in
Armory to help verify high-volume services).

-Alan





On 06/26/2013 11:29 AM, Alan Reiner wrote:
> Although I'd still prefer my original request, I get much of what I
> want from your guys' recommendation.  It complicates the wallet
> design, because it requires tracking and associating a matrix of
> addresses for each wallet, instead of a single linear list.  But if
> this is what it's going to take then I will go along. 
>
> Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
> used for distributing addresses, and j=1 is the "internal" chain for
> sending change.  The CONOPs (concept of operations) for the extended
> wallet would be like Jeremy described:
>
> - Chains with j>=2 would be independent address chains carved out for
> individuals relationships
> - Add wallet code to individually associate each j-value with a
> particular identity
> - Update the wallet code to pool all the addresses in all j-chains
> when calculating the balance of the wallet and/or creating transactions
> - When choosing to generically "Receive Bitcoins", will pick the next
> address from the j=0 chain
> - Will have to add extra function to "Receive Bitcoins" button to
> allow creation of new contacts/identities.
> - Change will always go to the next address in j=1, no matter which
> chains are used to provide inputs.
> - Add code to figure out lookaheads for each alternate chain.  Not
> just each chain, but looking ahead a couple chains, too.  Luckily, the
> lookahead doesn't have to be very big for chains j>=1 
> - Add an interface to display and choose the different chains in your
> wallet, and export the pubkey&chaincode in some
> soon-to-be-standardized format. 
> - Add code and interface to receive and track alternate j-chains from
> other clients/users, and maintain those.  Should we try associating
> incoming and outgoin

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Wendell 
"Packaged app pages always load locally. This allows apps to be less dependent 
on the network. Once a user installs an app, they have full control over the 
app's lifecycle. Apps open and close quickly, and the system can shut apps down 
at any time to improve performance. Users can fully uninstall apps."

Does this mean that upon install, a nice, icon-emblazoned package will drop 
into my /Applications folder on a Mac, or in my Windows Start menu, etc... Or 
are packaged apps always launched and maintained from within Chrome itself?

Provided that the technical stuff could be made to work within the context of 
the more limited API, this certainly seems like an interesting, user-friendly 
way to distribute a Bitcoin wallet!

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 9, 2013, at 2:14 PM, Mike Hearn wrote:

> Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP 
> socket connections:
> 
>   http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html
> 
> You would do it as a packaged app: 
> http://developer.chrome.com/apps/about_apps.html  because then they're a lot 
> more similar to native apps (they get their own windows, run offline, etc). 
> 
> But these aren't standard APIs. They're all Chrome extensions. I doubt HTML5 
> will support USB access anytime soon, for instance, but packaged apps do.

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Jeff Garzik 
On Fri, Aug 9, 2013 at 7:32 AM, Wendell  wrote:
> To those of you in the know about modern browser tech:
>
> Does it seem at all conceivable that an SPV wallet could be built entirely in 
> JavaScript? And if indeed it is within the realm of the possible, how would 
> such a thing be safely distributed for use? Would a signed Chrome Plugin be 
> an ideal vehicle?

Certainly.  BitPay is working on such a wallet:
https://github.com/jgarzik/wally

wally uses node.js JavaScript, and not browser JavaScript, so not
exactly what you're talking about...

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Melvin Carvalho 
On 9 August 2013 13:59, Wendell  wrote:

> We have been discussing something like this over here too, as well as
> exploring more esoteric blockchain+signature-based "SSO" implementations as
> discussed by John Light and others.
>

I've been using SSO for years using an X.509 private key in my browser, and
my public key referenced in my home page.

The unfortunate thing is that X.509 tends to use RSA, and bitcoin tends to
use ECC for space reasons.  Since, in its simplest form, bitcoin is a
distributed ledger of public key / balance values you could imagine an
enormous eco system where every key pair become a wallet with 10s of
millions of users.

I was thinking about an alt coin along these lines.  The problem is that
there's no OP_CODE for RSA and the block chain would become massive.


>
> One of our long-term ambitions with Hive is to provide a (mostly)
> user-transparent, decentralized authentication service. It sounds like our
> infrastructure could already handle a Persona implementation, and we very
> much want to get behind some forward-thinking standard. So as long as the
> plan _IS_ to remove said 'centralized struts' at the appropriate time, I'd
> say we're interested in exploring this further.
>

Sounds great, would love to hear more about what you come up with!


>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote:
>
> > This is just me making notes for myself, I'm not seriously suggesting
> this be implemented any time soon.
> >
> > Mozilla Persona is an infrastructure for web based single sign on. It
> works by having email providers sign temporary certificates for their
> users, whose browsers then sign server-provided challenges to prove their
> email address.
> >
> > Because an SSO system is a classic chicken/egg setup, they run various
> fallback services that allow anyone with an email address to take part.
> They also integrate with the Google/Yahoo SSO systems as well. The
> intention being that they do this until Persona becomes big enough to
> matter, and then they can remove the centralised struts and the system
> becomes transparently decentralised.
> >
> > In other words, they seem to do a lot of things right.
> >
> > Of course you can already sign payments using an X.509 cert issued to an
> email address with v1 of the payment protocol, so technically no new PKI is
> needed. But the benefit of leveraging Persona would be convenience - you
> can get yourself a Persona cert and use it to sign in to websites with a
> single click, and the user experience is smart and professional. CAs in
> contrast are designed for web site admins really so the experience of
> getting a cert for an email address is rather variable and more heavyweight.
> >
> > Unfortunately Persona does not use X.509. It uses a custom thing based
> on JSON. However, under the hood it's just assertions signed by RSA keys,
> so an implementation is likely to be quite easy. From the users
> perspective, their wallet app would embed a browser and drive it as if it
> were signing into a website, but stop after the user is signed into Persona
> and a user cert has been provisioned. It can then sign payment requests
> automatically. For many users, it'd be just one click, which is pretty neat.
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Melvin Carvalho 
On 9 August 2013 14:08, Mike Hearn  wrote:

> Bitcoin sought to reduce dependence on trusted third parties, where as,
>> persona is increasing the reach of trusted third parties.  The keys and
>> passwords are stored on mozilla's servers, sometimes on your email
>> providers.  Persona, is however, a progression and will hopefully improve
>> its security and decentralization as it goes along.
>>
>
> When Persona is supported by all the key players in a transaction Mozilla
> doesn't get anything, do they? You can easily run your own IDP on a
> personal server if you're the kind of person who likes to do that, then run
> Firefox so you have a native implementation and the Mozilla servers aren't
> involved. The keys never leave your computers.
>

You'd need to run your own email server and/or change email address, which
is not in the reach of the average user, and maybe not even of some
businesses.


>
> Whilst X.509 certs can indeed be issued for any arbitrary string, you
> still need a CA that will do it for you, and that's typically not so
> trivial. CAs aren't meant for widespread end user adoption, really, whereas
> Persona is.
>

You can self sign X.509 certificates quite easily (e.g. one click via
), then rely on a decentralized web of trust to remove browser
warnings.  A few people are working on this.


>
> I don't think Persona is any more or less centralised than other PKIs,
> really, just easier to use. Ultimately the string you're verifying is a
> user@host pair, so the host is centralised via DNS and to verify the
> assertions it vends, you must use SSL to connect to it, so under the hood
> the regular SSL PKI is still there.
>
>
>
It is easier to use, that's a great plus.  But convenience is often a trade
off with security.

I dont user user@host, I use my home page because it's easy to dereference
and get a public key.  Email is hard to dereference.

Yes, there is a reliance on DNS, which Tim calls the 'Achilles heel' of the
web, but it's held up quite well so far (fortunately for us).

Mozilla also have a master key to most email accounts, so if anyone got
access to that they could impersonate the vast majority of users that have
not opted in.  I would not use persona for financial stuff, but if I made a
casual app with non sensitive information it would be one of the top
choices, imho
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Mike Hearn 
Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP
socket connections:

   http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html

You would do it as a packaged app:
http://developer.chrome.com/apps/about_apps.html  because then they're a
lot more similar to native apps (they get their own windows, run offline,
etc).

But these aren't standard APIs. They're all Chrome extensions. I doubt
HTML5 will support USB access anytime soon, for instance, but packaged apps
do.



On Fri, Aug 9, 2013 at 2:10 PM, Mike Hearn  wrote:

> Code that runs inside NativeClient has the same access level as JavaScript
> does. It's just a way to do things faster.
>
> Distribution as a Chrome app via the Chrome store is a fine approach, as
> long as people understand it's just an app platform like any other. It has
> pros and cons that must be weighed up. For instance, Chrome for mobile
> doesn't really do apps, at least not at the moment. Also, you're still
> limited by what APIs Chrome exposes, which are a strict subset of what a
> real OS provides.
>
>
> On Fri, Aug 9, 2013 at 2:05 PM, Wendell  wrote:
>
>> Right, I'm not suggesting that we have this wallet in a web app, but
>> rather precisely what you are talking about: using special browser
>> features, and bundling it. I am fundamentally monoculture-opposed, but
>> given Chrome's present installed base, that initial target makes sense to
>> me, provided that we could have a one-click installation (as per normal,
>> via the Chrome Store).
>>
>> Chrome also has this "Native Client" plug-in: I know next to nothing
>> about it, and this goes off the rails of the Subject, but perhaps an SPV
>> implementation there could be a solution to the concerns you expressed?
>>
>> -wendell
>>
>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>>
>> On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:
>>
>> > JavaScript is turing complete so of course it can be done. The real
>> question you're asking is, can it be done in a web app? I think the answer
>> is I think "no" because web apps aren't allowed to make raw TCP socket
>> connections.
>> >
>> > Now there may be a way around that by using browser-specific things
>> like extensions or "installable apps" which give your code greater access
>> permissions. This approach means you essentially use Chrome as your app
>> platform instead of a JVM, the assumption presumably being that more users
>> have Chrome than a JVM. The flip side is that users who don't would
>> probably balk at the idea of installing an entire browser in order to run a
>> wallet app, whereas a JVM can be bundled and the resulting app acts like
>> any other. I don't know of a convenient way to "statically link" Chrome
>> into a regular-looking application.
>> >
>> > I personally wouldn't find such a design compelling. Whilst Java isn't
>> exactly a great language, JavaScript is significantly worse in virtually
>> all aspects. I don't understand why anyone would want to use JavaScript
>> outside the browser - you get less safety, less performance, fewer
>> features, less mature tools and so on. If the end result is an installable
>> app like any other, all you did is cripple yourself vs the competition
>> that's using languages/platforms designed for it.
>>
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Mike Hearn 
Code that runs inside NativeClient has the same access level as JavaScript
does. It's just a way to do things faster.

Distribution as a Chrome app via the Chrome store is a fine approach, as
long as people understand it's just an app platform like any other. It has
pros and cons that must be weighed up. For instance, Chrome for mobile
doesn't really do apps, at least not at the moment. Also, you're still
limited by what APIs Chrome exposes, which are a strict subset of what a
real OS provides.


On Fri, Aug 9, 2013 at 2:05 PM, Wendell  wrote:

> Right, I'm not suggesting that we have this wallet in a web app, but
> rather precisely what you are talking about: using special browser
> features, and bundling it. I am fundamentally monoculture-opposed, but
> given Chrome's present installed base, that initial target makes sense to
> me, provided that we could have a one-click installation (as per normal,
> via the Chrome Store).
>
> Chrome also has this "Native Client" plug-in: I know next to nothing about
> it, and this goes off the rails of the Subject, but perhaps an SPV
> implementation there could be a solution to the concerns you expressed?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:
>
> > JavaScript is turing complete so of course it can be done. The real
> question you're asking is, can it be done in a web app? I think the answer
> is I think "no" because web apps aren't allowed to make raw TCP socket
> connections.
> >
> > Now there may be a way around that by using browser-specific things like
> extensions or "installable apps" which give your code greater access
> permissions. This approach means you essentially use Chrome as your app
> platform instead of a JVM, the assumption presumably being that more users
> have Chrome than a JVM. The flip side is that users who don't would
> probably balk at the idea of installing an entire browser in order to run a
> wallet app, whereas a JVM can be bundled and the resulting app acts like
> any other. I don't know of a convenient way to "statically link" Chrome
> into a regular-looking application.
> >
> > I personally wouldn't find such a design compelling. Whilst Java isn't
> exactly a great language, JavaScript is significantly worse in virtually
> all aspects. I don't understand why anyone would want to use JavaScript
> outside the browser - you get less safety, less performance, fewer
> features, less mature tools and so on. If the end result is an installable
> app like any other, all you did is cripple yourself vs the competition
> that's using languages/platforms designed for it.
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Mike Hearn 
>
> Bitcoin sought to reduce dependence on trusted third parties, where as,
> persona is increasing the reach of trusted third parties.  The keys and
> passwords are stored on mozilla's servers, sometimes on your email
> providers.  Persona, is however, a progression and will hopefully improve
> its security and decentralization as it goes along.
>

When Persona is supported by all the key players in a transaction Mozilla
doesn't get anything, do they? You can easily run your own IDP on a
personal server if you're the kind of person who likes to do that, then run
Firefox so you have a native implementation and the Mozilla servers aren't
involved. The keys never leave your computers.

Whilst X.509 certs can indeed be issued for any arbitrary string, you still
need a CA that will do it for you, and that's typically not so trivial. CAs
aren't meant for widespread end user adoption, really, whereas Persona is.

I don't think Persona is any more or less centralised than other PKIs,
really, just easier to use. Ultimately the string you're verifying is a
user@host pair, so the host is centralised via DNS and to verify the
assertions it vends, you must use SSL to connect to it, so under the hood
the regular SSL PKI is still there.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Wendell 
Right, I'm not suggesting that we have this wallet in a web app, but rather 
precisely what you are talking about: using special browser features, and 
bundling it. I am fundamentally monoculture-opposed, but given Chrome's present 
installed base, that initial target makes sense to me, provided that we could 
have a one-click installation (as per normal, via the Chrome Store).

Chrome also has this "Native Client" plug-in: I know next to nothing about it, 
and this goes off the rails of the Subject, but perhaps an SPV implementation 
there could be a solution to the concerns you expressed?

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:

> JavaScript is turing complete so of course it can be done. The real question 
> you're asking is, can it be done in a web app? I think the answer is I think 
> "no" because web apps aren't allowed to make raw TCP socket connections.
> 
> Now there may be a way around that by using browser-specific things like 
> extensions or "installable apps" which give your code greater access 
> permissions. This approach means you essentially use Chrome as your app 
> platform instead of a JVM, the assumption presumably being that more users 
> have Chrome than a JVM. The flip side is that users who don't would probably 
> balk at the idea of installing an entire browser in order to run a wallet 
> app, whereas a JVM can be bundled and the resulting app acts like any other. 
> I don't know of a convenient way to "statically link" Chrome into a 
> regular-looking application.
> 
> I personally wouldn't find such a design compelling. Whilst Java isn't 
> exactly a great language, JavaScript is significantly worse in virtually all 
> aspects. I don't understand why anyone would want to use JavaScript outside 
> the browser - you get less safety, less performance, fewer features, less 
> mature tools and so on. If the end result is an installable app like any 
> other, all you did is cripple yourself vs the competition that's using 
> languages/platforms designed for it.

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Wendell 
We have been discussing something like this over here too, as well as exploring 
more esoteric blockchain+signature-based "SSO" implementations as discussed by 
John Light and others.

One of our long-term ambitions with Hive is to provide a (mostly) 
user-transparent, decentralized authentication service. It sounds like our 
infrastructure could already handle a Persona implementation, and we very much 
want to get behind some forward-thinking standard. So as long as the plan _IS_ 
to remove said 'centralized struts' at the appropriate time, I'd say we're 
interested in exploring this further.

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote:

> This is just me making notes for myself, I'm not seriously suggesting this be 
> implemented any time soon.
> 
> Mozilla Persona is an infrastructure for web based single sign on. It works 
> by having email providers sign temporary certificates for their users, whose 
> browsers then sign server-provided challenges to prove their email address.
> 
> Because an SSO system is a classic chicken/egg setup, they run various 
> fallback services that allow anyone with an email address to take part. They 
> also integrate with the Google/Yahoo SSO systems as well. The intention being 
> that they do this until Persona becomes big enough to matter, and then they 
> can remove the centralised struts and the system becomes transparently 
> decentralised.
> 
> In other words, they seem to do a lot of things right.
> 
> Of course you can already sign payments using an X.509 cert issued to an 
> email address with v1 of the payment protocol, so technically no new PKI is 
> needed. But the benefit of leveraging Persona would be convenience - you can 
> get yourself a Persona cert and use it to sign in to websites with a single 
> click, and the user experience is smart and professional. CAs in contrast are 
> designed for web site admins really so the experience of getting a cert for 
> an email address is rather variable and more heavyweight.
> 
> Unfortunately Persona does not use X.509. It uses a custom thing based on 
> JSON. However, under the hood it's just assertions signed by RSA keys, so an 
> implementation is likely to be quite easy. From the users perspective, their 
> wallet app would embed a browser and drive it as if it were signing into a 
> website, but stop after the user is signed into Persona and a user cert has 
> been provisioned. It can then sign payment requests automatically. For many 
> users, it'd be just one click, which is pretty neat.

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Melvin Carvalho 
On 9 August 2013 13:43, Mike Hearn  wrote:

> This is just me making notes for myself, I'm not seriously suggesting this
> be implemented any time soon.
>
> Mozilla Persona is an infrastructure for web based single sign on. It
> works by having email providers sign temporary certificates for their
> users, whose browsers then sign server-provided challenges to prove their
> email address.
>
> Because an SSO system is a classic chicken/egg setup, they run various
> fallback services that allow anyone with an email address to take part.
> They also integrate with the Google/Yahoo SSO systems as well. The
> intention being that they do this until Persona becomes big enough to
> matter, and then they can remove the centralised struts and the system
> becomes transparently decentralised.
>
> In other words, they seem to do a lot of things right.
>
> Of course you can already sign payments using an X.509 cert issued to an
> email address with v1 of the payment protocol, so technically no new PKI is
> needed. But the benefit of leveraging Persona would be convenience - you
> can get yourself a Persona cert and use it to sign in to websites with a
> single click, and the user experience is smart and professional. CAs in
> contrast are designed for web site admins really so the experience of
> getting a cert for an email address is rather variable and more heavyweight.
>
> Unfortunately Persona does not use X.509. It uses a custom thing based on
> JSON. However, under the hood it's just assertions signed by RSA keys, so
> an implementation is likely to be quite easy. From the users perspective,
> their wallet app would embed a browser and drive it as if it were signing
> into a website, but stop after the user is signed into Persona and a user
> cert has been provisioned. It can then sign payment requests automatically.
> For many users, it'd be just one click, which is pretty neat.
>

Persona, in it's current state, is the exact opposite of the principle
behind of bitcoin.

Bitcoin sought to reduce dependence on trusted third parties, where as,
persona is increasing the reach of trusted third parties.  The keys and
passwords are stored on mozilla's servers, sometimes on your email
providers.  Persona, is however, a progression and will hopefully improve
its security and decentralization as it goes along.

A (client or server side) X.509 cert can be issued to any address, be it
email, telephone, webpage, *or* to a bitcoin address, it allows any URI in
he subjectAlternativeName field.  This is much more of bitcoin like model
where the private key sits on your client and the public key is in
discoverable by the other end.

Most enterprises (including Mozilla) take the stance that key management on
the client is beyond the average user.  The notable exception is twitter
who are rolling out 2 factor auth based on PKI.

If you're interested in signing stuff with RSA (or other) keys, the web
payments and payswarm guys have done a ton of work on this, including
implementations, which you may be able to reuse ...


>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Mike Hearn 
JavaScript is turing complete so of course it can be done. The real
question you're asking is, can it be done in a web app? I think the answer
is I think "no" because web apps aren't allowed to make raw TCP socket
connections.

Now there may be a way around that by using browser-specific things like
extensions or "installable apps" which give your code greater access
permissions. This approach means you essentially use Chrome as your app
platform instead of a JVM, the assumption presumably being that more users
have Chrome than a JVM. The flip side is that users who don't would
probably balk at the idea of installing an entire browser in order to run a
wallet app, whereas a JVM can be bundled and the resulting app acts like
any other. I don't know of a convenient way to "statically link" Chrome
into a regular-looking application.

I personally wouldn't find such a design compelling. Whilst Java isn't
exactly a great language, JavaScript is significantly worse in virtually
all aspects. I don't understand why anyone would want to use JavaScript
outside the browser - you get less safety, less performance, fewer
features, less mature tools and so on. If the end result is an installable
app like any other, all you did is cripple yourself vs the competition
that's using languages/platforms designed for it.



On Fri, Aug 9, 2013 at 1:32 PM, Wendell  wrote:

> To those of you in the know about modern browser tech:
>
> Does it seem at all conceivable that an SPV wallet could be built entirely
> in JavaScript? And if indeed it is within the realm of the possible, how
> would such a thing be safely distributed for use? Would a signed Chrome
> Plugin be an ideal vehicle?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Mike Hearn 
This is just me making notes for myself, I'm not seriously suggesting this
be implemented any time soon.

Mozilla Persona is an infrastructure for web based single sign on. It works
by having email providers sign temporary certificates for their users,
whose browsers then sign server-provided challenges to prove their email
address.

Because an SSO system is a classic chicken/egg setup, they run various
fallback services that allow anyone with an email address to take part.
They also integrate with the Google/Yahoo SSO systems as well. The
intention being that they do this until Persona becomes big enough to
matter, and then they can remove the centralised struts and the system
becomes transparently decentralised.

In other words, they seem to do a lot of things right.

Of course you can already sign payments using an X.509 cert issued to an
email address with v1 of the payment protocol, so technically no new PKI is
needed. But the benefit of leveraging Persona would be convenience - you
can get yourself a Persona cert and use it to sign in to websites with a
single click, and the user experience is smart and professional. CAs in
contrast are designed for web site admins really so the experience of
getting a cert for an email address is rather variable and more heavyweight.

Unfortunately Persona does not use X.509. It uses a custom thing based on
JSON. However, under the hood it's just assertions signed by RSA keys, so
an implementation is likely to be quite easy. From the users perspective,
their wallet app would embed a browser and drive it as if it were signing
into a website, but stop after the user is signed into Persona and a user
cert has been provisioned. It can then sign payment requests automatically.
For many users, it'd be just one click, which is pretty neat.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] SPV client in pure JavaScript?

2013-08-09 Thread Wendell 
To those of you in the know about modern browser tech:

Does it seem at all conceivable that an SPV wallet could be built entirely in 
JavaScript? And if indeed it is within the realm of the possible, how would 
such a thing be safely distributed for use? Would a signed Chrome Plugin be an 
ideal vehicle?

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development