Sean Gilligan

A few things you can try: 1. Make sure the input transaction is correct and confirmed at the time of sending the dependent transaction (I'm not sure what validation BlockCypher...

> I think this can be deferred to 0.18. Agreed. Note that dead2c74ab962215aed6f5ecd52f0678fd02ff65 added `getDefault()` and `getDefault(Network)` which could be updated to use `ServiceLocator` to find configurable default implementations.

We're using some JCE hash functions via javax.crypto already so I don't see this as a change in philosophy. And I'd rather keep this function independent of an external library....

Why can't we use the "SunJCE" provider directly? (Although maybe we might have to use a different provider on Android?) If we specify provider(s) don't we know which implementation we're...

This is good thinking and an overall solid approach. We still need to do something like this. See PR #3189

> In my mind, this method is part of our future transaction builder. And I'd like Builder classes stay flexible and not be limited to single usecases, in this case...

Rebased and force-pushed.

> given that our Gradle 4.4 requirement isn't going to budge within the next months. Next _years_, right? There won't be any movement beyond Gradle 4.4.x until Trixie is released,...

We also have a related PR pending: https://github.com/bitcoinj/bitcoinj/pull/2640

> This is testnet I assume. Yes. > What's your earliest key birthdate? I believe it is 2019, but I'll check.