Nxt devs have released a testnet version of the next release so the release notes on two phased transactions (phasing) also released:
Phasing.
Phasing API calls:
ApproveTransaction, GetAccountPhasedTransactions,
GetAccountPhasedTransactionCount, GetAssetPhasedTransactions,
GetCurrencyPhasedTransactions, GetPhasingPoll, GetPhasingPolls,
GetPhasingPollVote, GetPhasingPollVotes, GetVoterPhasedTransactions.
A transaction of any type can be phased by adding a phased=true parameter and
an appropriate set of phasing parameters. Phased transactions are accepted in
the blockchain immediately (subject to all usual validations), but are executed
only at finish height, if still valid and if the required quorum has been met.
If not approved, or not valid at finish height, they remain in the blockchain
but are never executed, and any changes they caused to the sender unconfirmed
balance are reversed, except that the fee is not refunded.
In addition to the voting models available in polls, phased transactions can
use a whitelist of accounts (max 10) allowed to vote for the transaction.
It is possible to vote for (approve) up to 10 phased transactions with a single
approval transaction. This transaction will be accepted in the blockchain only
if all phased transactions it is voting for are already in it.
Voting multiple times is allowed but has no effect on vote counting, votes
after the first vote from each account are ignored.
It is also possible to make any transaction phased without needing voting for
approval. This can be used to create transactions with deferred execution.
Pay on reveal secret is supported as a voting model for phased transactions.
When this voting model is used, the phased transaction must include the
hash of a secret chosen by the sender (up to 100 bytes long), and an approval
transaction for it is only accepted if it includes the secret that results in
this hash. It does not matter who the sender of the approval transaction is,
unless a whitelist is also defined. Supported hash functions currently are
sha256, ripemd160, and sha256 followed by ripemd160. The codes to specify them
as parameters are available from the getConstants API.
Finally, it is possible to make a phased transaction that is released or
rejected not on the basis of voting, but based on the presence of other
transactions (linked transactions) in the blockchain at its finish height.
To do that, up to 10 phasingLinkedFullHash transaction hashes can be defined
when creating the phased transaction. Note that this does not create a
dependency between the linked transactions themselves. This feature can be
used to implement atomic execution of transactions of any type, provided the
phased transaction is phasing safe. Transactions already in the blockchain
before the acceptance of the phased transaction can also be linked, as long
as they are not more than 60 days old, or themselves phased transactions.
The deferred execution with no approval needed, pay on reveal secret, and
linked transactions features are currently accessible using the API only, the
UI for them will be completed in a later release.
Similar to voting, the phasing data for phased transaction that finished before
the last trim height is also deleted and only the aggregate approval results
are kept.
The fee for making a transaction phased depends on the voting model selected.
For by-account voting with no minimum balance, or no voting needed, it is 1 NXT
in addition to the regular fee for that particular transaction type. For voting
that depends on voter balances, the additional phasing fee is 20 NXT.
The fee for approving a phased transaction is 1 NXT for each phased
transaction included in the vote.
Full message here: https://nxtforum.org/nrs-releases/nrs-v1-5-0e/ (remember, testnet version only at this stage) |
|
|
|
Account Control will be in NRS 1.6  Yes, this is part of account control and is planned for 1.6, Petko is working on it.
|
|
|
|
This is good thread  |
|
|
|
What happened here is that some unqualified people just took their favorite part the parts relevant to Nxt from the paper and present it as FACT Vitalik Buterins opinion.
FIFY Reread the OP and title. |
|
|
|
|
Maybe he's a Dutchman whose really good at imitating russian, lithuanian, latvian and belarus-style and now his life is really easy?
***MIND BLOWN****
|
|
|
|
Let the experts evaluate and criticize and withhold your opinion until something reaches some sort of expert consensus.
Isn't this thread a step towards this? |
|
|
|
I don't know, why not ask some of the Dutch Nxt guys?  |
|
|
|
Potential for expiring voting tokens in version 1.7, BUT... Sorry, no additions anymore(for 1.5.x at least), we're going to release! In 1.7 / further releases some additions to VS possible( features for 1.6 already considered and mostly implemented). *snip* ...version 1.6.x features have already been decided and have already been implemented. Nice I think artificial delays are being used to allow bugs to emerge and be fixed between big feature updates in each release that we will be going through for a while yet. +1 |
|
|
|
Does it differ from the Ripple protocoll now ?
What always put me off about the Ripple protocoll is that validators have to trust each other and that those trust-lines have to be set manually.
Not only do validators need to trust each other, users also have to set trustlines to actually start using Ripple.
I mean sure that'll most likely make the network very secure since noone can just come an spread false data but it just doesn't right. It's not really decentralized either.
It still looks decentralized if you managed to pick validators that won't collude. It's more secure because in Bitcoin a successful attack will invalidate some transactions, in Ripple/Stellar the attack will only break consensus putting the network on hold. What would you prefer - to see your money goes to another wallet or to see that system stops working? Would picking validators be left up to the user or form part of the protocol? |
|
|
|
The high quality, in depth research you do before you post is showing through again The message you posted is from the admin of Bitt rex, an exchange. The attacker was CynicSOB who Nxters invited over to attack Nxt, even set him up on the testnet and let him have as much testNxt as he wanted to try and recreate the attack. That was mid January. Cynic has so far failed to recreate this attack in Nxt, even in the benign environment of the testnet. Read the full thread here: https://nxtforum.org/testnet/nxt-security-audit-attack-simulations-on-testnet/Apex coin can only be taken as the poster child of POS if GlobalCoin or Vootcoin can be taken as the same for POW |
|
|
|
Yup...the next Nxt release ( cheesy ) will allow a 40 kB payload per message, either clear or encrypted. Hmm..... Really? What would that do to the blockchain (i.e., bloat)? the blockchain will become more and more heavier How to implement Blockchain 'trimming' has already been discussed and also referenced in the voting section of NRS version 1.5.0e. I think if you want a message to persists beyond each trim, there will be higher fees. But not sure yet so don't quote me |
|
|
|
But the first Gen 2.0 platform to host torrent sites anon will jump into the Top 3 market cap.
Hosting torrents sites could be a big deal for crypto coins. Actually it is already possible using Nxt messages to create apps hosting torrent links. This is where Nxt needs to go... or some else will soon. Create "scratch pad" temporary storage that will host html + backend custom data structure... All controlled by a Java plug-in... You are basically making the klunky Tor Project irrelevant by hosting "hidden sites" on Nxt platform... With Ver 1.5 you can hack it by compressing data into permanent Arbitrary Message storage... (I believe SuperNET already uses AM storage a lot so there is competition for this limited resource). But you really need slightly more sophisticated p2p storage... Remember you are only hosting web site content, not competing with Amazon and Google like Storj... And you also need some form of micropayments to replace the millions $$$ torrent sites generate from ads... With Nxt it's 1 NXT (about $0.01) for everything... and that is very limiting. Torrents are less evil than the fat, rich Hollywood lawyers prosecuting random downloaders... While Hollywood posts record profits, the entire torrent space is under attack and in disarray = Big Opportunity Now you just need to find a dev, do the trustless crowdfunding using Nxt Monetary System and you'll be a millionaire by the end of the year |
|
|
|
Come-from-Beyond seems satisfied too In the paper - https://raw.githubusercontent.com/vbuterin/scalability_paper/master/scalability.pdf, the authors used Nxt algo as an example. It seems a confirmation of Nxt security (But I am not a expert) Example 3.0.2. The cryptoeconomically secure entropy source used in NXT[16] is de ned recursively as follows:
E(G) = 0
E( + ) = sha256(E()+V ( )) where V ( ) is the block proposer of
.
Assumption 3.1. For any time internal I, there exists some xed probabil-ity po(I) such that a node randomly selected according to the weight functionused to measure a cryptoeconomic state machine's Byzantine fault tolerancecan be expected to be oine for at least the next I seconds starting from anyparticular point in time with at least probability po.Note. We can derive the above assumption from an altruism assumption bysimply stating in the protocol that nodes \should" randomly drop oinewith low probability; however, in practice it is simpler and cleaner to relyonly on natural faults.Note. Combining the two uninuenceability criteria into one (\it is impos-
sible to increase the probability of P from p to p (1+k) without expendingat least b L k resources") is likely very dicult; it is hard to avoid having
ways to cheaply multiply the probability of low-probability predicates byonly acting when you are sure that your action will have an inuence on theresult.
......
Lemma 3.0.3. The NXT algorithm described above satis es the conditionsfor being a cryptoeconomically secure entropy source.Proof. To prove unpredictability, we note that the NXT blockchain pro-duces a block every minute, and so the update v sha256(v; V ( )) takesplace once a minute. During each round of updating, there is a probabil-ity 1 ...........
BCNext's idea not to provide the whitepaper to force an independent analysis has finally worked. Good, now this page can be turned. |
|
|
|
WOW, this is huge people!
What is so huge in that? Often developers talk about other projects. He even said Monero technology is cool, so what? You don't see a difference between "cool" and "cryptoeconomically secure"? |
|
|
|
|
Show Posts
Post copied across. 
)
