I've been reading about bcrypt and scrypt, and it seems that the general consensus is that bcrypt is more "tried and true", but scrypt is better in theory.
Couldn't you just hash something with bcrypt, then with scrypt? If it has a layer of scrypt to use resources, and a layer of bcrypt, shouldn't that give you the benefits of both with the drawbacks of neither?
I would advise against this. When implementing slow-hashing (such as bcrypt or scrypt), it's usually recommended to select as high a work-factor as is tolerable (in relation to how much time the user is willing to wait, and/or how much strain you're willing to put on your server). Assuming you're working within this constraint, using two distinct slow hashes would force you to halve the work-factor of each, potentially making one or both more susceptible to attack.
Of course, depending on the context, if time and resources are not limited, then your proposal is at best a buffer to dampen paranoia, but honestly I think scrypt is mature enough to be used exclusively.
Mostly similar questions than this are about scrypt and PBKDF2. Shortly: No.
The execution time for slow-hashing (password-based key derivation) must be as long as you can afford (i.e. as long as your users are willing to wait for password derivation). If you use two functions, one taking another as input the time will normally grow, and you get less benefits than by picking stronger of the functions. However, if you can run the functions in parallel then you can get benefits with little cost.
To find more details, read on.
A common attack against key derivation functions is to try to brute-force underlying key material. In case of actual password-based key derivation functions, the functions attempt to ensure there is significant workload in trying to brute-force password (slow-hashing concept).
The benefit of scrypt is that it requires more memory. The usual cryptographic functions can be implemented in ASIC (or FPGA) in very small piece of silicon. Large memory requirements are usually not a problem for PC or smart phone, but implementation of brute-force will take lot more space.
PBKDF2 (from PKCS#5, RFC 2898) is old and tried function, which is much better than old practice of using e.g. hash instead of password-based key derivation. PBKDF2 allows to choose what PRF to use. NIST has made recommendation for PBKDF2, and thus PBKDF2 is the function that can be the option to use in systems having to be compatible with FIPS (in case the PRF is FIPS-approved and the library or chip implementing the function has been properly certified).
bcrypt falls in-between. It uses more memory than PBKDF2, and thus kind of represents compromise between PBKDF2 and scrypt.
scrypt's paper explains all these functions and compares them from perspective of password brute-forcing with ASIC.
For implementations where new relatively new algorithm is fine, I'd use just scrypt. In case it is needed to have old standards compliant algorithm, I would go with PBKDF2.
In combination where for some reason it is necessary to use three algorithms, well, bcrypt would be third.
If your device has more execution cores than one, you could try to run more functions in parallel. Many implementations of PBKDF2 and bcrypt parallelize well. Running functions in serial gives questionable combination and its efficiency is to be questioned.
For similar question nightcracker offered answer where he runs PBKDF2 and scrypt. This answer is easily parallelizable.
Instead of xor, the multiple results could also be combined with e.g. NIST SP 800-108 key derivation functions. If you want to be very careful, you might want to have different salts for different algorithms if you are ware of possible implementation details allowing shortcuts for brute-forcing. But this comes with great cost: you need to store lot more data per user.
Going easy: Just use scrypt.
Harder: If you really really want to use two functions you might want to consider the suggestion of parallelization.
Note: in any case, please spend some time benchmarking so that you choose good work-factors for functions. The most common mistake in use of PBKDF functions too low work-factor.
