[Bitcoin-development] BIP70 proposed changes

[Bitcoin-development] BIP70 proposed changes

[Andreas Schildbach]

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.

- 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.

(probably more to be added...)

Re: [Bitcoin-development] BIP70 proposed changes

[Ryan X. Charles]

[-- Attachment #1: Type: text/plain, Size: 4311 bytes --]

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

[-- Attachment #2: 0xA11B4DDE.asc --]
[-- Type: application/pgp-keys, Size: 5718 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 5679 bytes --]

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 <ryan@bitpay.com> 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
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
> --
> Ryan X. Charles
> Software Engineer, BitPay
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 7210 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Andreas Schildbach]

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

Re: [Bitcoin-development] BIP70 proposed changes

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

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
000000000000000051ad2df596f45df71320fb44b3c5f1b50231a591ffeb1d24

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Derber]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1866 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Bernd Jendrissek]

[Ick, resending to list due to From: snafu]

On Tue, Feb 18, 2014 at 11:47 PM, Peter Todd <pete@petertodd.org> 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.

Re: [Bitcoin-development] BIP70 proposed changes

[Jeff Garzik]

On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
<andreas@schildbach.de> 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/

Re: [Bitcoin-development] BIP70 proposed changes

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]

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" <jgarzik@bitpay.com> wrote:

> On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
> <andreas@schildbach.de> 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
>

[-- Attachment #2: Type: text/html, Size: 4007 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 1152 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

>
> 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

[-- Attachment #2: Type: text/html, Size: 1910 bytes --]

Re: [Bitcoin-development] BIP70 proposed changes

[Odinn Cyberguerrilla]

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
> <andreas@schildbach.de> 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

[Alon Muroch]

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]

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.cyberguerrilla@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
> > <andreas@schildbach.de> 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:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; 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
>

[-- Attachment #2: Type: text/html, Size: 4174 bytes --]