Quote from: sunk818 on October 02, 2019, 09:52:13 PM

Quote from: bible_pay on October 02, 2019, 09:43:48 PM

Quote from: sunk818 on October 02, 2019, 09:27:26 PM

> 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.

I think encrypted wallets are a necessary evil. You need it for operational security. I wouldn't suggest messing with it. That might invite more ridicule I think.

Quote from: bible_pay on October 02, 2019, 09:07:03 PM

Hmm.... I think this scheme would only work if a miner cannot change the reward address mid-block. How do you guarantee a miner is not creating more receive addresses while mining a block - by pre-testing the solution with the first createblock to see if its going to "win"? What mechanism could be used to pre-determine a registered miners entry point into that block? 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?

Quote from: bible_pay on October 02, 2019, 09:07:03 PM

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-root

2) timestamp is another input: https://en.bitcoin.it/wiki/Block_hashing_algorithm

Unless 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.

Quote

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.

1) Not suggesting we remove encrypted wallets. I was offering an alternative to store 256K in a non encrypted place. Besides, theoretically the ABN could be made up front, then the wallet locked and the abn stored as that cant be stolen by a hacker (it goes back to you when its cashed in).

2) On changing the receive address, it does change the blockhash, but then it also reveals the "key" to breaking the idea you posted about choosing the winner.
Timestamp wont help either. Either one can be manipulated by the miner, and make themselves the winner based on the table.

3) I am against the oracle, thats why Im not jumping on it. Although I said this before: I dont consider exec price an untrusted oracle. Its a "trusted" oracle. Because one, we only use it as a flag to know if our QT "state" changes. We dont use it to pay out 250K per day in rewards. Big differences. A state change occurs when our price sits above 1 sat for 24 hours. If the "trusted" oracle is wrong, everyone points the finger at our own foundation. And - the state change occurs like once every 2 years. PODC was different - it occurred daily, and, *all* of our blockchain emissions were at stake. Notice I mentioned above, in the "tier" idea, and its just a concept, really the heat miners earn this reward. But your right in the sense that it would still drive some heat rewards over to a "semi-trustworthy" oracle - thats enough for me to pause and put that idea on hold. We can talk about this later, but if we ever discuss cancer mining more - it could be that we simply flatten the rosetta data down to one chance of a heat mined block per cancer miner who has recent rac - something that removes the blockchain reward ratio out of the equation - *but* it may not be possible to do that.