Quote from: four3200 on December 30, 2019, 03:30:32 PM

well is there a way to make it less clunky?

Quote from: trax0r on December 13, 2019, 02:11:28 PM

https://media.discordapp.net/attachments/452386929103601666/651884886961029123/download-svg_1.png?width=120&height=120

I don't want to say more aggressive Gravity Well.

Because the SHA & SCRY can only be the DUO.

I have always wondered if a masternode with the option to lower diff after X time can call a block with no more reward than POW producers is functional.

Also MN just requires 2 DUO. (But phased towards timed LOCKED)

For the unitinated.

That just means MN can call down diff, yet earn minimal rewards.

Regarding the logo, we are sticking to the one created by our hungarian friend who designed it, it's very nice, and most people agree. We will be petitioning the artist who created the Go Gopher (and Plan 9 rabbit) to design us something in the future but unless a very talented artist shows up and we can pay them that's that for now. However side projects will get their own design. That gopher is just a rough concept melding the current logo and the gopher together but we will reserve such changes for the future when we can afford such luxuries as nitpicking over a graphic design. Protocol and utility and elegant, smooth GUI interface is our focus right now.

No coin using scrypt and sha256d can possibly get anywhere with the hostile mining environment. It's not possible, also, to downregulate difficulty without a new block being found as such behaviour cannot become a consensus.

The new difficulty regime currently has a distance of interval ratio between the shortest and longest interval currently of about 20. I have been thinking it needs to be made wider, currently I have derived the prime number based intervals using a simple algorithm that I can compute from a prime number table, a much longer one could have some interesting uses, and create a wide range of reward schedules depending on the amount of hashpower a miner has. I believe I have already coded in a bias that lets you set a threshold level and above or below as desired in the miner configuration.

Regarding the mining algorithm, nothing is more democratic than a CPU algorithm. This one should indefinitely resist attempts to make it faster. Its bottleneck process is very large integer long division, which is a mathematical process that has not been significantly improved in cycles-per-bit to calculate in ever. Intel famously tried to make a faster long division unit and created a nasty bug as their tables were wrong and the implementation, baked into silicon, could not be fixed once minted. The only way to dominate the post Hard Fork DUO will be to buy a shitload of computers, and though the caches of most CPUs could swallow the size of the eventual numbers the proof requires, I'm not aware of any motherboard that runs without memory installed. This may change but it's the smaller part of the cost anyway so the effect will be minimal. I correct myself, it can't be done without remaking the CPU, as all modern CPUs integrate their memory controller. So even, you have to buy at least a gigabyte of memory, even though your miner will never use it.

More complex scripting patterns can actually already be written, if you have the inclination to do so, but they have to depend on block heights not on timestamps, as it is timestamps are only checked to be within an hour or two of the consensus, and are set in stone once the block is mined on (6, of course, probabilistic finality).

You may be familiar with similar time-based systems as used in the Graphene chains, that is because they are Proof of Stake and 1 block basically is 3 seconds so you still are counting block numbers, they use it to great effect, and there's no reason it can't be done on a nakamoto consensus chain, with that constraint. Again, this can be done with scripting. The new chain does no changes to the script engine aside from switching it after the fork to Schnorr signatures (saving time in validation and space for multiple inputs) so any scripts you may know of used with any other bitcoin fork can be equally implemented. If you wanted such a new transaction type to be on the chain it is just a matter of formalising the script template and putting up an issue on the github, we would be happy to implement such things in the wallet especially if it is rather clever, useful, most importantly, useful, or popular (and practical at the same time). I'm a big fan of 'savings and disbursement' regimes like the power up/power down of Steem, that is a script I would be keen to see integrated into the chain in the future, besides that, I am adding Cosmos Inter Block Chain (IBC) protocol capability to the chain, to at least validate signatures, so later on we can roll out Tendermint/Cosmos SDK based sidechains for specific application types. These have far more flexibility than the Satoshi - designed scripting language, and run faster than Ethereum so don't forget that's on our roadmap once we roll out the hard fork and get some funding to continue work (even if that is just by you all buying every DUO you can get your hands on and increasing the value of our holdings).