bitcoin-verde VS priceoracle

AFAIK Verde has been releasing this for months now. (git).

Fair enugh, there is no formal proposal for consensus rules for UTXO commitments. That would be the next step if continuing from this proposal (as mentioned several times in the doc): https://github.com/softwareverde/bitcoin-verde/blob/development/specification/utxo-fastsync-chip-20210625.md

Verde: https://bitcoinverde.org / https://github.com/SoftwareVerde/bitcoin-verde/releases/tag/v2.2.0 (v2.2.0)

utxo commitments for real scaling

For now, the most obvious answer is to make the node reconsider the block for processing. Unfortunately, that script wasn't added to the latest release, but I've added it to our development branch. You can download it here: https://github.com/softwareverde/bitcoin-verde/blob/development/scripts/rpc/reconsider-block.sh . Despite the script not existing in the latest release, the node does support the RPC call, we only failed to include the convenience script.

Bitcoin Verde 2.1.0 has a feature

The most obvious point is oracle risk - GP can enter contracts, then manipulate oracle to be in its own favor. GP tries to run its oracles better than many others and is significantly more accountable, but the centralization does not go away. We have tried to outsource this to established, reliable third parties from the very start, but none took the bait - it's simply too unproven of a project for any big players to throw significant resources at it.

The mitigation of fraudulent behavior is that the oracle follows a very strict standard which would allow anyone who detects conflicting messages (any message used to redeem a contract will be public) can prove that the oracle is acting out of spec, and everyone can take steps to resolve contracts separately through the mutual redemption. Through other circumstances that take time to explain, mutual redemption is not actually available on the current set of contracts. It's not an ideal situation.

The Price Oracle Library (and on NPM)

Medium answer: The oracle follows a specification that makes it easy for someone to prove if the oracle is misbehaving, for example publishing two prices for the same point in block/time.

Prices they can get from various apis like bitcoin.com, coingecko or bitpay. At least I know coingecko provides historical prices. Depends on their use case as to how they want to get price data though. If they need highly accurate minute-to-minute data, they may need to aggregate themselves. If they need BCH-USD prices, they could use the existing General Protocols price oracle https://gitlab.com/GeneralProtocols/priceoracle.