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 tim
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 O
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
>
>
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,
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 a
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 in
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", w
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
>
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
"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 uninstal
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 distrib
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 brow
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,
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 n
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 weigh
>
> 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
> it
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 th
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
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
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 lik
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 chall
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 v
22 matches
Mail list logo
