I'd like to ask a hypothetical question (situation didn't really happen) to better my understanding of addresses and wallet encryption.

I had about $40 in a Bitcoin Core un-encrypted (backed up) wallet.

My hard drive crashed and the computer repair guy was able to recover 100% of the documents that I needed that were saved since my last backup.  

When picking up the computer, the repair guy commented, "I noticed you had a Bitcoin wallet so I recovered that for you too".

I restored my entire hard drive image from a week-old backup to a new hard drive including wallet.dat (no activity during the week on wallet.dat).

If I now generate a new receiving address from the wallet and receive funds on that address, would the private key for that new address (and therefore funds) be available to an opportunistic computer repair guy if he were to dump all addresses and private keys from the un-encrypted wallet.dat? i.e., if he generated all addresses in the pool in the un-encrypted wallet.dat, would my new receiving address and private key eventually show up for him?

After all of this, I encrypted my wallet.dat.  Does encrypting change replace all addresses from the un-encrypted wallet with new addresses?

Does keypoolrefill replace all old addresses with new addresses in the pool or only just replenish back to the maximum? If replaces, then that one command would insure that I'd get an address that's not in the old wallet.dat.

Do I have to create a new wallet, encrypt it and use a receiving address from the new wallet to receive future funds (and transfer the $40 to an address in the new wallet)? This is a simple thing to do, I just want to understand what addresses are in a wallet using this hypothetical situation.

Thanks.

[bitcoin-cli getnewaddress]

Every story needs a happy ending and although I didn’t find a Mainnet block (yet), it appears that I have the mechanisms to do so.  This is the "last chapter" but I still have a concern and a question below.

As I said in a previous post, if you make a change to mining or pool software, USE TESTNET!!!

Background:  The NOMP that I had been using for years wasn’t SegWit compliant so I couldn’t use it for Bitcoin.  I therefore needed and found a SegWit commit to a different NOMP fork, and added the code to my NOMP.  This was the solution that I chose, I could have started using different pool software or connect to a public pool.

For reference:

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

After adding the SegWit code, I installed a BitPay wallet to get a Testnet address.  The address began with an "m".  This address is used for the miner to connect to my NOMP pool.

My Testnet Bitcoin Core wallet - bitcoin-cli getnewaddress - gave me an address beginning with a "2" by default.  This address was used by the pool to communicate with the Bitcoin network.

When I found 6 Testnet blocks, I got errors in the PaymentProcessing module seconds after each find.  It turns out, that in checking the Bitcoin Testnet Block Explorer, the address associated with my found blocks began with an "m" but didn't belong to my wallet.  I have no idea where this address came from. How this address changed from a "2" to an "m" is my concern. It would be nice to return the faucet coins that I borrowed for testing, but I can't get access to this "m" account.  Obviously, I don't want anything of the sort to happen on Mainnet.

Next, using bitcoin-cli getnewaddress "" "legacy", I got an address beginning with an "m", confirmed that it belonged to my wallet, found 2 more blocks, and after 100 confirmations, funds were in my BitPay wallet.  So everything seems to work with like legacy addresses.

So on Mainnet, I'll use all addresses (ASIC miners and pool) starting with a "1".

I may try again with two "2" addresses on Testnet to see if that works.

Q: What would be the advantage of using "2" addresses on Testnet rather than "m" (and then all "3" addresses on Mainnet rather than "1")?

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

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.

[I'm mining using a SegWit-compatible full node, Bitcoin Core 0.18 and wallet, and I'm using non-SegWit compliant pool software, NOMP.]

I don't think I provided all relevant information in my previous post with a similar title.

The conclusion in that previous topic was that I can keep doing what I'm doing and don't have to fear losing the reward if I find a block.

I want to provide more information and see if that's indeed the case, since elsewhere (e.g., link below) it is suggested that I will lose the reward if I find the block given my setup.

https://bitcoin.stackexchange.com/questions/86208/are-there-still-miners-or-mining-pool-which-refuse-to-implement-segwit

I think the assumption in my previous post was that I was using a non-SegWit compliant full node e.g., before  Bitcoin Core 0.13.  I am not.

I'm mining using a SegWit-compatible full node, Bitcoin Core 0.18 and wallet, and I'm using non-SegWit compliant pool software, NOMP.

Mining with this setup, will my block be considered invalid and I lose my reward?

[QUESTION: If I change my NOMP code to create Empty Blocks (with only the coinbase transaction) will I get around the problem of other (SegWit-compliant) nodes considering my block as invalid?]

Eight months ago or so, I wanted to solo mine some "lesser known" coins and the only way to do so was to use my own pool.

I found NOMP, which mostly didn't work and had long since been abandoned. Piecing together modules from 2 different NOMP forks, along with some coding, I was able to get it to work and successfully ASIC mine dozens of Scrypt and sha256 coins. (Every single one has lost significant value but that's another discussion.)

I now want to use my NOMP pool to solo mine Bitcoin.  (I know that I have a better chance of throwing a stone and hitting the moon than finding a block, but that's also another discussion.)

SegWit doesn't appear to be implemented in NOMP.

I read that SegWit doesn't apply the the coinbase transaction so:

QUESTION: If I change my NOMP code to create Empty Blocks (with only the coinbase transaction) will I get around the problem of other (SegWit-compliant) nodes considering my block as invalid?

To be clear, I'm using Bitcoin Core 0.18 and non-SegWit compliant pool software.

(And when I read that my block will be considered invalid, I assume that means that if I happen solve a block, that all mining effort will have been wasted, no exception.)

One thing has been puzzling me.

In reading several topics in this board, I understand that solo miners (if they still exist) and pools have the option to select the transactions that will be included in their blocks.

So if a pool in creating a new block selects e.g., 6 transactions #1, #2, #4, #5, #6 and #7, deciding to leave out #3 which e.g., had a lower fee than other transactions.

They calculate the merkle root(s), create the block header(s), etc. and pool members start hashing their respective headers.

Someone in the pool uses a nonce that causes the hash to be lower than the target, and that block is added to the blockchain.

My question simply is, how does transaction #3 ever get to the blockchain?