mattf42/pepe-core

PePe-Core Rebooted in July/August 2023

pepe-core's Issues

Solo mined coins not shown anywhere

Today about 3:22 (0 gmt) +-1m solo block was mined, core wallet showed a notification with right label and 5000 coins, also a ccminer had a green Yes!
But in a wallet no sign of new coins, no new transaction, balance unchanged, getbalance show same,
2. Address used for solo has no records on explorer.
3. Orphans blocks from explorer happened at different time.
4. Wallet launched with -rescan, but seems do not even work.

Cross compiling for aarch64-linux fails

Need to manually update config.guess and config.sub in the working build dir of the depends.

#MightFix

Masternodes self inflict partioning through unecessary ban score increases

No IPv6 Seeding Information

All seeds are currently IPv4 meaning pure IPv6 nodes will not be able to connect without an addnode.
Same presumably true for pure onion nodes if there is such an animal.

SPORK_8 doesn't do what it should do

So prior to 2.3.1.2 we had
"SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT": true,

I disabled it in 2.3.1.2 because:

If an incorrect blocks get generated without the masternode payment enforcement in place, the network SHOULD reject these and orphan, them, but it doesn't.

What actually seems to happen is that the voting MNs self partition off with an invalid chain. The correctly reject the block as per

PePe-core/src/masternode-payments.cpp

Lines 202 to 205 in 6decb6e

	if(sporkManager.IsSporkActive(SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT)) {
	LogPrintf("IsBlockPayeeValid -- ERROR: Invalid masternode payment detected at height %d: %s", nBlockHeight, txNew.ToString());
	return false;
	}

But then spiral off into a death spiral of InvalidChainFound, Invalid masternode payment detected and fairly quickly stop syncing.

I think this happens because only the voting MNs participate in in the IsTransactionValid() / IsBlockPayeeValid() checks, but honestly I'm rather out of my depth here.....

So, we shouldn't get MNs sulking and stopping getting paid (hurrah) - but we CAN have invalid blocks (with not MN reward) which the network will not correctly reject :(

Can someone please take a look and work out how we can re-enable SPORK8 without causing MN breakage?

Block 483396 was an example of such a block:

~/bin/PEPEPOW-cli getrawtransaction a133ae7f74523db8cd389196f8eb6480990a233eff694b96b44cf7db5fedb6f7 1
{
"hex": "02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1f0344600704b896ff64088100d3b9030304027a657267706f6f6c2e636f6d00000000000100a89c13460200001976a9140ddc16715823d16442abc7bf0538c2cd46ea2c1988ac00000000",
"txid": "a133ae7f74523db8cd389196f8eb6480990a233eff694b96b44cf7db5fedb6f7",
"size": 116,
"version": 2,
"locktime": 0,
"vin": [
{
"coinbase": "0344600704b896ff64088100d3b9030304027a657267706f6f6c2e636f6d00",
"sequence": 0
}
],
"vout": [
{
"value": 25000.00000000,
"valueSat": 2500000000000,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 0ddc16715823d16442abc7bf0538c2cd46ea2c19 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9140ddc16715823d16442abc7bf0538c2cd46ea2c1988ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"P9rTbRfgkXLmvquRHRKY5Nq7ewA1bFoUZv"
]
}
}
],
"blockhash": "00000000001ccca9511293f1cd73be38089b36b6e6b5a74c9a8709e92d220559",
"height": 483396,
"confirmations": 36166,
"time": 1694471865,
"blocktime": 1694471865
}

Building from source on ubuntu 20

After building from source I attempt to run the QT file and encounter this issue

The X11 connection broke: Maximum allowed requested length exceeded (code 4)
XIO: fatal IO error 22 (Invalid argument) on X server ":0"
after 403 requests (403 known processed) with 0 events remaining.
when I attempt to run the QT

Found another issue referencing this
bitcoin/bitcoin#18537

Fails to build on Debian12

Known issue.

Ubuntu 18.04 is the current build platform of choice for X64 Linux binaries.
Ubuntu 22.04 seems to work best for cross-compiling the Windows binaries.