To help counter the threat of mega pool centralization and support loyal miners, dynamic unlock hopes to discourage network hopping behavior, which games the difficulty algorithm. The assumption is that miners on multi-coin pools are motivated to mine any coin that is profitable at any given time. Having pseudorandom unlock times adds an element of uncertainty for pool operators and miners.
However, there is a possibility that a pool could hold a buffer of coins and compensate blocks as they are mined, in effect running as a ponzi scheme, but they take the risk of miner and market fluctuations and might find maintaining wow not worth it. Block unlock time can rang from 1 day to 1 month.
If network decentralization does not improve, we could look at other options.
Related to https://git.wownero.com/wownero/meta/issues/44 and https://git.wownero.com/wownero/meta/issues/28
To help counter the threat of mega pool centralization and support loyal miners, dynamic unlock hopes to discourage network hopping behavior, which games the difficulty algorithm. The assumption is that miners on multi-coin pools are motivated to mine any coin that is profitable at any given time. Having pseudorandom unlock times adds an element of uncertainty for pool operators and miners.
However, there is a possibility that a pool could hold a buffer of coins and compensate blocks as they are mined, in effect running as a ponzi scheme, but they take the risk of miner and market fluctuations and might find maintaining wow not worth it. Block unlock time can rang from 1 day to 1 month.
If network decentralization does not improve, we could look at other options.
Going from a byte array to an ascii hex string back to an integer feels a bit hacky, could we not just take the first few bytes of the tx public key?
Also is there any way for a miner to game this? Could they keep producing reward transactions until the tx public key is close to the minimum?
Going from a byte array to an ascii hex string back to an integer feels a bit hacky, could we not just take the first few bytes of the tx public key?
Also is there any way for a miner to game this? Could they keep producing reward transactions until the tx public key is close to the minimum?
Cmake crys about no viable conversion from 'crypto::publickey' to 'const void 'when converting byte array to an integer type. Yes, it could possibly be gamed by generating reward txs. I added height and already generated coins to the mix to try to counter this.
Cmake crys about no viable conversion from 'crypto::publickey' to 'const void 'when converting byte array to an integer type. Yes, it could possibly be gamed by generating reward txs. I added height and already generated coins to the mix to try to counter this.
You should be able to do tx_pub_key.data to get it as a char array. Although it's not the end of the world to do it like this I guess, just that every little helps when this code is going to be run hundreds of thousands of times when syncingggf. Think hex_str will be too long for the short string optimisation in most standard libraries so it will always end up being a heap allocation and then a free shortly after.
Yes, it could possibly be gamed by generating reward txs. I added height and already generated coins to the mix to try to counter this.
Hmm but since the miner knows the height and already generated coins they could still figure out the unlock time of a block template before they started mining. Maybe it could be totally out of the miners hands, i.e. block at height #1234 will always take 500 blocks to unlock no matter what it does. Like it could be based on the height or the previous block hash.
You should be able to do `tx_pub_key.data` to get it as a char array. Although it's not the end of the world to do it like this I guess, just that every little helps when this code is going to be run hundreds of thousands of times when syncingggf. Think hex_str will be too long for the short string optimisation in most standard libraries so it will always end up being a heap allocation and then a free shortly after.
***
> Yes, it could possibly be gamed by generating reward txs. I added height and already generated coins to the mix to try to counter this.
Hmm but since the miner knows the height and already generated coins they could still figure out the unlock time of a block template before they started mining. Maybe it could be totally out of the miners hands, i.e. block at height #1234 will always take 500 blocks to unlock no matter what it does. Like it could be based on the height or the previous block hash.
Related to wownero/meta#44 and wownero/meta#28
To help counter the threat of mega pool centralization and support loyal miners, dynamic unlock hopes to discourage network hopping behavior, which games the difficulty algorithm. The assumption is that miners on multi-coin pools are motivated to mine any coin that is profitable at any given time. Having pseudorandom unlock times adds an element of uncertainty for pool operators and miners.
However, there is a possibility that a pool could hold a buffer of coins and compensate blocks as they are mined, in effect running as a ponzi scheme, but they take the risk of miner and market fluctuations and might find maintaining wow not worth it. Block unlock time can rang from 1 day to 1 month.
If network decentralization does not improve, we could look at other options.
sample of transactions on testnet https://pastebin.ubuntu.com/p/2fZQFwc2G5/
{crypto::public_key tx_pub_key = cryptonote::get_tx_pub_key_from_extra(b.miner_tx);std::string hex_str = epee::string_tools::pod_to_hex(tx_pub_key).substr(0, 3);uint64_t pub_key_num = std::stol(hex_str,nullptr,16) * 2;Going from a byte array to an ascii hex string back to an integer feels a bit hacky, could we not just take the first few bytes of the tx public key?
Also is there any way for a miner to game this? Could they keep producing reward transactions until the tx public key is close to the minimum?
Cmake crys about no viable conversion from 'crypto::publickey' to 'const void 'when converting byte array to an integer type. Yes, it could possibly be gamed by generating reward txs. I added height and already generated coins to the mix to try to counter this.
You should be able to do
tx_pub_key.datato get it as a char array. Although it's not the end of the world to do it like this I guess, just that every little helps when this code is going to be run hundreds of thousands of times when syncingggf. Think hex_str will be too long for the short string optimisation in most standard libraries so it will always end up being a heap allocation and then a free shortly after.Hmm but since the miner knows the height and already generated coins they could still figure out the unlock time of a block template before they started mining. Maybe it could be totally out of the miners hands, i.e. block at height #1234 will always take 500 blocks to unlock no matter what it does. Like it could be based on the height or the previous block hash.
sample of transactions on testnet2 https://pastebin.ubuntu.com/p/5c24vvQHVf/
e805d42c1ainto master manually 4 years agoe805d42c1a.