this coin needs new fresh air now
fresh air in the form of world record, ETA in 40hs from now |
|
|
|
All 400^k possibilities are very very likely to have less cumulative difficulty than the main chain, because 75% < 100%
You're not appreciating how the statistics work out here. 75% being less than 100% just means that the delay distribution is shifted to the right. But sampling from a huge number like 400^k means you'll get much further into the left-tail of this shifted distribution, so you can easily beat the unshifted average. Ok, this is a different attack vector. The math is tricky and it's probably not worth it: we agreed that if you have that stake you can attack without hashrate! still, for the sake of argument ( http://xkcd.com/1432/): ok, but each block is independent, you are in disadvantage on every block, and you want more cummulative difficulty after k blocks. On every block that you select any account of yours that is not the one with lowest delay, you get farther away from your goal expecting to offset that with "good luck" in following blocks. With a large sample you can expect to get lucky, but on each block that you don't use the optimal (minimal delay) account you need even more luck to catch up. I still think that beating the unshifted average is not that easy and it could happen that in all your branches you end up with less cummulative difficulty. In NXT the target gets larger as time since last block passes by, so doing a simulation would be much easier than calculating. Still, my point is: if you have that stake you can attack without hashrate! Regarding the other attack that someone posted a link to: they mention bruteforcing the private key in order to get a public key that will forge in the future. You can forge 1440 blocks after setting the public key, and you can't reorg more than 720 so it doesn't work. If you remove that limitation, yes, it's an attack that requires big amounts of hashrate. So, I concede there are attacks that utilize lots of hashrate. However, I'll say it again: if you have that stake you can attack without hashrate! |
|
|
|
Alice wants to attack the blockchain.
She owns private keys of 400 accounts totalling to 75% of the stake.
She is planning to rewrite the history from block 5'000.
Legit chain is at block 5'300 (less than 720).
Cumulative difficulty at block 5'000 is 8'000'000.
Cumulative difficulty at block 5'300 is 9'000'000.
How many SHA256 operations in average it's necessary to do to find a branch where cumulative difficulty at block 5'300 is at least 9'000'001?
Hint: Blocks from 5'000 to 5'300 were forged by 100% of the stake.
Without a detailed further explanation of the so called Nothing at Stake 'problem', further discussion is quite useless.
Well, first of all, if Alice has 75% of stake, then the simplest attack would be in the future: just fork and keep both branches as equal in cumulative difficulty as possible, never letting one get too far ahead of the other. Thus, there will never be consensus. In fact, for this attack, one needs only 51%. Or even much less if other stakeholders work on both branches. But for argument's sake, let's consider the original challenge. The math is pretty tricky, but let me sketch the rough idea of an attack. The regular history developed by picking, at each block, the minimum delay among the stakeholders. This delay has some probability distribution and some expectation which is the average block interval. If you reduce the stakeholders to 75%, then the distribution will shift to longer delays. BUT, Alice is not limited to single-step extensions. She can compute a huge tree of all possible k-step extensions. With 400 accounts, this tree will have 400^k leaves, and require roughly that many SHA256 computations. But for large enough k, one would expect one of these leaves to have a path with an unusually small sum of k delays, less than k times the average delay for all stakeholders. The question is, how big a k do you need. And this obviously depends on both the number of accounts, and percentage of stake held by Alice. For the given numbers, I expect a small k like 4 would suffice, but this needs to be worked out in detail. In that case, to cover 300 blocks, you'd need to compute 75 trees of 400^4 leaves each, for a rough total of 75*400^4 = 1.92*10^12 SHA256s, well within the realms of feasibility. For k larger than 6 this attack would become quite infeasible, but it's not clear to what percentage of stake that corresponds, unless one goes through the math... This doesn't make sense to me. All 400^k possibilities are very very likely to have less cumulative difficulty than the main chain, because 75% < 100% The attack will probably fail. This attack does not make sense to me. However, imagine she had 51% some 200 blocks ago, and sat on it, without staking. Then, she can stake them on a parallel, attack chain. The attack chain will have stake 51% > 49%, so it is very very likely to succeed just doing it the normal way, minimizing the delay, which requires only minimal hashrate. Be it 6, 200, or 720 blocks. This attack makes sense and does not need hashrate. |
|
|
|
any NEW user would download MY CHAIN.
Bob has a client that only downloads valid chains. He sees 99 nodes with invalid chain and 1 node with valid chain (more stake involved). Which one does he download? My node knows which chain is valid, the one with more stake involved. You need to build a valid longer chain without majority of stake. Which, as we are discussing, requires extreme amounts of computing power (calculations pending). wtf? No! Nothing requires extreme amounts of computing in POS. That's the point of POS. The attack would be possible, but it is not only because checkpoints |
|
|
|
That vote is directly proportional to the amount of tokens they own. Technically (assuming all stakeholders vote) you need 51% of the currency supply to have total control of which delegates get elected.
That assumption is not safe. They should show in the block explorer how much % of the supply is actually being used to vote. I'd bet not much. A couple of questions, since I haven't read documentation or code on DPOS: 1) How do you know the 101 are actually different people? most coins don't have 101 people who care. 2) Is the voting, electing, and the revoking of the right to be one of the 101 done automatically by the protocol? or is there human intervention (other than the voting)? 3) If I get 51% of the % of the supply that actually votes (which I bet is much less than 51% of the total supply) at any time in history (after the last update), then I could vote on the main chain, and then vote differently in an attacking chain. Then I could rewrite everything. Couldn't I? 4) If delegate N decides to ignore blocks N-1 and N-2 and build on block N-3, and then delegate N+1 builds up from block N, then blocks N-1 and N-2 would be skipped and considered missing? So 2 delegates could collude against the other 2? Now extend that 2 to 6 or to whatever number of confirmations are used... |
|
|
|
why do you think there are many SHA256 operations involved?That is what is required to calculate a longer chain that stands a chance of being accepted as legitimate. The better chain needs to almost mirror the honest one in terms of certain properties.
The retargeting algo in Nxt plays an important role in this. how would a large hashrate benefit an attacker?See above. We are talking about POS, right? and specifically you are talking about NXTs implementation, right? The security of all POS coins is based on the premise that getting 75% of stake is hard, and it's not based on any brute force calculation of SHA256 hashes. Please explain exactly how would a large hashrate benefit an attacker?No special hashrate (more than the number of accounts per second), is required to create the main chain, and also not any special hashrate would be required to create an attacking chain. You only need the staking power. Regardless of the baseTarget ajustments (which I seen in the Java code for NXT v1.3.3, not in any documentation because reading NXT docs is terrible, you never know what is actually implemented and what not), if you have more coins than those that were at stake then you can rewrite up to 720 blocks. No need for much hashrate. This applies to all POS implementations that I have seen. |
|
|
|
2. It does not bother to mention how many calculations are needed to secretly build a valid longer chain with a small stake in a specific PoS system. This is like saying sha512 algo can be cracked, without calculating how many tries one needs to crack it...
I'm eagerly awaiting a revised version that calculates needed computing power to n@s-attack, let's say current version of Nxt. The tedious details that would go into trying to figure out precisely how NxT would be attacked don't resolve the problem that the paper is talking about, and more importantly, it's not the responsibility of us to put forward the security model. The 'tedious detail' is what your argument is and relies upon. Until you provide this and show there is a problem, then there is no problem as it hasn't been articulated. It is in the same camp as stating categorically "The numbers 3 and 5 can never be used to give a sum of 23" and then not even attempting any calculations to check you are correct, as it isn't your "responsibility to put forward summation models". Below is paraphrased from Come-from-Beyond and is a question that was posed in May 2014. It has still gone unanswered (publicly at least, the silence of the initial Nothing at Stake zealots is telling I think). Alice wants to attack the blockchain. She owns private keys of 400 accounts totalling to 75% of the stake. She is planning to rewrite the history from block 5'000. Legit chain is at block 5'300 (less than 720). Cumulative difficulty at block 5'000 is 8'000'000. Cumulative difficulty at block 5'300 is 9'000'000. How many SHA256 operations in average it's necessary to do to find a branch where cumulative difficulty at block 5'300 is at least 9'000'001?Hint: Blocks from 5'000 to 5'300 were forged by 100% of the stake. Without a detailed further explanation of the so called Nothing at Stake 'problem', further discussion is quite useless. Bump. I am genuinely interested in the answer, I can only assume you are all busy with your calculators right now. I can wait. My follow up question would then be... Would doing this many SHA256 operations be at no cost? If you still believe this would be free, check would it be possible to do. i.e. what is likelihood that you can do this many SHA256 operations to recalculate a better chain within the 720 block time limit? There is no answer because the question makes no sense. first answer this: why do you think there are many SHA256 operations involved? how would a large hashrate benefit an attacker? it's not a matter of hashrate, it's 300 blocks * 60 seconds * 400 accounts = 7200000. Hashing that many SHA256 takes less than one second on a modern cpu. The question is not clear because it talks about "the stake", but what is "the stake"? the total amount of coins? or the amount of coins actively forging at the given time? were your 400 accounts forging on the main chain at block 5000 or not? If you control more coins at block 5000 than those that were forging at block 5000 then you can simply rewrite everything. |
|
|
|
You just have to buy 51% of the currency or track down majority of stakeholders and compromise their private keys. Much cost free
lots of people seem to believe this (I think it's even mentioned in Sunny King's PPC paper), but it's not accurate: you need 51% of the actively staking coin-age. That's much, much, less than 51% of the currency. I had some ideas to help fix this, I'm working on it. Peercoin PoS is not the same as NXT PoS, the latter doesn't use coin-age. it doesn't matter, it has the same probblem, just replace "coin-age" by "coins". form their "whitepaper" (actually a wiki): tokens must be stationary within an account for 1,440 blocks before they can contribute to the block generation process this means all coins that are used for transfers cannot be staken and do not count toward the total of which you need 51% moreover, lots of holders do not stake, so it's not 51% of coins, it's 51% of coins being actively at stake ...and it get worse if you consider NXT has punishments for not staking... |
|
|
|
You just have to buy 51% of the currency or track down majority of stakeholders and compromise their private keys. Much cost free
lots of people seem to believe this (I think it's even mentioned in Sunny King's PPC paper), but it's not accurate: you need 51% of the actively staking coin-age. That's much, much, less than 51% of the currency. I had some ideas to help fix this, I'm working on it. Peercoin PoS is not the same as NXT PoS, the latter doesn't use coin-age. it doesn't matter, it has the same probblem, just replace "coin-age" by "coins". form their "whitepaper" (actually a wiki): tokens must be stationary within an account for 1,440 blocks before they can contribute to the block generation process this means all coins that are used for transfers cannot be staken and do not count toward the total of which you need 51% moreover, lots of holders do not stake, so it's not 51% of coins, it's 51% of coins being actively at stake |
|
|
|
If you reverse PoS and PoW in your post, then your post would be 100% accurate and correct  Doesn't it cost nothing to attack a PoS coin? While you must use actual resources to attempt to attack a PoW coin? Exactly, I thought attacking PoS coin is much more cost free (next to nothing) than attacking PoW coin. You just have to buy 51% of the currency or track down majority of stakeholders and compromise their private keys. Much cost free lots of people seem to believe this (I think it's even mentioned in Sunny King's PPC paper), but it's not accurate: you need 51% of the actively staking coin-age. That's much, much, less than 51% of the currency. I had some ideas to help fix this, I'm working on it. |
|
|
|
whats up with the furry wallpaper man
It's funny how that's still news. it was new to me... I went wtf? Nice analysis, the thought I'd like to add is that even if you had the most possibly efficient x11 implementation and it still runs cooler than, say, scrypt, then you should still prefer scrypt over x-whatever. If the most optimized implementation is cooler, you are wasting power in keeping all the system working compared to scrypt, so you get a worst "network security / watt spent" ratio. |
|
|
|
Happening now elsewhere in outer space the Rosetta 12-Earth-year journey to comet 67P/Churyumov-Gerasimenko. See the spacecraft live feeds landing on the comet. http://rosetta.esa.int/Their promo short sci/fi video is cool: http://vimeo.com/109903713btw: I have seen your email, I just don't know what to answer yet back on-topic: at current rates, the superblock should come next moday (of course this is just an estimate and may change depending on how fast blocks are found) |
|
|
|
Time to buy some RIC! Which exchange has the highest volume ?
btc38 and Poloniex |
|
|
|
that is bullshit too , crypto asian proof of developer , code speaks for itself, when it is put on github all changes are there for anyone to evaluate anytime people who don't understand code should not ever be evaluating it, also giving your real name is not necessary to be respected in the world of cryptocurrency anyone who gives crypto asian any credability is making a mistake, imo honestly if i did not like riecoin so much that fact that crypto asian is involved even at a distance makes me not want to be around. The original creator goes by a real-life name of Pablo Gatra. And he has decided to move on with general consensus that the improved Riecoin v0.10.2 is for its own best future interest. While you'll be measured by what is done and the consequence of yours own only.
Please don't distance yourself in the fragments of Riecoin past.
Thanks for your support, but my real name is actually Pablo Carbajo, Gatra is a nickname, and I have submitted to Crypto Asian's POD last week. Will publish this soon. I kind of agree: it shouldn't be necessary, however I thought it was something that could only be positive towards respect and credibility, or null if you don't believe it, but I never thought it could work against it... I went to cryptoasian because I think he was the first one that did the verification thing. |
|
|
|
Nah, the total supply didn't change. The average supply per day hasn't changed. Difficulty adjustments were and will still be every 288 blocks. The only change is that, once a week, one block will have more difficulty (will take more time be found) and will have a larger reward. And to compensate for this, the 287 blocks that surround it will have a little less difficulty (will come every 2min16sec instead of 2:30) and have a slightly smaller reward. So everything is kept fair and balanced. To point of this is that the block that is more difficult and takes a few more minutes will have larges primes, thus breaking the world record. This won't benefit anyone in particular: expected return for miners will not change. The objective of this is breaking the world record for the largest prime 6tuple. Just wanted to make this clear, I'll try to stay away from this thread from now on. Cheers! Gatra |
|
|
|
junk keeps freezing and crashing. Old wallet was bad, new one is worse.
New wallet is as bad as, or as good as, the previous one because nothing changed except the superblock code, which is not being executed and won't be until next week. If you have crashes, please run using the -debug option and send me the debug.log file after the crash and I'll try to fix it (you may want to anonymize it before sending). |
|
|
|
If you had followed the Riecoin development from the beginning then you should know moving forward by the hardfork is good. I'm here from the beginning as you may see. And hardforking is a bad practice. cat << EOF | patch -p0
+++ src/makefile.unix
@@ -38,6 +38,7 @@
-l boost_filesystem\$(BOOST_LIB_SUFFIX) \\
-l boost_program_options\$(BOOST_LIB_SUFFIX) \\
-l boost_thread\$(BOOST_LIB_SUFFIX) \\
+ -l boost_chrono\$(BOOST_LIB_SUFFIX) \\
-l db_cxx\$(BDB_LIB_SUFFIX) \\
-l ssl \\
-l crypto
EOF
sha1sum -c << EOF
9928c39fc2d593e2e83a55e51eecf7b9608c78fc *src/makefile.unix
EOF I stay in the original network. Decide for yourself or someone will decide for you. I'm surprised by this. This was in discussion in this thread for a long time and I went ahead because I didn't see any opposition. Some doubts, which are natural, but never strong opposition and a lot of support for the fork. BTW, that patch you submitted in February is not needed if you compile with gitian, maybe you needed it because you were using the wrong version of boost. Also, thanks to a little mistake I made, we actually have one more week before the actual fork takes place. This gives everyone more time to update, rendering the "sudden move without notice" point obsolete. Those of you who want to stay on the old fork would like to keep in mind that most (>99%) of the miners already are on 0.10.2, meaning that you'll be left with a high difficulty. Now that I think of it, there may be some interest on people who hold RIC to keep the old fork alive and have it accepted on an exchange: they would be allowed to dump their coins from the old fork without affecting their holdings on the new fork. You have my blessing (if it means anything to anyone), but I won't be supporting both forks (by this I mean fixing bugs and generating new binaries); only the fork that the majority already accepted. Applying new commits from one fork to the other should be very easy though. |
|
|
|
The original creator goes by a real-life name of Pablo Gatra. And he has decided to move on with general consensus that the improved Riecoin v0.10.2 is for its own best future interest. While you'll be measured by what is done and the consequence of yours own only.
Please don't distance yourself in the fragments of Riecoin past.
Thanks for your support, but my real name is actually Pablo Carbajo, Gatra is a nickname, and I have submitted to Crypto Asian's POD last week. Will publish this soon. |
|
|
|
In the source code it says the fork is after block 159000. See isAfterFork1(). In a previous post Gatra stated that the first block in the new fork is 156672 which doesn't match with the source. Am I overlooking something? Of course, you should trust the code and not my post. I first thought about doing it near block 160000 and then decided to do it near 156000, but forgot to update the code. Sorry about this, the fork will be after block 159000. The first block that will actually break the old protocol will be 160704 (this is the first one that satisfies that it's >159000 and also the isInSuperblockInterval condition) and the superblock will be 160848 (the first one >159000 that also isSuperblock). So, we have one more week. Only the post where I wrote the block number is wrong. Wallets are compiled using gitian, which ensures that the source in git is the one that gets compiled, so we can be sure that all 0.10.2 binaries are ok. |
|
|
|
Yes, the superblocks will have higher difficulty and the record holder would have the highest, however if more than one of them share the same top difficulty you'll have to decide by comparing the value of the hash of the block's header (in the bit order that is used to generate the base prime), or just compare the base prime for those.
Ok, that should work directly then, I cache the primes in the explorer db, so it should just be a matter of sorting. Beta version: https://chainz.cryptoid.info/ric/halloffame.dwsWill probably need to tweak stuff once the first super-block happens Speaking of which, maybe just having the blockheight of the next super-block in the RPC getinfo API could be nice for a count-down. I could hard-code it in the explorer, but this would be more fragile, and it could be nice to show the countdown in the Qt client as well. Great work! I'll do it: it would be helpful to see in the Qt if the superblock is happening, so the user knows that any tx could take a little longer than usual. |
|
|
|
|
Show Posts
