SegWit, NOMP (Part 3)

[PCW]

This is an interesting experience.  Hopefully someone else will find these posts and learn as I have.

I now need some help determining why Testnet is not accepting my blocks.

Brief background: I use NOMP locally to solo mine and have done so successfully for dozens of coins.  I like and have grown accustom to NOMP.  When I started the first post just 5 days ago, my NOMP wasn't SegWit compliant so I couldn't use it for Bitcoin.  I've since found a commit for a NOMP fork making it SegWit compliant and I added the code to my NOMP, tested it on Testnet and I'm having problems.

The biggest lesson learned: if you make changes to Bitcoin mining or pool software, USE TESTNET!!!!  Thank you to all who encouraged me to do so: @Carlton Banks, @jackg and @gmaxwell.  

Thanks to @DaveF for giving me some more stable alternatives to NOMP which I may still end up using, and to all others who shared their knowledge and experience with me.

These are 6 blocks that I found on Testnet.

https://tbtc.bitaps.com/mtAeMSyVpsdX3BrVdNMaKwA1G8G4GMWHpF

What I've noticed:

(1) I don't think this is anything but bitcoin-cli getnewaddress gave me an address that I used as the pools address (it began with a "2" and testnet=1 was set) but my blocks were found by the above address beginning with an "m".  I assume they equate to each other.

(2) I notice looking at my Raw Transactions that my version number is a 1 whereas all other transactions had a 2 but I didn't think transaction numbers were still being used.  If this is the issue, easily fixed and tested again.

(3) After the first rejection I started the daemon with ./bitcoind -debug=rpc -debug=http but after finding the next block, nothing additional of value was in the debug log

(4) The pool reported the issue to me in multiple lines when payment processing ran (example of block 1609642):

Code:

Daemon reports invalid transaction: 72aefa77a1b642e599788dd29e336e666b48e54e8b5fe1974dc25b316e908180 
Filtering out round 1609642 as kicked cause of invalid tx
Round with height 1609642 and tx 72aefa77a1b642e599788dd29e336e666b48e54e8b5fe1974dc25b316e908180 is orphan

I don't think the block was actually orphaned because all 6 found blocks reported the same way

(5) Looking at the blocks in the link above, I notice that the blocks are getting confirmations.  I'm not sure how many are required before (fake) payment but I doubt that payment is coming.

(6) This really may be minor but when looking at the Verbose listing, I see of the 2 outputs, that my OP_RETURN is listed first whereas in all other blocks that are not mine, the OP_RETURN is 2nd.  I think there's a reason but not sure what it is.

Any help appreciated on any of the above.

[1715205474]

1715205474

[1715205474]

1715205474

[1715205474]

1715205474

[1715205474]

1715205474

[Carlton Banks]

The biggest lesson learned: if you make changes to Bitcoin mining or pool software, USE TESTNET!!!!  

you can also use Regtest for a purely private test network. and soon Signet (not sure how soon), that will allow 'members only' public testnets for more experimental testnets.

(1) I don't think this is anything but bitcoin-cli getnewaddress gave me an address that I used as the pools address (it began with a "2" and testnet=1 was set) but my blocks were found by the above address beginning with an "m".  I assume they equate to each other.

I've forgotten the specifics of the 'm' addresses', but I don't think the equivalence thing is correct. Maybe NOMP won't accept the "2" addresses? "2" is the testnet counterpart of "1" legacy addresses (compressed or uncompressed IIRC), whereas the segwit native testnet addresses are... I think "bt1"

(5) Looking at the blocks in the link above, I notice that the blocks are getting confirmations.  I'm not sure how many are required before (fake) payment but I doubt that payment is coming.

should be 100 blocks to coinbase maturity, assuming it's the same as mainnet. Mainnet used to be 120 blocks coinbase maturity, cannot remember when it was changed, or if testnet (this is testnet3 you're using) was ever changed tbh.

[PCW]

(1) I don't think this is anything but bitcoin-cli getnewaddress gave me an address that I used as the pools address (it began with a "2" and testnet=1 was set) but my blocks were found by the above address beginning with an "m".  I assume they equate to each other.

... I don't think the equivalence thing is correct. ...

@Carlton Banks
So it looks like you're right.  The address that found the blocks is not recognized by my Bitcoin Core wallet as its own.  So given that my daemon wallet created a "2" address and the pool confirmed that the "2" was from the daemon, where did this "m" address come from? I'm glad this is fake Bitcoin.

Code:

p03@ubuntu3:~/bitcoin/src$ bitcoin-cli getaddressinfo "mtAeMSyVpsdX3BrVdNMaKwA1G8G4GMWHpF"
{
  "address": "mtAeMSyVpsdX3BrVdNMaKwA1G8G4GMWHpF",
  "scriptPubKey": "76a9148ac256d3a18daf5d306fc733b1a643bcfd122d2588ac",
  "ismine": false,
  "solvable": false,
  "iswatchonly": false,
  "isscript": false,
  "iswitness": false,
  "ischange": false,
  "labels": [
  ]
}

[Carlton Banks]

I'd assume NOMP has a wallet as part of the software, and that it rejected the address you supplied to it, for whatever reason (syntax? address type? error detected in the address string? bug?)

[PCW]

No, NOMP has no wallet.

NOMP just confirms that the address supplied belongs to the Bitcoin Core daemon.

Yet this "m" address appeared in Testnet corresponding to each of my found blocks, rather than the "2" address actually supplied by the daemon and confirmed by the pool.

The errors that I experienced

Code:

Daemon reports invalid transaction: 72aefa77a1b642e599788dd29e336e666b48e54e8b5fe1974dc25b316e908180
Filtering out round 1609642 as kicked cause of invalid tx
Round with height 1609642 and tx 72aefa77a1b642e599788dd29e336e666b48e54e8b5fe1974dc25b316e908180 is orphan

are probably related to the address not matching, so the issue in my mind is only, where did the "m" address come from?

After 100 confirmations, payment may be sent, but I wonder to where and I wonder if the same will happen on Mainnet.

[pooya87]

"2" is the testnet counterpart of "1" legacy addresses (compressed or uncompressed IIRC), whereas the segwit native testnet addresses are... I think "bt1"

P2PKH script address equivalent (legacy starting with 1 on mainnet) starts with m or n on testnet
P2SH script address equivalent (legacy starting with 3 on mainnet) starts with 2 on testnet
P2WPKH script address equivalent (native SegWit starting with bc1 on mainnet) starts with tb1 on testnet

[Carlton Banks]

P2PKH script address equivalent (legacy starting with 1 on mainnet) starts with m or n on testnet
P2SH script address equivalent (legacy starting with 3 on mainnet) starts with 2 on testnet
P2WPKH script address equivalent (native SegWit starting with bc1 on mainnet) starts with tb1 on testnet

yep, scratch that earlier input from me, pooya87 has the correct info here

[barrysty1e]

This is an interesting experience.  Hopefully someone else will find these posts and learn as I have.

...

The difficulty here would be generating a coinbase transaction correctly using the new address types (bech32 etc).
There isn't much information available on this topic - I've had some success with yiimp however.

All you need to do is encapsulate the address type correctly.