bitcoin-abc / bitcoin-abc Goto Github PK

ABC claims to have replay protection but it seems to go out of its way to not have replay protection. E.g. it changes to use the segwit sighash scheme but then needs extra code to support bitcoin sighashing.

You could have very strong replay protection with roughly a single line code change: simply require all transactions after the point where you fork off bitcoin to have a negative version number. If you don't have the resources to implement this-- or something like it-- right now, I'm sure I can talk someone into doing it for you.

A failure to do this will cause severe monetary losses in the event that this new asset you're issuing becomes worth anything and these losses are avoidable with the most minimal of considerations on your part.

I just sent my Bitcoins to a Bitcoin Cash wallet by mistake, did i lost my coins? or will they be converted to Bitcoin Cash coins after August the first ? Thanks

This is not an issue per say but something really ought to be done to be able to generate addresses that are distinct from what Bitcoin core uses.
Running an exchange is an absolute nightmare - no matter how many warnings you put on the page, users will still mess up.

It will not solve all the issues we have due to legacy, and to be fair this should have not been rushed, but here we have it - we need something to be able to make the Bitcoin ABC addresses unique.

Not sure if this accounted for, but what if some mischievous actor mines a block directly after the mandatory large block that is 'back in time' so that the second block occurs before the trigger date. Would another large block then be required ?

Code in validation.cpp

if (IsUAHFenabled(config, pindexPrev)) {
// If UAHF is enabled for the curent block, but not for the previous
// block, we must check that the block is larger than 1MB.
if (!IsUAHFenabled(config, pindexPrev->pprev)) {

We are sending Bitcoin Cash in batches and on at least one occurrence, the transaction ID that was recorded is different from what BlockDozer reports.

At the time of the send, the server returned transaction ID 47dfe1cea704c687b05c57ad340e150efb475dd4a118f8a8ab33509275f259bc - which is what I recorded in my DB and I can query from the command line (gettransaction).

However Blockdozer cannot find this Transaction ID, but by looking at the recipient address, I found that the transaction was broadcasted using a different Transaction ID: 4939a4fe0a6f048eb00ad7ed9c99ec879980a64615da28a78230aecd34407686

I am using the latest version of Bitcoin ABC - 0.14.6

We could gather here instructions and feedback about migrating a node from BU to Bitcoin ABC.

So, anything in particular to do in order to migrate besides installing Bitcoin ABC and running it?

• Anything about the config?
• Any caveats?

Other places where this question has been asked:
subreddit /r/BitcoinABC/
subreddit /r/btc/
Arch Linux unofficial package

Hello, I synced the blockchain with bitcoin core until the early morning of 1 august, so few hours before the fork of bitcoinabc.
I installed bitcoinabc then and using the same datafolder i continued the sync.
The bitcoinabc software has synced all blocks until august 1 15:16:14
After that is stuck:
in the debug log:
2017-08-02 14:04:57 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:04:57 ERROR: invalid header received
2017-08-02 14:04:57 ProcessMessages(headers, 11503 bytes) FAILED peer=25
2017-08-02 14:05:05 receive version message: /Satoshi:0.13.0/: version 70014, blocks=478714, us=[2001:0:9d38:6abd:1c61:22a9:af97:97e0]:64635, peer=26
2017-08-02 14:05:05 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:05:05 ERROR: invalid header received
2017-08-02 14:05:05 ProcessMessages(headers, 11503 bytes) FAILED peer=26
2017-08-02 14:05:11 receive version message: /Satoshi:0.10.2/: version 70002, blocks=478714, us=80.104.104.31:60215, peer=27
2017-08-02 14:05:14 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:05:14 ERROR: invalid header received
2017-08-02 14:05:14 ProcessMessages(headers, 11503 bytes) FAILED peer=27
2017-08-02 14:05:17 socket recv error An existing connection was forcibly closed by the remote host. (10054)
2017-08-02 14:05:45 receive version message: /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/: version 70015, blocks=478714, us=80.104.104.31:56160, peer=29
2017-08-02 14:05:45 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:05:45 ERROR: invalid header received
2017-08-02 14:05:45 ProcessMessages(headers, 11503 bytes) FAILED peer=29
2017-08-02 14:05:57 receive version message: /Satoshi:0.14.2/: version 70015, blocks=478714, us=80.104.104.31:52783, peer=30
2017-08-02 14:05:57 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:05:57 ERROR: invalid header received
2017-08-02 14:05:57 ProcessMessages(headers, 11503 bytes) FAILED peer=30
2017-08-02 14:05:59 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:05:59 ERROR: invalid header received
2017-08-02 14:05:59 ProcessMessages(headers, 11503 bytes) FAILED peer=26
2017-08-02 14:05:59 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:05:59 ERROR: invalid header received
2017-08-02 14:05:59 ProcessMessages(headers, 11503 bytes) FAILED peer=30
2017-08-02 14:06:05 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:06:05 ERROR: invalid header received
2017-08-02 14:06:05 ProcessMessages(headers, 11503 bytes) FAILED peer=29
2017-08-02 14:06:08 receive version message: /Satoshi:0.13.2/: version 70015, blocks=478715, us=80.104.104.31:59159, peer=31
2017-08-02 14:06:09 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:06:09 ERROR: invalid header received
2017-08-02 14:06:09 ProcessMessages(headers, 11584 bytes) FAILED peer=31
2017-08-02 14:06:16 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:06:16 ERROR: invalid header received
2017-08-02 14:06:16 ProcessMessages(headers, 11503 bytes) FAILED peer=25
2017-08-02 14:06:33 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:06:33 ERROR: invalid header received
2017-08-02 14:06:33 ProcessMessages(headers, 11503 bytes) FAILED peer=27
2017-08-02 14:06:39 receive version message: /Satoshi:0.14.1/: version 70015, blocks=478715, us=80.104.104.31:60204, peer=33
2017-08-02 14:06:40 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:06:40 ERROR: invalid header received
2017-08-02 14:06:40 ProcessMessages(headers, 11584 bytes) FAILED peer=33
2017-08-02 14:06:41 receive version message: /Satoshi:0.14.0/: version 70015, blocks=478715, us=80.104.104.31:64328, peer=34
2017-08-02 14:06:41 ERROR: AcceptBlockHeader: block 000000000000000000706fed6d85dabcd45f69abddcdfd7d41ee78758de939f9 is marked invalid
2017-08-02 14:06:41 ERROR: invalid header received
2017-08-02 14:06:41 ProcessMessages(headers, 11584 bytes) FAILED peer=34

It easy to reproduce just run command getblockchaininfo from console. And notice even though node is fully synced verificationprogress will report values little below 1.0

Describe the issue

We have a proxy node running with prune=20480 that has an internet connection and several client nodes that only connect to proxy via their bitcoin.conf setting connect=<IP of proxy>:8333.

proxy get's new blocks from other ABC nodes on the internet and all clients do get the new blocks from proxy. But often it happens that the client nodes do fall behind and never ever again sync to the current block height of proxy.

Can you reliably reproduce the issue?

1. run a proxy node with internet connection and option prune=20480
2. run a client node with connect=<IP of proxy>:8333 in it's bitcoin.conf
3. wait until the client doesn't sync new blocks from proxy anymore.

Expected behaviour

The client should download all new blocks from the proxy machine.

Actual behaviour

The client does not download new blocks. Instead it logs in it's own debug log:

Ignoring getheaders from peer=0 because node is in initial block download

What version of bitcoin-abc are you using?

0.14.6 compiled on Ubuntu 16.04 LTS

Any extra information that might be useful in the debugging process.

proxy node is running for hours without problems, downloading new blocks as they come.

proxy = block height 478583
client = block height 478570

debug.log from client machine after restart:

2017-08-03 07:57:57 Bitcoin version v0.14.6.0-ga46e63c
2017-08-03 07:57:57 InitParameterInteraction: parameter interaction: -connect set -> setting -dnsseed=0
2017-08-03 07:57:57 InitParameterInteraction: parameter interaction: -listen=0 -> setting -upnp=0
2017-08-03 07:57:57 InitParameterInteraction: parameter interaction: -listen=0 -> setting -discover=0
2017-08-03 07:57:57 InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
2017-08-03 07:57:57 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-08-03 07:57:57 Assuming ancestors of block 000000000000000000ff3a41f208c932d5f91fe8d0739fca36152f6073b2ef5e have valid signatures.
2017-08-03 07:57:57 Default data directory /home/bitcoin/.bitcoin
2017-08-03 07:57:57 Using data directory /home/bitcoin/.bitcoin
2017-08-03 07:57:57 Using config file /home/bitcoin/.bitcoin/bitcoin.conf
2017-08-03 07:57:57 Using at most 125 automatic connections (1024 file descriptors available)
2017-08-03 07:57:57 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements
2017-08-03 07:57:57 Using 0 threads for script verification
2017-08-03 07:57:57 scheduler thread start
2017-08-03 07:57:57 Allowing HTTP connections from: 127.0.0.0/8 ::1/128 x.x.x.x/32 
2017-08-03 07:57:57 Binding RPC on address :: port 8332
2017-08-03 07:57:57 Binding RPC on address 0.0.0.0 port 8332
2017-08-03 07:57:57 Binding RPC on address 0.0.0.0 port 8332 failed.
2017-08-03 07:57:57 Initialized HTTP server
2017-08-03 07:57:57 HTTP: creating work queue of depth 16
2017-08-03 07:57:57 Starting RPC
2017-08-03 07:57:57 Starting HTTP RPC server
2017-08-03 07:57:57 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2017-08-03 07:57:57 Registering HTTP handler for / (exactmatch 1)
2017-08-03 07:57:57 Starting HTTP server
2017-08-03 07:57:57 HTTP: starting 4 worker threads
2017-08-03 07:57:57 Using BerkeleyDB version Berkeley DB 5.3.28: (September  9, 2013)
2017-08-03 07:57:57 Using wallet wallet.dat
2017-08-03 07:57:57 init message: Verifying wallet...
2017-08-03 07:57:57 CDBEnv::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2017-08-03 07:57:57 Entering http event loop
2017-08-03 07:57:57 Cache configuration:
2017-08-03 07:57:57 * Using 2.0MiB for block index database
2017-08-03 07:57:57 * Using 8.0MiB for chain state database
2017-08-03 07:57:57 * Using 440.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2017-08-03 07:57:57 init message: Loading block index...
2017-08-03 07:57:57 Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2017-08-03 07:57:57 Opened LevelDB successfully
2017-08-03 07:57:57 Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2017-08-03 07:57:57 Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
2017-08-03 07:57:58 Opened LevelDB successfully
2017-08-03 07:57:58 Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: 406d4b99b2383ee0
2017-08-03 07:58:02 LoadBlockIndexDB: last block file = 953
2017-08-03 07:58:02 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=62, size=44456164, heights=478509...478570, time=2017-08-01...2017-08-02)
2017-08-03 07:58:02 Checking all blk files are present...
2017-08-03 07:58:02 LoadBlockIndexDB: transaction index disabled
2017-08-03 07:58:02 LoadBlockIndexDB: hashBestChain=000000000000000000e29f8c626dd806633e7fe23004126ab4ec157ad720660b height=478570 date=2017-08-02 03:15:01 progress=0.998642
2017-08-03 07:58:02 init message: Rewinding blocks...
2017-08-03 07:58:03 Committing 0 changed transactions (out of 0) to coin database...
2017-08-03 07:58:03 init message: Verifying blocks...
2017-08-03 07:58:03 Verifying last 6 blocks at level 3
2017-08-03 07:58:03 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2017-08-03 07:58:03 No coin database inconsistencies in last 7 blocks (2936 transactions)
2017-08-03 07:58:03  block index            5761ms
2017-08-03 07:58:03 Reading estimates: 98 buckets counting confirms up to 25 blocks
2017-08-03 07:58:03 init message: Loading wallet...
2017-08-03 07:58:03 nFileVersion = 140600
2017-08-03 07:58:03 Keys: 322 plaintext, 0 encrypted, 322 w/ metadata, 322 total
2017-08-03 07:58:03 Performing wallet upgrade to 60000
2017-08-03 07:58:03  wallet                    7ms
2017-08-03 07:58:03 setKeyPool.size() = 300
2017-08-03 07:58:03 mapWallet.size() = 9
2017-08-03 07:58:03 mapAddressBook.size() = 19
2017-08-03 07:58:03 mapBlockIndex.size() = 478631
2017-08-03 07:58:03 nBestHeight = 478570
2017-08-03 07:58:03 init message: Loading addresses...
2017-08-03 07:58:03 ERROR: Read: Failed to open file /home/bitcoin/.bitcoin/peers.dat
2017-08-03 07:58:03 Invalid or missing peers.dat; recreating
2017-08-03 07:58:03 Flushed 0 addresses to peers.dat  1ms
2017-08-03 07:58:03 init message: Loading banlist...
2017-08-03 07:58:03 ERROR: Read: Failed to open file /home/bitcoin/.bitcoin/banlist.dat
2017-08-03 07:58:03 Invalid or missing banlist.dat; recreating
2017-08-03 07:58:03 Flushed 0 banned node ips/subnets to banlist.dat  1ms
2017-08-03 07:58:03 init message: Starting network threads...
2017-08-03 07:58:03 DNS seeding disabled
2017-08-03 07:58:03 init message: Done loading
2017-08-03 07:58:03 msghand thread start
2017-08-03 07:58:03 opencon thread start
2017-08-03 07:58:03 trying connection <IP OF PROXY>:8333 lastseen=0.0hrs
2017-08-03 07:58:03 addcon thread start
2017-08-03 07:58:03 net thread start
2017-08-03 07:58:03 Added connection to <IP OF PROXY>:8333 peer=0
2017-08-03 07:58:03 AddToWallet ....
2017-08-03 07:58:03 AddToWallet ....
2017-08-03 07:58:03 sending version (113 bytes) peer=0
2017-08-03 07:58:03 send version message: version 70015, blocks=478570, us=[::]:0, them=[::]:0, peer=0
2017-08-03 07:58:03 received: version (113 bytes) peer=0
2017-08-03 07:58:03 sending verack (0 bytes) peer=0
2017-08-03 07:58:03 sending getaddr (0 bytes) peer=0
2017-08-03 07:58:03 receive version message: /Bitcoin ABC:0.14.6(EB8.0)/: version 70015, blocks=478583, us=[::]:0, peer=0, peeraddr=<IP OF PROXY>:8333
2017-08-03 07:58:03 added time data, samples 2, offset +0 (+0 minutes)
2017-08-03 07:58:03 received: verack (0 bytes) peer=0
2017-08-03 07:58:03 sending sendheaders (0 bytes) peer=0
2017-08-03 07:58:03 sending sendcmpct (9 bytes) peer=0
2017-08-03 07:58:03 sending ping (8 bytes) peer=0
2017-08-03 07:58:03 sending feefilter (8 bytes) peer=0
2017-08-03 07:58:03 received: sendheaders (0 bytes) peer=0
2017-08-03 07:58:03 received: sendcmpct (9 bytes) peer=0
2017-08-03 07:58:03 received: ping (8 bytes) peer=0
2017-08-03 07:58:03 sending pong (8 bytes) peer=0
2017-08-03 07:58:03 received: getheaders (997 bytes) peer=0


2017-08-03 07:58:03 Ignoring getheaders from peer=0 because node is in initial block download


2017-08-03 07:58:03 received: pong (8 bytes) peer=0
2017-08-03 07:58:04 received: addr (30003 bytes) peer=0
2017-08-03 07:58:04 Added 1000 addresses from <IP OF PROXY>: 0 tried, 874 new
2017-08-03 07:58:05 received: inv (37 bytes) peer=0
[..]

Describe the issue

On Windows, Bitcoin Core and Bitcoin ABC both store their settings by default in the registry at Computer\HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt. This actually prevents running Bitcoin Core and Bitcoin ABC on the same machine, without taking extra care: The key strDataDir stores the path to the datadirectory. The local copy of the blockchain will get corrupted if you run both (not even parallel, but sequentially) and do not explicitly pass the option datadir.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Install Bitcoin Core, choose some data directory
2. Check the registry, it is stored in strDataDir
3. Install Bitcoin ABC, it will silently also use that strDataDir

Expected behaviour

Bitcoin ABC should have its separate registry path.

Actual behaviour

Bitcoin ABC uses the same registry path as Bitcoin Core

What version of bitcoin-core are you using?

Bitcoin ABC Version v0.14.6.0-a46e63c (64-Bit)

Machine specs:

• OS: Windows 10, 64bit (en)

Assertion failed in maxuploadtarget.py (during run of extended tests):

maxuploadtarget.py:
Initializing test directory /tmp/testcflv3y34/161
MiniNode: Connecting to Bitcoin Node IP # 127.0.0.1:12288
MiniNode: Connecting to Bitcoin Node IP # 127.0.0.1:12288
MiniNode: Connecting to Bitcoin Node IP # 127.0.0.1:12288
Assertion failed: not(3 == 2)
Stopping nodes
Not cleaning up dir /tmp/testcflv3y34/161
Failed

stderr:
  File "/home/ftrader/abc/qa/rpc-tests/test_framework/test_framework.py", line 145, in main
    self.run_test()
  File "/home/ftrader/abc/qa/rpc-tests/maxuploadtarget.py", line 165, in run_test
    assert_equal(len(self.nodes[0].getpeerinfo()), 2)
  File "/home/ftrader/abc/qa/rpc-tests/test_framework/util.py", line 520, in assert_equal
    raise AssertionError("not(%s)" % " == ".join(str(arg) for arg in (thing1, thing2) + args))

Pass: False, Duration: 110 s

Issue can be reliably reproduced on my system (Debian 7 x86_64) by running the test on its own:
$ qa/pull-tester/rpc-tests.py maxuploadtarget

I executed a comparison run on the same system with Bitcoin Core 0.14 branch (f2a96e7) - the test passed 10 / 10 times.

Since we haven't mined a block yet and at current Hash power it will take like a day or more to get to one. I propose changing the algorithm to whatever suits ViaBTC the best.

Making code style changes for no apparent reason is not a good thing to do, e.g. 0d79bc4

It is making backporting features/bug fixes from mainline (Bitcoin Core) hard.

@ftrader told us he wants to apply our Bitcore patches on top of ABC code (see https://www.reddit.com/r/TREZOR/comments/6ompvc/do_trezor_will_support_uahf_in_the_same_you_said/dkmdjgn/) but after these codestyle changes, merging the Bictore patches will be almost impossible task (certainly not doable until August 1st, when you do want to have this ready).

I suggest to revert all formatting patches, such as:

Describe the issue

Client was at block height 478583 and received newest block 478584, then logs error and RPC calls like getbalance fail.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Run bitcoin-abc node until the error CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain. Chain state database corruption likely. is logged to debug.log
2. Run bitcoin-cli getbalance

Expected behaviour

balance is returned

Actual behaviour

Output:

error code: -2
error message:
Safe mode: Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade.

What version of bitcoin-core are you using?

0.14.6 compiled on Ubuntu 16.04 LTS

Any extra information that might be useful in the debugging process.

2017-08-03 08:54:01 addcon thread start
2017-08-03 08:54:01 net thread start
2017-08-03 08:54:01 receive version message: /Bitcoin ABC:0.14.6(EB8.0)/: version 70015, blocks=478583, us=[::]:0, peer=0, peeraddr=<IP OF PROXY>:8333
2017-08-03 08:54:02 Imported mempool transactions from disk: 366 successes, 0 failed, 0 expired
2017-08-03 09:06:35 UpdateTip: new best=000000000000000002d841cbdff1aa150be40e9025127681e72ea36becfa9cc0 height=478584 version=0x20000000 log2_work=86.862281 tx=243298462 date='2017-08-03 09:06:24' progress=1.000000 cache=27.9MiB(2794tx) warning='75 of last 100 blocks have unexpected version'
2017-08-03 09:06:35 CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.

The qa/pull-tester seem to be failing. For example on travis, on the latest run, I see

wallet.py                      | False  | 10 s
p2p-fullblocktest.py           | False  | 102 s
mempool_limit.py               | False  | 3 s
abandonconflict.py             | False  | 7 s
merkle_blocks.py               | False  | 11 s
rawtransactions.py             | False  | 15 s
mempool_reorg.py               | False  | 6 s
prioritise_transaction.py      | False  | 3 s
nulldummy.py                   | False  | 4 s
invalidblockrequest.py         | False  | 103 s
invalidtxrequest.py            | False  | 103 s
mempool-accept-txn.py          | False  | 102 s

Is that to be expected?

Should you be advertising this as being robust? 8mb blocks seem largely untested. Massive on-chain scaling is also false advertising unless Bitcoin ABC has solved the holy grail of scaling.

For example for this address: 1HuiNCrXDEDHeUkKZds1EMPvwW5ejwNeN2

When running Bitcore for Bitcoin, it shows correctly the following transaction: 86d813bdf37a27da0b210d41003da9556327e74650bd53bd068d30600fb54a8a

But running Bitcore for Bitcoin Cash it shows no transactions.

(I am leaving this issue here, because fork which contains Bitcore patches - https://github.com/bitprim/bitcoin-abc - does not have issues enabled.

The 'getdifficulty' RPC command does not seem to return the correct difficulty. It looks like it's not taking into account the new difficulty retargetting rules. It still currently reads '860221984436.22' (as of Aug 2, 2017).

We are running ABC 0.14.6.

Describe the issue

The current comment on the new difficulty adjustment does not reflect how the code works.

    // If producing the last 6 block took less than 12h, we keep the same
    // difficulty.
    const CBlockIndex *pindex6 = pindexPrev->GetAncestor(nHeight - 7);
    assert(pindex6);
    int64_t mtp6blocks =
        pindexPrev->GetMedianTimePast() - pindex6->GetMedianTimePast();
    if (mtp6blocks < 12 * 3600) {
        return nBits;
    }

GetMedianTimePast takes the median time for the last 11 blocks. An accurate comment would be

    // If the difference between the median time for the last 11 blocks and blocks 7-18th from the tip is below 12 hours
    // then we keep the same difficulty.

Can you reliably reproduce the issue?

Blocks 478565 and 478571 were more than 12 hours apart and there was no difficulty retarget.

Expected behaviour

The comment should reflect the code

Actual behaviour

The comment is misleading

On the code, the sigHash seems to be pushed as it is before hashing:

But on the spec:

It says:

    ss << ((GetForkId() << 8) | nHashType);

Could someone help me to understand this? Thanks.

I suggest to change the address version to something different, so it is obvious the address is a Bitcoin Cash address. (It can start with C for example). Don't forget to change also address version for P2SH!

The modified difficulty adjustment code in pow.cpp checks the time to generate the last 6 blocks, no reference to the current time. As the last 6 blocks were on the original chain, they were fast, and the difficulty would therefore not adjust unless at least one other block is found first.

Apply the following modifications:

• Exclude scriptsigs when computing transaction hashes in GetHash() (optionally rename to GetId() as zCash did).
• Create a new CTransaction method getTransactionFullHash() that includes scriptSigs, similar to the GetHash() method prior this change.
• Modify the leaves of the transaction Merkle-Tree to contain two fields {txHash,fullTxhash} instead of only the txHash.
• When verifying a block, check that the fullTxHash corresponds to the txHash.
• Allow scriptSigs to be padded by trailing NOPs and consider them standard scripts, and standard transactions.
• Before signing a transaction, first estimate the amount of bytes required for each scriptSig
• When signing and computing the transaction hash (SignatureHash), also hash the (estimated/actual) length of the scriptSig of the input being signed, to prevent on-the-wire transaction malleability.
  e.g.
  CHashWriter ss(SER_GETHASH, 0);
  // Version
  ss << txTo.nVersion;
  ss << hashPrevouts;
  ss << hashSequence;
  ss << txTo.vin[nIn].prevout;
  ss << static_cast<const CScriptBase &>(scriptCode);
  ss << originalScriptSigLength
  ss << amount;
  ss << txTo.vin[nIn].nSequence;
  ss << hashOutputs;
  ss << txTo.nLockTime;
  ss << nHashType;
• When packing signatures in a scriptSig, add trailing NOPs afterwards to make the actual length reach the estimated length.

While synchronizing the blockchain, the GUI presents severe hangs and slow-downs, delayed click/keyboard events and other problems characteristic to running expensive code on the UI (main?) thread.

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

1. Start bitcoin-qt with a very outdated blockchain state (mine was last updated with blocks from 2014 before switching to Bitcoin ABC). Maybe the bug also happens with a blank library state.
2. Let the synchronization run for about 15-30 minutes.
3. Attempt to use the GUI, which will be very slow, unresponsive and at times completely blocked.

Expected behaviour

No hangs should happen. No UI Coe should be blocked.

Actual behaviour

UI hangs constantly, sometimes for a few seconds, and every 3-5 seconds.

Screenshots.

Screen capture: https://www.youtube.com/watch?v=HqWliB0S3AY

What version of bitcoin-core are you using?

Bitcoin ABC v0.14.6.0-a46e63c
/Bitcoin ABC:0.14.6(EB8.0)/
Berkeley DB 4.8.30: (April 9, 2010)

Machine specs:

• OS: macOS Sierra 10.12.6
• CPU: 3.3 GHz Intel Core i5
• RAM: 24 GB 1867 MHz DDR3
• Disk size: 2TB
• Disk Type (HD/SDD): Fusion Drive (HDD+SSD)

The URI scheme bitcoin: is used on the Bitcoin blockchain and makes it easy to accidentally send coins on the wrong blockchain.

A different scheme like bitcoincash: can solve this issue.

Bitcoin ABC:0.14.6(EB8.0) is stuck at block 478558 (core, unlimited, btc1, uasf is at 478560) and logs:

2017-08-01 13:31:54 receive version message: /Satoshi:0.14.2/: version 70015, blocks=478560, us=XXX, peer=35, peeraddr=XXX
2017-08-01 13:31:54 ERROR: AcceptBlockHeader: block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148 is marked invalid
2017-08-01 13:31:54 ERROR: invalid header received
2017-08-01 13:31:54 ProcessMessages(headers, 163 bytes) FAILED peer=35

Error repeats, abc node is stuck at 478558

Ok, so the situation with NULLDUMMY:

Signaling for the null dummy soft fork is done by signaling support for segwit, and the null dummy soft fork will activate at the same time as segwit.

For more information, please see BIP147.

I do not know about a technical justification for placing this on the same bit (1) as SegWit, but if there isn't, and if this feature is able to offer benefit independent of SegWit, then I would suggest not removing it from ABC, but allocating a separate activation bit for it.

A decision will have to be reached - if it is to remove NULLDUMMY entirely, then there is some leftover C++ code that also needs to be adjusted.

Describe the issue

After upgrading a proxy node (connected to the internet with a public IP) and a client node (connected only to proxy, running txindex=1) from bitcoin-core to bitcoin-abc everything is falling apart.

The client node is rejecting TX it requested from proxy with error was not accepted: non-final (code 64). The proxy node receives this reject but seems not to understand reject since it logs Unknown command "reject". There seems to be a protocol mismatch between both bitcoin-abc nodes because right after that the client raises misbehaving level for the proxy node and finally when misbehaving level for it's only connection to the bitcoin-abc network (node proxy) reaches 100 it drops the connection.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. run bitcoin-core-0.14.2 on node proxy in pruning mode
2. run bitcoin-core-0.14.2 on node client in full mode (no pruning) with additional options
   connect=proxy
txindex=1
3. stop bitcoin-core on both nodes and start bitcoin-abc-0.14.4 on both nodes (same datadir, same bitcoin.conf etc)

Expected behaviour

client connects to proxy and resumes block download from proxy

Actual behaviour

client connects to proxy and then reports proxy as misbehaving, drops connection and repeats

What version of bitcoin-core were you using?

0.14.2 release, self compiled on ubuntu xenial.

What version of bitcoin-abc are you using?

0.14.4 release, self compiled on ubuntu xenial.

Machine specs:

• OS: Ubuntu 16.04 LTS
• AWS t2.small instance
• RAM: 2G
• Disk size: 180G
• Disk Type (HD/SDD): SSD

Any extra information that might be useful in the debugging process.

debug.log from client:

2017-07-26 06:11:36 trying connection <IP-FROM-NODE-PROXY>:8333 lastseen=0.0hrs
2017-07-26 06:11:36 addcon thread start
2017-07-26 06:11:36 net thread start
2017-07-26 06:11:36 Added connection to <IP-FROM-NODE-PROXY>:8333 peer=0
2017-07-26 06:11:36 sending version (113 bytes) peer=0
2017-07-26 06:11:36 send version message: version 70015, blocks=477485, us=[::]:0, them=[::]:0, peer=0
2017-07-26 06:11:37 received: version (113 bytes) peer=0
2017-07-26 06:11:37 sending verack (0 bytes) peer=0
2017-07-26 06:11:37 sending getaddr (0 bytes) peer=0
2017-07-26 06:11:37 receive version message: /Bitcoin ABC:0.14.4(EB8.0)/: version 70015, blocks=477618, us=[::]:0, peer=0, peeraddr=<IP-FROM-NODE-PROXY>:8333
2017-07-26 06:11:37 added time data, samples 2, offset -1 (+0 minutes)
2017-07-26 06:11:37 received: verack (0 bytes) peer=0
2017-07-26 06:11:37 sending sendheaders (0 bytes) peer=0
2017-07-26 06:11:37 sending sendcmpct (9 bytes) peer=0
2017-07-26 06:11:37 sending ping (8 bytes) peer=0
2017-07-26 06:11:37 sending feefilter (8 bytes) peer=0
2017-07-26 06:11:37 received: sendheaders (0 bytes) peer=0
2017-07-26 06:11:37 received: sendcmpct (9 bytes) peer=0
2017-07-26 06:11:37 received: ping (8 bytes) peer=0
2017-07-26 06:11:37 sending pong (8 bytes) peer=0
2017-07-26 06:11:37 received: getheaders (997 bytes) peer=0
2017-07-26 06:11:37 getheaders -1 to end from peer=0
2017-07-26 06:11:37 sending headers (1 bytes) peer=0
2017-07-26 06:11:37 received: pong (8 bytes) peer=0
2017-07-26 06:11:37 received: inv (37 bytes) peer=0
2017-07-26 06:11:37 got inv: tx e6b7abdbc56304b84c1775d32fb594dfc32cec4a3c42cc1faa54ae10dc948866  new peer=0
2017-07-26 06:11:37 askfor tx e6b7abdbc56304b84c1775d32fb594dfc32cec4a3c42cc1faa54ae10dc948866  0 (00:00:00) peer=0
2017-07-26 06:11:37 Requesting tx e6b7abdbc56304b84c1775d32fb594dfc32cec4a3c42cc1faa54ae10dc948866 peer=0
2017-07-26 06:11:37 sending getdata (37 bytes) peer=0
2017-07-26 06:11:37 received: inv (37 bytes) peer=0
2017-07-26 06:11:37 got inv: tx 6eb0e9a491e62b6a1178f605a54387bc7363fe4d90a6110656fb583da70efb1d  new peer=0
2017-07-26 06:11:37 askfor tx 6eb0e9a491e62b6a1178f605a54387bc7363fe4d90a6110656fb583da70efb1d  0 (00:00:00) peer=0
2017-07-26 06:11:37 Requesting tx 6eb0e9a491e62b6a1178f605a54387bc7363fe4d90a6110656fb583da70efb1d peer=0
2017-07-26 06:11:37 sending getdata (37 bytes) peer=0
2017-07-26 06:11:37 received: tx (225 bytes) peer=0
2017-07-26 06:11:37 e6b7abdbc56304b84c1775d32fb594dfc32cec4a3c42cc1faa54ae10dc948866 from peer=0 was not accepted: non-final (code 64)
2017-07-26 06:11:37 sending reject (46 bytes) peer=0
2017-07-26 06:11:37 Misbehaving: <IP-FROM-NODE-PROXY>:8333 peer=0 (0 -> 10)
2017-07-26 06:11:37 received: inv (37 bytes) peer=0
[..]
2017-07-26 06:11:39 got inv: tx fb80f5fda7e8fa66b3f23978cfc83918efc5bf7ccfc06a295ddceee1ed7a41de  new peer=0
2017-07-26 06:11:39 askfor tx fb80f5fda7e8fa66b3f23978cfc83918efc5bf7ccfc06a295ddceee1ed7a41de  0 (00:00:00) peer=0
2017-07-26 06:11:39 Requesting tx fb80f5fda7e8fa66b3f23978cfc83918efc5bf7ccfc06a295ddceee1ed7a41de peer=0
[..]
2017-07-26 06:11:39 received: tx (373 bytes) peer=0
2017-07-26 06:11:39 fb80f5fda7e8fa66b3f23978cfc83918efc5bf7ccfc06a295ddceee1ed7a41de from peer=0 was not accepted: non-final (code 64)
2017-07-26 06:11:39 sending reject (46 bytes) peer=0
2017-07-26 06:11:39 Misbehaving: <IP-FROM-NODE-PROXY>:8333 peer=0 (50 -> 60)
[..]
2017-07-26 06:11:39 received: tx (520 bytes) peer=0
2017-07-26 06:11:39 8ba23b3d23dc69642e7c47ad3f81c4a797c55fa1cf81292e61ae0efb6640b0a0 from peer=0 was not accepted: non-final (code 64)
2017-07-26 06:11:39 sending reject (46 bytes) peer=0
2017-07-26 06:11:39 Misbehaving: <IP-FROM-NODE-PROXY>:8333 peer=0 (80 -> 90)
2017-07-26 06:11:39 received: notfound (37 bytes) peer=0
2017-07-26 06:11:39 received: notfound (37 bytes) peer=0
2017-07-26 06:11:39 received: notfound (73 bytes) peer=0
2017-07-26 06:11:40 received: inv (37 bytes) peer=0
2017-07-26 06:11:40 got inv: tx dc4804fac9a0c8415c5516c5f4855cf6fd65fdfe11c51c54920ad16f780b9e0d  new peer=0
2017-07-26 06:11:40 askfor tx dc4804fac9a0c8415c5516c5f4855cf6fd65fdfe11c51c54920ad16f780b9e0d  0 (00:00:00) peer=0
2017-07-26 06:11:40 Requesting tx dc4804fac9a0c8415c5516c5f4855cf6fd65fdfe11c51c54920ad16f780b9e0d peer=0
2017-07-26 06:11:40 sending getdata (37 bytes) peer=0
2017-07-26 06:11:40 received: inv (37 bytes) peer=0
2017-07-26 06:11:40 got inv: tx 3f15c20667c0f130a9adb3c19d1013cc6c837cbb4239b086ae32dd33d0ad9d15  new peer=0
2017-07-26 06:11:40 askfor tx 3f15c20667c0f130a9adb3c19d1013cc6c837cbb4239b086ae32dd33d0ad9d15  0 (00:00:00) peer=0
2017-07-26 06:11:40 Requesting tx 3f15c20667c0f130a9adb3c19d1013cc6c837cbb4239b086ae32dd33d0ad9d15 peer=0
2017-07-26 06:11:40 sending getdata (37 bytes) peer=0
2017-07-26 06:11:40 received: tx (373 bytes) peer=0
2017-07-26 06:11:40 dc4804fac9a0c8415c5516c5f4855cf6fd65fdfe11c51c54920ad16f780b9e0d from peer=0 was not accepted: non-final (code 64)
2017-07-26 06:11:40 sending reject (46 bytes) peer=0
2017-07-26 06:11:40 Misbehaving: <IP-FROM-NODE-PROXY>:8333 peer=0 (90 -> 100) BAN THRESHOLD EXCEEDED
2017-07-26 06:11:40 disconnecting peer=0

debug.log from proxy:

2017-07-26 06:11:36 Added connection to <IP-FROM-NODE-CLIENT>:53654 peer=6
2017-07-26 06:11:36 connection from <IP-FROM-NODE-CLIENT>:53654 accepted
2017-07-26 06:11:36 received: version (113 bytes) peer=6
2017-07-26 06:11:36 sending version (113 bytes) peer=6
2017-07-26 06:11:36 send version message: version 70015, blocks=477618, us=[::]:0, them=[::]:0, peer=6
2017-07-26 06:11:36 sending verack (0 bytes) peer=6
2017-07-26 06:11:36 receive version message: /Bitcoin ABC:0.14.4(EB8.0)/: version 70015, blocks=477485, us=[::]:0, peer=6, peeraddr=<IP-FROM-NODE-CLIENT>:53654
2017-07-26 06:11:36 added time data, samples 8, offset +0 (+0 minutes)
2017-07-26 06:11:37 received: verack (0 bytes) peer=6
2017-07-26 06:11:37 sending sendheaders (0 bytes) peer=6
2017-07-26 06:11:37 sending sendcmpct (9 bytes) peer=6
2017-07-26 06:11:37 sending ping (8 bytes) peer=6
2017-07-26 06:11:37 initial getheaders (477617) to peer=6 (startheight:477485)
2017-07-26 06:11:37 sending getheaders (997 bytes) peer=6
2017-07-26 06:11:37 received: getaddr (0 bytes) peer=6
2017-07-26 06:11:37 received: sendheaders (0 bytes) peer=6
2017-07-26 06:11:37 received: sendcmpct (9 bytes) peer=6
2017-07-26 06:11:37 received: ping (8 bytes) peer=6
2017-07-26 06:11:37 sending pong (8 bytes) peer=6
2017-07-26 06:11:37 received: feefilter (8 bytes) peer=6
2017-07-26 06:11:37 received: feefilter of 0.00001000 BTC/kB from peer=6
2017-07-26 06:11:37 received: pong (8 bytes) peer=6
2017-07-26 06:11:37 received: headers (1 bytes) peer=6
2017-07-26 06:11:37 connection to 46.243.172.188:8333 timeout
2017-07-26 06:11:37 sending inv (37 bytes) peer=4
2017-07-26 06:11:37 received: inv (1261 bytes) peer=4
[..]
2017-07-26 06:11:37 sending tx (224 bytes) peer=6
2017-07-26 06:11:37 sending inv (37 bytes) peer=6
2017-07-26 06:11:37 received: tx (667 bytes) peer=4
2017-07-26 06:11:37 AcceptToMemoryPool: peer=4: accepted 0cb953937659efc1dbbfffad8da5b06ee0241aed3beb54b0ab18651417f5afe2 (poolsz 460 txn, 1317 kB)
2017-07-26 06:11:37 received: reject (46 bytes) peer=6
2017-07-26 06:11:37 Reject tx code 64: non-final: hash e6b7abdbc56304b84c1775d32fb594dfc32cec4a3c42cc1faa54ae10dc948866
2017-07-26 06:11:37 Unknown command "reject" from peer=6
2017-07-26 06:11:37 sending inv (37 bytes) peer=6
2017-07-26 06:11:37 received: getdata (37 bytes) peer=6
2017-07-26 06:11:37 received getdata (1 invsz) peer=6
2017-07-26 06:11:37 received getdata for: tx 1ce0478e96462b26e3ead53650e02f3b4d43582a5fc542df99c9fc38fd2595c1 peer=6
2017-07-26 06:11:37 sending tx (260 bytes) peer=6
2017-07-26 06:11:37 received: reject (46 bytes) peer=6
2017-07-26 06:11:37 Reject tx code 64: non-final: hash 6eb0e9a491e62b6a1178f605a54387bc7363fe4d90a6110656fb583da70efb1d
2017-07-26 06:11:37 Unknown command "reject" from peer=6
[..]

While nodes are already banning each other nicely, it would be much nicer to change the abc network magic to something else sooner rather than later. Barring that, we'd need to do some dirty hacks like bitcoin/bitcoin#10982 to help the networks split more readily, as well as other things to avoid relaying addresses for nodes on other coins. This more fully and quickly prevents both sides from wasting time/network resources connecting to nodes that will never reach consensus with each other.

to something else than 8333 so it will not collide with Bitcoin.

Describe the issue

Upon starting bitcoin abc the menu bar is accessible however after it is minimized to the task bar then restored, the menu bar does not appear again until bitcoin abc is restarted.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Start bitcoin abc
2. minimize or close bitcoin abc to task bar
3. Click Show/Hide from bitcoin abc icon in task bar
4. Menu bar is missing

Expected behaviour

The menu bar should be available after restoring the bitcoin abc wallet after it was minimized.

Actual behaviour

The menu bar disappears and is not accessible after restoring a minimized bitcoin abc wallet.

Screenshots.

Menu bar immediately after startup -

Menu bar after minimizing and restoring -

(My mouse cursor is hovering in the menu bar in both instances. Upon the screen capture, the mouse cursor is hidden.)

What version of bitcoin-core are you using?

bitcoin abc 0.14.6

Machine specs:

• OS: Ubuntu running unity 7.4.0
• CPU: Intel® Core™ i7-2640M CPU @ 2.80GHz × 4
• RAM: 4GB

Any extra information that might be useful in the debugging process.

I don't see anything out of the ordinary in debug.log. Most if not all of the menu bar is alternatively available from the dropdown menu from the bitcoin abc icon in the task bar.

Hi,

I'm trying to set up Bitcoin-abc wallet on my Ubuntu 16.04 server. After a full sync I'm receiving this message:
Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade.

And can't connect the wallet using rpc.

Does someone have this issue before?

I've tried to reload the wallet several times, the message disappears till the new block is mined.

The difficulty drop consensus rule creates an interesting scenario as follows:

Consider the following simple scenario:

1. Miners wait for difficulty to down significantly low (they can mine BTC meanwhile)
2. They mine 2016 blocks very fast.
3. Back to step 1

With a stable hash rate (stable referring to amount of hash power such that 2016 blocks are mined in 2 weeks), miners can wait for some periods of 12 hours and then mine. Assuming stable hash rate, some basic calculations I did showed that it is possible mine 2016 blocks in 6.3 days while maintaining the same difficulty across periods. I think the problem is even worse because the potential hash power(BTC + BCH) which can mine bitcoin cash is atleast 5 times higher than stable hash power.

I think such a faster rate of coin generation is problematic as it would lead to faster halving(less than 2 years), which leads to faster rise of transaction fees. This leads to the very problem for which bitcoin cash was created to solve. Furthermore, faster generation of coins will also lead faster into unexplored lands of comparable transaction fees overcome block reward incentive.

This is a big problem because if 95% hash power can meetup at a place, it is quite easy to collude for this profit as it fits perfectly in the consensus rules for Bitcoin Cash. Miners are also not necessarily bound to Bitcoin Cash, since they have main bitcoin to fall back on.

A simple solution would be remove the rule by adding a Soft Fork.

I am sure that that the scenario has been considered before designing REQ-7 of UAHF spec, but I feel these consequences do not justify the rationale.

I intended this for a mailing list discussion, but I can't seem to references to it in bitcoinabc.org or bitcoincash.org

Every day you wake up to the same day. Except this time its someone working on an incompatible bitcoin client. Why are you doing it? Do you think your code will be used for anything? Arent you just wasting your time?

I need a testnet for bitcoin-abc or Bitcoin Cash (with big block activated). So I can test my software if it works with the >1M blocks.

Has bitcoin-abc or Bitcoin Cash a testnet? And how can my node join it?

Does requirement to use new hash type applies to transactions in forking block? If yes, then it could take quite a lot of time until there will be enough new style transactions in mempool to create >1MB block. Most of users will not send transactions until fork definitely happened.

or to something else.

Alot of this is going to be copypasta from reddit but I tried to be concise.
I should also mention that I notice a block hasn't been found since shortly after I did this at 00:30 but I'm going to hope that correlation != causation with respect to that. Regardless, I still think this is a pretty major issue as it causes bitcoins (and poss BCC )to be sent to unrecoverable addresses and seemed to break my abc client.

Describe the issue

bitcoin-abc is sending txs on the bitcoin network, destroying funds if user doesn't control target address.

I close my bitcoin core 13.2.
I install and run btcABC with datadir="X:/mybitcoincoredatadir" to save myself a few hundred gigs of duplicate chain data.
I create a BCC deposit address on bittrex.
I send .005 BCC to the address while 8 days behind on sync.
I wait for it to broadcast....
wait....
wait....
still no broadcast after an hour so I grab the raw tx and open the console and do "sendrawtransaction blahb9blasdhfblahb9dsfh8486blah3145926etcetcetc"
seems to finally broadcast.
Now showing as not in mempool, no confs.
I check tradeblock and blockchair and lo and behold:
It's showing on bitcoin chain but not BCC.
Good thing I don't control that address on the bitcoin chain ell oh ell.
I saw the "attempting to spend btc that are affected by not-yet-displayed txs will not be accepted" but fail to see the relevance as these are from inputs "already displayed"---a few weeks old that is. What the hell happened here? Is this client still so alpha that something as basic as sendrawtransaction is still propagated through the bitcoin chain? I'm not asking rhetorically or trying to be flippant here---I'd really like to know how this can be.

Also worth noting is not long after this my client stopped syncing at block 478558

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

see above

Expected behaviour

not this.

What version of bitcoin-core are you using?

13.2 (not running while this happened). Using latest ABC.

Machine specs:

• OS: w7
• CPU:
• RAM:
• Disk size:
• Disk Type (HD/SDD):

Any extra information that might be useful in the debugging process.

some log pasta from occurance (see at 00:30:59):
2017-08-04 00:29:37 UpdateTip: new best=000000000000000000cbd667f920b0d97d4563eeab9652cf00efaa8790934b59 height=477567 version=0x20000002 log2_work=86.823957 tx=241856622 date='2017-07-25 22:09:07' progress=0.989707 cache=201.6MiB(93314tx)
2017-08-04 00:29:37 version handshake timeout from 14
2017-08-04 00:29:38 keypool added key 1161, size=101
2017-08-04 00:29:38 keypool reserve 1061
2017-08-04 00:30:17 UpdateTip: new best=0000000000000000011d30ee7cc2e13c3671884fd6f27adbd3e12a21544067dc height=477568 version=0x20000002 log2_work=86.823993 tx=241857380 date='2017-07-25 22:08:53' progress=0.989706 cache=215.9MiB(97281tx)
2017-08-04 00:30:18 version handshake timeout from 15
2017-08-04 00:30:36 UpdateTip: new best=000000000000000000c9304228b79decd641a87998f6bc65f09c6ac2ead395b0 height=477569 version=0x20000002 log2_work=86.824029 tx=241859040 date='2017-07-25 22:26:56' progress=0.989720 cache=229.5MiB(99972tx)
2017-08-04 00:30:59 UpdateTip: new best=0000000000000000004bd1e9ba360df1ed7e41740e0adf3aba73dd8801f80bb7 height=477570 version=0x20000002 log2_work=86.824066 tx=241860983 date='2017-07-25 22:46:17' progress=0.989735 cache=233.8MiB(103524tx)
2017-08-04 00:30:59 CommitTransaction:
CTransaction(txid=2a057b11e7, ver=2, vin.size=1, vout.size=2, nLockTime=477531)
CTxIn(COutPoint(f73d3d4454, 9), scriptSig=4830450221008c5a49fc1553, nSequence=4294967294)
CTxOut(nValue=0.04414312, scriptPubKey=76a914f87d2e5f5d5377c5dbd5f86b)
CTxOut(nValue=0.00500000, scriptPubKey=76a9141e6dc7b850069f7f54abed9b)
2017-08-04 00:30:59 keypool keep 1061
2017-08-04 00:30:59 AddToWallet 2a057b11e7bcaa4333880c11fca2e43e7b160f0a8e7b85575506515fd3035c17 new
2017-08-04 00:30:59 AddToWallet 2a057b11e7bcaa4333880c11fca2e43e7b160f0a8e7b85575506515fd3035c17
2017-08-04 00:30:59 Relaying wtx 2a057b11e7bcaa4333880c11fca2e43e7b160f0a8e7b85575506515fd3035c17
2017-08-04 00:31:06 version handshake timeout from 16
2017-08-04 00:31:21 UpdateTip: new best=000000000000000000dece85da10a61288012b7c464389d27e63b2b6c0d704e4 height=477571 version=0x20000012 log2_work=86.824102 tx=241863059 date='2017-07-25 23:13:50' progress=0.989756 cache=236.7MiB(107064tx)
2017-08-04 00:31:44 UpdateTip: new best=000000000000000000d99f8a2fca01ee138610993478d406d83ed9b53546c318 height=477572 version=0x20000002 log2_work=86.824139 tx=241865059 date='2017-07-25 23:24:03' progress=0.989764 cache=239.8MiB(110746tx)

This version is failing to build under Arch Linux. Previously I was able to build in this same environment.

This is what appears in the console just before failure.

==> Starting check()...
  -> Testing...
Making check in src
make[1]: Entering directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make[2]: Entering directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make  check-TESTS check-local
make[3]: Entering directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make[4]: Entering directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
FAIL: test/test_bitcoin
============================================================================
Testsuite summary for Bitcoin ABC 0.14.6
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See src/test-suite.log
Please report to https://github.com/Bitcoin-ABC/bitcoin-abc/issues
============================================================================
make[4]: *** [Makefile:9204: test-suite.log] Error 1
make[4]: Leaving directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make[3]: *** [Makefile:9312: check-TESTS] Error 2
make[3]: Leaving directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make[2]: *** [Makefile:9415: check-am] Error 2
make[2]: Leaving directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make[1]: *** [Makefile:9096: check-recursive] Error 1
make[1]: Leaving directory '/home/{user}/build/bitcoin-abc-qt/src/bitcoin-abc-0.14.6/src'
make: *** [Makefile:686: check-recursive] Error 1
==> ERROR: A failure occurred in check().
    Aborting...

And this is the test-suite.log:

============================================
   Bitcoin ABC 0.14.6: src/test-suite.log
============================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test/test_bitcoin
=======================

Running 248 test cases...
test/txvalidationcache_tests.cpp(66): error: in "txvalidationcache_tests/tx_mempool_block_doublespend": check ToMemPool(spends[0]) has failed
test/txvalidationcache_tests.cpp(72): error: in "txvalidationcache_tests/tx_mempool_block_doublespend": check ToMemPool(spends[1]) has failed
test/txvalidationcache_tests.cpp(80): error: in "txvalidationcache_tests/tx_mempool_block_doublespend": check ToMemPool(spends[1]) has failed
test/txvalidationcache_tests.cpp(82): error: in "txvalidationcache_tests/tx_mempool_block_doublespend": check chainActive.Tip()->GetBlockHash() == block.GetHash() has failed
test/uahfstarttime_tests.cpp(52): error: in "uahfstarttime_tests/uahfstarttime_rpc": unexpected exception thrown by CallRPC(std::string("setuahfstarttime ") + std::to_string(chain_mtp + 2 * HOUR + 1))
test/uahfstarttime_tests.cpp(53): error: in "uahfstarttime_tests/uahfstarttime_rpc": check config.GetUAHFStartTime() == chain_mtp + 2 * HOUR + 1 has failed [1501590000 != 1501787889]
test/uahfstarttime_tests.cpp(59): error: in "uahfstarttime_tests/uahfstarttime_rpc": unexpected exception thrown by CallRPC(std::string("setuahfstarttime ") + std::to_string(DEFAULT_UAHF_START_TIME + 24 * HOUR))
test/uahfstarttime_tests.cpp(61): error: in "uahfstarttime_tests/uahfstarttime_rpc": check config.GetUAHFStartTime() == DEFAULT_UAHF_START_TIME + 24 * HOUR has failed [1501590000 != 1501676400]
test/uahfstarttime_tests.cpp(65): error: in "uahfstarttime_tests/uahfstarttime_rpc": unexpected exception thrown by CallRPC(std::string("setuahfstarttime ") + std::to_string(DEFAULT_UAHF_START_TIME + 30 * 24 * HOUR))
test/uahfstarttime_tests.cpp(67): error: in "uahfstarttime_tests/uahfstarttime_rpc": check config.GetUAHFStartTime() == DEFAULT_UAHF_START_TIME + 30 * 24 * HOUR has failed [1501590000 != 1504182000]
test/uahfstarttime_tests.cpp(71): error: in "uahfstarttime_tests/uahfstarttime_rpc": unexpected exception thrown by CallRPC(std::string("setuahfstarttime ") + std::to_string(DEFAULT_UAHF_START_TIME + 365 * 24 * HOUR))
test/uahfstarttime_tests.cpp(73): error: in "uahfstarttime_tests/uahfstarttime_rpc": check config.GetUAHFStartTime() == DEFAULT_UAHF_START_TIME + 365 * 24 * HOUR has failed [1501590000 != 1533126000]
test/uahfstarttime_tests.cpp(78): error: in "uahfstarttime_tests/uahfstarttime_rpc": unexpected exception thrown by CallRPC(std::string("setuahfstarttime ") + std::to_string(std::numeric_limits<int64_t>::max()))
test/uahfstarttime_tests.cpp(80): error: in "uahfstarttime_tests/uahfstarttime_rpc": check config.GetUAHFStartTime() == std::numeric_limits<int64_t>::max() has failed [1501590000 != 9223372036854775807]
test/uahfstarttime_tests.cpp(92): error: in "uahfstarttime_tests/uahfstarttime_rpc": check chain_mtp < hfStartTime has failed
test/uahfstarttime_tests.cpp(97): error: in "uahfstarttime_tests/uahfstarttime_rpc": unexpected exception thrown by CallRPC(std::string("setuahfstarttime ") + std::to_string(chain_mtp + 2 * HOUR + 1))
test/uahfstarttime_tests.cpp(98): error: in "uahfstarttime_tests/uahfstarttime_rpc": check config.GetUAHFStartTime() == chain_mtp + 2 * HOUR + 1 has failed [1501590000 != 1501787888]
test/uahfstarttime_tests.cpp(102): error: in "uahfstarttime_tests/uahfstarttime_rpc": check hfStartTime == chain_mtp + 2 * HOUR + 1 has failed [1501590000 != 1501787888]

A cursory glance of bitcoinabc.org's download section doesn't seem to have it. The closest thing resembling it are the release yaml files minus the signatures.

After switching to bitcoin abc, the balance of my wallet is zero.

I had to rebuild the chain index and then rescan the wallet. (Started out from my bitcoin core's data dir, but had to zap a few block files as it moved past fork date already.)

Afterwards, balance is zero. Wasn't zero before. Anyone seeing this?

I've added the next to my bitcoin.conf:

addnode=47.94.56.232:8333
addnode=144.76.220.17:9090
addnode=39.108.71.254:8333
addnode=52.63.175.61:8333
addnode=97.113.45.103:8333
addnode=71.127.43.68:8333
addnode=52.77.223.113:8333
addnode=51.15.78.11:8333
addnode=5.135.180.61:8333
addnode=46.233.43.155:8333
addnode=13.210.30.22:8333
addnode=176.24.198.205:8334
addnode=69.55.64.221:8333
addnode=47.91.197.178:8333
addnode=72.190.79.138:8333
addnode=45.33.14.27:8333
addnode=13.55.131.240:8333
addnode=76.118.98.204:8333
addnode=35.154.149.128:8333
addnode=52.221.227.157:8333
addnode=54.179.133.79:8333
addnode=83.163.223.145:8333
addnode=80.216.4.252:8333
addnode=71.93.206.181:8333
addnode=147.91.82.116:8333
addnode=188.68.38.210:8333
addnode=100.4.108.100:8333
addnode=98.206.255.202:8333
addnode=13.126.155.63:8333
addnode=122.228.96.58:8333
addnode=178.21.118.33:8333
addnode=39.108.100.122:8333
addnode=47.94.57.128:8333
addnode=47.94.57.121:8333
addnode=47.94.45.184:8333
addnode=47.93.120.133:8333
addnode=47.94.47.152:8333
addnode=39.108.107.120:8333
addnode=47.94.57.156:8333
addnode=68.11.92.58:8333
addnode=54.66.222.15:8333
addnode=34.253.24.13:8333
addnode=163.172.4.66:8333
addnode=108.61.205.173:8333
addnode=54.238.171.233:8333
addnode=34.227.47.255:8333

but that didn't help (seems that these nodes above are not used by my bitcoin-abc node) and I see on my debug log:

2017-08-06 08:52:36 connect() to [2001:0:9d38:6ab8:185f:6e5d:8475:a521]:8333 failed: Network is unreachable (101)
2017-08-06 08:52:36 connect() to 89.246.166.178:8333 failed after select(): No route to host (113)
2017-08-06 08:52:44 connect() to [2001:0:9d38:6ab8:2c07:22f3:4314:7dbe]:8333 failed: Network is unreachable (101)
2017-08-06 08:52:45 connect() to 109.91.159.67:8333 failed after select(): No route to host (113)
2017-08-06 08:53:03 connect() to [2a02:810d:2cbf:ef20:8db9:e29e:28d0:8211]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:21 connect() to [2601:8d:8700:9b60:9814:3cd7:23e4:4b21]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:22 connect() to [2001:0:4137:9e76:2884:9ad0:5251:a94b]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:22 connect() to [2001:0:4137:9e76:2cac:2fcf:46bb:be0d]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:23 connect() to [2001:0:5ef5:79fd:26:e61e:4c28:832f]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:29 connect() to [2001:41d0:2:edd7::]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:30 connect() to [2001:0:9d38:90d7:2cd8:49d:b4af:d8db]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:31 connect() to [2001:470:1f11:36f:6010:2a3a:a2b2:452a]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:31 connect() to [2001:0:4137:9e76:2898:2273:3f57:36cd]:8333 failed: Network is unreachable (101)
2017-08-06 08:53:34 connect() to 24.22.123.27:8333 failed after select(): Connection refused (111)
2017-08-06 08:53:59 receive version message: /Satoshi:0.14.2/: version 70015, blocks=479318, us=XXX.XXX.XXX.XXX:52901, peer=17
2017-08-06 08:54:05 connect() to [2a02:2528:503:2::14]:8333 failed: Network is unreachable (101)
2017-08-06 08:54:06 receive version message: /Satoshi:0.13.2/: version 70015, blocks=479318, us=XXX.XXX.XXX.XXX:56196, peer=18
2017-08-06 08:54:13 connect() to [2a01:e34:ecbb:5a30:a4fd:4558:f893:21b8]:8333 failed: Network is unreachable (101)
2017-08-06 08:54:14 connect() to [2602:306:83f8:c20::46]:8333 failed: Network is unreachable (101)
2017-08-06 08:54:15 receive version message: /Bitcoin ABC:0.14.6(EB8.0)/: version 70015, blocks=478651, us=XXX.XXX.XXX.XXX:59522, peer=19
2017-08-06 08:56:07 connect() to [2a07:a880:4602:1041:e69a:2ae6:6579:baef]:8333 failed: Network is unreachable (101)
2017-08-06 08:56:55 connect() to 217.247.101.231:8333 failed after select(): No route to host (113)

How can I fix that?

I see there isn't a formalized method in place to improve Bitcoin Cash.

I have forked the original bips repo and refactored it as followed:

• each relevant, active or final bip becomes a BCIP

• removed bips that have been withdrawn, or are no longer relevant to this project. Obviously, they can be resubmitted if need be.

• changed file names and links from bip to bcip, for Bitcoin Cash Improvement Proposal

• changed the mailing list for BCIP submission from bitcoin-dev to bitcoin-ml

• small edits of the original bip texts to reflect current 8MB maxblocksize where needed

• changed editor from Luke to myself

some links won't work because they are referencing a nonexistent https://github.com/Bitcoin-ABC/bcips repo that I am proposing here.

The bips I removed for various reasons are: 2 10 12 15 17 18 19 20 33 36 40 41 42 43 62 68 74 75 101 102 103 109 125 141 142 144 145

I won't go into my reasoning for each here, it should be self evident, and of course they can be readded if I removed in error.

I'm volunteering to be the BCIPs editor for now if that works for people, but no new bcips would be added before discussion and agreement, as in the bip process.

This is just a first pass, I'm sure there is stuff that's wrong, or is missing, or should be missing I will examine/fix later but in the meantime:

Please feel free to review, comment or make PR here: https://github.com/mpatc/bcips

The FAQ on https://www.bitcoincash.org used to say:

Bitcoin Cash transactions use a new flag SIGHASH_FORKID, which are invalid on the legacy blockchain. This prevents Bitcoin Cash transactions from being replayed on the Bitcoin blockchain.
Legacy transactions will be non standard on the new chain, but hard replay protection will be opt-in: you must specify with the OP_RETURN flag that BTC transactions be ignored on the Bitcoin Cash chain. This means if you are using a non-upgraded Bitcoin wallet, you will be potentially making a Bitcoin Cash transaction each time you make a Bitcoin transaction, unless you specifically set the flag not to.
Since the transactions are non-standard, that means normally this should not happen, but a miner could choose to include your Bitcoin transactions in a Bitcoin Cash block if replay protection is not specified.

However now it says:

Bitcoin Cash transactions use a new flag SIGHASH_FORKID, which is non standard to the legacy blockchain. This prevents Bitcoin Cash transactions from being replayed on the Bitcoin blockchain and vice versa.

How are you now preventing Bitcoin transactions from being replayed onto Bitcoin Cash. Is SIGHASH_FORKID now mandatory?

The spec still contains that opt-in requirement and it needs to be updated:
https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md#req-6-1-disallow-special-op_return-marked-transactions-with-sunset-clause

I downloaded the binary but am unable to run bitcoin-cli on my ubuntu 16.04 Are there any instructions on how to properly install and run it?
Is there a qt version?

Will you host your binaries on the domain bitcoin-abc.org?

Spend transaction from a 2 out of 3 Mulitisig is successfully created (complete = true...) But transaction is rejected by the network. (Illegal use of sighash type... )
(the transaction shows the ALL|FORKID flag in front of each signatures)...
Push in viaBTC = invalid raw transaction
Pusn in Electrum = "error: The transaction was rejected by network rules. (16: mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation))

After the HF it's quite possible there will not be enough mining hash power behind bitcoin ABC to ensure it's survival. For this reason I suggest a difficulty reset system in the same light as testnet, until after the first proper difficulty reset period. (Or something like that?)