|
Added a little of potential devs and donation addresses. If anyone may want to work on this with me, let me know.
TODO: Work out basic skeletons for additional functions that need to be implemented and create bounties for their implementation in a list in the original post.
I will not be around much for the next couple of weeks, but I will try to keep an eye on this thread and answer any questions you may have related to this chain.
|
|
|
|
tacotime
how to change the language?
changes the language, reboot, but the language is English, and not that I need.
Sorry, I haven't translated it into any other languages yet. What language do you need? |
|
|
|
Naming cryptocurrency 'coins' has bothered me - at least since the alts had a chance of fixing this. It's the type of http://en.wikipedia.org/wiki/Skeuomorphism that may not make much sense a few years from now. And Skeumorphs are bad in general.  We should come up with a better suffix than -coin if this is an alt. Perhaps something deriving from "credits", which seems to be what most SciFi authors call future money. Also, I like the idea here regarding reducing the massive profits of early adopters: https://bitcointalk.org/index.php?topic=169623.0Metacredit sounds kind of neat, I guess. |
|
|
|
Why not create a tier system that benefits those who have little Hashing power?
With byte coin individuals ave already mined thousands of coins.
Where people with a single GPU and a hash rate of a hundred or so, suffer as they have under 100 coins even after mining for days.
My idea is that for every additional GPU, your hashing power is reduced more and more with a tax.
What is reduced is actually sent to a community faucet. As time goes on, that tax is reduced more and more as the difficulty increases.
This tax rate is linked to your ip address,in order to stop tax evaders.
This tax also prevents the price of this new coin from imploding on day one, within hours when it first goes to market.
We also need to prevent ASIC bombing some how.
If you have an ASIC,why should we allow you to blow up the difficulty to that of Bit coin, almost over night and ruin this alt-coin?
The problem is there's no real way to determine what someone's hashing power is on the network -- they can just run 10 instances of the miner on a GPU to make it looks like their overall hashrate is lower and that they are 8 miners on a pool. Solo mining, it's impossible. |
|
|
|
I really don't understand the rationale behind these hybrid PoS/PoW systems. You can either solve the Byzantine consensus problem with proof of stake, or you can't. In the first case there's no need for wasteful proof of work. In the second case it makes no sense to complicate the design with something that does not add security. It's as if the designers want PoS, haven't quite figure it out how to achieve it, and add PoW for good measure just in case their PoS scheme turns out to be vacuous.
The same can be said about the baroque "polymorphic" hash. If your goal is memory hardness and a small performance opportunity for custom hardware, you should design a scheme specifically tuned for CPU implementation - if such a thing is indeed possible. A hodgepodge of all hashes under the sun while hoping the ASIC designers won't bother to implement them all is security through "copypasting lots of code".
I was really hoping there would be at least one major naysayer in this thread to think about things to improve the chain, but I'm not sure I'm following your argument. Any solution to the byzantine consensus problem with a hybrid PoW-PoW stake system that further introduces fault-tolerance and enhances network security with no real net increase in computation power should be a better solution, not a worse one (main tradeoff is chain bloat, but I'm sure people find this acceptable). In MC2 there are two new mechanisms of fault tolerance: (1) Multiple secure hash algorithms (2) The requirement of at least some coins (very large amounts as the chain matures) that are 90 days old in addition to 51% of the network hash rate. The first addresses any potential failure of SHA2-256, while the second addresses double-spend attacks created by short forks of the chain. In this way the hybrid PoW-PoS system is a better solution to the byzantine consensus problem as far as I can tell. There's too much on the CPU that will never be used for encryption schemes for obvious reasons, such as the FPUs. The same goes for GPUs. Encryption algorithms need to be totally invertible, so they are forced onto the ALUs. I'm not going to write my own secure hash algorithm when we already have several viable ones that have been poured over for years by extremely intelligent people -- it's unlikely I'm going to make one that's more secure than the ones already available. I'm not sure I follow the "copy-pasting" argument either. Yes, I'm adding more hash algorithms -- but there is no simple way to implement them all together with an ASIC or FPGA without using a massive number of logic units. You're looking at maybe 35k gates with a scrypt ASIC while this would easily require 100k+ to hit all encryption algorithms. You can tune one for just one or two of the algos, eg Chacha20-BLAKE512 and Salsa20-BLAKE512, but even attacking with a vector like that gives you 25% of the network if you had some insane amount of them; this is not enough to attack the network with a 51% attack. Further, you have the design hassle of having to optimize for random values of N within a range of 512-2560, and you also have to do the hard hashes to determine the order and quantities for N-values for the upcoming blocks (requiring a CPU or GPU at some level in the easiest implementation). |
|
|
|
Just to confirm, the PoS inital block reward is 12.5 would be for block 1. But since there are no block one stake blocks. The first PoS block is at...
Okay now I run into another problem. 90 days is 32400 blocks (360 blocks per day). But, no PoS blocks are generated for the first 90 'days'. That means that the first PoS blocks won't be generated till 180 days later. And PoW blocks will have a reward adjustment every 18 earth days.
This is correct. The first PoS blocks will be less than 12.5 coins and PoW will have a head start. During this time PoW also disinflates though, so they will both maintain a 50:50 ratio to one another. |
|
|
|
Okay, I have some more questions.
The hash type used for the block is calculated and added for the block header. The hash type that is supposed to be used is used is shown through the block header. Because we know what hash type is used it is easier to verify the legitimacy of the block. But, how do we verify that the correct hash is chosen? We would need to calculate that. But, then that would defeat the whole point. In the whitepaper it says the hash type is given so that you don't need to calculate it. Who would be calculating and verifying the hash type?
The hash type used is determined from a pseudorandomly generated table for the first 200k or so blocks and then is simply derived from the Pearson hash of the 1st, 2nd, ... , nth block after reaching this predefined block height. In the case of both this and N, they are (eventually) both chosen from the blockchain itself, but through previous blocks, never current blocks. Note: N values are calculated from the last 8 blocks in a block cycle, but also not current blocks. The N value is calculated from a much harder scrypt hash of the merkle root. I think the merkle root is able to be gamed though (by manipulating coinbase transaction) so in the next draft this should change to to the block hash rather than the merkle root. We might also need to do another scrypt hash instead of the Pearson hash for secure hash algorithm order and then use that to determine the order of SHAs -- this could afford more security and is easy to implement. We verify that the correct hash is chosen the same way we do in bitcoin: We require that the hash has a number of leading zeroes (difficulty). Because the type of hash in also in the block header, you could never use one of the other hashes too (the network clients would reject it even if it satisfied the correct number of leading zeroes). Edit: If we use the block hash though, we need to contend with the fact that we have essentially a truncated input because of leading zeroes. This might be make it a little less secure (though I doubt it). In this case, we can just use the last 256-bits (which will likely never be 0's) of the block header hash for use in the hard hash to calculate N. |
|
|
|
execute command setx GPU_MAX_ALLOC_PERCENT 100 close the terminal open a new terminal and run cgminer |
|
|
|
shhhhh  |
|
|
|
|
Botnets compete for the allocation of scarce resources as well (stolen computers).
All LTC seems to be doing is driving up the price for stolen computers to mine it with. Pretty soon the cost of a rooted computer will be absurd.
As long as there is competition among the botnet miners, the chain will be secure.
There seems to be some wacky notion of botnets as this looming deathstar above LTC waiting to destroy it.
|
|
|
|
The value n is
again used to determine the cycle size of the polymorphic hash chain, where
each of the 8 possibilities of a sequential memory-hard hash function are
incorporated into the hash chain once and only once; as before, in MC2 n =
8. These are also ordered in a pseudorandom fashion every cycle.
Are there details on the pseudo-random mechanism and why it is done this way? Is it secure to do it pseudo-random rather than truly random?
Sorry but I'd like more information because whenever I see pseudo-random I usually perceive it as a negative red-flag.
The quantities of N for each 8 block cycle are pseudorandom because they are based on the hard hashes of the merkle roots of the last 8 blocks. I say pseudorandom because something is determining them. The reason this can't likely be gamed is because the hard hashes from which these are based on take a long time and a lot of memory to compute (N = 262144; I think they take about 500 msec each to compute on a CPU). In order to game them, you would have to both select for the blocks you put into the hash chain (very hard, because PoW is competitive) and also calculate millions of these extremely hard hashes.
the order will be determined by the integer ordering of the Pearson hashes
of the the Merkle root of blocks {(current block 259,200) ... (current block 259,192) – – }
such that
Huh? Okay why was this decision chosen unless it's the only way?
Pearson hashes are non-secure, but they are exactly 8-bits. The gap for all subranges in N' (Nmax - Nmin) is 256, and 2^(8 bits) = 256. Because we calculate the pearson hash from the hard hash we've already generated, it shouldn't pose a security issue (as before, the hard hashes are really, really hard to game). Edit: Sorry, realized this was about the block ordering, not N-ordering and value generation. I figured that it would be unlikely that people game values in the chain for the ordering of the SHAs years in advance, because that's a massive expenditure of energy (throwing away millions of blocks) in order to do so. There are other ways to do so, but this was easy and there shouldn't be any major security qualms about it I would think (but if you can think of some, I am all ears). I should note in the next update of the paper that these will be based on the PoW blocks only, not PoS blocks (which can easily be gamed). Anyway I'm digesting your paper and I think a lot of it is brilliant so you've won me over as a long term supporter. I think these sorts of currencies need more democratic processes built in because this way they can adapt better to social conditions. The one problem I see with cryptocurrencies is that they all assume that not a lot will change from now to 100 years from now. It's almost certain that Bitcoin cannot last 100 years by design. The birth of AGI or superintelligence will change everything and that hasn't really been factored into this enough.
Theoretical question, if AI or a robot does some work should that AI or robot have to be paid in some sort of cryptocurrency as well? That would potentially be an advance because it would make balance the value of human labor and robot or AI labor for instance if even robot or AI labor is accounted for. It would also provide a mechanism to potentially fund building robots and AI if the creators would be able to tax the profits of their robots.
This would mean there would be no free labor, not even if bots. This is philosophical but I figured I'd add it to the discussion because if cryptocurrency becomes more energy efficient and AI reaches artificial general intelligence and eventually super intelligence then there will be less a need for human labor at all. Why not consider that when designing cryptocurrency? The miraculous thing about Bitcoin is that the protocol can change over time; the clients just need to download new versions they agree upon. Right now the BTC protocol is good enough, but in 10 years? 20 years? 30 years? The democratic system is in place as an eventuality -- you might be surprised as to what doesn't change in 30 years, too. But if AI is designing things, well, I think it'll probably look quite a lot different than this. |
|
|
|
I like the idea, but have a couple of comments
whitepaper: "BLAKE512, SKEIN512, SHA3-512 (KECCAK512), and SHA2-512 are incorporated with both Salsa20 and Chacha20 stream ciphers."
I like how this makes fpga's and asics harder, but it also means that if there is a flaw in any one of these hashes or stream ciphers then the coin fails. Is there any other way to achieve this goal?
The worst thing that can happen with a secure hash algorithm is that any given input's output hash can be predicted more easily than actually hashing it. In the event this happens, we only lose 1/4 of the security of the chain (1/4 of the blocks can be solved more quickly than the others) because we are still using all the other secure hash algorithms, whereas with bitcoin if SHA2 fails the entire chain will trainwreck. If there is a collision attack or something of this nature for one of the hash algorithms, we can just replace it in an update -- the effect on the currency overall is minimal. whitepaper: "Transactions will largely stay the same as in BTC; coin age will be calculated from the the timestamp of the block in which it appears."
Why calculate from the timestamp and not the block height? timestamps can be incorrect, the block height can't be. They both give estimates since the block height to time calculation is based on the target block time that isn't always met, but it is good to base as much as possible on truths inherent to the blockchain.
This is a (good) possibility too -- we can use PoW block height as a consistent metric for network time. I will think about this some more and may use it. |
|
|
|
So the PoW blocks aren't competitively mined? Does the miner get nothing from a PoW block?
Sorry if these are answers already written.. I should probably read your initial stuff more closely..
They are competitively mined as in BTC/LTC/PPC. PoS blocks are not competitively mined, you can simply grab them once you have enough coins of a certain age (which is why you need to put heavy restrictions on the timing of PoS blocks; otherwise a double spend is really, really easy). I also kinda like this idea, but it also poses the difficulty of deciding what level interest should be.
The reward for MC2 is 12.5 coins per clock (vs. 25 coins per block initially for PoW), and it decreases 8% per coin year the same as for the PoW blocks. I think it's ideal for PoW to have a doubly higher reward, as PoW takes more computational effort. |
|
|
|
1) Require that every single PoS block be followed by a PoW block and succeeded by a PoW block, limiting the maximum block rate of the network to PoW and preventing PoS blocks from easily making forks so they can double spend.
I'm pretty new to PoS designs, but wouldn't this kinda defeat any long-term energy efficiency purposes of using PoS? Why bother with PoS at all then? No -- it still affords enhanced security for no real net gain in electricity used. You get some extra resistance to 51% attacks and extra confirmations through this system. Aside from that, I'd really like to have an alt. chain where you are rewarded for saving coins in a fashion that is disconnected from the market. |
|
|
|
|
tldr I was a long bitcoin miner lost a lot of money investing in Tom/bASIC and think I missed the boat on LTC and am unsure whether or not I should invest in LTC FPGAs
|
|
|
|
You guys do realize that TRC is only up at the moment because fontas is pumping the price, right?  Once he decides to hop to another coin, he'll dump all his TRC, and price will never recover. who the heck is fontas?!?!?!?!? btc-e trollbox champion. |
|
|
|
Thanks for the help Tacotime!
np |
|
|
|
I just thought of a great idea.... add an option that allows a user to essentially enter in the exact same information as you would to get guiminer up and running...but instead of mining in the gui it will spit out a config file that you can copy to the desktop and run. IMO, a properly configured cgminer is almost more user friendly then the guiminer (however guiminer is easier to setup for a complete new guy). I can't imagine it would be THAT much work to implement, however I an not technically capable of such a task.. so I suggest it here instead keep up the great work taco. As the other user stated, it does dump the mining command to console. In the next version I'll make it automatically output a "mine-yourminername.bat" file to the cgminer folder though so you can run them from the console if you like too (should also help people troubleshooting the program) |
|
|
|
What do you think would be more fair, extremely unexplained and undocumented source?
That's about right, yeah. |
|
|
|
|
Show Posts
