Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Spec updated: https://gist.github.com/4120476 Notable changes are: + Removed SignedReceipt + Replaced Invoice.x509chain with a "pki_type" and "pki_data" to make using other identity systems cleaner. + Added a "Why not an existing electronic invoice standard?" section to the design notes -- -- Gavin Andresen -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
On Wed, Nov 21, 2012 at 01:38:37PM -0500, Matt Corallo wrote: > On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote: > > On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote: > > > I've written a draft BIP describing the bloom filtering protocol > > > extension developed by myself and Matt. > > > > > > https://en.bitcoin.it/wiki/BIP_0037 > > > > Two comments I made on the pullreq page, which are probably better > > discussed here: > > * The 0x/(n-1)*i seed value seems intended to result in large bit > > differences between the different hash function's seeds. Together with > > the tweak, > > however, the first and the last now get seeds tweak and tweak-1. I think > > something simpler like k1*i+k2*n+tweak is better (with k1 and k2 > > arbitrary large > > odd 32-bit integers). > Meh, sure, whatever...I dont really think the seed values matter > significantly (Murmur3 isnt that bad of a hash function...) (and the > original algorithm wont result in a significant bit difference between > the seeds in many cases). Sure, it's nothing important, but it seems like it fails to do what it was intended for. How about just this: tweak + i*0xFBA4C795 (number optimized to give large seed differences for every tweak). If you want variation when changing the number of hash functions, just choose a different seed. > > Maybe the actual filter data in filterload can be made optional: > > if it is omitted, it's assumed to be all zeroes (though that would mean > > the size > > has to be specified). > > > I'm not sure here, if you are sending a filter just to use filteradd to > add things to it manually, you are doing something very, very, very > wrong... Though we could certainly do some kind of compressed bloom > filter encoding to allow for small filter loads (loading the few things > you need to filteradd right away) where you anticipate adding > significantly more filter elements down the road (can anyone even come > up with a case where you anticipate doing this?), the filter is small > enough (max 36kB) that I see little benefit for the large increase in > complexity (or is this another repeat of the merkle branch discussion?) It's probably not worth it for something that is max 36 kilobytes. If ever necessary, we can define a new message type that just lists a number of bits to be set in the server-side filter. For now, I agree that you should just send the filter as intended, and not expect to do many filteradds (though you should take the implicitly-added txids into accounted when computing the filter size). -- Pieter -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client
Source code URL: https://github.com/jgarzik/picocoin/ I'd like to announce another bitcoin implementation, which is really two useful pieces in one: libccoin - a bitcoin library, written in C picocoin - A lightweight, C-based SPV bitcoin wallet client libccoin supports all key network datastructures (block, transaction, etc.), script parsing and validation, transaction and block validation, a "headers-only" or full block database, and many other features essential to any bitcoin client. libccoin passes all key encoding, script and transaction tests available in the Satoshi reference bitcoin client. picocoin is much more under construction. When complete, it will be a very low resource, command line / JSON-driven bitcoin wallet. Advanced security features already implemented include required wallet encryption, fork-based process separation of P2P networking and wallet (and chroot/SELinux jailing coming soon), something that the reference Satoshi client does not even support. Status: Alpha quality, developer release. Passes reference client base58/script/transaction tests, but is still a developer-only preview. Feature list: Intended to be a full-feature bitcoin support library. The library will not be limited to "what picocoin needs." Supports all core data structures and network messages Full script implementation Passes hundreds of available reference client tests Supports multiple block chains: main or testnet3 Very low resource usage (cpu, disk, and memory) Small codebase (both source code and compiled object) Supports advanced thin-client features such as "bloom filtering", an upcoming proposal that will reduce client bandwidth usage. Works on big endian machines, as well as little endian machines Multi-platform: Linux supported currently. Should work on OSX/BSD/Windows with minimal modifications. libccoin should work on Windows. picocoin will work on Windows, but be a bit less secure than other platforms due to lack of fork. Improved security: fork-based process separation firewall between networking and wallet code -- your wallet is never directly exposed to the network. Follows the philosophy of "do, not hype." This library is already far more secure and capable than other libraries hyped as the "future of bitcoin" by their authors. Code contributions are welcome (see github URL above). Comments are welcome. Donations are welcome too (1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj). -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
> That hash would then be reported via some secure channel outside of bitcoin's > domain. OK, I see. I guess that could be a reasonable fallback for the case where you have a secure channel. > I don't understand what the relevance of multi-factor is to invoices? Yes, exactly. It's about paying who you think you're paying (when you confirm on a second uncompromised device). -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote: > That's pretty much what we have today - in future other schemes can be > proposed as extensions. Protocol buffers are easily extended, they > ignore unknown fields. Then you'd wait and see what the invoice > request looked like and produce an invoice with the right security > bits. That's good; I've not done anything with protocol buffers, so wasn't aware it was that simple. > > In particular two additional identification types: > > - GnuPG (obviously) > > It's not obvious to me, incidentally. The web of trust has been > dead-on-arrival since it was first proposed, and for good reasons. > SSL/X.509, for better or worse, has significant usage. Sorry, I meant "obviously" in the sense that "obviously that's the other one that everyone will want". The web-of-trust as a universal identity mechanism is, I agree, not useful. However, as a localised, smaller-scale identity verification system it's used by every GnuPG user. You become your own certificate authority. For example, I've set up my whole family with GnuPG; I've set them up to trust me to authenticate (and I doubt any of them has ever added anyone else). Then I take on the responsibility of signing all my family/friends keys and they don't need to worry about it. There's no reason that a small group of companies wouldn't do exactly the same sort of thing. > Your case of a small business is a perfect example of people who won't > be using GPG. If they don't want to buy an SSL cert, they can just as Bear in mind, I was using that example as an example of a hash protected in a GPG envelope, not a GPG-signed invoice. People who've already got their GPG system in place will appreciate being able to leverage it. > well put a reference number in the memo field or a "Hey Bob, here is > the bill we discussed". The payer does not get the multi-factor auth How can they put a hash of an invoice inside the invoice? In my "hash mode" invoices, it would be a random number (or possibly specifying the hash algorithm) then the SignedInvoice would simply be the original invoice + hash. That hash would then be reported via some secure channel outside of bitcoin's domain. > protection so if their computer has a virus, they may be hosed. But > that's good incentive for sellers to get verified. Some CA authorities > do it for free these days. I don't understand what the relevance of multi-factor is to invoices? The payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or not? This invoice system has one primary job: to ensure that the target of the payment is who the payer thinks it is -- that's not affected by multi- factor methods of protecting my wallet. Andy -- Dr Andy Parkins andypark...@gmail.com -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
> Personally, I'd like to see fewer implicit ties to X509. With X509 as one > option. That's pretty much what we have today - in future other schemes can be proposed as extensions. Protocol buffers are easily extended, they ignore unknown fields. Then you'd wait and see what the invoice request looked like and produce an invoice with the right security bits. > In particular two additional identification types: > > - GnuPG (obviously) It's not obvious to me, incidentally. The web of trust has been dead-on-arrival since it was first proposed, and for good reasons. SSL/X.509, for better or worse, has significant usage. Your case of a small business is a perfect example of people who won't be using GPG. If they don't want to buy an SSL cert, they can just as well put a reference number in the memo field or a "Hey Bob, here is the bill we discussed". The payer does not get the multi-factor auth protection so if their computer has a virus, they may be hosed. But that's good incentive for sellers to get verified. Some CA authorities do it for free these days. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
Personally, I'd like to see fewer implicit ties to X509. With X509 as one
option. For example, I'd much prefer to see a doorway to the future left open
like this:
message Invoice {
repeated bytes issuerIdentityType;
repeated bytes issuerIdentityBytes;
or similar, instead of "x509chain".
In particular two additional identification types:
- GnuPG (obviously)
- Hash based
The hash-based system would be there as a method of leveraging an existing
trusted connection, without needing to get into the nitty-gritty of
certificates. For example, I am paying for something on a web site; I
presumably already have a secure connection that I trust to that site. That
site can issue me an invoice (which is to be sent to the bitcoin client) _and_
a hash of the certificate on the same page.
I trust that hash because I received it over a secure connection from a
trusted source. When my bitcoin client pops up with the received invoice, it
shows me the hash of the invoice, and I can be sure that it is from the web
site I thought it was from.
Imagine I'm a (very) small business, I have two or three customers. I want to
email one of my customers an invoice. I don't want to have to get an X509
certificate, and I don't necessarily know how. However, I can ring my
customer up and say "I've generated an invoice with my bitcoin client, it is
hashed A7DE-521X-9977. Write that down and confirm it when you get my
invoice". Alternatively, I might attach a file called
invoice-A7DE-521X-9977.bitinv to a signed GnuPG email. The receipient can
easily confirm I sent it because the filename must match the contents and
GnuPG protects against tampering.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
One more thought: RE: "Receipt" verus "Acceptance" : I believe "Receipt" is the right term-- it means "I got your payment", NOT "your payment has cleared." E.g. if I hand a merchant a paper check they'll hand me a receipt, but the check could still bounce. That's the analogy here-- a merchant might give you a receipt, but if the transaction is rejected by the network for whatever reason (Finney attack maybe) you cannot expect to go to court with your invoice/receipt and claim you made a valid payment. -- -- Gavin Andresen -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
RE: SignedReceipt: I agree it is superfluous. I'll remove it from the spec. RE: "it is controversial use of the host key to use it for digital signing of documents" : The idea of embedding a x509 certificate chain comes from the IETF's JSON Object Signing and Encryption working group "JWS" specification, so I can't be TOO controversial. RE: the ifex-project and other electronic invoicing standards: Thanks for the pointers, Walter! I'm all for adopting the best ideas that have come before, as long as we end up with something useful and small enough to convince ourselves it is as secure as we can make it. I looked at the ifex spec, and quickly got lost. It would help me if you could write up what our motivating use cases would look like if implemented on top of ifex. RE: jgarzik's suggestion to allow txids in the Payment: that worries me, because it is trivial to create several different variations of the same transaction (same inputs to same outputs) with different txids (re-signing inputs uses a different signature nonce, which changes the signature/txid, for example). RE: using self-signed certificates: as Mike said, I assume Bitcoin clients will have some way of managing root certificates, so experts could add trusted self-signed certs. -- -- Gavin Andresen -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
> No, the point of using X509 certs is to get a verified identity (a > domain name) on the receipt, this is needed for multi-factor > authentication. You can't do that without some kind of third party > asserting to an identity. Agree that you need a third party to verify identity. But the verification policy of sites is the job for a payment provider not a payment technology. So if you would like verification of the site you could just sign the memo using standard S/MIME - why mix it with the payment protocol? Further, it is controversial use of the host key to use it for digital signing of documents, and not even within the policy of a host certificate as far as I recall. The problem you are trying to tackle is that we don't have an ID solution on the internet today for this purpose. Certificates for signing messages are distributed freely and insecurely only based on temporarily having an email from within an organization, and the host certificates are meant for SSL handshakes. Funnily, any CA can issue digital certificates for email signing for any domain, even though they don't own them, and without notifying the owner. DANE actually solves this, but until then using the host certificates is unintended use, it is cryptographically a nice solution, but legally and standard-wise a hack. /M -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
> Further, the inclusion of x509 is not really needed in the spec - you don't > need to sign the invoice with an x509, you can use the payment key. No, the point of using X509 certs is to get a verified identity (a domain name) on the receipt, this is needed for multi-factor authentication. You can't do that without some kind of third party asserting to an identity. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
> > If a merchant/payment processor is willing to take the risk of zero or > low confirmation transactions (because they are insured against it, > for example), they were allowed to reply "accepted" immediately, and > this would be a permanent proof of payment, even if the actual Bitcoin > transaction that backs it gets reverted. I guess that moves the discussion from developers to lawyers ;) Even though you send a signed receipt, if you can proof you didn't get the money, you will never be expected to deliver the goods. (and you can even write that in the the receipt ...) So the SignedReceipt is legally not worth the bits it is composed of, hence I don't see the point in supporting it. If you are selling atoms you can usually wait for N confirmations (even though you start shipping I guess you can recall a parcel within 144 blocks). If you are selling bits (like access to a site), you can revoke that access once you discover the transaction did not go through. So I can't find a use case where a Signed Receipt in the proposed form is advantageous. /M -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote: > > > > The SignedReceipt message is useful in the sense that it shows > > confirmation by the merchant, but if you don't get one, you can still > > prove you paid the invoice. So from this perspective perhaps > > SignedReceipt should be renamed to Acceptance or something like that, > > and then the spec should call out that a signed invoice plus accepted > > Bitcoin transactions is mathematically a proof of purchase. > > Which is why I find the "SignedReceipt" somewhat superfluous. If you > implement a payment system, like bit-pay/wallet you are likely to double that > through some sort of e-mail receipt anyway. Gavin's proposal differs in this from my original proposal, where I exactly *didn't* want to couple the receipt with the acceptance of the Bitcoin transaction. If a merchant/payment processor is willing to take the risk of zero or low confirmation transactions (because they are insured against it, for example), they were allowed to reply "accepted" immediately, and this would be a permanent proof of payment, even if the actual Bitcoin transaction that backs it gets reverted. For that reason, I also had a separate "pending" state, which means the receiver isn't willing to just accept the current state as irrevocably paid. In this case, the sender was allowed to retry until the receipt sayd "accepted" or "rejected". The whole point was to avoid that customers/merchants would have to deal with the uncertainty involved in Bitcoin transaction. At some point, someone is going to accept the transaction (whether that is at 0 or at 120 confirmations), and acceptance will at the higher level be considered a boolean anyway - not some "probably, unless reorg". -- Pieter -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
> > The SignedReceipt message is useful in the sense that it shows > confirmation by the merchant, but if you don't get one, you can still > prove you paid the invoice. So from this perspective perhaps > SignedReceipt should be renamed to Acceptance or something like that, > and then the spec should call out that a signed invoice plus accepted > Bitcoin transactions is mathematically a proof of purchase. Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway. Further, the inclusion of x509 is not really needed in the spec - you don't need to sign the invoice with an x509, you can use the payment key. The proof would still be equally binding, and valid also for non holders of x509 (server) certificates (like normal people). Finally, host certificates does not normally keep in their "purpose" S/MIME Signing. So you are bending the intended use of the x509 certificate anyway. /M > > -- > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager wrote: > * What if the SignedReceipt is not received AND the transactions IS posted on > the p2p. I think this is a problem with confusing terminology rather then the spec itself. The original formulation had a receipt being something generated purely by the buyer. The signed Invoice message + the Bitcoin transactions paying to the outputs + the merkle branches showing acceptance by the network *is* the receipt. The SignedReceipt message is useful in the sense that it shows confirmation by the merchant, but if you don't get one, you can still prove you paid the invoice. So from this perspective perhaps SignedReceipt should be renamed to Acceptance or something like that, and then the spec should call out that a signed invoice plus accepted Bitcoin transactions is mathematically a proof of purchase. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Short comments: * What if the SignedReceipt is not received AND the transactions IS posted on the p2p. Then you have payed for the goods, but you don't have a receipt. This could happen both from malice or system failures. ** Suggestion - sign the invoice with the key to which to send the transaction, the proof of payment, equivalent to a signed receipt is then in the blockchain. This scheme would work both with or without x509, if you want to include x509, the message in the invoice could simply be signed by the x509 certificate as well. PRO: Any user can send signed invoices, not only those with a x509 cert. PRO: No limbo situation with no SignedReceipt CON: This disables the use of anything but payment to key/address incl multisig etc. However, the wast majority of use will anyway be payment to key/address. Support of general pay to script could be supported through the payment scheme proposed earlier by Mike: No non-fee payments are accepted, except in a group - i.e. it is up to the merchant to generate the final transaction incl the fees, and that one could be to a general script. This also keeps the support of pay to general script needed for a client to a minimum. Cheers, Michael -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Luke-Jr - common subset of what operating systems ship is fine for me as long as people do due diligence around mobile OS' here. It seems easier to me to just grab a list from a popular browser, on the grounds that SSL is mostly used by them so nobody is going to buy an SSL cert rejected by IE/Firefox/Chrome/etc. But intersecting OS lists is effectively the same. For my own clients I'd just ship my own copy of the canonical CA certs regardless, because integrating with each operating systems proprietary crypto APIs is a lot of work vs just loading a pem file into OpenSSL. If there are a lot of people who want to use the OS cert management UIs then I guess that can be a point wallet clients compete on. > Removing that and adding a opaque string called domain name, or > identityName would be sufficient to move the conversation forward > without the x.509 baggage. But it would result in implementations that do not meet the requirements. Yes, X.509 has problems. It's in the proposal because we can get the effect we want (verifiable domain names in the UI) in about 50 lines of code, today, with the id-verified keys people actually have already bought. As Gavin says, we can add optional fields later to extend the protocol in a backwards compatible way. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
