So I have this so far: int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
int64 nSubsidy = 0 * COIN;
std::string cseed_str = prevHash.ToString().substr(8,7);
const char* cseed = cseed_str.c_str();
long seed = hex2long(cseed);
int rand = generateMTRandom(seed, 1000000);
if(nHeight == 1)
nSubsidy = 1100000 * COIN; //.5% Public Wallet Premine
else if(nHeight == 2)
nSubsidy = 1100000 * COIN; //.5% Coin Owner Premine
else if(nHeight > 250 && nHeight <= 14726880){
nSubsidy = 49 * COIN; //Standard 49 Coin Reward
if(nHeight > 5000 && rand < 9723)
nSubsidy = 10045 * COIN; //The super block Protocol Random 250x Block Award
}
return nSubsidy + nFees;
}
What about the substring problem though? With so many coins using superblocks, haven't any of them figured out a fix for that part? Or have they actually discovered it is not actually a problem really due to some (valid) reason why it is not? -MarkM- Well it is only a problem if the difficulty ever gets up high enough. Doubt any alt chain , and especially one using superblocks is getting near the point it becomes an issue. We could just move the start position over a bit. Bitcoin is at what 15 zeros? So have it start at 20 or so? Or take the last seven characters. |
|
|
|
I didn't check whether its the usual integer random number, zero to one less than number given, or some weird custom job the luckyblocks coder came up with; if we know it runs from zero through one less than number of sides we can leave out the "rand < 0 &&" clause.
-MarkM-
It is written using the boost library. int static generateMTRandom(unsigned int s, int range)
{
random::mt19937 gen(s);
random::uniform_int_distribution<> dist(1, range);
return dist(gen);
}
so guess it is from 1, but we can change it. Think we need to change the substring for the seed based on doublec's concern a few posts up? |
|
|
|
I would say give some hours to make up binaries, then a day or two for it to kick in at least.
Okay, and (using 'bc'): 120 * 60 7200 last / 70 102.85714285 100000/last 972.22222228 So 972 sides of a 100,000 sided die or 9722 sides of a 1,000,000 sided die or 97222 sides of a 10,000,000 sided die, etc. Sound about right or did I do the arithmetic in reverse somewhere in there and get totally the wrong result? (Should have gone to bed long ago...) -MarkM- I am in the same boat, too tired to think... but there supposed to be what, 51 blocks an hour, so 102 ever two hours... so a 1% chance should more or less hit a VGB every two hours? So by that 100,000 rounding all over the place to your 97222 being more exact. Seems in the ballpark. |
|
|
|
it rolls 100,000-sided die, and only ten sides of that die are "lucky", so on average one block per ten thousand blocks is "lucky".
How does this work in terms of nodes validating blocks? In other coins they check the number of generated coins is valid and fail to validate if a number greater than the subsidy value is there. In this coin if the random check succeeds the subsidy value will be higher. Any other node validating the block would also need to hit that random value successfully to actually validate it without rejecting the block as invalid. And every node on the network would need to do that everytime it validates the blockchain. How does this coin prevent that from happening? If it doesn't validate the block amount then people could change the source to any subsidy they want. Edit: See the check in ConnectBlock that the generated coins is not greater than GetBlockValue. The value of that will change for each node that tries the random number. Seed is based on a block hash all have, and then feed into a deterministic pseudo random generator. |
|
|
|
I am at block 2600
Me too, now. if the chance of getting lucky is to be increased, the chances increase that the result would think we should have had a lucky block hours ago, so lets figure out the desired number of sides of how many sided a die should be lucky and make it only roll that die after block what, 2700? Or sooner? Or later? -MarkM- I would say give some hours to make up binaries, then a day or two for it to kick in at least. |
|
|
|
it rolls 100,000-sided die, and only ten sides of that die are "lucky", so on average one block per ten thousand blocks is "lucky".
A day is 1440 minutes, block target is a minute and ten seconds...
So yeah it just never "got lucky" because the chance of doing so is way lower than Vlad's design called for.
So there has been no fork yet and on average would only be one every 10000 blocks.
"Both" blockchains are the same blockchain so far.
-MarkM-
Ah, yeah, then the every two hours average is defiantly not what is happening. |
|
|
|
What block are you on? I am seeing 2597
Maybe we can just have the lucky blocks start at some future block since all seems fine so far up to block 2597 to my nodes even though mine believe in the chance that such blocks could have occurred at any time since block 251. Evidently the block hashes are such that it does not think any should have occurred so far.
We should not set it far ahead though probably else we'd just be allowing even more time for, thus chance of, a fork...
It is strange though because if the "chance" is deterministic once the main chain's top block is such that the chance says the next block is a lucky one then all my nodes should have stuck right there, rejecting any non-lucky next block built on that...
-MarkM-
I am at block 2600 |
|
|
|
I reverted to the one that matches the only released version with a binary so far. I suggest we go from the release, and make a fix for the golden blocks that is at a future block, so no one who used the release loses stuff.
Would they lose anything? There is still no indication that any lucky blocks actually happened. Maybe the random chance that was supposed to work out as averaging to happen every two hours is actually wrong and simply has not yet happened in all this time despite the blockchain having been moving along just fine all this time. People were definitely mining all along, as blocks kept showing up. None of the nodes were misbehaving, as in trying to distribute an invalid blockchain. So it kind of looks like somehow the lucky blocks luckily did not happen yet, maybe just by variance aka the grace of God or maybe because the chance of them happening is set way too low to cause them to happen every two hours on average... -MarkM- Well if the VGB are still not working then, they wont lose anything, if it is fixed the the first found VGB should split the chain. Though if the majority of the hashing power is the first version, then and VGB found would become orphans maybe? Guess someone should unit test the VGB code. |
|
|
|
The commit that fixed the lucky blocks was https://github.com/nuggets-project/nuggets/commit/43261b22dc20c5b49030b9609dbb7b17a8257c0fAs far as i was able to detect, it seemed all the active nodes were using that code. But, no one has claimed to have found any lucky blocks. I am not really very familiar with git nor github but I will look around on github to see if i can fork that repo at the point where that commit was made... Well that didn't work, even though I was on that commit's page, it seems to have forked the entire repo not just up to that commit. So i guess I am going to have to figure out how to roll-back to that point. -MarkM- I struggle with git still myself, but found the git revert command.... https://bitbucket.org/mytwobits/nuggetsTwoBits, thanks for reversing the hijack madness. I appreciate it. I think r3 stole millions if coins and covered his tracks but if he's gone and you and mark fixed it I appreciate it so much. Please lock the repo files until I get my programer working on it then i'll need that. Thanks again. Actually, he reverted the fixing of the golden blocks, so he has reverted back to the old code in which lucky blocks did not work. In my repo, I reverted back to what every node actually running and mining seemed to be using, which was the version in which the lucky blocks fix was in place so there should have been lucky blocks happening. But, there still has been no report that anyone did actually find any lucky blocks, so hmm... -MarkM- I reverted to the one that matches the only released version with a binary so far. I suggest we go from the release, and make a fix for the golden blocks that is at a future block, so no one who used the release loses stuff. |
|
|
|
The commit that fixed the lucky blocks was https://github.com/nuggets-project/nuggets/commit/43261b22dc20c5b49030b9609dbb7b17a8257c0fAs far as i was able to detect, it seemed all the active nodes were using that code. But, no one has claimed to have found any lucky blocks. I am not really very familiar with git nor github but I will look around on github to see if i can fork that repo at the point where that commit was made... Well that didn't work, even though I was on that commit's page, it seems to have forked the entire repo not just up to that commit. So i guess I am going to have to figure out how to roll-back to that point. -MarkM- I struggle with git still myself, but found the git revert command.... https://bitbucket.org/mytwobits/nuggets |
|
|
|
In this case though, another principal applies. This was a work for hire. Part of that should have included them giving Vlad access to the repo. The fact that this was not done and programmer X and Y are associates does indicate a dereliction here . So a hostile fork using the same repo that was created as part of this work for hire is probably actionable.
I would question that if the repo were part of someone's own github account, such as if I had done the work and done it by creating a repo in my own github account; but a whole new github account seemingly having been created as part of, and presumably for, the paid work project seems to lend credence to your hypothesis (of it possibly being actionable). Of course I am not licensed to practice law on this planet so what do I know. -MarkM- Yep, and as we can see the project was put under a newly created account called 'nuggets-project'. I checked this before I posted my viewpoint. |
|
|
|
In this case though, another principal applies. This was a work for hire. Part of that should have included them giving Vlad access to the repo. The fact that this was not done and programmer X and Y are associates does indicate a dereliction here . So a hostile fork using the same repo that was created as part of this work for hire is probably actionable. Unless there was a contract and the contract specified control of a specific repo it is unlikely. I mean there is a pretty simple solution, Vlad is in control (I use this term loosely) of this thread. This thread links to a repo. The repo it links to is the "official" (once again used loosely) repo. Vlad clones the existing report and changes the link in the OP to the one he controls. Tada. It could have been done in about 2 minutes and done days ago. Of course that would require someone with the most basic knowledge or competence. Then again this is all academic. He paid a grand total of $20 for a copy & paste job. Nobody is suing anybody or anything related to the shitcoin. I actually think it is pretty likely. The git hub account was created just for this project. I think intent of that being part of the create process would be easy to establish. However like you said, the damages would be too low to make it worthwhile. Probably a treble damages case at best. And yes, that is exactly what Vlad should do at this point. If he can not do that, he did not get the resources in place to manage a coin. |
|
|
|
You gave legal permission to everyone on the planet to "modify and publish copies" of NUG. This permission is binding and irrevocable. You have no legal authority to restrict anyone's access to the source code, or prevent them from making changes you don't like. In the future you may want to learn among a list of other things about open source licensing before "developing" anything.
In general, yeah. Though there have been some cases of it being revocable. The one I remember off hand involved a dvd ripper that was gpled. The code was forced to have a change of ownership by a court, and they also allowed the gpl to be revoked on it if I remember right. Was like 10 years back. In this case though, another principal applies. This was a work for hire. Part of that should have included them giving Vlad access to the repo. The fact that this was not done and programmer X and Y are associates does indicate a dereliction here . So a hostile fork using the same repo that was created as part of this work for hire is probably actionable. |
|
|
|
Does anybody here actually live in Amercica or is everyone here really so stupid and hateful that you don't know what theft by majority vote is?
Democracy? |
|
|
|
I can't believe we have hackers and programmers here and novody can stop this loser r3. Unreal.
The project admin/manager should have set up a team account for the repo, and should kick his access. Others can not do that, they do not have admin rights to the project on github. Whoever gave him access should revoke it. If they gave it in a way that it can not be revoked now, then they made a mistake. No one else can fix that mistake directly here. |
|
|
|
I never ran the code, so no I guess I would not have run it. However some people did, and whoever has coins after the new code hits the first superblock will lose them if this new code becomes the accepted chain.
Actually all the coins will be lost as the repo-guy changed the subsidy of block 1 Ah, yep, looks like the code was changed again from when I last looked at it. So at least three potential chains from the repo versions now. |
|
|
|
So far there still does not seem to be any hijacking happening, the chain still seems to be rolling smoothly along with the fix that was published way back before block 250 first happened... Is there any sign that block 250 happened more than once?
-MarkM-
The change, can't really call it a fix, was put into the repo two days ago it looks like. Pretty sure that was long after block 250. But was anyone even using the repo by then? Due to all the drama is seems more likely everyone either shut down to wait for the dust to settle or put the fix published in the thread into their copy of the code and ran with that fix, which was available to them right here in the thread long before block 250. Would you sit there running broken code that come block 250 was not going to give you any lucky blocks to wait for some purportedly evil github-repo-maintainer to get around to merging the patch into the github, or just go ahead with what the founder wanted regardless of the procratinations of the purportedly evil repo-guy? Maybe by block 250 all nodes running old broken code had already shut down? -MarkM- I never ran the code, so no I guess I would not have run it. However some people did, and whoever has coins after the new code hits the first superblock will lose them if this new code becomes the accepted chain. |
|
|
|
So far there still does not seem to be any hijacking happening, the chain still seems to be rolling smoothly along with the fix that was published way back before block 250 first happened... Is there any sign that block 250 happened more than once?
-MarkM-
The change, can't really call it a fix, was put into the repo two days ago it looks like. Pretty sure that was long after block 250. |
|
|
|
You can ignore the government but they will not ignore you. So better to keep them away proactively. (Means: persuading them.)
What governments need persuading? It is legal in the jurisdictions I know about. |
|
|
|
|
Show Posts
