Well - in a POW chain, you see which chain has the most WORK put into it. This is independent of anyone. You just sum it up and choose the one with the most.
Well - in a POS chain, you see which chain has the most STAKE put into it. This is independent of anyone. You just sum it up and choose the one with the most. simple as that. I'm sorry - It's not. My INVALID chain has just as much stake put into it as the VALID one. I bought accounts that are empty now but were full of coins sometime in the past.. (Or hacked an exchange to get the keys to their now empty wallets etc..) Nxt will have a concept known as economic clustering, you join the chain with the largest economic cluster when you first join the network. But it won't be included before the Christmas so we can discuss in future just prior to release. Or there is an Economic Clustering sub forum in the Whitepaper section of nxtforum.org. As discussed above, the history attack (have an old account(s) with a majority of stake and rebuild a better chain) doesn't work (in Nxt). As I said before, Nxt security is layered and interlocking (not all elements active at the moment) and I am sourcing and checking a complete answer for Dumbfruit above. The approach is too simplistic to work. Come-from-Beyond is happy for everyone to sell their historic passphrases as this is not a threat. N.B there are no anti-clone traps in Nxt anymore, the post is from May. Never give away your historical passphrases.
Delete you historical passphrases.
No need. I'm afraid I'll be forced to reveal the last anti-clones trap to explain why "nothing-at-stake" is just a buzzword and doesn't actually work. Feel free to sell historical passphrases. I'm just waiting for D&T's reply on the problem about Alice with 75% of the stake. I was always asking for details of such an attack, coz when one is trying to explain the details he sees that such the attack requires enormous computing power. |
|
|
|
Most average crypto users don't even understand NXT, how will general society?
Most average internet users don't even understand tcp/ip, how will general society? ... |
|
|
|
So they said this was the NXT big thing, by far the best crypto 2.0 bla bla bla, I plow in this summer and what happens? Bitshares doubles, Counterparty quadruples, and NXT? Only went down, 2 cents a fucking coin. 0.00004500 btc now. All time lows. Lost 70% of my money!
Should I sell it all, hold on, or buy more?
I think you should sell. How much do you have? Post you're account and I might make you an offer, depending on how much you got. |
|
|
|
A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).
I wouldn't be wrong to suppose no math will follow to back this statement, would I? I say as much in the quote. Though, an FPGA should be an order of magnitude faster than a General-purpose computer (or even PoW hasher) for that type of problem. The discussion I saw estimated that recalculating a better chain to attack Nxt would take the current bitcoin network hashrate several times the age of the Universe to do. I wouldn't like to comment but I haven't seen any advances on that which are backed by any calcs. You would also need to calculate this attack chain in 720 blocks otherwise it would be rejected. |
|
|
|
A bank such a JP Morgan with a FPGA super computer can conceivably do it (without figuring out how many operations are actually required).
How can you be so sure, should I take you at your word. Try this one.
https://nxtforum.org/proof-of-stake-algorithm/forging-2088/msg35543/#msg35543It is also in the whitepaper section. Here is OP of BaseTarget adjustment Algorithm without any following discussion. I'd argue the discussion is more illuminating. mthcl is a Maths Professor on sabbatical and has spent many hours looking at the Nxt algos, suggesting this improvement. Sabastian256, a Maths Phd, did the required modelling that mthcl needed throughout the thread. Blind Shooter/Retargetting you will have to log in for if you're interested, it is in the same sub forum. Some thoughts about the BaseTarget adjustment algorithm, described here. In more mathematical terms, this algorithm dynamically readjusts the rate of the Exponential random variable which is approximately the time until next block, to ensure that #[blocks per period of time] remains constant regardless of how much stake is actually forging. The algorithm currently in use can be described in the following way (R n stands for the rate of that Exponential random variable at time n): __________________________________________________ R 0=1; Let X be an Exponential random variable with rate R n (one may put X=(1/R n) ln U, where U is a Uniform[0,1] random variable) if X ≥ 2, then R n+1=2R nif X ≤ 1/2, then R n+1=R n/2 if X ∈ (1/2,2), then R n+1=XR n (note that XR n = ln U, so XR n is an Exponential(1) random variable) ___________________________________________________ The idea was R n should fluctuate around 1, so we'll have one block per minute in average. In fact, it turns out that this is not the case. Additionally, with this algorithm the rate occasionally becomes rather close to 0, leading to long intervals between the blocks (note that the expectation of an Exponential(r) random variable equals 1/r). The first problem (average rate is not 1) is easy to correct by a simple rescaling, but the second one (occasional very long block time) is more serious, since it is an inherent feature of this algorithm. So, I propose a modified version of this algorithm. Let γ ∈ (0,1] be a parameter (γ=1 corresponds to the current version of the algorithm). Then (abbreviating also β=(1 - γ/2) -1) _________________________________________________ R 0=1; Let X be an Exponential random variable with rate R n (one may put X=(1/R n) ln U, where U is a Uniform[0,1] random variable) if X ≥ 2, then R n+1=2R nif X ≤ 1/2, then R n+1=R n/β if X ∈ (1,2), then R n+1=XR n if X ∈ (1/2,1), then R n+1=(1-γ(1-X))R n ___________________________________________________ In words, we make it easier to increase the rate than to decrease it (which happens when X is "too small"). This is justified by the following observation: if Y is an Exponential(1) random variable, then P[Y<1/n]=1-e -1/n≈1/n and P[Y>n]=e -n, and the latter is much smaller, than the former. In other words, the Exponential distribution is quite "asymmetric"; even for n=2, we get P[Y<1/2]≈0.393 and P[Y>2]≈0.135. Now, to evaluate how does the modified algorithm works, there are two methods. First, one can do simulations. Otherwise, we can write the balance equation for the density f of the stationary measure of the above process in the following way: (1) f(x) = e -xf(x/2)/2 + β(1-e -βx/2)f(βx) + e -x ∫ f(s) ds + γ -1e -x/γ ∫ e (1-γ)s/γ f(s) ds, where the first integral is taken from x/2 to x, and the second one from x to βx. Here, f(x) is positive for x>0 and ∫f(s) ds (from 0 to ∞) = 1 (since f is a density). The problem is that I don't know, how to solve the equation (1). I mean, most probably there is no closed-form analytic solution, and I'm not able to provide a numerical solution because of my lack of knowledge how to do it  But, provided that the solution of (1) is available, the quantities of interest may be obtained in the following way: mean time to next block = ∫s -1f(s) ds (from 0 to ∞), and probability that the rate becomes less than ε equals ∫ f(s) ds (from 0 to ε) (observe that if the rate is ε, then one should expect the next blocktime to be roughly 1/ε). Hopefully, with some reasonable γ (say, γ=1/2), this algorithm would perform much better than the current one. So, I think that it would be important to investigate this (either by doing simulations, or by solving (1) numerically), since we'll probably need this retargeting algorithm even after the TF is in place. |
|
|
|
I have no idea what you're going on about.
I know  Search nxtforum for "BaseTarget adjustment algorithm" thread (leads to Blind Shooter algorithm and how it interacts with the retargeting algo, in the same thread) if you are genuinely interested. I get the impression no one on BTT is, they just listen to the echo and then repeat it. The above makes the Nothing at Stake 'problem' wishful thinking. At least in Nxt it does. |
|
|
|
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.
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. 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. it's not a matter of hashrate, it's 300 blocks * 60 seconds * 400 accounts = 7200000Which POS implementation is this possible in? It doesn't look very secure. what is "the stake"? The stake is Alice's coins, 75% of all coins in existence. were your 400 accounts forging on the main chain at block 5000 or not?Assume worst case for coin, best in favour of the attacker. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. How do you fix the past? If someone had 51% stake share at one point, what can you do to prevent him forking the chain? Relating to Nxt only: There is nothing to fix. The current inclusion of the retargeting algorithm makes it computationally very expensive to do a history attack. i.e. much much more hash power the bitcoin network currently has. The better chain needs to almost mirror the honest one in terms of certain properties. And you only have 720 blocks to calculate this in. Nxt has interlocking, layered security. A lttile bit being added at a time (economic clustering next IIRC). Transparent Forging isn't a switch that will be flipped one day, >50% of Transparent Forging is 'on' now. /Nxt But since you insist that POS = POS = POS, I don't think you'd be interested. |
|
|
|
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 am also looking forward to this in Nxt. But we won't see it. I have seen no one even attempt to do the calcs as I think those *capable* of doing the calcs already know what the answer will be... and the status quo around the N@S 'problem' suits their agenda. |
|
|
|
*snipped*
In PoS, it isn't the majority that decides, it's the majority stakeholder entity which once appeared can't be erased from history. Once the majority condition has been achieved ONCE, it will be available as an attack vector FOREVER. In PoW, a majority condition achieved ONCE will provide temporary reversible benefits and is very easy to spot and eliminate.
The cost to fork and keep up a hidden PoS blockchain is less than 5 USD a month for ANY coin.
The cost to fork and keep up a hidden PoW bitcoin blockchain is 30000000 USD a month.
Do you still need to compare the two?
*blahblah snipped*
Guys, could we focus on pure math instead of personal opinions?
|
|
|
|
Update from nxtforum.org, devphp's timeframe looks right. Hi folks,some updates and teasers: 1.3.3 is almost finished. Its up-front improvement is the **tease**.  For the 1.4 series we already decided a feature freeze: - Monetary System (UI in progress), mostly described here: https://bitbucket.org/JeanLucPicard/nxt/issue/136/monetary-system - Dividends Payment (awaiting UI, but is trivial) - Alias Deletion (awaiting UI, but is trivial) We assume having a workable UI for MS in 1 or 2 weeks and we are going to put this on the testnet as 1.4.0e. We further expect you, guys, to shit-test the MS as you did with the Asset Exchange; to test every single nasty corner and special case. The MS is a very huge feature update containing a lot of new transactions types, database upgrade and bugs (kidding but you never know, so it is your responsibility to find them). Do not forget to test dividends payments and alias deletion either. Leave your feedback here. Cheers, Chuck PS: active MS thread: https://nxtforum.org/monetary-system/monetary-system-documentation/ But CfB has hinted a few times about the 24th November... I'd be surprised if nothing was announced My 5 Nxt bet goes on his Sryrim mod as the distributed computing proof of concept using Jinn  |
|
|
|
Generally when you see a flare up of "Nxt is a sacm", "Nxt Pirates killed Elvis" and "Nxt ate my babies" type threads on here, you know a release is just around the corner  There has been a persistent smearing in the week before the last two releases, always from the usual suspects. But they only delay people in discovering what is happening in Nxt, I see a troll-turned-nxter every so often The 24th of November is Nxt's 1st birthday! so expect something special around then. There is a programme of a release roughly every 6 weeks, but you won't get much more precise than that. |
|
|
|
Where can we get info about this Lior dev?
I have got a feeling it is lyaffe, who has posted the Monetary System Documentation here: https://nxtforum.org/monetary-system/monetary-system-documentation/Nxt Currencies, which are coins built on top of Nxt through Monetary System, Documentation is here - https://bitbucket.org/JeanLucPicard/nxt/issue/136/monetary-systemExtract below: **** ## Currency Properties ## The currency entity supports several properties. Properties can be mixed and matched in various ways to compose the currency type. The currency type then controls the inner workings of the currency. The list of available currency properties is as follows: **EXCHANGEABLE** - the currency can be exchanged with NXT. Holders of the currency can publish an exchange offer specifying the buy and sell rate of the currency much the same as banks or currency exchanges publish their exchange rates . Each account can publish only a single exchange offer at any given time. Buyers and sellers can issue buy offer and sell offer to match published exchange offers. Unlike asset orders, offers are not saved, they are either executed immediately (fully or partially) or not executed at all. A match of exchange offer with a buy or sell offer creates an exchange entity which represents the transfer of currency units in return to NXT balance and causes the relevant account balances to update. **CONTROLLABLE** - currency property suitable for currencies which needs to track an external entity. It imposes the following limitations on the currency (1) Currency can be transferred only to/from the issuer account (2) only the issuer account can publish exchange offers. The idea is that the issuer account can issue a large (practically infinite) supply of units in advance, then transfer units to accounts or exchange units to reflect actual transactions which takes place in an external system. The large supply of units in the issuer account can be used for creating units out of nowhere to support features such as interest payments, dividends or other inflationary practices. **RESERVABLE** - means that the currency units are not issued immediately. Instead the currency issuer sets a block height at which the currency will be issued and a limit of NXT needed in order to issue the currency. Currency "founders" then lock their NXT to reserve their currency stake. If the amount of NXT needed inn order to issue the currency is not reserved before reaching the block height the issuance is cancelled and funds are returned minus fees. If the required reserve is allocated, the currency is issued and units are split between founders according to their proportional stake of invested NXT. In case of rounding, leftovers are sent to the issuer account. Reservable currency can be used as crowd funding tool where the issued currency units serve as stake in the issued currency. **CLAIMABLE** - currency units of resereable currency can later be claimed at the same exchange rate used when reserving the currency. The ability to claim a currency at a certain rate imposes some practical limits on the rates in which users would want to exchange it. However claimable currency can also be exchanged if only for the purpose of exchanging the whole currency supply so that the currency can be deleted. **MINTABLE** - currency can be minted using proof of work algorithms much the same as Bitcoin. Unlike Bitcoin mining, minting currency does not secure the network (this is done by NXT). Minting is used solely for creating new currency units and serve as the only mechanism to inflate the number of available units after the currency issuance. **SHUFFLEABLE** - this property indicates that in the future this currency can participate in coin shuffling. Properties are combined into an Integer bit mask designated as the Currency type. |
|
|
|
Coin Shuffling is part of Monetary System but won't be included until release 1.5. And I forgot to mention Coin Shuffling which was initially part of the Monetary System, it will not be in 1.4, but Lior is already working on it so very likely 1.5.
I don't even know who Lior is so we must have a new core dev |
|
|
|
i don't think there are many countries that officially allow using virtual currencies
but many countries are neutral about their policy
and they never declared anything about cryptocurrency if it is legal or illegal to use them
See bitlegal.io |
|
|
|
Jean-Luc confirms features (and possible features) for Nxt NRS version 1.4. *snip*
Monetary System definitely yes.Smart Contracts definitely no. Voting, and Phasing, not yet sure. Smaller features that will be included: asset dividends payment transaction, alias deletion transaction. Nxt has had Voting in the backend since Mar/April but we have a bottleneck around user interface devs right now (Wesley had to leave Jinn just to concentrate on the core). I guess that is why Voting is a maybe. |
|
|
|
|
Show Posts
