priceoracle VS bitcoin-cash-node

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.

Thinking maybe this: https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/tree/master

Yep, just a suggestion/comment in the config file here which showed me 'this was useful for me, let me share it' kind of vibes. I also checked their history there. Seem to be helping review things too (i have no idea about the back story here, just going on what I'm seeing before me)

They're already implemented and running on testnet4, using node software built from this MR: https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/merge_requests/1600

Either build the test branch yourself (https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/merge_requests/1600) or use Calin's build here (https://www.c3-soft.com/downloads/BitcoinCash/testing/mr-1600)

At first I was disappointed by the results following official build instructions for BCHN (here) & Bitcoin Core (here), but eventually I realized they were missing the strip * command. BCHN gave a strange warning when running it, but that issue is apparently resolved with the -DCLIENT_VERSION_IS_RELEASE flag. Without stripping, the bitcoin-qt.exe can be 415 MiB instead of under 31 MiB.

#!/bin/bash sudo apt-get update sudo apt-get upgrade -y sudo apt-get install -y build-essential cmake git git-lfs libboost-chrono-dev libboost-filesystem-dev libboost-test-dev libboost-thread-dev libevent-dev libminiupnpc-dev libssl-dev libzmq3-dev ninja-build python3 help2man unzip sudo apt-get install -y build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev sudo apt-get install -y libdb-dev libdb++-dev liblmdb++-dev sudo apt-get install -y htop git config --global user.email "[email protected]" git config --global user.name "Your Name" #git clone https://github.com/mtrycz/txunami.git #cd txunami #git submodule update --init --recursive #cd BitcoinUnlimited #git checkout dev #./autogen.sh #./configure --with-gui=no --enable-shared --enable-wallet --with-incompatible-bdb #make -j9 #./src/bitcoind -scalenet -blockmaxsize=256000000 -maxmempool=2048 -daemon -rpcworkqueue=32 #cd .. #make git clone https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node.git cd bitcoin-cash-node/ git checkout 24.1.0 #git clone https://gitlab.com/matricz/bitcoin-cash-node.git #cd bitcoin-cash-node/ #git checkout phmap mkdir build cd build cmake -GNinja .. -DBUILD_BITCOIN_QT=OFF -DCMAKE_BUILD_TYPE:STRING=Release ninja #cd #wget https://mtrycz-test.s3.eu-central-1.amazonaws.com/prunedscalenet.zip #unzip prunedscalenet.zip mkdir /dev/shm/.bitcoin cd # ./bitcoin-cash-node/build/src/bitcoind -daemon -debug=bench -debug=coindb -checkpoints=0 -assumevalid=0 -datadir=/dev/shm/.bitcoin -scalenet # tail -f /dev/shm/.bitcoin/scalenet/debug.log | grep -E --color "Flush:|"

BCH runs by a diverse set of node implementations that have slightly different implementations (and docs), although following the same consensus rules. I would recommend starting with BCHN's list of consensus changes since the hard fork in 2017: https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/blob/master/doc/bch-upgrades.md

A draft implementation is coming to testnets for BCH via Bitcoin Cash Node hopefully soon.