Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
>> We are not establishing an IETF working group, which is an option that >> was explored prior to the Paris meeting and has been sidelined at >> present for depth-of-bureaucracy by the backing commercial entities. >> Rather, we are establishing a top-level IANA registry group. This is >> not anticipated by the IETF old-guard working with us to be either (a) >> controversial or (b) possible to block. > > My last note in this sub-thread. Mine too! > There are no IANA registry groups, there is no such thing, and no way > to form one. Reading between the lines, I believe this phrase, which is not my own but that of experienced IETF staff, refers to the groups visible at http://www.iana.org/protocols/ (which you yourself cited). Whether it is formally used or not is unknown to me. > The IETF can ask the IANA to form a registry but these > things take lots of support and take a long time, Expert opinion estimates six weeks, and by current estimates, we should have an arrival circa February. > and these are only > created through standards track RFC. ICANN runs the IANA and there is > no such framework that you elude to. Review > http://www.iana.org/protocols/ I would like to suggest that perhaps exactly this sort of banter is an excellent illustration for the Bitcoin community of what we have been up against in this (conceivable simple an public benefit oriented) endeavour. If you also look at the fact that the ISO4217 registry (to take currency/commodity codes as just one example) there is apparently not even a public list of requirements for codepoint issue. This sort of thing is *exactly* why the internet community appears to desperately need an open registry - allowing public internet bodies (IANA) to function to support innovation and interconnectivity for all sectors of the internet's various financial communities so that anyone, including innovators, can obtain interoperability via simple, hassle-free paths, without encountering self-important bureaucrats. We anticipate victory circa February. - Walter -- 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
> > We are not establishing an IETF working group, which is an option that > was explored prior to the Paris meeting and has been sidelined at > present for depth-of-bureaucracy by the backing commercial entities. > Rather, we are establishing a top-level IANA registry group. This is > not anticipated by the IETF old-guard working with us to be either (a) > controversial or (b) possible to block. My last note in this sub-thread. There are no IANA registry groups, there is no such thing, and no way to form one. The IETF can ask the IANA to form a registry but these things take lots of support and take a long time, and these are only created through standards track RFC. ICANN runs the IANA and there is no such framework that you elude to. Review http://www.iana.org/protocols/ If you are applying for a gTLD, good luck with that. -rick -- 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
>> We are currently working with IETF staff, with open offers of support >> from multiple well funded commercial bodies, to transition these >> proposals through to IANA management. > > I hate to inform you that you have been mislead. The IETF and the IANA > do not operate as you outlined above. Having spent too many years > within ICANN/IETF/IANA I can assure you are mistaken. > Your drafts are expired and it appears that there is no support for a > "finance" working group in the IETF. We are not establishing an IETF working group, which is an option that was explored prior to the Paris meeting and has been sidelined at present for depth-of-bureaucracy by the backing commercial entities. Rather, we are establishing a top-level IANA registry group. This is not anticipated by the IETF old-guard working with us to be either (a) controversial or (b) possible to block. - Walter -- 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 Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish wrote: >>> X-ISO4217-A3 >> >> I see that draft-stanish-x-iso4217-a3 is not standards track, is there >> a reason for this? > > Of the three currently published proposals, all are essentially IANA > registry proposals. > > We are currently working with IETF staff, with open offers of support > from multiple well funded commercial bodies, to transition these > proposals through to IANA management. I hate to inform you that you have been mislead. The IETF and the IANA do not operate as you outlined above. Having spent too many years within ICANN/IETF/IANA I can assure you are mistaken. Your drafts are expired and it appears that there is no support for a "finance" working group in the IETF. -rick -- 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
>> X-ISO4217-A3 > > I see that draft-stanish-x-iso4217-a3 is not standards track, is there > a reason for this? Of the three currently published proposals, all are essentially IANA registry proposals. We are currently working with IETF staff, with open offers of support from multiple well funded commercial bodies, to transition these proposals through to IANA management. It appears that the Independent Stream Editor path will be used to transition these through to IANA, at which time the proposals themselves will be converted to Informational status. (As far as I understand right now, Within the IETF, Standards Track has special meaning and entails relatively large degrees of bureaucracy that are not within the current contributors' resources. It is also worth pointing out that many popular protocols implemented on the majority of systems (IIRC, such as IMAP) never reach formal standardization for this reason. It should be noted that in these cases, this does not make the protocols any less attractive as potential components for system implementation.) > It also doesn't appear to address ~any of the the targeted items here. > Is there another draft I should be looking for which has more overlap > with the discussion here? As outlined in the previous post: - Internet Financial EXchange (IFEX). A proposal under development that facilitates the negotiation of financial transactions between internet-based financial endpoints. (The area we would love your input) http://www.ifex-project.org/our-proposals/ifex As well as the information linked to above, significant but not particularly well grounded discussions have occurred regarding the IFEX-based paradigm for settlement versus some other proposed paradigms, in particular Ripple (as it appeared some months ago), which can be read here: https://groups.google.com/forum/?fromgroups#!topic/rippleusers/v4bEBZZVEsA[1-25] Kind regards and with the hopes of combining our efforts as a joint proposal that can benefit other currencies/commodities and settlement systems as well as Bitcoin, Walter Stanish Skype:walter.stanish -- 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 Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wrote: > X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? It also doesn't appear to address ~any of the the targeted items here. Is there another draft I should be looking for which has more overlap with the discussion here? -- 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
> This is the next big "lets all agree to do things the same way" thing > I think we should tackle. I'm particularly looking for feedback from > other bitcoin client developers, even if it is just a quick "looks > reasonable, if everybody else is going to do it then I will > (eventually) too..." I agree this is a very pertinent subject, and with a bit of looking around it is clear that there is a requirement here for emerging financial ecosystems of many types, certainly not just for the Bitcoin community, which until now seems to have been getting along just about OK despite the current levels of complexity. That said, I have a number of serious concerns with the proposal. 1. Undue Broadening of Scope: From an architectural perspective, if one accepts the unix mantra of "do one thing and do it well" as reasonable and time-proven doctrine, given that Bitcoin is already trying to be both a commodity and a distributed consensus-based settlement system, does it really make sense to attempt to tack-on business-level functions? 2. X.509: I have read (somewhere or other, recently) that it is generally considered bad form to mandate specific cryptographic systems in new protocols where open support is possible. Given the recent issues with X.509, the security nightmare that already exists with the volume of (sometimes cracked, sometimes government-compromised?) issuers, and the complexity of the scheme, it seems a little strange to singularly mandate X.509, despite its widespread use at present. There are also a swathe of potential issues around DNS interdependence, information leakage within certificates themselves and/or their DNS-interpretation by clients, etc. I would consider suggesting open support with initial support for GPG, as it is apparently preferred as a simple and further decentralized solution by the majority of the open source and cryptographic software development community. 3. Failure to Review Existing Work: I would urge anyone to be wary of adopting any proposal that does not inform itself through reference to existing protocols in the same area. In this area there are a few protocols in current use (chiefly in Europe) such as those listed at http://en.wikipedia.org/wiki/Invoice#Electronic_invoices as well as various hosted platforms such as http://xero.co.nz/ (chiefly Australia/New Zealand). Often, existing work shows its age with after-the-fact alterations that sit poorly with initial assumptions: exactly the kind of situation one can walk in to developing against a proposal before adequately researching the area. 4. Complexity of Metadata: Physical and digital invoicing for businesses operating at scale often requires delivery terms, product classification codes, locale-specific taxation (often at multiple levels), various fees and discounts (sometimes fulfillment-speed linked with multiple tiers/thresholds), and other features that I am skeptical are ever going to be made fully available within a business protocol tacked on to a hybrid digital currency/settlement system (like Bitcoin) as a secondary concern. 5. Non-BTC Currencies/Currency-like Commodities: No approach to non-BTC currencies appears to have been made, which makes the "invoice" of limited utility for almost all businesses, save those willing to accept all of the 'capital risk' (exchange rate fluctuation risk) inherent in a BTC-based fulfilment process with a potential term long enough to justify an invoicing process. (Does this narrow scope actually cover any existing business?) 6. DNS: As already mentioned with regards to X.509: a huge red flag as an area of potential vulnerability, or at least information leakage. I must now admit that in raising the above I am definitely biased. My employer (Payward, Inc.) and other organizations (OpenCoin, Inc., etc.) have been working with the Internet Engineering Task Force (IETF) on tabling some open proposals within this area under the auspices of the Internet Financial Exchange Project (http://ifex-project.org/). Our hope is to facilitate the requisite standardisation within internet-connected systems to deal with what is perhaps fairly characterised as a relatively heterogeneous outlook on the rise of cryptographic (and other alternate) currencies and commodities, and emerging settlement infrastructures. Whilst the current Bitcoin proposal is admirable for correctly raising the area as one of immediate concern, I hope that the above points out some of the perhaps as-yet unconsidered complexities and draws in to question whether Bitcoin is in fact the appropriate place to implement a solution, given the hassles that will entail. After all, wouldn't Bitcoin developer time would be better spent improving the core of bitcoin (ie. distributed settlement system and commodity) rather than adding new features? I would invite parties within the Bitcoin community with an interest in non directly settlement-linked financial transaction negotiation and reporting features to con
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Supporting DNSSEC/DANE in the future when they are widely deployed is a great idea. Note that the x509chain field is 'repeated', and any repeated field may have zero entries. So I would suggest supporting other PKI systems in the future by adding optional new fields (for maximum compatibility or security merchants might want to include both a x509chain AND -- 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
On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn wrote:
>> Perhaps we should agree to talk about everything _except_ that first?
>
> Yeah, alternatives to X.509 chains don't interest me right now except
> in the sense that they should be cleanly implementable with future
> extensions.
>
> So if you care about DANE or DNSSEC or custom PKI infrastructures or
> whatever, rather than proposing them as replacements here (DOA), just
> figure out how you would extend the protocol in Gavins mail in a
> future extension. If you can't see a clean way to do it then let's
> discuss that. If you can think of a way to do it then let's table it.
> Better replacements can come in later BIPs.
The only part that has an x509 cert associated is in the invoice message.
message Invoice {
//repeated bytes x509chain = 1;
optional string domainName =1;
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional bool single_use = 5 [default = true];
optional string memo = 6;
optional string receiptURI = 7;
optional bytes merchant_data = 8;
}
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.
-rick
--
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, November 27, 2012 12:16:07 AM Gregory Maxwell wrote: > On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote: > > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: > >> Would you find it acceptable if something supported a static whitelist > >> plus a OS provided list minus a user configured blacklist and the > >> ability for sophisticated users to disable the whitelist? > > > > How is this whitelist any different from the list of CAs included by > > default with every OS? > > Because the list is not identical (and of course, couldn't be without > centralizing control of all OSes :P ) meaning that the software has to > be setup in a way where false-positive authentication failures are a > common thing (terrible for user security) or merchants have to waste a > bunch of time, probably unsuccessfully, figuring out what certs work > sufficiently 'everwhere' and likely end up handing over extortion > level fees to the most well established CAs that happen to be included > on the oldest and most obscure things. There is a common subset of CAs which are included in all OSs. That's the "whitelist equivalent". We or someone else could even setup a list of these common CAs for merchants if that is needed. The fees CAs charge for certs is a flaw in the CA model in general, I don't see that it's important for us to solve it. -- 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 Mon, Nov 26, 2012 at 4:31 PM, Luke-Jr wrote: > On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote: >> Another nifty thing is that it can associate a cert to a domain and a >> payment address, if one were to put said address in the DNS :) >> >> Now I am sure the majority of the bitcoin user-base desires anonymity, >> but as a merchant I would like to be knowable and wouldn't mind it if >> my identity and those of my transactions were "known" and associated >> both with my domains and x.509 cert. In most commercial transactions >> (which include many of those that leverage invoices) identity is >> important, at least for the merchant. > > Anonymity isn't a feature we claim to have, nor a goal of the project for the > most part. Using a single Bitcoin address has many problems besides non- > anonymity: your customers are denied basic privacy and there is no good way to > guarantee the user who says he paid you really did (since transaction ids are > public record, anyone can claim they sent it). > > In short, it is for the most part considered a rule to always use a unique > address per transaction or at least per customer. putting payment addresses in the DNS does not require that only a single address be used. This is an assumption and a possible use case, but there is no requirement that payment addresses must be 1:1 associated. -rick -- 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, November 27, 2012 12:02:42 AM Rick Wesson wrote: > Another nifty thing is that it can associate a cert to a domain and a > payment address, if one were to put said address in the DNS :) > > Now I am sure the majority of the bitcoin user-base desires anonymity, > but as a merchant I would like to be knowable and wouldn't mind it if > my identity and those of my transactions were "known" and associated > both with my domains and x.509 cert. In most commercial transactions > (which include many of those that leverage invoices) identity is > important, at least for the merchant. Anonymity isn't a feature we claim to have, nor a goal of the project for the most part. Using a single Bitcoin address has many problems besides non- anonymity: your customers are denied basic privacy and there is no good way to guarantee the user who says he paid you really did (since transaction ids are public record, anyone can claim they sent it). In short, it is for the most part considered a rule to always use a unique address per transaction or at least per customer. Luke -- 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
> Perhaps we should agree to talk about everything _except_ that first? Yeah, alternatives to X.509 chains don't interest me right now except in the sense that they should be cleanly implementable with future extensions. So if you care about DANE or DNSSEC or custom PKI infrastructures or whatever, rather than proposing them as replacements here (DOA), just figure out how you would extend the protocol in Gavins mail in a future extension. If you can't see a clean way to do it then let's discuss that. If you can think of a way to do it then let's table it. Better replacements can come in later BIPs. -- 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 Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote: > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: >> Obviously the state of the world with browsers is not that good... but >> in our own UAs we can do better and get closer to that. > > This effectively centralizes Bitcoin (at least in the eyes of many) and even > if each competing client had their own list, you'd be back to the original > "problem" of not being sure your CA is on all lists. Thats the CA model generally. It _is_ a distributed-centralized model in practice. >> Would you find it acceptable if something supported a static whitelist >> plus a OS provided list minus a user configured blacklist and the >> ability for sophisticated users to disable the whitelist? > > How is this whitelist any different from the list of CAs included by default > with every OS? Because the list is not identical (and of course, couldn't be without centralizing control of all OSes :P ) meaning that the software has to be setup in a way where false-positive authentication failures are a common thing (terrible for user security) or merchants have to waste a bunch of time, probably unsuccessfully, figuring out what certs work sufficiently 'everwhere' and likely end up handing over extortion level fees to the most well established CAs that happen to be included on the oldest and most obscure things. Taking— say— the intersection of Chrome, Webkit, and Firefox's CA list as of the first of the year every year and putting the result on a whitelist would be a possible nothing-up-my-sleeve approach which is not as limited as having some users subject to the WinXP cert list, which IIRC is very limited (but not in a way that improves security!). Jeff wrote: > Self-signed certs are quite common, because it is easier, while being > more secure than http:// Uhh. Really? Well, I agree with you that they should be (I unsuccessfully lobbied browser vendors to make self-signed https on http URLs JustWork and simply hide all user visible evidence of security), but the really nasty warnings on those sites undermines the security of the sites _and_ of other HTTPS sites because it conditions users to click ignore-ignore-ignore. I don't think they are all that common. One thing which I think will be hard for us in this discussion is being sensitive to the (quite justified!) concerns that the current CA system is absolute rubbish, both terrible for security, usability, and an unreasonable barrier to entry relative to the provided security— without allowing the discussion to be usurped by everyone's pet replacement, which there are a great many of with varying feasibility and security. Perhaps we should agree to talk about everything _except_ that first? -- 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
I hope you all take a moment to see what DANE leverages with DNSSEC and SelfSigned x.509 certs. DANE provides the capability for any entity to associate a self signed certificate with a domain name. This capability removes the critical path of whitelists and/or Root CA certs. Another nifty thing is that it can associate a cert to a domain and a payment address, if one were to put said address in the DNS :) Now I am sure the majority of the bitcoin user-base desires anonymity, but as a merchant I would like to be knowable and wouldn't mind it if my identity and those of my transactions were "known" and associated both with my domains and x.509 cert. In most commercial transactions (which include many of those that leverage invoices) identity is important, at least for the merchant. -rick On Mon, Nov 26, 2012 at 3:52 PM, Jeff Garzik wrote: > On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen > wrote: >> This is the next big "lets all agree to do things the same way" thing >> I think we should tackle. I'm particularly looking for feedback from >> other bitcoin client developers, even if it is just a quick "looks >> reasonable, if everybody else is going to do it then I will >> (eventually) too..." > > Comments: > > 1) Payment message should include ability to specify the transaction > _or_ a transaction id sent via normal means over the network. > > 2) I think a significant bitcoin userbase will want to operate outside > the full root-CA chain. Just look at https:// websites now. > Self-signed certs are quite common, because it is easier, while being > more secure than http:// > > So some provision for self-signed certs, a use case in wide use > elsewhere, or equivalent thereof, seems reasonable. > > -- > Jeff Garzik > exMULTI, Inc. > jgar...@exmulti.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 -- 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
X.509 has some problems we have recent experience with. I'd prefer to
leverage something like DANE which looks to help with assertions
around certificates and creates an option around the CAs and x.509
roots.
-rick
On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen wrote:
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
>
> Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
> suggestions and brainstorming.
>
> This document is online at https://gist.github.com/4120476
>
> If you respond to this message, please be considerate of people who
> subscribe to the digest version of this mailing list and trim your
> response.
>
>
> Invoices, Payments and Receipts for Bitcoin Transactions
>
>
> This document proposes protocol buffer-based formats for signed,
> authenticated "invoices" and "receipts" -- requests for payment, and
> proof-of-payment.
>
> Separate documents propose an extension to the Bitcoin URI syntax and
> new MIME types to support them.
>
> Motivation
> ==
>
> The idea of a "payment protocol" to improve on Bitcoin addresses has
> been around for over a year. Users have been asking for some features
> in this proposal (like the ability to provide a refund address so
> overpayments or refunds can be returned to customers without the need
> to ask them for their address) for two or three years, and have
> started to work around shortcomings in the Bitcoin payment process
> with creative (but inefficient) uses of transactions.
>
> The key features of this proposal are:
>
> + Requests for payment (Invoices) are tied to authenticated identities
> using the only widely-deployed identity authentication system we have
> right now (X.509 certificates signed by root certificate authorities)
> + Invoices include a user-friendly description of what the payment is for
> + Payments include where refunds should be sent
> + At the end of the payment process, the customer holds a
> cryptographically signed Receipt that can be used as proof-of-payment
> if there is any dispute with the merchant.
>
>
> Specification
> =
>
> Invoice/SignedInvoice
> -
>
> An Invoice is a request for payment from a merchant to a customer:
>
> ::
>
> message Output {
> optional uint64 amount = 1;
> required bytes script = 2;
> }
>
> amount: Number of satoshis (0.0001 BTC) to be paid. If not given
> or zero, then the customer will be asked how much to pay.
>
> script: a "TxOut" script to which the customer should direct payment.
> This will normally be one of the standard Bitcoin transaction script
> (e.g. pubkey OP_CHECKSIG).
>
> ::
>
> message Invoice {
> repeated bytes x509chain = 1;
> repeated Output outputs = 2;
> required uint64 time = 3;
> optional uint64 expires = 4;
> optional bool single_use = 5 [default = true];
> optional string memo = 6;
> optional string receiptURI = 7;
> optional bytes merchant_data = 8;
> }
>
> outputs: one or more outputs where Bitcoins are to be sent.
>
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
>
> time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was created.
>
> expires: Unix timestamp after which the Invoice should be considered
> invalid. If not given, the Invoice may be re-used until the earliest
> certificate expiration date in the X509chain.
>
> single_use: If true, this Invoice should be used for only one payment.
> If false, it may be added to the user's address book and used
> repeatedly until it expires (e.g. for donations or a recurring
> payment).
>
> memo: UTF-8 encoded, plain-text (no formatting) note that should be
> displayed to the customer, explaining what this Invoice is for.
>
> receiptURI: Secure (https) URI where a Payment message (see below) may
> be sent to obtain a SignedReceipt as proof-of-payment.
>
> merchant_data : Arbitrary data ignored by the client that may be used
> by the merchant to identify the Invoice.
>
> ::
>
> message SignedInvoice {
> required Invoice invoice = 1;
> required bytes signature = 2;
> }
>
> A SignedInvoice is an Invoice signed using the private key
> corresponding to the public key in the first certificate in the
> x509chain and the HMAC SHA-256 algorithm.
>
> When a Bitcoin client receives a SignedInvoice, it must authorize
> payment by doing the following:
>
> 1. Validate the x509chain certificate chain up to it's list of root
> certificate authorities
> 2. Validate that the time on the customer's system is before Invoice.expires
> 3. Display the "Common Name" (CN) s
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen wrote: > This is the next big "lets all agree to do things the same way" thing > I think we should tackle. I'm particularly looking for feedback from > other bitcoin client developers, even if it is just a quick "looks > reasonable, if everybody else is going to do it then I will > (eventually) too..." Comments: 1) Payment message should include ability to specify the transaction _or_ a transaction id sent via normal means over the network. 2) I think a significant bitcoin userbase will want to operate outside the full root-CA chain. Just look at https:// websites now. Self-signed certs are quite common, because it is easier, while being more secure than http:// So some provision for self-signed certs, a use case in wide use elsewhere, or equivalent thereof, seems reasonable. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.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
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: > Obviously the state of the world with browsers is not that good... but > in our own UAs we can do better and get closer to that. This effectively centralizes Bitcoin (at least in the eyes of many) and even if each competing client had their own list, you'd be back to the original "problem" of not being sure your CA is on all lists. > Would you find it acceptable if something supported a static whitelist > plus a OS provided list minus a user configured blacklist and the > ability for sophisticated users to disable the whitelist? How is this whitelist any different from the list of CAs included by default with every OS? -- 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 Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr wrote: > On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: >> They could be included as well of course, but from a seller >> perspective the most important thing is consistency. You have to be >> able to predict what CAs the user has, otherwise your invoice would >> appear in the UI as unverified and is subject to manipulation by >> viruses, etc. > > That's expected behaviour - except it's mainly be manipulated by *users*, not > viruses (which can just as easily manipulate whatever custom cert store we > use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no > matter who Joe is or what connections he has. > >> So using the OS cert store would effectively restrict merchants to the >> intersection of what ships in all the operating systems their users >> use, which could be unnecessarily restrictive. As far as I know, every >> browser has its own cert store for that reason. > > Browsers with this bug are not relevant IMO. This is messy. It's important to people to know that their cert will be accepted by ~everyone because non-acceptance looks like malice. If the cert system is actually to provide value then false positives need to be low enough that people can start calling in law enforcement, computer investigators, etc.. every time a cert failure happens. Otherwise there is little incentive for an attacker to not _try_. Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. Would you find it acceptable if something supported a static whitelist plus a OS provided list minus a user configured blacklist and the ability for sophisticated users to disable the whitelist? This way people could trust that if their cert is signed via one on the whitelist they'll work for ALL normal users.. and the UI can have very strong behavior that protects people (e.g. no 'click here to disable all security because tldr' button)... but advanced users who can deal with sorting out failure can still have complete control including OS based control. -- 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
> That's expected behaviour - except it's mainly be manipulated by *users*, not > viruses (which can just as easily manipulate whatever custom cert store we > use). The point of using signed invoices as virus protection isn't to change what the user sees on the infected host. The point is the invoice can be relayed to a second device that isn't also compromised which then independently renders a payment confirmation screen (like your mobile phone), and it has an identifier in it that's useful to people, like bitmit.net instead of an address. If it was just showing you a Bitcoin address, that doesn't mean anything to you so a virus on your PC could wait until you want to make a large payment somewhere and swap out the address in use. You'd never know it was the wrong address and you'd happily confirm on your second device. For this to work, the seller has to be able to predict what certs you have in all your devices. If it's up to the OS vendors then it's hard to know and in practice all that'll happen is somebody will compile a list of CAs that are "known good" (ie, present in all deployed mobile and desktop OS') and that'll be the minimal cert list. No different to if it was hard-coded in the spec. > If I don't trust Joe's certs, I don't want Bitcoin overriding that no > matter who Joe is or what connections he has. Nothing says your wallet software can't provide cert management UI like browsers do. In practice I have a feeling that cert management UI is one of the least used parts of a browser. I've used browsers for years and the only time I've ever had to go into those screens was to manage installation/removal of self signed certs used by various organizations. I never manually revoked a root authority. When it was necessary due to breaches (Comodo/DigiNotar) the browser makers revoked them for me. -- 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, November 26, 2012 11:16:03 PM Mike Hearn wrote: > They could be included as well of course, but from a seller > perspective the most important thing is consistency. You have to be > able to predict what CAs the user has, otherwise your invoice would > appear in the UI as unverified and is subject to manipulation by > viruses, etc. That's expected behaviour - except it's mainly be manipulated by *users*, not viruses (which can just as easily manipulate whatever custom cert store we use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no matter who Joe is or what connections he has. > So using the OS cert store would effectively restrict merchants to the > intersection of what ships in all the operating systems their users > use, which could be unnecessarily restrictive. As far as I know, every > browser has its own cert store for that reason. Browsers with this bug are not relevant IMO. -- 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
They could be included as well of course, but from a seller perspective the most important thing is consistency. You have to be able to predict what CAs the user has, otherwise your invoice would appear in the UI as unverified and is subject to manipulation by viruses, etc. So using the OS cert store would effectively restrict merchants to the intersection of what ships in all the operating systems their users use, which could be unnecessarily restrictive. As far as I know, every browser has its own cert store for that reason. -- 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, November 26, 2012 11:02:14 PM Mike Hearn wrote: > Minor caveat, IMHO we should support all CAs used by the popular > browsers. I would prefer using the user-accepted certs at the operating system level... -- 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
Obviously this LGTM :)
Minor caveat, IMHO we should support all CAs used by the popular
browsers. This ensures no merchant ever finds that their SSL cert they
already own is OK for the web but not for Bitcoin. I don't see a need
to be stricter here, given all it achieves is signing some data in a
way linked with a domain name.
X.509 is pretty baroque indeed, for our use cases it'd not be hard to
do better. In particular, the inability to delegate properly rather
defeats the benefits of chained certificates. For the payment
processor case what you really want to do is take your keys, then
issue a new cert that is specific to signing Bitcoin transactions and
give that to the payment processor secure in the knowledge that they
cannot MITM your secure connections. Unfortunately X.509 wasn't
designed for the web and thus certificates you buy are marked such
that they are not allowed to sign for other certs (due to lack of real
namespace support).
This leads to the idea of redefining the cert chain part of the
protocol like this:
repeated bytes x509_chain = 1;
becomes
message Certificate {
enum Type {
X509 = 1;
}
required Type type = 1;
required bytes data = 2;
}
repeated Certificate cert_chain = 1;
Then if later we want to introduce our own minimal certificate formats
which include features we want, we can add new enum types to do so.
Note that if an old client encounters an invoice with a cert type it
doesn't recognize, it will abort parsing of the message entirely. So
the request to download the invoice should probably include a protocol
version number of some kind so the server knows when it's safe to use
new invoice features.
--
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
[Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
This is the next big "lets all agree to do things the same way" thing
I think we should tackle. I'm particularly looking for feedback from
other bitcoin client developers, even if it is just a quick "looks
reasonable, if everybody else is going to do it then I will
(eventually) too..."
Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
suggestions and brainstorming.
This document is online at https://gist.github.com/4120476
If you respond to this message, please be considerate of people who
subscribe to the digest version of this mailing list and trim your
response.
Invoices, Payments and Receipts for Bitcoin Transactions
This document proposes protocol buffer-based formats for signed,
authenticated "invoices" and "receipts" -- requests for payment, and
proof-of-payment.
Separate documents propose an extension to the Bitcoin URI syntax and
new MIME types to support them.
Motivation
==
The idea of a "payment protocol" to improve on Bitcoin addresses has
been around for over a year. Users have been asking for some features
in this proposal (like the ability to provide a refund address so
overpayments or refunds can be returned to customers without the need
to ask them for their address) for two or three years, and have
started to work around shortcomings in the Bitcoin payment process
with creative (but inefficient) uses of transactions.
The key features of this proposal are:
+ Requests for payment (Invoices) are tied to authenticated identities
using the only widely-deployed identity authentication system we have
right now (X.509 certificates signed by root certificate authorities)
+ Invoices include a user-friendly description of what the payment is for
+ Payments include where refunds should be sent
+ At the end of the payment process, the customer holds a
cryptographically signed Receipt that can be used as proof-of-payment
if there is any dispute with the merchant.
Specification
=
Invoice/SignedInvoice
-
An Invoice is a request for payment from a merchant to a customer:
::
message Output {
optional uint64 amount = 1;
required bytes script = 2;
}
amount: Number of satoshis (0.0001 BTC) to be paid. If not given
or zero, then the customer will be asked how much to pay.
script: a "TxOut" script to which the customer should direct payment.
This will normally be one of the standard Bitcoin transaction script
(e.g. pubkey OP_CHECKSIG).
::
message Invoice {
repeated bytes x509chain = 1;
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional bool single_use = 5 [default = true];
optional string memo = 6;
optional string receiptURI = 7;
optional bytes merchant_data = 8;
}
outputs: one or more outputs where Bitcoins are to be sent.
x509chain: one or more DER-encoded X.509 certificates that identifies
the merchant. See the "Certificates" section below for details.
time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was created.
expires: Unix timestamp after which the Invoice should be considered
invalid. If not given, the Invoice may be re-used until the earliest
certificate expiration date in the X509chain.
single_use: If true, this Invoice should be used for only one payment.
If false, it may be added to the user's address book and used
repeatedly until it expires (e.g. for donations or a recurring
payment).
memo: UTF-8 encoded, plain-text (no formatting) note that should be
displayed to the customer, explaining what this Invoice is for.
receiptURI: Secure (https) URI where a Payment message (see below) may
be sent to obtain a SignedReceipt as proof-of-payment.
merchant_data : Arbitrary data ignored by the client that may be used
by the merchant to identify the Invoice.
::
message SignedInvoice {
required Invoice invoice = 1;
required bytes signature = 2;
}
A SignedInvoice is an Invoice signed using the private key
corresponding to the public key in the first certificate in the
x509chain and the HMAC SHA-256 algorithm.
When a Bitcoin client receives a SignedInvoice, it must authorize
payment by doing the following:
1. Validate the x509chain certificate chain up to it's list of root
certificate authorities
2. Validate that the time on the customer's system is before Invoice.expires
3. Display the "Common Name" (CN) string from the first x509chain
certificate and ask the customer if they would like to submit payment
Payment
---
::
message Payment {
required Invoice invoice = 1;
repeated bytes transactions = 2;
repeated Output refund_to = 3;
optional string memo = 4;
}
invoice : the invoice received from the merchant. A merchant must
validate the Invoice and may reject the Payment if the Invoice was
altered by the customer.
transactions : One or more vali
[Bitcoin-development] Has anyone compiled under MacOS 10.8?
It appears that something about Boost doesn't play nicely with the default build instructions (possibly the switch to clang++?). I will dig in eventually but for now, if anyone has a recipe that fixes things, let me know. -- 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
