[Bitcoin-development] SPV client in pure JavaScript?
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=48897031iu=/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
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=48897031iu=/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
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=48897031iu=/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?
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 m...@plan99.net 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 w...@grabhive.com 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=48897031iu=/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
On 9 August 2013 14:08, Mike Hearn m...@plan99.net 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 KEYGEN), 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=48897031iu=/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
On 9 August 2013 13:59, Wendell w...@grabhive.com 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=48897031iu=/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=48897031iu=/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?
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=48897031iu=/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)
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 pubkeychaincode 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 outgoing chains? What happens if they do it
Re: [Bitcoin-development] SPV client in pure JavaScript?
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=48897031iu=/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?
On Fri, Aug 9, 2013 at 1:58 PM, Wendell w...@grabhive.com 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=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BitMail.sf.net - encrypted p2p email
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=48897031iu=/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)
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 etothe...@gmail.com 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 Bitcoins button to allow creation of new contacts/identities. - Change will
Re: [Bitcoin-development] Optional wallet-linkable address format (Re-request)
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 etothe...@gmail.com 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 etothe...@gmail.com 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
Re: [Bitcoin-development] BitMail.sf.net - encrypted p2p email
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=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
