ЗЫ: кстати, а что такое "туземунизм" ? Гугл такого не знает (
туземунизм = это значит, что курс NXT полетит to the Moon. Высоко, в общем  |
|
|
|
Again on this "true randomization" issue. In general, what amount of randomization is desirable, i.e., how often should it happen? If not very often (e.g., several times a day), then the real world will take care of this (because nodes go online and offline, money are transferred, etc.).
I agree. I wrote the following to CfB: I do not think that is possible anymore. Preparing means you need to know 1440 blocks in advance which accounts you need. So, you need to build up the a whole forging graph of size http://www.wolframalpha.com/input/?i=28000%5E1440 (28000 accounts, 1440 blocks for effectiveBalance) [to get sure you cover all cases]. The leaves of that graph represent the entry points for the attacker's accounts. Then the attacker needs to create accounts at the right time to forge the next N blocks. That is like calculating the private key out of your public key. If this is not enough, then the following procedure is possible. First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try)..
The problem here still is: who belongs to X if one of X is offline and who decides that? It is the very same consensus finding problem that block generation tries to solve. Well, with our forging procedure we obtain a consensus about who are the best X account w.r.t. the inverse weights, right (and the network then delegates to the best of the best the right to create the next block)? Then we just ask those best accounts to provide a random number for us. The idea is that if there is at least one "honest" guy among them, then this random number will be "truly random", even if all the others try to cheat. The problem is not on the side of the forgers. It is on the side of the one that uses the random numbers. Which numbers does he choose? More importantly, which numbers does he omit and which ones does he include in his calculation? Assume, he finds a way to exclude everything but one number, he can then pre-calculate an account that provide a suitable random number for him in the future. It is the very same problem. Btw. invalidating the whole procedure would lead to abusing this exit mechanism: a bad guy could pre-calculate an account that yields an error in the procedure. The random number provided by this procedure is supposed to be known to everyone (say, from time to time we insert it to the blockchain) and used to "break" the determinism. The random numbers the accounts provide cannot be precalculated, they are just outputs of rand() or smth similar. In principle, there should not be any "errors" in the procedure: the account first publishes the hash, and then (if required) the number itself. The error can only appear if the guy is deliberately cheating; but, in this case, he doesn't get nothing for it: his account is banned, and the procedure is repeated after some time. I'm writing this now in a more detailed way; will post the new version of the paper by tomorrow. |
|
|
|
Again on this "true randomization" issue. In general, what amount of randomization is desirable, i.e., how often should it happen? If not very often (e.g., several times a day), then the real world will take care of this (because nodes go online and offline, money are transferred, etc.).
I agree. I wrote the following to CfB: I do not think that is possible anymore. Preparing means you need to know 1440 blocks in advance which accounts you need. So, you need to build up the a whole forging graph of size http://www.wolframalpha.com/input/?i=28000%5E1440 (28000 accounts, 1440 blocks for effectiveBalance) [to get sure you cover all cases]. The leaves of that graph represent the entry points for the attacker's accounts. Then the attacker needs to create accounts at the right time to forge the next N blocks. That is like calculating the private key out of your public key. If this is not enough, then the following procedure is possible. First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try)..
The problem here still is: who belongs to X if one of X is offline and who decides that? It is the very same consensus finding problem that block generation tries to solve. Well, with our forging procedure we obtain a consensus about who are the best X account w.r.t. the inverse weights, right (and the network then delegates to the best of the best the right to create the next block)? Then we just ask those best accounts to provide a random number for us. The idea is that if there is at least one "honest" guy among them, then this random number will be "truly random", even if all the others try to cheat. |
|
|
|
I figured out how to choose a random number deterministically within the decentralized Nxt network, where someone with 90% of the forging power as determined by proof of stake could only get lucky enough to manipulate this number 1 in a billion years at a rate of 1 block per minute. It would only require 300 forgers online, we currently have more than this. If we have get 500 forgers participating this number drops to someone with 90% of the forging power only getting lucky enough 1 in approximately 40 Octillion years.
And it scales nicely and it's fast, could easily be done. No proof of work required. Could probably cut down how long you lock up funds and changes to forging power to 10 blocks, say 60 if you want to be safe. I'm telling you, it's big. Already run it by one person, would like to run it by others.
If I were working for Nxt it'd be a different story but I don't want to just put the whole idea if I can get a bounty on it. If I can proof this, is there a bounty on it? Or you guys already have a work around in mind that could achieve this?
I proposed a randomization procedure a few days ago, here: https://bitcointalk.org/index.php?topic=345619.msg5838370#msg5838370Is your solution similar? |
|
|
|
There is no reward - the wrongdoer is simply forbidden to forge for quite some time (this I mean by "penalty"), and the procedure is repeated (immediately or after a few blocks).
Reward == to be able to forge a lot of blocks in a row. If the math model works (=enough randomization), this won't happen anyway, for probabilistic reasons. Then, if the bad guy decides to cheat this randomization procedure, for each attempt to do so he would have to sacrifice one of his top accounts, while gaining absolutely nothing for it (because the procedure will be repeated soon, and one of his top accounts is unable to forge). |
|
|
|
There is no reward - the wrongdoer is simply forbidden to forge for quite some time (this I mean by "penalty"), and the procedure is repeated (immediately or after a few blocks). @CIYAM, @CfB, @ChuckOne, ..., - can you comment on this randomization procedure I proposed on the previous page? First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try).
Won't work if the penalty < reward. |
|
|
|
@CIYAM, @CfB, @ChuckOne, ..., - can you comment on this randomization procedure I proposed on the previous page? First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try).
|
|
|
|
But, "the past" is known to the attacker at the current time, so why does this add randomness?
Yes - but if they have to check "all tickets" then provided the information is *different per ticket* then it will take "more effort" to do this checking. If you add in hash rounds the amount of time required to do all the checking might just end up being *not worth the effort*. So, this depends on the assumptions about the processing power the attacker has? Then one never knows... |
|
|
|
Another thing that springs to mind wrt randomness would be looking at "the past" (so say the payload hash of the block at height x - 1440).
Other things to "add entropy" might be the account's public key and their balance at whatever point in time and one could even require "hash iterations" or the like so that "trying to calculate" ticket values for all possible accounts in order to try and game might be more costly that the time it takes to forge a block.
But, "the past" is known to the attacker at the current time, so why does this add randomness? |
|
|
|
It's all fine to say "let the market decide" but you do know that in many countries "it is illegal to squat on domain names" (countries like say Australia).
Also look at .bit - how well has that done?
Basically the squatting has pretty much ruined any impetus it had at all.
I tend to agree with CIYAM in this discussion. |
|
|
|
|
Again on this "true randomization" issue. In general, what amount of randomization is desirable, i.e., how often should it happen? If not very often (e.g., several times a day), then the real world will take care of this (because nodes go online and offline, money are transferred, etc.).
If this is not enough, then the following procedure is possible. First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try)..
For now, I don't see how this can be gamed...
|
|
|
|
crazy wall 0.00007000 1,581,716.425 110.72015
It seems that some rich guy is acting against price drops: the same wall was at 0.00004, then at 0.00005, it just moves... |
|
|
|
Alguem que está acompanhando mais de perto poderia me falar como está o desenvolvimento da moeda?? Está andando pra sair mesmo, ou estão meio que enrolando?? Investi nela mas estou acompanhando bemmm de longe  Pelo que entendi, os desenvolvedores estao falando pouco, mas trabalhando muito. Bem, devemos ter noticias no dia 23 de marcco, quando a nova versao do whitepaper deve sair. |
|
|
|
I had a similar idea: the forger is determined in the same way, but then, say, 10 accounts who are "next in the queue" append some random numbers (determined by them) to the new block. Or not the next 10, but, say, those with the weight "close" to the winning one. If this is doable, then the "bad guy" needs to control really a lot of top accounts, because even 1 account not under his control and which is allowed to insert the number, will completely mix up the things.
I would favor forgers of previous blocks. Say, we are currently at block X. At X-1440, subsequent forgers must commit random numbers until, say,10 numbers are collected. These 10 numbers will in part determine the forger of the block at X+20. One big issue I see with that is: what forgers are allowed to include their number? That is a consensus problem, too. Who decides that? For example, those forgers whose inverse weight differs from the winning one by less than something. |
|
|
|
Haven't given up yet. Is there a reason this wouldn't reliably get random numbers into a decentralized network?
3 forgers at once, first 3 from the list of next forgers in line to forge.
A picks a random number, signs it, and sends to B
B picks random number, signs it, and sends to C
C picks random number, signs it, and sends to A
Who decides who are A, B and C? Hint: you do not know if an account will forge even when it is due to do. I had a similar idea: the forger is determined in the same way, but then, say, 10 accounts who are "next in the queue" append some random numbers (determined by them) to the new block. Or not the next 10, but, say, those with the weight "close" to the winning one. If this is doable, then the "bad guy" needs to control really a lot of top accounts, because even 1 account not under his control and which is allowed to insert the number, will completely mix up the things. |
|
|
|
Do I understand correctly that there is concern about the fact that the "randomness" is actually pseudorandomness (i.e., it is deterministic, but not predictable)?
In this case, we can just put some "true randomness from the real world" in: take some parameter which is rapidly changing in time and is not controlled by one person or entity, and use it as an additional randomizer. For instance, total amount of all transactions (and/or fees) in the previous block could act as this randomizer.
We can't coz an entity with a lot of computing power will be able to game the system. Ok, not this. But maybe there are other parameters of the network that change rapidly and that no one can effectively control (number of forging nodes, ..., whatever)? |
|
|
|
|
Do I understand correctly that there is concern about the fact that the "randomness" is actually pseudorandomness (i.e., it is deterministic, but not predictable)?
In this case, we can just put some "true randomness from the real world" in: take some parameter which is rapidly changing in time and is not controlled by one person or entity, and use it as an additional randomizer. For instance, total amount of all transactions (and/or fees) in the previous block could act as this randomizer.
|
|
|
|
Not sure. The next forging queue (that one 100 blocks in the future when each of the 100 forgers forge) might not favor our 50% account.
Probability of that is very-very small. But, anyhow, the number of blocks generated by this 50% account will be strongly reduced, so this would encourage splitting. |
|
|
|
|
Show Posts
