Re: [Bitcoin-development] BIP70 proposed changes
Hi Odinn, There is a tromendous progress and we are working hard on the 2 factor auth. You an follow our progress at : https://github.com/cpacia/BitcoinAuthenticator We are still at development and there is a lot to be done :) On Tue, May 6, 2014 at 4:35 AM, Odinn Cyberguerrilla < odinn.cyberguerri...@riseup.net> wrote: > I am curious if the Android developer who had been working on two factor > authentication and bitcoin had worked toward an open issue or pull > request? I had been looking around for some sign that this had occurred > but hadn't found it, I am interested to know what is the progress in this > area (in a fully decentralized way that resides fully on one's device or > devices). > > For some reason maidsafe keeps rising up in my brain, have bitcoin core > developers touched bases with maidsafe developers on these kind of fine > points? > > Just thoughts and questions. > > -Odinn > > > On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach > > wrote: > >> On 02/18/2014 08:14 PM, Ryan X. Charles wrote: > >>> BitPay is working on a new standard > >>> based on bitcoin-like addresses for authentication. It would be great > >>> if > >>> we could work with the community to establish a complete, decentralized > >>> authentication protocol. > >> > >> Sounds interesting, let us know as soon as you have anything. > > > > SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1 > > > > -- > > Jeff Garzik > > Bitcoin core developer and open source evangelist > > BitPay, Inc. https://bitpay.com/ > > > > > -- > > Managing the Performance of Cloud-Based Applications > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > > Read the Whitepaper. > > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > > ___ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > -- > Is your legacy SCM system holding you back? Join Perforce May 7 to find > out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
I am curious if the Android developer who had been working on two factor authentication and bitcoin had worked toward an open issue or pull request? I had been looking around for some sign that this had occurred but hadn't found it, I am interested to know what is the progress in this area (in a fully decentralized way that resides fully on one's device or devices). For some reason maidsafe keeps rising up in my brain, have bitcoin core developers touched bases with maidsafe developers on these kind of fine points? Just thoughts and questions. -Odinn > On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach > wrote: >> On 02/18/2014 08:14 PM, Ryan X. Charles wrote: >>> BitPay is working on a new standard >>> based on bitcoin-like addresses for authentication. It would be great >>> if >>> we could work with the community to establish a complete, decentralized >>> authentication protocol. >> >> Sounds interesting, let us know as soon as you have anything. > > SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1 > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
> > On an unrelated note, X.509 is a terrible standard that should be > abandoned as quickly as possible. BitPay is working on a new standard > based on bitcoin-like addresses for authentication. It would be great if > we could work with the community to establish a complete, decentralized > authentication protocol. The sooner we can evolve beyond X.509 the better. Because this is such a common sentiment, I wrote a couple of articles on the matter. The first is about why BIP 70 uses the SSL PKI and an examination of the most commonly proposed alternative ideas: https://medium.com/p/b64cf5912aa7 ... including the web of trust, using bitcoin addresses/the block chain, allowing multiple certs, trust-on-first-use and (for SSL only) perspectives/convergence. The second is a summary of some of the most famous crypto-usability research papers published in the past 10-15 years. They cover SSL and PGP. If you're interested in designing alternatives, reading these papers would be a good place to start: https://medium.com/p/d04ea6a2c771 There's a book from O'Reilly called Security & Usability that contains 34 papers and essays. It's very good: http://shop.oreilly.com/product/9780596008277.do -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
> > One more thing. The new bitcoin URI in BIP 72 is extremely long and > makes for very dense QR codes. BIP 73 seems OK except that existing wallets that can scan QR codes will choke. One reason the new URIs are long is for backwards compatibility. One thing that makes the URI smaller is not escaping the payment URL - bitcoinj/Bitcoin Wallet at least does not require it, and it reduces the size of the QR code by a non-trivial amount. Removing the https:// and just defaulting to it also saves some bytes. Finally, BitPay is using rather long invoice IDs. Do you really need an ID like JkLdFhQVFqmUurXpPXZcRp? That's a really huge ID space and the invoices expire fast. So you could potentially implement a short mapping on the server side and make much smaller IDs that way. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
Thanks for the feedback guys! I would also like to understand the problems you've been having with certificates in node.js. FYI the CA cert is *not* supposed to be included, this matches what the code in Bitcoin Core and bitcoinj expects. It may be that Bitcoin Core accepts a redundant CA cert being provided, but if so that'd fall in the category of openssl being generous. If there are issues here, it sounds like an issue with node and not the spec. I'm not even sure why it would matter - certs are just byte arrays so if node can sign a hash with a private key, the rest should be easy. With regards to the PKI I'd appreciate it if we don't go around that circle again. Please remember one of the primary goals of all of this is to show to the user on their hardware wallet a meaningful name. Almost all merchants on the Internet already went through the process of associating a public key with their name, using X.509. Whilst for now your payment requests will have to be signed as BitPay, this isn't ideal for the longer term and I'd like to design a protocol extension to allow merchants to delegate their signature authority to you. In this way they would be able to sign a secondary key with their own ssl key as part of the enrolment process, and after that you could sign payment requests on their behalf. Kind of like a Bitcoin specific subcert (and there would be no reason to use X.509 format for that). Re: feedback url. How is this different to a result code in PaymentAck which already caused much debate? Surely we want a payment to either work out boy work and for that decision to be made immediately? Your invoice page switches to a completed state once you see a tx be broadcast so that's the "done" state today even if there are caveats. I'd like to see a status code added to PaymentAck so receivers can reject payments if they are bad in some way. On 19 Feb 2014 19:41, "Jeff Garzik" wrote: > On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach > wrote: > > On 02/18/2014 08:14 PM, Ryan X. Charles wrote: > >> BitPay is working on a new standard > >> based on bitcoin-like addresses for authentication. It would be great if > >> we could work with the community to establish a complete, decentralized > >> authentication protocol. > > > > Sounds interesting, let us know as soon as you have anything. > > SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1 > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach wrote: > On 02/18/2014 08:14 PM, Ryan X. Charles wrote: >> BitPay is working on a new standard >> based on bitcoin-like addresses for authentication. It would be great if >> we could work with the community to establish a complete, decentralized >> authentication protocol. > > Sounds interesting, let us know as soon as you have anything. SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
[Ick, resending to list due to From: snafu] On Tue, Feb 18, 2014 at 11:47 PM, Peter Todd wrote: > What specifically do you dislike about X.509? The technical standard or > the infrastructure around it? (IE the centralized authorities) I'm not the one who was complaining, but what I dislike is that a certificate can have only one issuer. Cross-signing doesn't address my dislike: it's different enough from being a certificate's single issuer that it leaves too much power in the CAs' hands, IMHO. It isn't so much the centralization per se that I object to, but the way that the technical standard encourages concentration in the infrastructure. See http://lair.fifthhorseman.net/~dkg/tls-centralization/#Why_does_the_architecture_encourage_concentration%3F I've been (slowly) working on a patch to allow pki_data to contain more than just the single certificate chain that the single-issuer-only format insists on, but I'm making as many steps back as forward, being unsure of the right way to do it. Implementing an OpenPGP-based pki_type would probably be better, but hacking x509+* seems like a lower-hanging fruit. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
Any possibility of a UNIX UTC timestamp field in the customer payment message? For many transactions, the exact time of payment is when it is 'made' by the customer and not when 'requested' by the retailer or later mined. The blockchain time is an aggregate for the block and can differ significantly from transaction time so its value is limited. Small slices of time can greatly impact the transaction value. If we are ultimately taxed as a currency, an exact time will for the transaction will impact US GAAP accounting and the transaction's tax accounting. A time field may also support 'first come first served' retailer programs and time sensitive promotions. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
On Tue, Feb 18, 2014 at 02:14:24PM -0500, Ryan X. Charles wrote: > The payment protocol is also the perfect opportunity to implement merge > avoidance to increase customer and merchant privacy. The merchant can > simply deliver multiple outputs in the payment details, say 10 or so, > and the customer can spend multiple outputs to those outputs in separate > transactions. It would be great if BitPay could work with wallet authors > to make merge avoidance a reality in the near-term. > > Merge avoidance would increase the need to have a bitcoin-paymentstatus > message since it's possible that some, but not all, of the transactions > would confirm, and so knowing the status of payment would be a complex > question that should be handled automatically by the software. Note that merge-avoidance implemented in conjunction CoinJoin doesn't have this problem - the CoinJoin'd transaction either does or doesn't confirm. Meanwhile being able to avoid merges, or more precisely, being able to be flexible with them, makes achiving good value-privacy much easier. Secondly merge-flexibility also makes cut-thru payments possible. For example BitPay can direct customers paying for goods to pay to addresses controlled by merchants and other parties who are owed money by BitPay. This skips a step, saving on transction fees as well as increasing privacy. Notably in this case the only parties that have to deal with accounting complexity are BitPay and the merchants - consumers' wallet software needs no changes beyond generic payment protocol support, and notably you can even use this technique without the payment protocol. See my post "DarkWallet Best Practices" for more info: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03508.html > On an unrelated note, X.509 is a terrible standard that should be > abandoned as quickly as possible. BitPay is working on a new standard > based on bitcoin-like addresses for authentication. It would be great if > we could work with the community to establish a complete, decentralized > authentication protocol. The sooner we can evolve beyond X.509 the better. What specifically do you dislike about X.509? The technical standard or the infrastructure around it? (IE the centralized authorities) -- 'peter'[:-1]@petertodd.org 51ad2df596f45df71320fb44b3c5f1b50231a591ffeb1d24 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
On 02/18/2014 08:14 PM, Ryan X. Charles wrote: > The most important missing piece of the payment protocol is that is has > no concept of the status of a payment after it has been made. What if > the payment is too little? Too much? What if it is never confirmed? What > if it is confirmed, but very late? These are regular occurrences at > BitPay (although hopefully they will be a lot fewer after the payment > protocol is widely adopted). I would like to understand why this happens at BitPay? If this is because people use cut and paste to copy the address and then type the amount by hand... well this kind of usage will go away. A program (like an app) should be capable of paying the exact amount. If not, that's a bug of the app not the protocol. > On an unrelated note, X.509 is a terrible standard that should be > abandoned as quickly as possible. +1 > BitPay is working on a new standard > based on bitcoin-like addresses for authentication. It would be great if > we could work with the community to establish a complete, decentralized > authentication protocol. Sounds interesting, let us know as soon as you have anything. >> - certificate chain in pki_data: I think it should be required that is >> most contain the first certificate PLUS all intermediate certificates >> (if any), but NOT the root certificate. Reason: We want to be able to >> verify offline. > > So long as the root certificate remains an optional addition, this seems > like a good idea. In which case does it make sense to duplicate the root cert? I'm asking because it should already be present in the trusted root store, right? Maybe can you tell about which measures you needed to take to get X.509 working? To me it felt there very several problems. > My experience with tls in node is that it is required TLS? We're not using that for pki_data -- its just a byte array. >> - definition of timezone: Its not clear if times (e.g. expires) are in >> UTC or local. I suggest to require UTC. If if we can't agree on this, >> there should be a sentence about timezones in the spec. > > The world needs to abandon timezones altogether for everything and only > use UTC. So, agreed. Require UTC. --> https://github.com/bitcoin/bips/pull/20 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
Fantastic feedback, thanks Ryan and Andreas! Please don't let me being busy get in the way of progress, so submit pull requests to the BIP (the UTC timezone issue seems obvious and non-controversial) or write up draft specs for extensions. RE: wallets checking the status of payment: excellent idea. A URL that can be polled to check payment processing status sounds like the right thing to do. That feels very similar to the proposal for recurring payments; I think they would be separate mechanisms, but maybe their specs could share some of the same concepts / field names On Tue, Feb 18, 2014 at 2:14 PM, Ryan X. Charles wrote: > Here are my complementary thoughts after working on the payment protocol > on the merchant side at BitPay. > > The most important missing piece of the payment protocol is that is has > no concept of the status of a payment after it has been made. What if > the payment is too little? Too much? What if it is never confirmed? What > if it is confirmed, but very late? These are regular occurrences at > BitPay (although hopefully they will be a lot fewer after the payment > protocol is widely adopted). > > One way to handle this would be to add another type of message, say with > content-type bitcoin-paymentstatus, that can return the merchant's view > of the status of the transaction(s). Are the transactions under or > overpaid? Are they confirmed? How many confirmations? Is the payment > "accepted" even if the transactions aren't confirmed? > > I think it would be great if wallets could check the status of a > payment, and if anything goes wrong, request a refund, all within the > payment protocol. > > The payment protocol is also the perfect opportunity to implement merge > avoidance to increase customer and merchant privacy. The merchant can > simply deliver multiple outputs in the payment details, say 10 or so, > and the customer can spend multiple outputs to those outputs in separate > transactions. It would be great if BitPay could work with wallet authors > to make merge avoidance a reality in the near-term. > > Merge avoidance would increase the need to have a bitcoin-paymentstatus > message since it's possible that some, but not all, of the transactions > would confirm, and so knowing the status of payment would be a complex > question that should be handled automatically by the software. > > On an unrelated note, X.509 is a terrible standard that should be > abandoned as quickly as possible. BitPay is working on a new standard > based on bitcoin-like addresses for authentication. It would be great if > we could work with the community to establish a complete, decentralized > authentication protocol. The sooner we can evolve beyond X.509 the better. > > One more thing. The new bitcoin URI in BIP 72 is extremely long and > makes for very dense QR codes. BitPay has proposed a new standard, BIP > 73, for shorter URIs and less dense QR codes. We hope wallet authors > will implement this better standard. > > My response to Andreas' thoughts: > > On 2/18/14, 12:31 PM, Andreas Schildbach wrote: > > I'm starting a thread on proposed changes on BIP70 based on my > > experience in implementing the payment protocol in Bitcoin Wallet: > > > > - certificate chain in pki_data: I think it should be required that is > > most contain the first certificate PLUS all intermediate certificates > > (if any), but NOT the root certificate. Reason: We want to be able to > > verify offline. > > So long as the root certificate remains an optional addition, this seems > like a good idea. My experience with tls in node is that it is required > for the root certificate to be present, so we don't want to require that > the root certificate be absent, since that would make it painful to make > code that is interoperable between the two. IIRC setting > rejectUnauthorized=true will reject connections that do not deliver the > root certificate, so allowing the root certificate to be present would > be compatible with this and presumably other tls code. > > Would be great if someone with more experience with tls weighed in on > whether the root certificate can/should be present. > > > > > - definition of timezone: Its not clear if times (e.g. expires) are in > > UTC or local. I suggest to require UTC. If if we can't agree on this, > > there should be a sentence about timezones in the spec. > > The world needs to abandon timezones altogether for everything and only > use UTC. So, agreed. Require UTC. > > > > > (probably more to be added...) > > > > > > > -- > > Managing the Performance of Cloud-Based Applications > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > > Read the Whitepaper. > > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > > ___ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > >
Re: [Bitcoin-development] BIP70 proposed changes
Here are my complementary thoughts after working on the payment protocol on the merchant side at BitPay. The most important missing piece of the payment protocol is that is has no concept of the status of a payment after it has been made. What if the payment is too little? Too much? What if it is never confirmed? What if it is confirmed, but very late? These are regular occurrences at BitPay (although hopefully they will be a lot fewer after the payment protocol is widely adopted). One way to handle this would be to add another type of message, say with content-type bitcoin-paymentstatus, that can return the merchant's view of the status of the transaction(s). Are the transactions under or overpaid? Are they confirmed? How many confirmations? Is the payment "accepted" even if the transactions aren't confirmed? I think it would be great if wallets could check the status of a payment, and if anything goes wrong, request a refund, all within the payment protocol. The payment protocol is also the perfect opportunity to implement merge avoidance to increase customer and merchant privacy. The merchant can simply deliver multiple outputs in the payment details, say 10 or so, and the customer can spend multiple outputs to those outputs in separate transactions. It would be great if BitPay could work with wallet authors to make merge avoidance a reality in the near-term. Merge avoidance would increase the need to have a bitcoin-paymentstatus message since it's possible that some, but not all, of the transactions would confirm, and so knowing the status of payment would be a complex question that should be handled automatically by the software. On an unrelated note, X.509 is a terrible standard that should be abandoned as quickly as possible. BitPay is working on a new standard based on bitcoin-like addresses for authentication. It would be great if we could work with the community to establish a complete, decentralized authentication protocol. The sooner we can evolve beyond X.509 the better. One more thing. The new bitcoin URI in BIP 72 is extremely long and makes for very dense QR codes. BitPay has proposed a new standard, BIP 73, for shorter URIs and less dense QR codes. We hope wallet authors will implement this better standard. My response to Andreas' thoughts: On 2/18/14, 12:31 PM, Andreas Schildbach wrote: > I'm starting a thread on proposed changes on BIP70 based on my > experience in implementing the payment protocol in Bitcoin Wallet: > > - certificate chain in pki_data: I think it should be required that is > most contain the first certificate PLUS all intermediate certificates > (if any), but NOT the root certificate. Reason: We want to be able to > verify offline. So long as the root certificate remains an optional addition, this seems like a good idea. My experience with tls in node is that it is required for the root certificate to be present, so we don't want to require that the root certificate be absent, since that would make it painful to make code that is interoperable between the two. IIRC setting rejectUnauthorized=true will reject connections that do not deliver the root certificate, so allowing the root certificate to be present would be compatible with this and presumably other tls code. Would be great if someone with more experience with tls weighed in on whether the root certificate can/should be present. > > - definition of timezone: Its not clear if times (e.g. expires) are in > UTC or local. I suggest to require UTC. If if we can't agree on this, > there should be a sentence about timezones in the spec. The world needs to abandon timezones altogether for everything and only use UTC. So, agreed. Require UTC. > > (probably more to be added...) > > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Ryan X. Charles Software Engineer, BitPay 0xA11B4DDE.asc Description: application/pgp-keys -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
