> When time permits we can also look into removing the need to unlock the wallet - I think thats a hindrance also (for mining)
> by storing the ABN funds in a separate wallet.dat. Maybe we make a keypair for ABNs, and ask the user to pre-fund the keypair etc.
Don't you have a parameter "headlesspassword"?
We do, but I was thinking maybe other communities are laughing at this.
Because basically we are saying: to mine BBP with an encrypted wallet, you have to script your "headlesspassword" command in order to mine.
I just feel like its a weak point - as then mining fails if you don't know about this command- and the other communities wonder what are we doing? LOL.
So I was thinking we offer an alternative - to fund your own purse for an abn - then mining always works regardless of wallet lock state.
Encrypted wallets are a necessary evil. You need it for operational security. I wouldn't mess with it. If you do it for ABN, what about for GSC?
Even if we made each miner pre-register to mine the next block, what would stop a miner from pre-creating 16 receive addresses and starting the miner with all, and as soon as they discover which address will be rewarded, they increase the hashpower on that address midblock?
I'm not a blockchain dev so I'm going off of my research:
1) since the coinbase transaction is included in the merkleroothash, changing the receiving address changes the blockhash overall
https://bitcoin.stackexchange.com/questions/71659/is-the-hash-of-the-coinbase-transaction-needed-for-the-merkle-root2) timestamp is another input:
https://en.bitcoin.it/wiki/Block_hashing_algorithmUnless you know exactly what second you will hit a block with a high enough difficulty, it seems difficult to game. You'd need to have a hash that matches exactly, then wait for blockhash to change to match your receiving address and risk another miner doesn't beat you to the punch.
Maybe a cryptodev like you could do it, but you'd still need the CPU power to generate an acceptable nonce. So, you'd still need the computing power even before having the other elements match up perfectly.
PoDC & CPID
This runs into the oracle potential issue relying on a third-party. You already do with Quantitative Tightening and commands exec price. Not saying using an oracle can't work (because QT has been running well for many months), I'm just saying the alternative to use blockchain data points offers more reliability.