ARDOR Implements Game-Changing Features In New TESTNET RELEASE

Do you remember, back in the day, the first time you got your mind blown? I remember fondly how that happened to me with Nxt. That blockchain bastard repeatedly blew my mind – sometimes several times a week as it implemented feature upon feature at such a frantic pace. As such, I became a part of the embracing high-level community of Nxters and eventually surmounted the steep learning curve. It was totally worth it but afterward, I became hard to impress.

Released today, a brand new Ardor testnet finally made my brain cells feel a tiny bit explosive again, and it feels great! Not just a tiny bit, actually. The client that lands today is blockchain 2.0 evolution at its finest. Let the popular experts, and all the great blockchain visionaries do their talks. Jelurida just wrote it in code. Again. Let others continue to talk about TPS, ignoring scalability and security, we covered it already. And if you don’t know about Nxt, you should read up.

Ardor 2.0.4e

The Nxt and Ardor core dev team at Jelurida presents to you: New asset control features, multiphased smart transactions, a new API for creating regulated tokens on the decentralized Asset Exchange, and a transaction type that allows asset issuers to increase the number of asset shares in existence. All of this is an addition to all the existing core features and API.

This new Ardor testnet release resets the existing testnet and publishes a new Genesis block that tests the transition of data from Nxt to Ardor, based on a snapshot made of Nxt’s mainnet at block 1558000, shortly after the last JLRDA (IGNIS) exchange offer expired.

The testnet Genesis block timestamp has been set to 00:00 (midnight) UTC time
on Monday, Nov 6th, in order to allow time for users to setup nodes check their balances, and start forging.

From the Nxt blockchain has been transferred the following:

  • Accounts (public keys)
  • Account balances
    • IGNIS balances are based on NXT balances, divided by 2, plus JLRDA asset balances. Each of those has been additionally divided by 2, in order to allocate 50% of the testnet coins to developer accounts for testing purposes. There has been a 10% BITSWIFT asset sharedrop distributed proportionately to all IGNIS shareholders.
  • Account info (name and description)
  • Account properties
  • Account control settings for account control by whitelist with no minimum balance.
  • Account aliases transferred to the IGNIS child chain.
  • Janus, JanusXT, and ComJNSXT assets have been imported.
  • Monetary system currencies have been imported to the IGNIS child chain.
    • Only currency code and name. It will be up to each currency issuer to re-issue the currency with the appropriate properties and re-distribute it to users.

Lior Yaffe kindly asks all of us to check our accounts on Ardor and make sure everything has happened correctly:

If you are only interested in checking your balances head to the Jelurida public node , login using your existing NXT Mainnet account id (no need to login using passphrase) and check your ARDR, IGNIS and BitSwift balances. In addition, check your Janus asset balances, aliases, account properties, currencies, account control and all other entities migrated from the NXT Mainnet according to the changelog.

When you check, be aware that your IGNIS and ARDR holdings have been divided by 2 in this testnet release, so 50% of the tokens can be allocated to dev accounts for testing purposes.

Read all details here.

This was to be expected. Massive work, yes, all as promised and fair for a call to shift from one platform to the N(e)XT, Ardor. Pun intended. There are API changes too, and new API, coders please (you must!) check the change-log.

What made my brain cells begin to feel explosive again then?

New features

Yes, the new features. Nxters run. Run out there and share it with the world!

The change-log for Ardor 2.0.4e presents the following new transaction types – add to them all that the Nxt blockchain’s smart transactions and Ardor’s globally scalable, energy efficient child chain platform design can do, and you will see clearly the size of this gamechanger. This is what the release implements:

Asset control

Allows an asset issuer to control her assets. That’s right. As the issuer you decide who can buy and sell them; a small group of selected people, only KYC verified accounts, perhaps. Or you could send non-transferrable assets to a board of holders and give them voting rights over the asset. How about that. Read it again and let it sink in – with this release you, the issuer, will get complete asset control.

No, it’s not the end of a free market. Ignis is free. It is a new opening that allows all new as well as old running businesses to shift their old backend to Ardor and Ignis and receive all the benefits of the blockchain as a business backend, consumer front-end, and even get it cheaply.

Example:

  • Have an ICO/crowdfunding on Ignis
    Upload contracts and legal documents to the data cloud, time-stamped, hashed, let the KYC compliant accounts of your business partners or angels digitally sign the agreements, this will be documented on the blockchain as well.
  • Issue your asset tokens
  • Decide which rights you want to give to your asset holders, and to your market.
  • Distribute assets, each with the rights attached that you assigned to them. Watch them be traded.

Selected (or all) asset holders can have voting rights. You can pay dividends in any token on the platform; IGNIS, another child chain coin, an € pegged coin, that can be withdrawn with your VISA/Mastercard or just sit in your bank account. Or in other assets, representing bonus points, tickets, whatever fits your business plan. You could even create games with this. It is here.

We welcome this Java code, the Asset Control feature, as one of the best newest addition to the already existing API.

Composite Phasing

Introduces AND, OR, and NOT to Nxt’s Phased Transactions. This, combined with the new Asset Control feature, adds whitelist control over asset holder accounts, you can choose, for example, which asset holders should have the opportunity to vote or even control an account by vote. Even control the whitelist of new accounts. Do you see the better DAO coming?

It also allows for example combining the existing by hash or by transaction approval models with by whitelist, by balance, etc, approvals, which enables doing atomic coupling of transactions (including cross-blockchain) even for multisignature accounts, or with assets subject to Asset Control.

I couldn’t say it better.

The NOT operator allows for dead-man-switch type conditions, where a transaction is executed only if some condition (e.g. revealing a secret) is NOT satisfied.

Source

Asset share increase

With this new smart transaction type, asset issuers can increase the number of assets in existence. Print new money?!!

The new shares are allocated to the asset issuer account, but can then be distributed to shareholders using a separate dividend payment transaction. This allows corporate actions such as capital increases or stock splits to be performed.

Be careful, like we all learned in Economics 101, increasing the supply of money will decrease the value. Take care not to dilute your asset into nothingness.

By-Property phasing

First, if you don’t know Nxt’s feature “Account Properties”, I should fill you in: Account Properties is a Nxt feature that adds the ability to permanently ‘tag’ any account on the blockchain with a small amount of data, like meta-information. Tags can also be deleted by the tagger.

Let’s see what By-Property phasing is:

 

The new by-property approval model allows the transaction execution to be made conditional on the sender account or the recipient account having a specific account property set. If this property is set, the transaction will be executed immediately, else, a second check whether the property is set is performed at the finish height defined. This allows, for example, enforcing KYC by asset issuers, who can define in their Asset Control settings that only KYC-verified accounts, labelled with a predefined account property by a trusted authority (or the asset issuer itself), to perform transactions with their assets.

So with this feature, the blockchain market is regulated.

With this, you can, for example, in the near future, issue an asset on any Ardor child chain, trade it on any child chain, but enforce/be enforced to only let KYC approved accounts trade it on the market. Or choose by country. Or any group. With Ignis, asset issuers and traders can choose whether or not to trade on the regulated market, but we all know: Regulation will be. The new By-Property phasing API makes it not just possible but also easy and cost-effective to develop as a user-friendly service, and yeah, remember, the main purpose for Nxt 2.0, Ardor, was actually to make it globally scalable.

Where does this leave us? Accounts can be tagged by 3rd party KYC service providers or, even better, by governments, may they ever choose to set official ID on accounts and begin using the benefits of the blockchain. Don’t get me started. Secure us, our medical records, money, ID – let us be secured by cryptography. Jelurida’s code does it for them. Give us voting rounds that cannot be interfered with as the result is public, and votes have already been counted by code, see the graph. It’s on blockchain, but energy efficient, secured by nodes all over the world, and while we’re at it – possible. And see, Ardor has, as another first, a solution to the blockchain bloat problem running in production. The first and most tested globally scalable PoS Platform. It’s here, get started.

Sure I am excited. I’m a Nxter. Aren’t you?

Come on, try it!

For newcomers, it may seem weird that scammers and developers collect millions and millions of dollars worth of ETH or BTC in ICO’s, selling their whitepaper only, describing smart contracts they want to invent, code, test, execute, and need us to trust, when old Nxt Cryptocurrency 2.0 already has the functionality that most of them seek. It’s weird that what most of all of these devs and their investors are trying to achieve already exists on Nxt, that now gets further ahead with the scalable and even more beneficent and featureful public Ardor Platform. Yes, it IS weird, that Nxt has been under the radar and ignored by, for example, the larger Bitcoin-paid media for so many years.

The Nxt core devs, Jelurida, has split Nxt into IGNIS, the transactional token of Ignis, the first and unrestricted full featured child chain on Ardor; the mother blockchain that forges all Ignis’ transactions and will give birth to a lot more and take care of all her children (child chains), as well as make sure they keep communicating with each other. This is Ardor. With Nxt being a blockchain 2.0 platform, should Ardor be called blockchain 3.0? Nxt 4.0? Who cares. If you’re just a little familiar with Bitcoin, blockchains and smart transactions, you will realize that you want to test this release.

For those who want to setup an Ardor full node, install the software as usual and start forging, the first block will be generated tonight at 00:00 (midnight) UTC time on Monday, Nov 6th (about 14 hours from now)

If you are installing on top of a previous Ardor release delete first the nxt_test_db folder from C:\Users\<username>\AppData\Roaming\Ardor on Windows, ~/.ardor on Mac and the Ardor installation folder on Linux. If you don’t do that you’ll be left on a fork.

Follow the development closely and take part in the community. Even without the awesome potential that awaits us with this momentous release, it’s always mindblowing development.

 

Ardor Testnet is Launched

Early this morning, Jean-Luc, lead core developer of Nxt and Ardor, made an announcement on Nxtforum.org about the launch of the Ardor testnet. While some testing was already done by some members of the Nxt community who were very knowledgeable about the platform, as we mentioned in our previous newsletter, much more testing is needed to be done before the launch of mainnet in the third quarter of this year, thus the release of testnet. Also, this is a great way to experience the Ardor blockchain without risking any funds as the tokens are given away freely to people who want to try it.

At the moment, only .zip and .exe files have been released, so Mac users will have to wait a bit. Riker, core developer of Nxt and Ardor, mentioned that a client for Mac will likely be released in version 2.0.1e. However, users of Linux operating systems as well as Windows (32 and 64 bit) can get started now. Installation is very similar to that of the Nxt client, with the notable exception of some Ardor graphics.

Ardor’s Decentralized Polling

Some activity has already been going on in just a few hours after launch. On the testnet Ignis child chain, a poll was started asking users about their favorite animal among the animals mentioned. You can take a look at this by choosing the Ignis child chain on the testnet client, clicking on “Voting System” and then “Active Polls”. Remember, while all transactions are processed by the main chain which takes ARDR, when you’re on a child chain all processing is paid for in the child chain token. So, Ignis tokens are required in order to cast your vote.

Sending Bitcoin Using the Alias Feature On Ardor

This is just one of the few things currently being tested at the moment. Get the testnet client and to find out how to request test tokens on ardorplatform.org today and experience this new blockchain platform. If you find any bugs, please report them over at Nxtforum on the announcement thread or through one of the channels listed on the website.

Ardor v2.0.0e

Ardor v2.0.0e

THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE

Not available yet

Digital signature: "Stichting NXT"

.sh Sha256: 32ed1df94300275cf8aac9966a3f26bc6cf607c646fda54f7966953cab9aa882  ardor-client-2.0.0e.sh

Release 2.0.0e: https://bitbucket.org/JeanLucPicard/ardor/downloads/ardor-client-2.0.0e.zip

2.0.0e .zip sha256:b814ec631d37e2afc1319a458525d1cfd61c583f61f1d77d8312bc7249131711  ardor-client-2.0.0e.zip

Ardor testnet is here

Ardor 2.0.0e is the first public release of the Ardor testnet.

Read more about the launch in this post.

Learn more about the Ardor platform from www.ardorplatform.org.

ARDR assets representing real Ardor tokens are traded on exchanges.

 

Release notes

This is the first release of the Ardor software, for testnet only. It represents the first milestone in the building of the Ardor platform.

New Features

The main new user-visible feature is the existence of a single forging chain, using the ARDR token, and multiple child chains, each with its own token.

Forging Chain

The Ardor chain is used to establish the proof-of-stake consensus, using ARDR balances only. It supports only a few transaction types: ordinary payments, balance leasing, and coin exchange. Prunable plain or encrypted message attachments are also supported, but not permanent or standalone arbitrary message transactions.

Child Chains

The child chains support all transaction types as previously implemented on the Nxt platform, with the exception of balance leasing which is only available on the Ardor chain, and tagged data extend transaction which has been removed as unnecessary. A child chain can optionally be configured to disable certain transaction types, which has been done for testing purposes on the EUR child chain, disabling the Asset Exchange and Digital Marketplace.

Coin Exchange

To allow trading of child chain coins to each other, and also between child chains and the Ardor chain, a new Coin Exchange module has been implemented.

For trading between child chain coins, the coin exchange transactions are submitted on the child chain of the coin being sold. For trading between a child chain coin and Ardor, the transaction is submitted on the Ardor chain regardless of whether it is a buy or sell, and the fees for such transactions are higher.

Bundling

The bundling process is used to group child chain transactions from a child chain into a transaction on the Ardor chain. Bundlers accept the fees from those child chain transactions, in the corresponding child chain coin, and pay fees in ARDR to the parent chain forgers. Bundlers can be started from the cogwheel/bundlers menu, defining the coin to ARDR exchange rate they accept, a limit on the total fees in ARDR a bundler will pay, and an optional overpay amount.

When a bundler is running, it checks the unconfirmed transactions pool every time a new transaction from the child chain being bundled arrives. If the transaction fee included by the transaction sender, in child chain coins, when converted to Ardor using the exchange rate accepted by the bundler is at least equal to the minimum Ardor fee required for this transaction, the bundler will generate a ChildBlock transaction, including in it this and all other currently unconfirmed child chain transactions satisfying this requirement.

The Ardor fee the bundler will include for the ChildBlock transaction is equal to the sum of the minimum required Ardor fees for each, plus the calculated overpay amount, if any. Such overpay amount is optional, and may be used by bundlers willing to pay more in order to have their transactions included in block instead of those of competing bundlers.

The new ChildBlock transaction will displace from the unconfirmed pool any ChildBlock transactions of the same child chain that include only a subset of the same child transactions.

When propagating through the network, ChildBlock transactions will only be accepted by peers if they either include child transactions not already included in other ChildBlock transactions the peer already has in its pool, or offer to pay a higher fee for the same transactions. This ensures the network is not flooded with ChildBlock transactions even if every node is running a bundler, and allows bundlers to compete for propagating their transactions through the network by offering to pay higher fees.

It is now possible for child transactions to be submitted with zero fees, in child chain coins. If a bundler is willing to pay the Ardor fees for those, they will be included in the blockchain in the ChildBlock created by such bundler.

To prevent the unconfirmed pool from being overfilled with such zero-fees child chain transactions, once the maxUnconfirmedTransactions limit (configured in nxt.properties, default 2000) has been exceeded, child chain transactions will be dropped unless a bundler has already submitted a ChildBlock transaction which includes them.

Bundlers advertise their accepted bundling rates to other peers, signing such rates announcements with the private key of the bundler's account. To prevent fake rates announcements, they can be filtered based on this account effective balance (default set in nxt.minBundlerBalanceFXT is 1000 ARDR).

The GetBundlerRates API can be used to retrieve known bundlers rates, again with optional filtering by minimum bundler effective balance.

Peer Networking

The peer networking has been fully re-written and optimized to use socket connections and binary messages instead of http and JSON.

Block and transaction propagation through the network has been optimized, by sharing with peers the inventory of transaction IDs in the unconfirmed pool or in recent blocks, and only propagating the missing ones, if any, when a new block is generated, or a child block is bundled.

The hallmark feature has been removed as it is not needed anymore, hallmarks are no longer supported.

New APIs

APIs of the new Coin Exchange feature:
ExchangeCoins, CancelCoinExchange, GetCoinExchangeOrder, GetCoinExchangeOrders,
GetCoinExchangeOrderIds, GetCoinExchangeTrade, GetCoinExchangeTrades,
GetExpectedCoinExchangeOrderCancellations, GetExpectedCoinExchangeOrders,
GetLastCoinExchangeTrade.

Bundling related APIs:
BundleTransactions, GetBundlers, GetBundlerRates, StartBundler, StopBundler.

Other new APIs:
GetBalances, GetEffectiveBalance, GetFxtTransaction.

API changes

All APIs that are now chain specific accept a new chain parameter. Either the chain name or the chain ID can be used.

Transaction IDs are no longer 64-bit longs but 256-bit hashes, necessitating changes in all APIs that accept transaction ID parameters or return such in the JSON fields. For transactions on the Ardor chain, 64-bit long IDs can still be used with the getFxtTransaction API, as those are enforced to be unique. For child chain transactions, the getTransaction API now requires a fullHash parameter, in addition to specifying the chain.

Prices and rates are now defined relative to a whole unit of the holding being bought or sold (asset, currency, coin), not to a QNT indivisible unit.

All priceNQT and rateNQT parameters and JSON fields have been renamed where appropriate to priceNQTPerCoin, priceNQTPerShare, rateNQTPerUnit, etc., to reflect their changed meaning of price per whole unit of each holding rather than per QNT.

All "units" parameters in the Monetary System APIs have been renamed to unitsQNT.

DividendPayment API accepts holding and holdingType parameters to allow paying dividends in another asset or MS currency. The amountNQTPerQNT parameter has been renamed to amountNQTPerShare and now refers to dividend amount in NQT per
a whole share of the asset rather than per QNT.

The GetAccount API no longer returns balanceNQT and unconfirmedBalanceNQT, as balances are now chain specific. The GetBalance API should be used to get chain balances instead, or GetBalances for querying multiple chains.

APIs which accept holding and holdingType parameters now require holding to be set to the chain ID when holdingType=0 (coin).

Since 0 is now a valid fee value for child chains, all CreateTransaction APIs will accept it, instead of using it as a request for the server to calculate and use the minimum fee. To let the server calculate the child transaction fee, a value of feeNQT=-1 should be used, and a new feeRateNQTPerFXT parameter must be supplied, to indicate the exchange rate to use when calculating the fee (since minimum fees can only be calculated in ARDR). If feeRateNQTPerFXT is also set to -1, the server will query the currently known bundlers rates for this child chain, also subject to the minBundlerBalanceFXT limit on effective bundler account balance, and use the best one for the fee calculation. As bundlers rates cannot be trusted blindly, the transaction will not be broadcasted in this case, the returned transaction JSON including the fees calculated should be reviewed by the user. The bundler rate used will be returned in the bundlerRateNQTPerFXT JSON field, -1 if no bundlers are known for the chain.

The following APIs have been removed: ExtendTaggedData, GetPhasingPolls, GetTaggedDataExtendTransactions, GetInboundPeers, MarkHost, DecodeHallmark.

Transaction types and bytes format

The numbering of some transaction types has changed, due to the internal reorganizations of the TransactionType classes. Transaction types on the Ardor chain use negative numbers, e.g. -1 for ChildChainBlock, -2 for Ardor ordinary payment. Some transaction subtypes have been moved to a separate type, e.g. voting and phasing related transactions have been moved out of Messaging to a new Voting transaction type. The output of getConstants should be consulted for a full list of the current transaction types and subtypes.

The transaction bytes format has also changed, adding a chain ID, reorganizing the ordering of attachment and appendix bytes, and allowing prunable attachment parts to also optionally be represented in the bytes format, for the purpose of sending them more efficiently over the peer to peer network.

The JSON transaction representation is still supported, even though it is no longer used in the peer networking. Some attachment fields have been renamed for consistency with the API changes - units to unitsQNT, priceNQT to priceNQTPerShare, rateNQT to rateNQTPerUnit, amountNQT for dividend payments to amountNQTPerShare, etc.

Entity IDs

As part of designing child chain transactions to be prunable, it is no longer possible to enforce uniqueness of the 64-bit transaction IDs for child chains. This affects the IDs of derived entities such as Assets, MS Currencies, Polls, Digital Goods, Shufflings, etc.

For global derived entities such as Assets or Currencies, the 64-bit long IDs are still unique and used in the corresponding APIs. Note however that this uniqueness is now only within the same object type, i.e. it is not guaranteed that an Asset and a Currency will not happen to have the same 64-bit long ID.

For child chain local entities, such as Polls and Digital Goods, the 64-bit IDs are still unique, but within the same child chain only, and still used in their APIs. Again, there is no uniqueness guarantee across different entity types anymore.

For entities that are prunable, such as prunable messages, tagged data, and shufflings, the full 256-bit hash must be used as an ID now, and the appropriate APIs have been changed.

Phasing and Account control

Only child chain transactions can be phased. Therefore, when account control is set for an account, it can no longer submit Ardor chain transactions.

Phasing parameters which refer to transaction IDs must now use transaction full hashes instead, prefixed with the chain ID separated with ':'. It is possible to refer to transactions on other chains when approving a phased transaction, or setting up a by-transaction phasing voting model.

The controlMaxFees parameter when setting mandatory approval now accepts multiple values, each fee being prefixed with the child chain ID and ':', to indicate which child chain the limit applies to. If no max fee has been set for a child chain, there is no phasing transactions fees total limit on it for the controlled account.

Transaction selection, sorting, limits and fees

An Ardor chain block can contain up to 10 (ten) transactions, this including both native Ardor transactions and ChildBlock transactions. There is no total payload size limit.

A ChildBlock can contain up to 100 (one hundred) child transactions, subject to a total payload limit of 128 kbytes. Prunable child transaction parts are also counted towards the payload size limit.

There is a limit of one ChildBlock per Ardor block for each child chain.

As in Nxt, it is up to a block forger which transactions to include in a block and how to sort them. The default forger behaviour is to select transactions ordered by Ardor fee (not fee per byte as in Nxt, since there is no block payload limit), and then sort them based on arrival timestamp.

It is also up to the ChildBlock bundler which child transactions to include in a ChildBlock, and this selection can be customized by defining a custom filter in the nxt.bundlingFilter property. The default bundler behaviour is to select child transactions ordered by fee per byte, up to the count and payload limits of a child block, creating several child blocks if necessary. Within a child block, child transactions are sorted based on their full hash, but executed based on sorting them after adding the block hash to the child transaction hash, i.e. the execution order of child transactions within a block is deterministic but not predictable and not controllable by the bundler or by the forger. This is in order to prevent front-running of asset exchange and other trading orders.

Ardor fees from ChildBlock transactions paid to the block forger are shared with the previous three block forgers in 1:1:1:1 ratio. Other Ardor chain fees are fully kept by the block forger, and child block transaction fees (in child chain coins) are fully kept by the ChildBlock bundler.

The back fees sharing which was applied in Nxt for some other transactions types such as currency or asset issuance has been removed, however the limitations of one such transaction per block for scarce blockchain resources are preserved.

Default fee for Ardor chain transactions is 10 ARDR. Default fee for child chain transactions is 0.1 ARDR. A ChildBlock must contain at least one child chain transaction, but there is no minimum ChildBlock fee requirement, i.e. such a ChildBlock with a single transaction in it would require only 0.1 ARDR fee if this is the minimum fee for the child transaction it contains.

Fees for child chain transaction types have been scaled depending on their impact on the blockchain, e.g. asset issuance fees are still 1000 ARDR as assets are global and kept permanently. There is a 1 ARDR extra fee added to transactions that create a new account.

The above fees and limits are set for the current testnet only and are subject to change before the production mainnet release.

Testnet accounts

The testnet genesis block has been created based on account balances from the Nxt testnet, as of 2017/01/01 (block height 1061208). Users who had testnet accounts as of that height should find their ARDR and NXT testnet balances imported into this testnet, to ARDR and IGNIS tokens respectively, plus an approximately equivalent amount of BTC, USD, and EUR child chain coins for testing. To allow for developers testing and running forging and bundling nodes, account holdings have been reduced by 50% which have been allocated to developers accounts.

Upgrading from Nxt

The Ardor release is not an upgrade and does not in any way affect your existing Nxt account or client installation. Both Ardor and Nxt should be possible to run simultaneously on the same machine, as long as the hardware capacity allows it.

The included ArdorNxtComparison.pdf document summarizes the major differences between the Nxt and Ardor platforms, for those deciding which one is a better fit for their use case, or considering a migration from Nxt to Ardor. More documentation should be added as Ardor development and features mature and stabilize.

Source: https://nxtforum.org/nrs-releases/ardor-v2-0-0e/

Also see: Nxt 2.0: Ardor childchain blockchain platform

Ardor GUI screenshots

Damelon, of the Jelurida, has shared some previews with us regarding the Ardor platform.

This time a screenshot of the Coin Exchange, which allows users to exchange tokens in one child chain against tokens in another child chain, or against Ardor.

Here it is:

A preview of the dialog windows for bundlers has also been shared.

“Bundlers” will bundle child chain transactions and send them to the Ardor main chain where they will be “forged”. This operation costs ARDR. You can read more about how bundling will work in this newsletter.

Source: https://nxtforum.org/general-discussion/(ardor)-coin-exchange-and-bundlers’-screenies/

Ardor Features vs Nxt Features

Jean-Luc, Nxt and Ardor core developer, has published a chart on nxtforum.org that compares the major differences in the functionalities between Nxt and Ardor:

Blockchains

Single chain One parent chain with multiple child chains

Transaction tokens

The same token (NXT) is used for establishing the consensus and providing the security of the blockchain, as well as for the basic unit of value in all transactions Only the parent chain token (ARDR) is used in the proof-of-stake consensus, and thus provides security for all child chains. Child chain tokens are used as transactional units of value only.

Transaction fees

Transaction fees are paid in NXT only, requiring users to always have NXT in their accounts. On each chain transaction fees are paid in the native token (coin) of that chain. End users do not need to own ARDR tokens.

Features

Asset Exchange, Monetary System, Aliases, Messaging, Digital Goods Store, Voting System, Shuffling, Data Cloud, Phasing, Account Control, Account Properties All these features are preserved in Ardor, and are available on each child chain. A child chain can optionally be restricted not to enable some features. The parent chain supports a limited subset of features, as it is intended to be used for consensus establishing only and not for everyday transactions.

Accounts

Each passphrase maps to a single account. Passphrases can’t be changed, and there is no wallet file to store. The same mapping of passphrases to account numbers is used as in Nxt. Accounts are global across all child chains, and an account can have balances in each of the existing child chain coins, as well as in ARDR.

Holdings

There is a single coin (NXT), and unlimited user-issued Assets and Monetary System currencies. Each chain has its own coin. Assets and MS currencies can be issued on any child chain, and are available for trading globally. Assets or MS currencies can optionally be restricted* to some child chains only.

Trading

Assets and MS currencies can be traded for NXT only. Assets and MS currencies can be traded on any child chain, with price denominated in the corresponding child chain coin.

Coin Exchange

N/A A new feature, Coin Exchange, allows trading of child chain coins to each other, and also to the parent chain coin (ARDR).

Dividends

Asset dividends can be paid in NXT only. Asset dividends can be paid in any of the child chain coins, by simply issuing the payment transaction on the corresponding chain. Additionally, paying dividends in another Asset or in MS currency has been implemented.

Crowdfunding

Crowdfunding feature is available in the Monetary System, but the funds must be collected in NXT only. Crowdfunding feature is available on all child chains, and on each child chain the funds are collected in the corresponding child chain coin.

Shuffling

Shuffling of NXT, Assets, and MS currencies is available. On each child chain, shuffling of the corresponding coin, or any Asset or MS Currency, is supported.

Aliases

Alias names are globally unique. Alias names are unique within each child chain only.

MS Currencies

Currency codes and names are globally unique. Currency codes and names are unique within a child chain only.

Pruning

Pruning is available for plain and encrypted messages, and for tagged data (data cloud feature). Pruned data are retrieved automatically on demand from designated archival nodes. Pruning and retrieving of all prunable data is available as in Nxt. In addition, the child chain transactions themselves are designed to be prunable and will not need to be stored permanently or re-downloaded by every new node. The actual pruning of transactions will be implemented later.*

Transaction identifiers

Transaction IDs are 64-bit longs, and are globally unique. The 64-bit transaction IDs are no longer guaranteed to be globally unique for child chains. 256-bit transaction hashes (sha256 digests) are used instead as transaction identifiers.

Block generation

A “forging” process is used to create new blocks, with the probability of block creation dependent on the account NXT balance (stake). The same forging algorithm is used as in Nxt, dependent on ARDR account balances only.

Bundling

N/A A new process, “bundling”, is used to group child chain transactions into a parent chain transaction (“child chain block”), which is then included in the parent chain. Any account can play the role of a bundler. The bundling process also performs the exchange of fees paid by users in child chain tokens into ARDR fees accepted by the block forgers.

Phasing

Transaction execution can be made conditional, subject to approval using various voting models. Same voting models as in Nxt, but phasing is possible on child chains only. Approval transactions can be on a different child chain from the phased transaction, and the by-transaction voting model also supports linking to a transaction hash on a different child chain.

Account control

Accounts can be restricted to use phasing only (mandatory approval). Same as in Nxt, but accounts under phasing-only restriction cannot submit transactions on the parent chain, as those cannot be phased.

Peer networking

HTTP based, also with WebSocket support, transmitting JSON formatted data between peers. Completely re-written and optimized, using native Java sockets and binary messages between peers. Block and transaction propagation has been significantly improved, by exchanging and caching information about currently available blocks and transactions between peers and only propagating the missing data pieces.

API

HTTP query APIs, returning JSON formatted response. Mostly unchanged, except:
1. A “chain” parameter has been added to each API that is child chain specific.
2. 64-bit long transaction IDs have been replaced with 256-bit hashes.
3. All prices and rates that were previously defined relative to the smallest indivisible holding amount (“QNT”) are now defined relative to a unit of the holding (share).

Scalability

Transactions are stored in the blockchain permanently, and need to be re-downloaded and re-processed by every new node, which after months and years of operation becomes a significant bottleneck. All child chain transactions will be possible to prune completely, without affecting blockchain security, thus allowing the blockchain size to be kept much smaller. A new node joining the network only needs to download the parent chain transactions, followed by the latest snapshot of the current system state.*

* Functionallity marked with asterisk is planned to be implemented in a future Ardor release. All other functionallity is already implemented and currently being tested on a testnet blockchain.

Source and more information:https://nxtforum.org/core-development-announcements/ardor-vs-nxt-functional-comparison/

https://nxtforum.org/core-development-discussion/list-of-feature-request-for-nrs/

Beer, Betting and the Nxt Blockchain

Suppose you have a circle of friends who you meet with in a sports bar to drink beer, watch sports and make bets. You can make bets on the Nxt Blockchain and have a basic Python app automate it for you.

In my first article I introduced basics of a blockchain. As we learned, the most important value proposition of the blockchain is immutability of data submitted in transactions recorded into blocks, from which a blockchain is built.

Today I want to show how to build a simple but fully functional betting app in python. For the betting app that I present, immutability of data may be required, but in the case a bet should need to be canceled, the app can be modified to take into account this additional functionality.

Pre-requisites:
NRS (Nxt Reference software) 1.10.2: https://bitbucket.org/JeanLucPicard/nxt/downloads/Python 3 (or Python 2 with slightest modification). A beer or two (optional).

Application logic

A user submits a bet (transfers any amount of NXT coins) to the betting account and adds a public unencrypted attachment. In the attachment he should write the id of the bet, a colon and a number indicating his choice in the corresponding bet. Let’s give an example: the sports bar runs a bet which football team wins. They assign an ID to this game, let’s say “30”.

The choices are:
“1” – home team wins. “2” – other team wins. “3” – tie.

To bet on the victory of the home team, the player must submit a transaction of any amount of NXT, and attach a public unencrypted (for auditability) message with the content: 30:1

When the time comes, the betting host runs the app to find winners and process payments. The host can take a small fee for the service.

Implementation

The Nxt Server listens for queries on port 7876. If you run it on the same machine as your python code by default you must submit queries to http://127.0.0.1:7876/nxt

For our app we will need to import a few modules and write the function to submit queries which will be used a few times through the app.

import sys, json, re

def sendQuery(Query):
  from urllib import parse, request
  params = parse.urlencode(Query)
  headers = {"Content-type": "application/x-www-form-urlencoded", 
"Accept": "text/plain"}
  req = request.Request("http://127.0.0.1:7876/nxt", 
params.encode('utf-8'))
  response = request.urlopen(req)
  return response.read()
	
myAccount = "NXT-AAAA-BBBB-CCCC-DDDDD"
totalAmount = 0
serviceFee = 0.05
players = []
secretPhrase = "bla bla bla"

The function returns a JSON string to be decoded, with transactions and attachments to be parsed. Also a few variables are initialized.

Next we must query the betting account to fetch all incoming transactions.
This is the request you can send to the NXT server to execute this:

Query = {'requestType': 'getBlockchainTransactions', 
'account': myAccount, 'type': '0', 'subtype': '0', 'executedOnly': 'true'}

decode JSON and load it to a variable for further processing.

output = sendQuery(Query)
data = json.loads(output.decode('utf-8'))

As we have all the data now, we loop through the list and discard some of the transactions we don’t need. For instance, we don’t need to process outgoing transactions, so we continue the loop from the next item.

for i in data['transactions']:
  txAmount = i['amountNQT']
  txSender = i['senderRS']
  if txSender == myAccount:
      continue
  txRecipient = i['recipientRS']
  if txRecipient != myAccount:
      continue

Next we pull out the attachment, check if it is not encrypted and strip whitespace.

  line = i['attachment']['message']
  lineIsText = i['attachment']['messageIsText']
  if line.strip() != "" and lineIsText == True:
    line = line.strip()

Next step is to match the submitted message against the regular expression. It must satisfy the format “Number:Number”, the first number can be up to 3 digits.

    matchLine = re.match(r'(\d{1,3}:\d{1})(.*)', line, re.M|re.I)

If the attached message is of correct format we process it further…

The betting app accepts up to 3 command-line arguments: id of the game, the choice number that has won, and third optional parameter in double quotes to name the winner choice for verbosity in the payout message.

For instance, the betting host must run it like this:
python3 bet.py 30 1 “Home team wins”

The app will process transactions with game id 30 and rewards players who chose ‘1’.
The third argument can be omitted: python3 bet.py 30 1

Next we must calculate the sum of money submitted for our game, make a list of dictionaries of players who guessed the correct number, and calculate the total sum for distribution after the betting host gets his optional service cut.

    if matchLine:
      if matchLine.group(1).split(':')[0] == sys.argv[1]:
        totalAmount += int(txAmount)
        if matchLine.group(1).split(':')[1] == sys.argv[2]:
          d = {txSender: matchLine.group(1).split(':')[1], 
'amount': txAmount}
          players.append(dict(d))
afterFee = float(totalAmount - totalAmount * serviceFee)

We have winners in the ‘players’ list of dictionaries, we have money to distribute in ‘afterFee’, let us now process payouts.

sumCorrect = 0
for i in players:
  for key in i:
    if i[key] == sys.argv[2]:
      sumCorrect += float(i['amount'])
for i in players:
  for key in i:
    if i[key] == sys.argv[2]:
      t = float(i['amount']) * (afterFee / sumCorrect)
      if t > afterFee:
        strSendAmount = str(int(afterFee))
      else:
        strSendAmount = str(int(t))
      if len(sys.argv) > 3:
        reply = sys.argv[3]
      else:
        reply = sys.argv[2]
      message = "Payout for correct bet in poll " 
+ sys.argv[1] + "; your reply: " + reply
      Query = {'requestType': 'sendMoney', 'recipient': key, 
      'amountNQT': strSendAmount, 'secretPhrase': secretPhrase, 
      'feeNQT': '100000000', 'deadline': '1440', 'broadcast': 'true', 
'message': message, 'messageIsText': 'true', 'messageIsPrunable': 'true'}
      sendQuery(Query)

Needless to say the app can be improved to process errors, cancel bets or optionally allow other parameters in attached messages. Attached messages can be submitted with the Nxt Client (NRS) or from a web wallet that allows sending attachments.

To make transactions on the Nxt Blockchain you need NXT coins, which you can purchase directly, by exchanging Bitcoin for NXT or by attending the “Lucky Node” project by running a public Nxt node (Nxt server).

To learn how to participate in the Lucky node project, please visit https://nxtforum.org.

There are over a hundred API calls you can make to the Nxt server, a full list with mandatory and optional parameters and examples is available at https://nxtwiki.org/wiki/The_Nxt_API.

Cheers!

blockchain-betting

Lottery on the Nxt Blockchain in Golang

In my first article I introduced blockchain theory, what it can do for your software project and the basics of interacting with the Nxt blockchain in PHP.

Today I am going to present a small Lottery program written in Go.

Pre-requisites:
Golang (tested with Go 1.6.2)
NRS 1.10.1 (https://bitbucket.org/JeanLucPicard/nxt/downloads/)

The program is fully functional and runs a lottery every Sunday [1].
It was originally written in PHP, both sources are available for download from the Nxt Data Cloud [2].

Application logic

Data feed for this app is ‘tickets’ submitted by users in attachments.

A lottery player sends 10 NXT to the lottery account and attaches a public unencrypted message with a string of 5 numbers, ranging from 0 to 30 separated by commas. The attachment must be unencrypted for rewards to be publicly auditable using the blockchain.

The app makes a request to the NXT server to fetch all transactions from the lottery account, sorts through them, selects only valid transactions and creates a slice of maps (multidimensional array in PHP) of players’ accounts and their strings of numbers. It also calculates the total sum of NXT payable to the players from the sums of all valid tickets.

Upon receiving all the valid data the app runs three rounds of the lottery. Each round receives a portion of the total payable sum, split between concurrent winners. In the round of 5, the app finds user(s) who have correctly guessed 5 numbers, and sends out rewards. In the round of 4, the app does the same for users who have guessed 4 numbers, the slice of participating tickets is now short of winner(s) of round of 5. Rinse and repeat for the round of 3.

This is the gist of it.

A little bit on internals

For each of the three rounds the lottery generates sequences of 5 numbers and compares them to the strings of numbers in tickets until one or more winners are found. It can be said that the lottery “forces” the winning sequence onto ticket(s).

With a limited number of users this seems to be the only sensible way of running a lottery and not having to collect and keep a large jackpot for months and years.

Let’s take a look at the function that generates sequences of 5 numbers and returns an array of them to caller function. On average, this function is called hundreds of thousands of times to find the sequence of 5 matching one of the tickets, when we have a very limited number of participants. It takes fractions of a second. In PHP it takes a tiny bit longer (a second or two), although PHP 7 performance is really good.

func genFive(seed string) [5]int {
   var r [5]int
   seedInt, _ := strconv.Atoi(seed)
   d := false
   for a := offset; a < offset+5; a++ { 
      rand.Seed(int64(seedInt + offset)) 
      var dup [31]int 
      d = false 
      r[0] = rand.Intn(31) 
      r[1] = rand.Intn(31) 
      r[2] = rand.Intn(31) 
      r[3] = rand.Intn(31) 
      r[4] = rand.Intn(31) 
      for _, v := range r { 
         dup[v]++ 
      } 
      for k, _ := range dup { 
         if dup[k] > 1 {
            d = true
         }
      }
      offset = offset + 5
      if d == false {
         return r
      }
   }
   return r
}

An important characteristic of a blockchain lottery app is: it must be completely trust-free.
Everybody must be able to validate that results of the lottery haven’t been gamed. A logical and simple solution to this is to generate sequences of numbers with a deterministic seed.

The problem with deterministic seeds: if they are known in advance, sequences of numbers can be predicted and the lottery can be gamed. To address this problem we turn to the Nxt blockchain again, to find a source of seed with a getSeed() function.

func getSeed() (string, string) {
 type BlockchainStatus struct {
    NumberOfBlocks int `json:"numberOfBlocks"`
 }
 var status BlockchainStatus
 if seedBlockOutput, b := 
sendQuery("requestType=getBlockchainStatus", 
true); 
b != false { if err := 
json.Unmarshal([]byte(seedBlockOutput), &status); 
err != nil {
     fmt.Println(err)
   }
  }
 seedBlockHeight := 
strconv.Itoa(status.NumberOfBlocks - 11)

 type BlockId struct {
  Block string `json:"block"`
 }
 var block BlockId
 if seedBlockId, b := 
sendQuery("requestType=getBlockId&height="
+seedBlockHeight, true); b != false {
if err := json.Unmarshal([]byte(seedBlockId), 
&block); err != nil {
         fmt.Println(err)
    }
  }
 seed := block.Block[len(block.Block)-5:]
 return seed, seedBlockHeight
}

The app runs at 18:00 UTC on Sunday.

The first thing it does in the getSeed() function is to fetch the block id of the block which was generated 10 blocks before the app started (as seen in a local copy of the blockchain on the lottery node) and take the 5 last digits of the block id as a seed. Due to network latency and occasional blockchain reorganizations of 1-3 blocks, the lottery node may not see the same block as other nodes. The number 10 for getting the block for seed was chosen to be reasonably sure that block would not be reorganized.

It can be argued that there is a theoretical possibility that the block id is predictable. The odds of this are tiny in my opinion but I’ll leave it to the readers to debate and decide.

Now that the app has its seed, it can do its job in a way so users don’t need to trust the lottery host.

The Go source code doesn’t include the routine to verify past results.
The PHP source code does have it, it is fully functional and can be used to independently verify all past results with the deterministic seeds from the blockchain.

For Go I use this function to send queries to the Nxt Server and return results.

func sendQuery(Query string, Active bool) 
(output string, b bool) {
   output = ""
   b = false
   if Active == false {
      output = "Function disabled"
      return
   }
   body := strings.NewReader(Query)
   req, err := http.NewRequest("POST", 
"http://127.0.0.1:7876/nxt", body)
   if err != nil {
      output = fmt.Sprintf("%s", err)
      return
   }
   req.Header.Set("Content-Type", 
"application/x-www-form-urlencoded")

   resp, err := http.DefaultClient.Do(req)
   if err != nil {
      output = fmt.Sprintf("%s", err)
      return
   }
   bo, err := ioutil.ReadAll(resp.Body)
   defer resp.Body.Close()
   output = fmt.Sprintf("%s", bo)
   match, _ := 
regexp.MatchString(".*errorDescription.*", 
output)
   if match == true {
      fileHandle, _ := 
os.OpenFile("./error.log", os.O_APPEND, 0666)
      writer := bufio.NewWriter(fileHandle)
      defer fileHandle.Close()
      fmt.Fprintln(writer, output)
      writer.Flush()
      return
   }
   b = true
   return
}

The results are returned as a JSON string and need to be unmarshaled into proper structs.

validPlayers := make([]map[string]string, 0)

lotteryAccount := "NXT-YXC4-RB92-F6MQ-2ZRA6"

type Attachment struct {
   Message       string `json:"message"`
   MessageIsText bool   `json:"messageIsText"`
}

type Transaction struct {
   Timestamp   int        `json:"timestamp"`
   AmountNQT   string     `json:"amountNQT"`
   ID          string     `json:"transaction"`
   SenderRS    string     `json:"senderRS"`
   RecipientRS string     `json:"recipientRS"`
   Attached    Attachment `json:"attachment"`
}

type Response struct {
   Transactions []Transaction 
`json:"transactions"`
}
Query := 
"requestType=getBlockchainTransactions&account=" +
lotteryAccount + 
"&type=0&subtype=0&executedOnly=true"

if v, a := sendQuery(Query, true); a == true {
   var transactions Response
   if err := json.Unmarshal([]byte(v), 
&transactions); err != nil {
      fmt.Println(err)
   }

 p := 0
 for k, _ := range transactions.Transactions {
    // code to check tickets for validity.
    // if transaction satisfies all criteria 
    // add it to the slice of valid tickets.
		
    validPlayers = append(validPlayers, 
make(map[string]string))
    validPlayers[p][txSender] = lotteryNumbers
    p++
			
   }
}

Now that ‘validPlayers’ has all the good tickets we can start the game.

process() receives an integer (5, 4, or 3) and other parameters, including validPlayers and runs three rounds of the lottery. It makes a call to getWinners() function, that one calls genFive() to generate sequences of numbers until at least one winner is found. getWinners() returns results to process() which sends out reward, removes the winner ticket from eligible tickets and returns remaining tickets into main() for subsequent rounds. There is a helper function preparePlayers() which recreates validPlayers without the empty spots freed by the removed tickets.

I encourage every programmer to try coding on the Nxt blockchain. It is very easy with its rich API hooking into all the functionality of the core engine. https://nxtwiki.org/wiki/The_Nxt_API

My next app will probably be a poll app, with immutable records of votes saved into the blockchain. Do you think an app like that can find usage in the modern world? By the way, Nxt has its own built-in Voting. It’s too easy to forget what Nxt has, because it has so many features and all those features are accessible through API, kindly programmed by the core developers for userland. You can ‘mine’ your first NXT coins to send transactions in the Lucky node project running a public node, come to nxtforum.org and you will find out how.

Please leave your comments and suggestions.


1.
Lottery at nxtforum.org.

2.
To access Nxt Data Cloud, download and install the NRS (Nxt Reference Software 1.10.1) and search by ‘lottery’ keyword. Source code can also be downloaded from any of the public Open API Nxt servers, for instance:

Go: http://23.94.134.161:7876/nxt?requestType=downloadTaggedData&transaction=7872865106538381099&retrieve=true

PHP: http://23.94.134.161:7876/nxt?requestType=downloadTaggedData&transaction=13031806327722095646&retrieve=true
BACK TO POST.

Programming the Nxt Blockchain for fun and profit

Blockchains can be useful in various applications, facing global audience and supporting company internal infrastructure. A blockchain is a distributed database, a copy of the blockchain is stored on each node in a peer-to-peer network. This extreme redundancy can be duely considered inefficient, but please stay with me for a couple of minutes of blockchain theory.

As each node validates all transactions recorded into the blockchain and as past transactions cannot be rolled back or tampered with like in traditional RDBMS, this redundancy makes the blockchain *immutable*, and that is a very important value proposition of blockchains. Immutability of data is something traditional databases cannot provide. You may or may not need immutability of data and trust-free confirmation that data hasn’t been altered.

In this tutorial I assume you do need this.

One of the most versatile and flexible blockchains is the Nxt Blockchain (https://nxt.org). It has over a hundred API calls https://nxtwiki.org/wiki/The_Nxt_API.

Today you will learn basics of programming the Nxt blockchain. I will use only two API calls in this tutorial. With over a hundred API calls opportunities for programmers are limitless.

Application logic

A customer of a company or an employee in an organization uploads a file through a web form.
The file is renamed to a unique name and is saved in some location on the server.

A year later the customer / employee needs to verify, using the Nxt Blockchain, that the file hadn’t been altered. For instance, this may be required for legal purposes. It doesn’t have to be files. Internal company memos can be hashed and stored in the database, to be verified in a future audit.

Nxt allows us to send and record arbitrary messages (AM) into its blockchain.

Every transaction on the blockchain comes at a fee. If the transaction size is large, it can be expensive; fortunately Nxt has a subtype of AM called prunable messages. These are pruned after 90 days which make them cheap, they are available for retrieval from archival nodes after 90 days.

The maximum size of an arbitrary message in the Nxt blockchain is approx. 42 KB, the size of one block. A prunable message of 1 KB costs 1 NXT ($0.03). 1 KB is enough to store a hash of a file and this is our final cost to permanently record one hash in the immutable distributed Nxt blockchain.

As the customer uploads a file I create a SHA256 hash of the file and store the hash in the database in the organization’s server. For simplicity I’ve chosen SQlite, but you can use Mysql, Postgresql, Oracle. I will use PDO to access SQlite database in PHP.

When we do not use the immutable database (blockchain), the file can be modified, the new hash of the modified file saved in the database, making it hard to prove the file was like this from the beginning.

Blockchain comes to the rescue

Every prunable message can be retrieved from archival nodes. Every record in the blockchain is immutable. You can be sure the hash of the file you uploaded a year ago, when it is retrieved from the blockchain, is the same hash. All you need now is compare it with the hash in the organization’s internal RDBMS.

Pre-requisites:
PHP with curl, json and some db extension (I use sqlite3). A web server is optional, you can use php-cli. Java 8 (Oracle or OpenJDK to run Nxt). Nxt reference software: https://nxtforum.org/nrs-releases/nrs-v1-10-1/.

Install the NRS (Nxt Reference Software (depending on the context interchangeably called Nxt Client or Nxt Server)) and create an account. Fund it with a few coins. You can exchange Bitcoin to NXT at an exchange service like https://shapeshift.io or exchange with someone at https://nxtforum.org. It is also possible to “mine” some free NXT as reward for running a node; http://test.nxter.org/the-forging-bounty-lottery-campaign-will-pay-5-million-in-rewards-to-forgers-and-nxt-nodes/.

First we create a simple database table for our application, nothing fancy, you can add more column types if you must store more information. I like to use DB Browser for SQLite of http://sqlitebrowser.org.

Let’s make an empty database ‘files.db’ and save it in /home/lurker10/phptutorial/files.db

Using DB Browser for SQLite create the following table.

CREATE TABLE "files" (
`id` INTEGER PRIMARY KEY AUTOINCREMENT,
`txid` TEXT,
`hash` TEXT,
`uploadtime` TEXT,
`filename` TEXT
)

‘txid’ is the field for storing the id of a transaction we receive from Nxt when the transaction is accepted. It is unique. ‘hash’ is the sha256 hash of the file.

In this tutorial I skip the file upload part of code to keep it concise.

Let’s assume the file is already uploaded and stored on the web server. We define the file location variable in the code.

$uploadDir = "/home/lurker10/phptutorial/tmp/";
$fileName = "copy12345.tar";

By default the Nxt Server listens for API requests on port 7876. If you run it on the same machine as your php code, your code must send queries to http://127.0.0.1:7876/nxt

The other important variables are the passphrase of the Nxt account you’ve created and funded and the recipient’s account.

You can send the message to yourself, recipient can be your own account.

$host = "http://127.0.0.1:7876/nxt";
$secretPhrase = "your passphrase";
$recipientID = "NXT-XXXX-XXXX-XXXX-XXXXX";

The next part of code is the function that submits query using curl in a POST request.

To make a query we must define $payload and $payload_string variables and feed them to sendRequest(). It is possible to run the Nxt Server over HTTPS and use curl to verify the SSL certificate, but for this simple app we have disabled SSL verification in the curl connection.

Another point of interest is the $errorDescription, json-decoded from server response.

If there is a problem with the query (“Not enough funds” in your account when your balance is zero),
you must add error handling routine. I omit this too. For this app I assume the server responded properly, and return the response into the app for further processing.

function sendRequest($host, $payload, $payload_string) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $host);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 10000);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 10000);
curl_setopt($ch, CURLOPT_POST, count($payload));
curl_setopt($ch, CURLOPT_POSTFIELDS, $payload_string);
$output = curl_exec($ch);
$curl_error = curl_error($ch);
curl_close($ch);
$errorDescription = trim(@json_decode($output)->errorDescription);
if ($errorDescription != "") { // perform error handling; return false; }
return $output;
}

As the file is uploaded already, I create a sha256 hash of the file and timestamp.

$fileHash = hash_file("sha256", $uploadDir.$fileName);
$txTime = time();

I will use PDO to work with the database.

Open the db and insert a new record.

We don’t know the txid until we talk to the Nxt Server that can give it to us when transaction is accepted on the NXT network, so for now I’ll insert null for txid.

$pdo = new PDO('sqlite:/home/lurker10/phptutorial/files.db');
$sql = "INSERT INTO files (txid, hash, uploadtime, filename)
VALUES (null, '$fileHash', '$txTime', '$fileName')";
$result = $pdo->exec($sql);

Next we create a query to send to the NXT server.

This particular query is “sendMessage”, you can find a whole lot more queries to interact with the blockchain and their mandatory and optional parameters at https://nxtwiki.org/wiki/The_Nxt_API.

As I said earlier the fee to transact is 1 NXT. 1 NXT = 100,000,000 NQT (nanoquants).
1 NQT is the smallest unit of denomination in NXT same as 1 satoshi in Bitcoin.
The Nxt Server accepts the fee in NQT, so we pay exactly 100 million NQT ($0.03)

The “broadcast” parameter can be changed to false, in this case you will receive ‘transactionBytes’ in the response, which can be broadcast to the network later using the ‘broadcastTransaction’ request. But today I have set it to ‘true’ to broadcast the transaction instantly.

Remember to urlencode() the message. I insert the filename separated from the hash with a colon into the message.

$payload = array(
"requestType" => "sendMessage",
"recipient" => $recipientID,
"secretPhrase" => urlencode($secretPhrase),
"feeNQT" => 100000000,
"deadline" => 1440,
"broadcast" => "true",
"message" => urlencode($fileName . ":" . $fileHash),
"messageIsPrunable" => "true"
);
$payload_string = "";
foreach ($payload as $key => $value) {
$payload_string .= $key . "=" . $value . "&";
}
rtrim($payload_string, "&");

Send the query to NXT server using sendRequest() function:

$output = sendRequest($host, $payload, $payload_string);

and decode the JSON response from the server to get the transaction id:

if ($output != false) {
$txId = json_decode($output)->transaction;
}

Now that there is a positive response on the accepted transaction and its ID is known, let’s update the record in the in-house db.

$lastId = $pdo->lastInsertId();
$sql = "UPDATE files SET txid = '$txId' where id = '$lastId'";
$result = $pdo->exec($sql);

We can optionally provide these links to the customer for future reference and to prove that the hash was uploaded:

echo "NXT Transaction ID: " . $txId . ",
JSON response";
echo "

Use these links to verify Sha256 hash of your file saved in our internal database against the permanent record in the NXT blockchain:

" . $fileHash;

Optionally email the customer the $txId that they can later use to verify hash or somehow else give them basic information on retrieval of the hash from in-house db and comparing it to blockchain stored hash in the future, by timestamp or other criteria.

This app doesn’t include user authentication. Normally the customer or user of an intranet service would be able to see their files after having authenticated to the site.

This app also assumes that the verification app is out of reach of the in-house database maintainer to prevent faking verification outcome.

Now the record is saved in the company’s database. Show the db record to confirm it’s there.

$sth = $pdo->prepare("SELECT id, txid, hash, uploadtime, filename FROM files ORDER BY id DESC");
$sth->execute();
$result = $sth->fetch(PDO::FETCH_OBJ);
if ($result != false) {
var_dump($result);
}

The verification app

To use the hash verification app the customer must have the transaction ID in the NXT blockchain
passed to them when the transaction was submitted to the Nxt Blockchain.

Suppose the customer does have it, saved in the mail archive or retrieved by other means.
Here it is.

$txId = "111111111111111111";

Let us see what our in-house database has for the hash of the file. Fetch and save it in $hashInDb.

$pdo = new PDO('sqlite:/home/lurker10/phptutorial/files.db');
$sth = $pdo->prepare("SELECT hash FROM files where txid = '$txId'");
$sth->execute();
$result = $sth->fetch(PDO::FETCH_OBJ);
if ($result != false) {
$hashInDb = $result->hash;
}

Send a request to the NXT server and fetch all information stored in the NXT blockchain for transaction with the given ID.

$payload = array (
"requestType" => "getTransaction",
"transaction" => $txId
);
$payload_string = "";
foreach ($payload as $key => $value) {
$payload_string .= $key . "=" . $value . "&";
}
rtrim($payload_string, "&");

$output = sendRequest($host, $payload, $payload_string);

Decode the JSON response and extract the attachment field where the hash is stored.

In the first part of the app we recorded the filename separated from the hash with a colon.
Now we extract just the hash portion of the arbitrary message.

$attachmentPlainData = json_decode($output)->attachment->message;
$hashInBlockchain = explode(":", $attachmentPlainData)[1];

And compare what we have in the company’s database with what was recorded 1 year ago into the Nxt Blockchain.

if ($hashInDb == $hashInBlockchain)
echo "Hashes are identical";
else
echo "Hashes are not identical";

Next part of this series: Lottery on the Nxt Blockchain in Golang (and PHP)

NXT-crypto-developer

Lior Yaffe: Advanced Concepts in Blockchain Design

Lior Yaffe explains some design concepts that have made it into NXT and the upcoming Ardor platform, such as: Proof of Stake, Brain Wallets, Forging, Prunable data, The Ardor platform, Smart transactions and hard fork management.

The lecture took place on 27.7.2016, at Campus Tel Aviv.

Slides:
https://bitcoil.co.il/files/Advanced….
http://prezi.com/x8jyard5-h51/

Event page: http://www.meetup.com/bitcoin-il/even…

“Ardor snapshot” release – Nxt NRS 1.9.2

Nxt Client (NRS) 1.9.2

THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE

Digital signature: "Stichting NXT"

.sh Sha256: bf135f9d7280860b59fb69d4753e436ed23ebbcf95e1e4112cb707c7a64a20b4  nxt-client-1.9.2.sh

Release 1.9.2: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.9.2.zip

1.9.2 .zip sha256: 4fe0520e5b4d0fe244dc9d8ab7943c1a107a7e4227ce4ae9f3236ae1dcc1a8ab  nxt-client-1.9.2.zip

ARDR Snapshots

Snapshotting will start at block 870400 (expected July 14) and end at block 1000000 (Oct 12). Relevant reading: Ardor distribution

To get your ARDR tokens, it is recommended that you keep your NXT balance in your own account.

For balances on exchange accounts, it will be up to each exchange to handle the re-distribution of the ARDR tokens that will get automatically sent to the exchange account at snapshot end.

The 3 major exchanges for NXT; Poloniex, BTC38, and Bittrex will all run internal snapshots of their customers' NXT balances synchronized with the main blockchain. The Ardor tokens will then be distributed to their rightful owners at a ratio of 1 Ardor token for 1 NXT. The exchanges are prepared for new customers outside the Fintech and investment world looking to purchase Nxt tokens for future Ardor tokens with the introduction of fiat currency exchange. Retail customers will now be able to access the Ardor platform and purchase tokens using fiat currency.

NRS 1.9.2 release notes

This is the first stable release in the 1.9 series. Update to this release on mainnet is optional up until block 1000000 (Oct 12), however users are advised to do it earlier, as after July 14th updating will trigger a blockchain rescan.

The main new feature in 1.9 is the distribution of ARDR assets. See the 1.9.0e changelog for details.

Performance optimizations for blockchain rescans and for snapshot balance calculations. Added nxt.dbMaxMemoryRows property to allow setting the H2 MAX_MEMORY_ROWS parameter.

Updated Jetty to version 9.3.10, delete the old lib folder before unpacking on top.

Source: https://nxtforum.org/nrs-releases/nrs-v1-9-2/

Also see: Nxt 2.0: Ardor childchain blockchain platform

The NRS (Nxt Reference Software) Client is the Nxt core developers’ official wallet release.

NRS is a locally hosted client server application. By default it downloads the Nxt blockchain, but from version 1.10.0e you can run it as a light client as well as a full node. To forge and earn forging fees from processing transactions on the network you must run the Nxt Client in full mode, which is possible even on small devices like laptops, or on a Raspberry Pi. There are also bounties for running public nodes.

The Nxt Client is easy to install. Use the 1-click installers for Linux, Mac and Windows or read this INSTALLATION GUIDE to launch the NRS .zip from terminal.

Nxt [ANN]: NRS 1.9 experimental (updated)

Nxt Client (NRS) 1.9.1e

THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE

Digital signature: "Stichting NXT"

.sh Sha256: 4e21c830f43d9d842c7005252b2a75983a4a5a067994c1b49ac1339f8ac5ed2c  nxt-client-1.9.1e.sh

Release 1.9.1e: https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.9.1e.zip

1.9.1e .zip sha256: 097f2d10589b43bf5882f1e0d06f83740f09ca6f037ae73252eb6c555819b212  nxt-client-1.9.1e.zip

NRS 1.9.1e release notes

Fixed a client UI bug affecting some form submission.

Source: https://nxtforum.org/nrs-releases/nrs-v1-9-1e/

For further information about 1.9 branch, please read the NRS 1.9.0e release notes.

Relevant reading: Ardor distribution

Also see: Nxt 2.0: Ardor childchain blockchain platform

ARDR Snapshots

Snapshotting will start at block 870400 (expected July 14) and end at block 1000000 (Oct 12). Relevant reading: Ardor distribution

To get your ARDR tokens, it is recommended that you keep your NXT balance in your own account.

For balances on exchange accounts, it will be up to each exchange to handle the re-distribution of the ARDR tokens that will get automatically sent to the exchange account at snapshot end.

Damelon (Bas Wisselink) writes on 20-06-2016, 09:46:54 pm:

"The Nxt Foundation will be in contact with exchanges to help out with this process. Will keep you updated."
Source: https://nxtforum.org/index.php?action=post;quote=219422;topic=11475.0

The 3 major exchanges for NXT; Poloniex, BTC38, and Bittrex will all run internal snapshots of their customers' NXT balances synchronized with the main blockchain. The Ardor tokens will then be distributed to their rightful owners at a ratio of 1 Ardor token for 1 NXT. The exchanges are prepared for new customers outside the Fintech and investment world looking to purchase Nxt tokens for future Ardor tokens with the introduction of fiat currency exchange. Retail customers will now be able to access the Ardor platform and purchase tokens using fiat currency.

 NRS 1.9.0e release notes

This is an experimental release.
It is a required update for all testnet nodes, optional for main net.

This release enables taking multiple snapshots of accounts NXT balances, every 60 blocks, for a period of 90 days, and distributing an ARDR token based on the average of those balances, at the end of the snapshot, to be used for the Ardor consensus chain token distribution in Nxt 2.0.

On testnet, the snapshot will start at block 649400 and end at block 779000 (June 24).

On mainnet, the snapshot will start at block 870400 (expected July 14) and end at block 1000000 (Oct 12).

Since on testnet the starting block is in the past, on upgrade to this release a blockchain rescan will be performed automatically in order to calculate past account balances. Those who delay upgrading their mainnet nodes until after block 870400 will also experience such a rescan. However, the hard fork block is set at the end of the snapshot, so the final deadline for upgrading to 1.9 is at blocks 779000 and 1000000 respectively.

To get your ARDR tokens, it is essential that you keep your NXT balance in your own account. There is no need to run a node or forge. It is the confirmed NXT balance that is used for the snapshot, not the unconfirmed (available) balance, so having some NXT locked in open AE bid orders, shufflings, etc, will not affect your ARDR distribution.

For balances on exchange accounts, it will be up to each exchange to handle the re-distribution of the ARDR tokens that will get automatically sent to the exchange account at snapshot end.

A new getFxtQuantity API has been added, which allows retrieving the already accumulated ARDR quantity for each account during the snapshot, and an estimate for the quantity yet to be obtained. While snapshots are done every 60 blocks, the numbers that this API returns are updated once every 720 blocks only.

Snapshot balances used for the ARDR distribution for a specific account can be recorded in the log by setting the nxt.logFxtBalance property to that account number, and performing a rescan if the snapshot has already started.

Added some additional transaction bytes validation, and phasing parameters validation, to take effect after the hardfork.

Added getAssetDividends API, to retrieve the dividend payment history for an asset. It can be viewed in the client by clicking on the new "View Asset Dividends" link on the asset exchange page. Dividend payments made before a node is updated to 1.9.0e will not show in this history, unless a blockchain rescan is forced manually.

After the hardfork block, asset dividend payment transactions will be limited to not more than one per asset every 60 blocks.

Added a new Messages table in the client UI. Allowed uploading a file as a message attachment, plain or encrypted, and downloading such messages as files.

All create transaction APIs that support prunable message attachments now also optionally accept multipart file uploads as messageFile or messageToEncryptFile parameters, or when using client-side encrypted data the data part can also be uploaded using encryptedMessageFile parameter. As the test API page does not support multiple file upload parameters, upload buttons for those are not currently available there.

Accept sharedKey parameter in downloadPrunableMessage and getPrunableMessage APIs.

Added client UI support for decrypting messages using a shared key, to allow disclosing the shared key for a specific encrypted message to a third party in order to decrypt it without having to reveal the account passphrase.

Forging optimization to reduce block skipping when switching forks.

Minor other bugfixes and UI improvements.

Updated H2 library to version 1.4.192, tika to 1.13, and slf4j to 1.7.21. If
installing manually, make sure to delete the old lib folder first.

Source: https://nxtforum.org/nrs-releases/nrs-v1-9-0e/

The NRS (Nxt Reference Software) Client is the Nxt core developers’ official wallet release.

NRS is a locally hosted client server application. By default it downloads the Nxt blockchain, but from version 1.10.0e you can run it as a light client as well as a full node. To forge and earn forging fees from processing transactions on the network you must run the Nxt Client in full mode, which is possible even on small devices like laptops, or on a Raspberry Pi. There are also bounties for running public nodes.

The Nxt Client is easy to install. Use the 1-click installers for Linux, Mac and Windows or read this INSTALLATION GUIDE to launch the NRS .zip from terminal.

Announcement: Nxt 1.8 features

The work on Nxt and the Nxt NRS client continues. The Nxt core developers have just sent a list of the new features which will be implemented in the upcoming 1.8 release, expected to be released in April.

  • Desktop Wallet

    Run the client wallet as a desktop application.

Riker writes:

Until now when starting the NXT server, the user had to wait for the server to start, then open a browser and point it to http://localhost:7876 to start the browser wallet.

Starting from this release, starting the NXT server would immediately launch a desktop wallet application based on the same design of the browser wallet.

See: https://bitbucket.org/JeanLucPicard/nxt/issues/338/desktop-wallet

  • Account Monitor

    Server side component which automatically funds specific accounts based on various criteria to make sure the account owners always poses enough NXT to transact.

ScripterRon comments:

You can monitor Nxt, Asset or Currency.

When a monitored account balance becomes less than the threshold amount, a transfer transaction is initiated to transfer Nxt/Asset/Currency from the funding account to the monitored account.

Multiple account monitors can be active.  Monitored accounts are identified by an account property.  The account property must be set by the funding account owner.

  • Wallet home customisation

    Open the wallet on a specific page or modal.

Riker writes:

This feature enables linking into a specific page or modal of the client web wallet from an external web site or link.

For example, connecting to: http://localhost:7876#account=NXT-22222-…&modal=send_money_modal&recipient=NXT-33333

would log in as account NXT-22222 open the standard “Send Money” modal and pre-populate the recipient field with the value NXT-33333

See: https://bitbucket.org/JeanLucPicard/nxt/issues/320/start-the-client-on-a-specific-page-or

  • Add-Ons

    Simple server side plugin framework

Join the Nxt 1.8 conversation on nxtforum:
https://nxtforum.org/general-discussion/upcoming-features-in-1-8-release/

In parallel with the above, Nxt lead-dev, Jean-Luc, has started working on the Nxt 2.0 design.

Read more about the Nxt 2.0 design proposal:
http://test.nxter.org/nxt-2-0-design/
http://test.nxter.org/nxt-2-0-design-proposal-should-investors-and-asset-issuers-be-afraid/

Comments and ideas for the Nxt 2.0 design can be posted in
https://nxtforum.org/core-development-discussion/nxt-2-0-design/

DeBuNe – a Decentralised Business Network on the move

NXTER.ORG’s RubenBc interviews Roberto Capodieci, who is the CEO of DeBuNe (Decentralised Business Network) and OTDocs.com (Open Trade Docs) and also the Founder of TheSoundKey.com + Go.Notifile.me.

Roberto has extensive experience in the IT and business sectors. At age 10 he developed and sold his first video game, began his IT entrepreneurial career when still in his teens and at 20 years’ old was running an office of almost 40 developers and software engineers.

On January 16, 2015, he announced DeBuNe in Nxtforum and 10 days later began a successful fundraising campaign.

Roberto sees himself as a farmer with a seed in his hand (DeBuNe), a good fertile field to plant it in (Nxt) and needing only some more water (investors) to be sure of a bumper harvest.

RubenBc: Roberto, I’m delighted to be speaking with you and look forward to learning about the technology that you’re presenting to us. First of all: What is DeBuNe?

Roberto: Thanks Ruben –  it’s great to be chatting with you. Basically, DeBuNe was born with the aim of decentralising business processes. More specifically, putting business processes on the blockchain, delegating the execution of pre-agreed decisions to smart contracts and phasing transactions. DeBuNe therefore enables entrepreneurs to put the administrative aspects of their business relationships on auto-pilot. This of course means they can then focus much more on the aspects of their work that require their key skills.

RubenBc: What types of project are currently running on the DeBuNe platform?

Roberto: Before having the chance to become a service open to everyone, DeBuNe has become a technological foundation for other projects of our own. We’ve been using it as a platform to implement some of our other technological solutions:

For example, OTDocs. This was the first project to use DeBuNe decentralised business process solutions to help manage documentation in international trade finance. We’re currently working on proof of concept pilot projects with several banks in Singapore and Australia.

Another of our projects is TheSoundKey; this is a small hardware device you can use to digitally sign blockchain transactions while making sure your digital identity is absolutely secure at all times.

Last, but not least, our latest project – my favorite and for sure the best – but it’s still top secret! One of the four versions of this project, http://go.notifile.me, will run on the Nxt blockchain, and will hopefully help to keep Nxt alive!

RubenBc: Do you require a new financing round? If so, will you be making use of the Nxt platform to raise the finance?

Roberto: The short answers are: not yet and yes I expect we will be doing so but only when the time is right. Nxt of course is not only a platform, it’s also a community and it was the amazing enthusiasm and support of the Nxt community that gave me, and the rest of the team, the courage to drop everything else and focus 100% on DeBuNe and collateral projects. The funds which we raised initially represent less than 10% of what we ourselves have invested so far.

The income generated by the DeBuNe projects is distributed according to asset ownership which in practice means that approximately 25% is distributed, as revenue share, via the Nxt platform, to the individual asset holders and the rest is retained by DeBuNe to cover the running costs. This is why DeBuNe will never put up for sale in the market more than 50% of the total amount of assets.

To support our efforts we have started offering consulting on blockchain projects, and implemented a couple of solutions. We are now hoping with our most recent (and still top secret) project to generate some fast income, and at the same time we are closing some paid pilot projects with some banks in Singapore.

We haven’t yet accepted any seed fundings with our startups because, before we sell any equity to investors, we want the companies to be worth as much as possible. In this way we’ll be able to raise the necessary finance without having to give away too much share capital.

RubenBc: I’ve read some of your articles, blockchain technology clearly fascinates you and specifically the Nxt blockchain…. How do you think DeBuNe can change the way a business is run?

Roberto: Through data decentralisation, combined with the use of digital signatures and thus identities, secure “timestamping” of transactions, non-repudiation, and pre-programmable actions. These are all key aspects of how DeBuNe can prevent business processes from being manipulated by any third party.

Two other things are needed. First, a reputation management system that lets everyone know how much trust they can place on a user via his digital identity (i.e. their public key on the blockchain with which they sign all their digital transactions). Second, coupled with that, a good decentralised KYC system which ties a person’s or company’s real identity to their digital identity. Together these two things will empower people and companies all around the world to do business with each other, regardless of where they are located, or what prejudices other people may have of them or indeed they may have about other people.

RubenBc: What Nxt features are you using?

Roberto: We pretty much only use the messaging system and sometimes the Alias System. We may consider the use of Phased Transactions.

RubenBc: We have started 2016 with a remarkable increase of confidence in the crypto ecosystem thanks in part to the prospect of another large crisis in the financial markets. What will happen with DeBuNe during 2016?

Roberto: DeBuNe will take time to release a finished product, due to several legal and practical (funding) reasons, but it has opened the doors to the means to get there. DeBuNe sub products will see the light of day this year, and I am very confident that they will succeed!

RubenBc: Do you think that the growth of Nxt’s adoption and other cryptocurrencies will be constant, progressive or will there be an event which will make it grow exponentially?

Roberto: As with any new technology there is a huge need for education in order to gain adoption. At the moment though, the “blockchain” is just a buzz word and every financial institution thinks it needs to have a project involving one, even if in most cases they have not much idea of what it means. And, at the other end of the supply chain – the end users – don’t even know what they are using.

I recently overheard someone expressing his surprise that to use Facebook he needed an Internet connection: to him Facebook was an application on his phone, and had nothing to do with the Internet. It will therefore very likely take a few years before this person understands crypto platforms!

Roberto Capodieci: https://sg.linkedin.com/in/debune
The DeBuNe whitepaper: http://debune.org/DeBuNe.pdf

Read more about Roberto Capodieci and his background + blockchain visions in the The First Nxt Book (to be published in late February/early March 2016). 

Shareholders Meeting via Blockchain

It seems we are witnessing a revolution in the corporate world caused by blockchain technologies. We’re moving quickly towards a new business ecosystem of virtual corporations, distributed autonomous corporations, smart contracts, new models of funding and so on. This article is about the exciting possibility of having distributed shareholders’ meetings where results are public and counted in a trustless way.

Since late April last year, I’ve been working on the NXT cryptocurrency as a core developer. NXT is a 100% proof-of-stake cryptocurrency aiming “to transform a cryptocurrency into a decentralised financial platform that supports a thriving and fast-growing digital economy” (unlike hybrid Ripple’s approach which isn’t fully decentralized).

Since 12 May, NXT has had the Asset Exchange (NXT AE) as a core feature. Anyone can now issue assets on this totally decentralized and uncontrolled exchange and trade them.

You can monitor your Nxt asset purchases either via your client or via a number of independent web sites: NextBlocks, NXTReporting and SecureAE  (where you can also purchase Nxt and issue assets).

Read the asset descriptions and you’ll quickly gain an appreciation of the wide range of different applications and services that have already been built on top of the Nxt platform and they’re just the beginning; the start of what is set to evolve into an entire financial and economic ecosystem.

The key feature of the NXT AE for businesspeople is that they can fund their business via asset issuance, getting money from anyone (not just angels/VCs, as with KickStarter), and they can do so from day one and for a low fee.

Imagine getting funding directly from a community needing your product. And, wouldn’t it also be awesome to get feedback and community-powered decisions?

With the voting system I have finished recently that will all be possible. The voting system will be introduced in NRS (NXT Reference Software) 1.5. The latest release version is 1.4.16, so voting API & GUI is already accessible. I can share some API details right now as they will likely remain unchanged.

Also see: Nxt Voting Teaser video (GUI and functionality)

Consider the example of an indy developer making a game. First, he got some funds via the asset exchange. Then he made a promising v.1 of the game. Both the concept and its implementation are still raw but the fans are excited! So he wants to ask the community whether he should polish v.1 or instead build v.2 on the basis of a better concept, or… Having decided on the different options, he starts the poll:

    val question = "Further directions in game development. "
    val description = "I got some great reviews. I have 10000 NXTs left. How should I spend them?"

    val finishBlockHeight = Nxt.getBlockchain.getHeight + 1440 // ~= 1 day
    val options = Array("Improve graphics and release it ASAP", "Start to work on v.2 to get funds for it's development", "Better ask experts, e.g. attend GameDev Conference", "Game is abortive. Stop working on it.")

    val optionModel = Poll.OPTION_MODEL_CHOICE
    val votingModel = Poll.VOTING_MODEL_ASSET

    val pb = new PollBuilder(question, desc, options, finishBlockHeight, optionModel, votingModel)
    val assetId: Long =  // assetId here
    pb.assetId(ai)
    pb.optionsNumRange(1, 1) // only 1 option to choose

    issueTxToGodId(new Attachment.MessagingPollCreation(pb), phrase1)

A vote could be sent with following code:

    val poll = Poll.getByName(question).head
    val vote = Array(0.toByte, 1.toByte, 0.toByte, 0.toByte)
    val attachment = new Attachment.MessagingVoteCasting(poll.getId, vote)
    issueTxToGodId(attachment, phrase2) 

1440 blocks after starting the poll we can get and print to console poll results (where 1 asset=1 vote):

    val pr = PollResults.get(poll.getId).get
    pr match {
        case cpr: nxt.PollResults#Choice =
            val m = cpr.getResults.toMap
            println(m)      
    }

So, we are soon going to have fair, cheap, public and distributed shareholders voting! Just imagine how that could change the world of business.

Notes:

1. This blog post (as revised) was first released by Kushti on 2. The minimum fee to issue an asset on the NXT AE is 1000 NXT. The transaction fee is currently 1 NXT.

NXT Weekly 26.01.2015

Welcome Nxters: newcomers as well as long-time community members!

News Summary

Nxt has just released another major feature: The Monetary System, which allows users to issue customized coins on top of the Nxt Network. The community has voted on whom to entrust with spending our community funds, lots of 3rd party projects are cooking, the Consensus Research Group has released reports about the Nxt PoS algorithm, and also: You can now donate towards the possible destruction of our blockchain. Sounds massive? It is. This is NXT Newsletter #16.

top_no10

In this week’s issue, the focus is mainly on the inner workings of the Nxt core tech and the Nxt Community.

Topics

  • The MS launch
  • CFC: Voting result
  • New Nxt core devs
  • Kill the blockchain!
  • Consensus Research Group
  • Hail to the old committees
  • Quote of the week
  • Words of Wisdom of the week

The Monetary System launch

The Nxt Monetary System (MS) has launched. Using the various parameters outlined here, anyone can now create customized currencies on top of the Nxt blockchain. New coins can be designed for specific purposes, some of which are touched on in this article.

750+ currency names were registered within the first 24 hours of the launch, making it a good day for forgers, with approximately 370K NXT in fees (40NXT – 25,000 NXT per registration) being paid out.

With the Monetary System, you can create coins without having to set up and bootstrap a network, as it’s already backed and secured for you by the Nxt Network. Bootstrapping is one of the biggest hurdles to overcome when launching a new p2p coin, so this is of particular relevance whether you’re a person, a business or a local community which wants to go digital with an already existing local currency. Loyalty points, game currencies, and controllable/pegged currencies are easy to create, it’s even possible for existing coins to be moved onto the Nxt blockchain. The Nxt wiki has a great in-depth tutorial, and if you need further help, you can visit the Monetary System forum.

Another use case is the ‘crowd funding coin’, which is ‘sold’ in exchange for donations; if a pre-set amount of ‘coins’ have been ‘bought’ at a pre-set time, the funds are released to the issuer. If not, the money is returned to the donators/buyers. This feature turns Nxt into a 100% decentralized crowdfunding platform.

As usual with Nxt, this new core feature doesn’t come with an in depth ‘For Dummies’ manual. Use cases are proposed, but the community is encouraged to test, learn and tweak it, brainstorm and find more use cases. If you want to play around with issuing currencies, you are advised to start by doing so on the Nxt Testnet.

Nxt.org has set up an easy to access testnet node, and a well-funded account will provide you the testNXT you need to get familiar with the Monetary System. Instructions and testnet can be found here.

On mainnet new ‘PoW’ coins like EGOLD, ELEMS and FORKK are being minted with the Nxt Mint Worker Utility and sold in the in-client exchange, whilst in the giveaway threads in Nxtforum useless MS currency coins, created out of thin air for a 40 NXT fee, are being given away for free.

While some early MS coins are meaningless, others have clear purposes. These are a few examples:

ORA

ora_logo

The Ora project started out on bitcointalk.org with an idea of making a “free and fairly distributed” 2.0 PoS coin based on the Qora source code. Ora describes itself as being a “leaderless, decentralized ‘starfish’ community software development project”. The initial method of stake distribution was a giveaway using the Nxt Asset Exchange: 889 people registered for a free stake of 166,666 assets each, between June 24 and July 8.

On Nov. 25 Ora announced that it would be launched as a Monetary System coin.

Kora:

When CFB first suggested this option in June the only real reservation was that ORA would be dependent on the NXT platform for its very existence. Six months on, as NXT celebrates its first birthday we believe the connection with NXT is a major advantage for ORA. The NXT ecosystem is resilient, vibrant, and grows stronger every day, and the development output over the last 12 months has been truly staggering.

We believe the NXT platform offers ORA long term network stability, just as TCP/IP offers stability for higher order protocols like HTTP, FTP, SMTP, and this stability will allow us to focus our resources and attention on the more ‘retail’ level concerns, like user experience, leaving the ‘backstage’ grunt work of network security and stability for NXT. As always, we welcome any feedback our stakeholders might have, and we take this opportunity to invite all people to join us, particularly those with dev skills who are interested in developing the ORA applications that will run on NXT.

ORA’s three letter code is the ISO compatible, ‘XOR’, so ORA is set up for future growth and international recognition.

ZIN

ZIN_Logo

Sepehr:

We have issued ZIN as a POS Crypto in NXT Monetary System and will assign everybody with a SMS Number 100 ZIN soon! It can be the biggest airdrop ever in Cryptocurrency history!

Sepehr is a veteran Nxter from Iran, and also the issuer of another asset, Forgecoin, which has earned him trust in the community by paying dividends to its holders for 7 months.

CryptoZin will make NXT (as well as the MS coins built on it), BTC and other top altcoins simple to use for anyone with a smartphone. We don’t yet know whether ZIN will have its own monetary value or not. But by sending a Nxt backed cryptocurrency as a promotional offer to “anyone in the world with a mobile phone”, Sepehr will be indirectly demonstrating the value of his service. ZIN will prove to a non-tech audience that CryptoZin not only works but also is so easy to use that they can send ZIN/MS coins on to friends or even grandparents. Next step, of course, will be to teach them the value of real cryptocurrencies. CryptoZin plans to integrate SuperNET.

https://nxtforum.org/assets-board/(ann)-(cryptozin)-cryptocurrency-for-anyone-with-a-smartphone!-)/

TSC

jl777 has suggested in SuperNET Slack that he will issue an MS coin with a special use case. Exactly how he will tweak it, is something we’ll have to wait and see, as the announcement only contains limited information about this.

jl777:

I want to make a short life cycle realtime currency for poker chips. We need a way to do 1000 tx per second between the players as the poker players are playing that fast. Any change in players extinguishes the currency, and it goes to something more solid, maybe NXT, maybe some MS coin. I believe I figured out how to achieve realtime tx, backed by locked NXT, freely exchangeable, verifiable. Still some unsolved issues but I feel the locked MS coin is a key part of this.

James has not earned his respect in the crypto world by talking tech without backing his words with actual code. So we might soon see a new MS use case turn up here, as part of a feature in his brainchild, the SuperNET.

LTB or not?

Swiss NXT and Bitcoin investor Marc De Messel has recently offered Adam B. Levine to buy out all Let’s Talk Bitcoin coins for 4 million NXT, provided that Adam would use NXT as his reward currency instead. After having his offer appreciated but turned down for various reasons , Marc changed his offer to this: If the LTB crew and community re-issues their LTBcoin experiment as an MS coin with additional features, Marc will back it with 2 million NXT in addition to its own current net worth.

The discussion about his offer is ongoing and can be followed here.

So what’s next?

The Monetary System can be used in its most raw form within Nxt’s NRS client (like any other core feature), but as usual with Nxt, further developments, including third party ones, are quick to appear or at least be under discussion: a java ‘minter’ has already been launched, NxtMint, there’s talk going on about making easily customized standalone MS-wallets, MyNXT has released an MS-plugin for their online wallet, and MS enhancement proposals are being discussed with the core devs.

To discuss the use of MS currencies in Local Exchange Trading Systems, visit this thread.

Anyone can build on the Nxt platform for free. There’s a list of API calls here, and a list of the public nodes available for all. Inside.org is an initiative designed to help new Nxt programmers, and on the forum, you can get help from the Nxt core developers themselves. Nxt is an easy to use crypto platform, and with the MS core feature launch, Nxt has now taken another big technological step forward ahead of the competition. The current use cases for the NRS client are merely the tip of the iceberg of possibilities, as described in the Nxt [CORE] article series.

CFC: Voting result

The proposal on how to structure a new and pro-active Nxt Community Fund (as mentioned in the last newsletter) was adopted with 94.1% of the votes, meaning that the remaining NXT (approximately 6M in total) from the 3 existing community funding committees will be transferred to this NEW committee, which will be given authority to act and spend on behalf of the Nxt Community.

On December 03, interested Nxters were asked to nominate themselves for one of the 8 unpaid positions in CFC. On January 14, a 2 weeks’ voting round finally began and the result of the vote is the following lineup:

Chair : EvilDave
Secretary: Cassius
Business position : Damelon
Technical member : ChuckOne
Treasurers: DomP and Pouncer

Congratulations to all those elected and not least a great big THANK YOU!

New Nxt core devs

A new developer team has joined our CORE dev team. They will implement:

  • Global Collaboration, which includes:
    • Project Management.
    • Regular and flexible payment models via simplified Smart Contract Transaction.
  • Reputation System.

Their vision is a decentralized business network (https://nxtforum.org/debune/announcing-debune/).

NRS manager ChuckOne writes:

Please welcome the new members of the core dev team by providing donations or help to them. Roberto is going to release assets for crowdfunding in order to try covering their expenditures for both the NRS core additions and their third-party application DeBuNe on top of Nxt.

Welcome, Roberto (Capodieci), Yudi and aryanatameiyana. A full list of Nxt core devs are here.

Kill the blockchain!

A week ago a visitor from Bitcointalk made it to the Nxtforums.

cynicSOB:

Hi! I’m cynicSOB and I’m a cynical SOB
and I’m here to hack your coin
white hat
promise!

Nxt raises funds for its funeral

BCNext once advised: Do not trust strangers on the Internet, especially if their nickname is “BCNext”. It’s not the first time that the Nxt Community has set up bounties and dared hackers to attack the Nxt blockchain and kill it. cynicSOB has been met with open arms and best wishes by the community, as well as pledges of both NXT and BTC bounties from Nxt veterans, and EvilDave (former TechDevFund Committee member, now chair in the new Community Funding Committee) is offering cynicSOB technical support to carry out the attack. Unfortunately, an attack on the Nxt blockchain would cost around 3,7 million dollars, so the attack will be carried out on testnet.

EvilDave:

Could we please beef up the TestNet and get some more nodes up? I’d like to see around 20 nodes, with at least 10 forging accounts. We may need to do some serious TestNXT redistribution, as cynicSOB will also need a substantial amount to set up an attack (10% of the total was suggested) as well as substantial sums for the forging accounts.

Let’s see if the creation of BCNext and the Nxt CORE dev team can be trusted. We’re in the hands of cynicSOB. The ongoing drama can be followed here.

rlh:

Only in Nxt do prominent Nxt users want to see their coin hacked!  We know our devs can innovate past any verified flaw! ;D

Consensus Research Group

December 12, Kushti published a simulation tool for Nxt forging on GitHub, taking a less ‘cynical’ approach to the same declared goal – testing whether the Nxt PoS tech is as secure as we claim it to be or not. With ‘Consensus Research Group’, Kushti has started what he calls “the first independent research group going to bring formal verification to the world of cryptocurrencies.”

Kushti:

Cryptocurrencies suffer from unproven claims, bold statements, low-quality ‘papers’ and naive implementations, though the cost of an error could be very high (USD$ millions).

Consensus Research Group is going to improve overall quality of thinking about cryptocurrencies with:

  • proven open-source reference implementations code made partly at least in Coq programming language/theorem prover (https://en.wikipedia.org/wiki/Coq).
  • executable simulations anyone can play with (to e.g. find best parameters under some assumptions).
  • formal but understandable papers.
  • coins’ developers’ consultations.

The research project began when Kushti started writing a series of personal blog posts about the Nxt forging algorithm. Following up on the ideas contained in the first 2 posts, his friend andruiman published a statistical paper on some of the properties of Nxt forging, thereby causing a heated debate in the Nxt forums. He converted Kushti’s model into Coq, “proving some basic properties as theorems, and introducing multi branched forging (which could be turned into so-called Transparent Forging during implementation and also to open the door to Nothing-at-Stake investigation.”

Paper on attacks related to Multibranch Forging:  https://github.com/ConsensusResearch/articles-papers/blob/master/multistrategy/multistrategy.pdf

1st paper: http://www.scribd.com/doc/248208963/Multibranch-forging
MultiBranch Forging Simulation Tool: https://github.com/ConsensusResearch/MultiBranch
Nxt PoS forging simulation tool: 
https://github.com/ConsensusResearch/ForgingSimulation

Vitalik Buterin (Etherium) has discussed the first paper in this thread on reddit.

On January 14, 2015, Kushti concluded:

Nothing-at-stake attack – not possible at the moment! Will be possible when a lot of forgers will use multiple-branch forging  to increase profits. (…) In such scenario attack is possible only within short-range e.g. with 25 confirmations needed 10% attacker can’t make an attack. And attack is pretty random in nature, it’s impossible to predict whether 2 forks will be within N best forks (from exponentially growing set) for k confirmations. So from our point of view the importance of the attack is pretty overblown.

People are invited to carry out their own experiments using N@S simulation tool.

Kushti first entered the Nxt stage as the lead developer of a Techcrunch Disrupt Hackathon project, Cryptamail, a decentralized email system built on top of Nxt. He joined the Nxt CORE dev team as a tester and subsequently went on to develop several Nxt core features, including the Voting System and 2-Phased Transactions.

Consensus Research Group has issued a crowd funding asset (‘consensus’, asset ID 5841059555983208287) which is sold in lots, the timing of the sales being based on the achievement of certain development milestones. The price of each asset is 1 NXT and should be bought only from the Issuer account. There will be no dividends but there will be opportunities for investors to start research projects by vote. You can view all the results here: https://nxtforum.org/consensus-research/

Hail to the ‘old’ funding committees

To round this off, let’s take a look at some of the projects that the soon to be obsolete Nxt Funding Committees actually funded.

Recurring core developer salaries

The most valuable investment of the community funds: The core of the Nxt platform.

Nxtwiki.org

https://wiki.nxtcrypto.org/

300,000 Nxt to cover 12 months of bounty funds at 25,000 Nxt per month.

NxtWallet / NRS GUI

400,000 NXT. http://nxtra.org/nxt-wallet/ (redirects to nxt.org)

Freenxt.org

10,000 NXT for the faucet. http://freenxt.org

Nxt-Starter.com

One of the first community initiatives to get funded. 200K NXT were sent on April 23 to the NXT crowd funding site initiative, but then things got complicated. On October 27 POPPP announced that the site was finally up.

Nxt-Starter.com is fully functional but still in its first version. Payments are made through a coinpayments.net solution – the plan is to integrate p2p funding with NXT and MS-coins directly, making the payment system fully decentralized. If you want to raise a bounty for the NXT Community, you can do it here for no fee. In addition to running crowdfunding campaigns you can get a page for your Nxt Marketplace store, and list projects that have already got funded.

Nxt-Starter is part of the NXTweb asset, which will also contain a freelancer and a microjob website, based on source code from CoinEvolve. But, as they say, that’s another story.

The Nxt B-day giveaway

10 random NXTER.ORG newsletter subscribers have been picked as the winners of 100 NXTP each, as announced in the last NXT Newsletter. The Nxt Community was asked for random numbers, which we checked against our list of email subscribers to find the lucky winners and then asked them for their Nxt account ID to receive their prize. Congratulations to the winners!

6 x 100 NXTP have been sent out. As for the last 4 winners, if they haven’t claimed their prizes before 27.01.2015, new winners will be picked – so now is the time to check your inbox and spam box.

Quote of the week

Damelon

Work needs to be rewarded

Words of wisdom of the week

ChuckOne:

NXT will be the fuel currency of the Nxt ecosystem. People will pay NXT to forgers (as they do now) in order to get transactions verified. Forgers will sell NXT to people in exchange for currencies. So, there will be a market that determines the price of NXT.

Also read: The Value of 10 NXTs

Nxt [CORE]: Monetary System

Nxt’s Monetary System allows users to create new decentralized currencies on top of the secured Nxt blockchain. New coins are highly customisable, with a wide range of parameters that can be set to govern their properties and use.

The Nxt Monetary System (MS) enables the launch of altcoins without going through the trouble of bootstrapping the currency with its own blockchain and network, thereby removing a major impediment to easy, real-world adoption and use of different customized cryptocurrencies.

The ultimate value of a new coin is determined by the market, depending on adoption and demand, and by the parameters set by the issuer. However, coins may also be created by ‘locking’ a certain amount of NXT, thereby giving a floor value to the issued currency at which they can be redeemed for NXT if desired.

With Nxt, new coins are highly customisable, with a wide range of parameters that can be set to govern their properties and use. It is possible to launch an MS coin that is distributed by proof-of-work, but secured by Nxt’s PoS algorithm. It is also possible to create fiat- and commodity-backed tokens for particular real-world applications.

These allow for the creation of bespoke and niche currencies for highly specific applications, crowdfunding coins, ‘regular’ altcoins, reward points, coins pegged to fiat currencies or precious metals, while also being a stepping stone to new future Nxt features, such as p2p loans, meaning that Nxt can become the underlying tech for a completely decentralized banking system.

When? Now!

MS can be explored in the Nxt testnet, ask for testNXT here.

The main net NRS release that will implement the MS System has also been released. Monetary System will be activated with block 330000, and nodes not running 1.4.5 or later will be on a fork.

mscoins_testnetTestnet screenshot

Read an NRS installation tutorial here or on nxt.org.
A guide to the NRS Client interface can be found here – or watch the video tutorials.

Potential impact and significance

Monetary System offers greater exposure to NXT as the machinery that powers financial transactions, over and above its utility as a currency; however, this does not imply that NXT itself will become worthless. NXT remains a ‘decentralised store of value’, with fixed supply. MS currencies may become something akin to a decentralised credit system, meaning that users transact with MS coins but all of them depend on NXT for their ultimate utility.

Of course, this does not mean that MS will not catalyse a shake-up of the NXT ecosystem, providing an impetus for the redistribution of existing NXT wealth, as Come-from-Beyond writes:

‘In the beginning we will have an epoch of instability when hundreds of currencies will pop up every day. After a while some currencies will become more and more popular, but the whales will have their wealth dispersed among thousands and they will get only a fraction of initial wealth in the most popular currency.’

The Monetary System is necessary because different currency properties are suited to different applications. Having a series of currencies that fit the needs of the market are the obvious solution to the one-size-fits-all problems of both fiat and any single cryptocurrency. For example, as Come-from-Beyond also writes:

‘Having a fixed currency supply (like Bitcoin and NXT) isn’t ideal for all situations. Fixed currency supplies make a great ‘store of value’, but they make lousy credit systems. The Monetary System is simply another tool to allow people to create local currencies to break free of centrally controlled fiat.’

NXT will be bought by those looking to create currencies – it will not be used to purchase alternative currencies (as is presently the case).

ChuckOne writes:

‘NXT will have one specific use case only: to enable transactions. Nxt Monetary System is about separating power from economy. So, we can basically move the NXT Economy from this platform to another one if something is wrong with NXT or to penalize forgers if they misbehave.’

MS enables a series of far-reaching developments, including:

  • Coin shuffling. Claimable currency units can be shuffled and returned at the same exchange rate, allowing for anonymous transactions without potential loss of value in the process.
  • Fiat-backed tokens. Once USD, GBP, EUR or other fiat currency-backed coins are trading, it will be possible to send fiat money using the NXT infrastructure. This brings the benefits of speed and very low transaction costs to international money transfers. Unlike with Bitcoin and other cryptocurrency transactions at the moment, there would be no volatility, and exchange rates would be negligible (or zero, since these tokens could simply trade internally within the NXT system indefinitely, until the recipient wanted to redeem them against fiat).
  • Local currencies and exchange trading systems to benefit specific economies.
  • Niche loyalty tokens issued by businesses to reward customers. These tokens would also be freely and globally tradeable, meaning the market would set their value beyond what they could be redeemed for within the business in question.

ms_testnet2The NRS Client exchange, testnet screenshot

Monetary System: specifications

The following descriptions are taken directly from MS documentation as it stands at the time of writing. Documentation may change without notice. Latest version can be found here: https://bitbucket.org/JeanLucPicard/nxt/issue/205/monetary-system-documenation

Overview

The ‘Currency’ entity is the basic building block of the NXT Monetary System, currency has a unique name and code and uniqueness is guaranteed by the protocol, currencies can be deleted and their code can be reused under certain conditions.

The total currency supply is divisible into currency units. Like assets, currency units support decimal positions implemented as a client side feature. The maximum number of currency units which can be issued per currency is similar to NXT: i.e. 10^9 * 10^8. The actual maximum units supply is set by the currency issuer. The currency issuer is the account which issues the currency and pays the issuance fee. The issuer is responsible for setting the currency properties and in some configurations has additional control over the currency usage. Like asset balance, currency units can be transferred between accounts.

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, in much the same way as banks or currency exchanges publish their exchange rates. Each account can publish only a single exchange offer at any given time. Exchange offers have an expiry block after which they are no longer in effect.

Buyers and sellers can issue exchange requests to match published exchange offers. Unlike asset bid/ask orders, exchange requests 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 exchange request creates an exchange entity which represents the transfer of currency units, in return, to NXT balance and causes the relevant account balances to update. Issuing an exchange offer reduces the NXT and currency balance of the offering account temporarily until the offer expires. Exchange offers also specify a limit on the number of exchanged units which can be larger than the number of units offered. When a buy exchange request matches an exchange offer the number of units offered for sell is reduced and the number of units offered for buy is increased as long as the limit has not been reached. Once the exchange limit of an exchange offer has been reached, this exchange offer can no longer be used.

CONTROLLABLE – currency property suitable for currencies which need 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 issuer account can issue a large (practically infinite) supply of units in advance, then transfer units to accounts, or offer to exchange units, to reflect actual transactions which take place in an external system. The large supply of units in the issuer account can be used to mimic the effect of creating units out of nowhere to support features such as creating new units and interest payments.

RESERVABLE – currency units are not issued immediately. Instead the currency issuer sets a block height by which the currency is to be issued and a limit of NXT per unit needed in order to issue the currency. Currency ‘founders’ then spend their NXT to reserve their currency stake. If the amount of NXT per unit needed in 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. See below for a discussion of usage scenarios for Reservable currency.

CLAIMABLE – currency units of reservable currency can later be claimed at the same NXT per unit rate reached when reserving the currency. The ability to claim a currency at a certain rate imposes some practical limits on the rates at 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 in much the same way 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 serves as the only mechanism to increase the number of available units after the currency issuance.

NON_SHUFFLEABLE – this property indicates that in the future this currency cannot participate in coin shuffling. By default currencies are allowed to participate in shuffling.

Properties are combined into an Integer bit mask designated as the Currency type.

Currency Exchange

For exchangeable currency, each currency holder account, can publish a single exchange offer specifying the buy rate and sell rate vs NXT and the number of units she is willing to exchange (which cannot exceed her available currency units and NXT balance). Users can observe all currency exchange offers (intuitively similar to fiat exchange offices) and try to match them with buy/sell exchange requests. An exchange offer has an expiration height, as well as a limit on the total number of units which can be exchanged. When units are bought from an exchange offer the number of units to sell increases automatically and vise versa. The publisher can also limit the total transaction volume of currency units traded for a specific exchange offer.

Deleting a Currency

Since the available currency codes are limited to 3, 4 or 5 uppercase letters, the total number of codes is limited to 26^3 + 26^4 + 26^5 – 1 = 12355927 unique values (The code “NXT” is reserved), it is likely that some of these codes will have value in themselves. Therefore deleting a currency is possible under certain conditions depending on the currency type. Users may re-issue a currency, or delete a currency and then issue a new currency, with the same code but with different properties. In order to delete or re-issue a currency an account must poses all the currency units (and additional conditions apply based on the currency type)

Creating new Currency Units

The only way to create new currency units after issuing a currency is using proof of work minting. Other methods of creating units are susceptible to denial of service attacks and/or sock puppets and are therefore not allowed. The controllable currency type provides a partial solution for creating new units, by allowing the currency issuer account to treat her supply as a treasury and only consider units outside of this account as the total currency supply. This approach requires users to trust the currency issuer which can increase the currency supply at any time.

Minting

Users can issue minting requests in order to mint additional currency units. Each minting request triggers a hash calculation based on the submitted data and the currency hash algorithm. The resulting hash code is compared to the target value derived from the current currency difficulty. Minimal and maximal currency difficulty values and minting algorithm are specified when issuing the currency and cannot be changed later. The expected number of hash calculations (i.e. difficulty) of minting the first unit is 2^minDifficulty while the difficulty of minting the last unit is 2^maxDifficulty. Difficulty increases linearly from min to max based on the ratio between the current number of units and the total supply. Difficulty increases linearly with the number of units minted per CurrencyMint request, small minters can mint only a few units per request while large minters can mint large number of units per request.

The number of units per minting request is limited to 1/10000 of the total unit supply. Minting is limited to a single minting transaction per block/account/currency. Currency issuers can specify initial supply of units as a ‘pre-mint’ supply assigned to the issuer account then use crowd funding by making the currency RESERVABLE and EXCHANGEABLE.

Once the currency becomes active the delta between the current supply (reserved supply) and total supply can be minted. The NRS provides a Java based, reference implementation minter, which can be used for minting. In practice we expect users to enhance this minter to calculate hash codes using their Asics or GPUs, trying to match the current target, and when solving a hash, to submit a currency mint transaction (thus paying a fee).

However the hash code is smaller than the target, the currency units are credited to the sender account.

See the documentation for the reference implementation ‘Mint Worker’ utility here #207

Store of Value

The combination of RESERVABLE and CLAIMABLE properties can be used to allocate initial value for a currency by locking NXT. Once the currency is activated the reserved NXT are locked and the only way to release them is to claim back the currency units in return for NXT. This provides the currency with a value based on the locked NXT balance. Note: locked NXT do not participate in forging, therefore, in theory its possible that a large amount of NXT becomes locked as a currency store of value thus reducing the amount of NXT used for securing the network; we are aware of this problem and will monitor it closely. We do not expect this to become a major problem any time soon.

Crowd Funding

The combination of RESERVABLE and EXCHANGEABLE properties can be used for crowd funding; in this configuration the NXT balance reserved by founders is not locked, instead it is sent to the currency issuer account once the currency becomes active. The issuer can use these NXT for its operations and the founders cannot claim back their currency units, only exchange them based on the published exchange offers. Currency issuers can specify the initial supply as ‘pre mine’ and the founders get to share the difference between the reserve supply (also named ‘pre-activation’ supply) and the initial supply.

Fees

Currency issuance fee is based on the length of the currency code:

3 Letters – 25000 NXT

4 Letters – 1000 NXT

5 Letters – 40 NXT

Re-issuing an existing currency with different properties costs 40 NXT regardless of the currency code length. All other currency transactions (as of today) have a fee of 1 NXT.

Unit conversion

Currency is measured in units and like assets has decimal positions, however the blockchain maintains currency balances as a whole number (QNT). Therefore, for example, in the case of a currency which has 2 decimal positions and the client has reserved 123.45 units, the ‘units’ value submitted in the API call should be 12345. APIs using NXT balances should send the value measured in NQT as usual. When specifying ‘rate’ in the API, it calculates the ratio between NXT balance in NQT and currency balance in QNT.

Example: For a currency with 2 decimal positions. When submitting a buy exchange request for 12.34 units at a rate of 5.6 [NXT/Unit] the values submitted to the currencyBuy transaction should be: units = 1234 i.e. units without decimal position or 12.34 * 10^2 rateNQT = 5600000 i.e. rate converted to NQT then divided by decimal position or 5.6 * 10^8 / 10^2

In order to prevent rounding problems when submitting information to the server, the UI enforces the following rule: If a currency has D decimal positions. Unit values cannot have more than D decimal positions and rate values cannot have more than (8-D) decimal positions. Therefore when issuing a currency, we do not recommend specifying more than 4 decimal digits so that conversion rates are also divisible to at least 4 decimal digits.

Disclaimer

  1. Before issuing a currency we recommend issuing a currency with the same properties on the testnet and experimenting with all parameters since these cannot be changed without deleting the currency.
  2. This documentation reflects the actual code implemented as of this date.

API Documentation

This section is relevant to API and client developers.
https://bitbucket.org/JeanLucPicard/nxt/issue/205/monetary-system-documentation

Nxt Monetary System is only one Nxt CORE feature.

Read other articles from the Nxt [CORE] article series.

Also see: Nxt – The Economy Platform – Usecases for everybody

Monetary System on public testnet

UPDATE:

December 23, 2014, 07:40:06 pm

If you use testnet, an upgrade to this release is required, otherwise your node will stay stuck at block 161375.

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1Release 1.4.3ehttps://nxtforum.org/nrs-releases/nrs-v1-4-3e/

sha256:
ac54498c9246593d3aab6f5a2b6f651baa08851856dc0d70402048925f4269f3  nxt-client-1.4.3e.zip

Change log:

Added availableOnly parameter to getBuyOffers and getSellOffers, to return
only exchange offers with non-zero supply and limit, default false. This
parameter is however ignored when both currency and account are specified in
the above APIs.

Added getExchangesByOffer API to get executed currency exchanges for an offer.

Do not log currency exchanges of zero amount.

Fixed setting of peer state. Improvements in connecting to peers.

Added README.md, DEVELOPERS-GUIDE.md OPERATORS-GUIDE.md, and USERS-GUIDE.md
files.

Added search for currencies based on code, name, or description keywords.

Fixed bugs in unconfirmed balance handling in currency exchange and currency
deletion.

This release will perform a rescan, on testnet only.

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUmcIyAAoJEFOhyXc7+e2AetQQAKFXCB7YJKmracY+b+XR4MgK
KMQ807LNljQqcYXPAERizhthbhT5js6FY4Rj+K/EJjQ8iA3TYkvDMBs8ZyPEek1n
5xi4/i8eqfcBfKO5H88w/Em67pVwJuBW+WLtTs0ySCE+w+qUwVbE2v1iwkoJcyXh
ojQN9pKdycAM84Xir/Ukug23nxo/1utc0AutA0TuGMpzUVkO1qNo7x6wQdQdZVla
0iNXM69LJmKQsLJmgPLVxdVi8e4LBUaGrS5ban0CqpfZjO25mZgwqcI2LB0rUQSU
RDC0TPT7ENm/X/6IbRKNuvTp6jOtxNcccCv7R/qjRuDN6enx0X44Hk17gupfxcN1
YJyXqWiOXd82rlHxQHeqDBKh2CcFCL6n7bYAmMIV7KL2NSfZipDc1TW+dCDvyfL2
QNZWEOSSmtjSNMXh1X4cj+LHTwIhhSdu56+05fjBvR4Hd3ryBj+Eay5bAZWfsYrU
x/F7tubNd0JOjsCm+irHKGtvyLAZ7Y8TaAPBKi2K11zIUOLKWkbNS9i1gqzjjtwo
ZHl4w8GD1g5bQ0moz3bpqgU5MZDdE9rlDpQebYsCyG0xNF1jDmcBERxXWCyzY5gk
ndk5+lWeDRGMWC8DmCxaZODlqtBXBEaLn7ZEfOe/mQPFX+0UjxWJfiHvne68hFlx
qRohdybMnKFIwrWIxHig
=p2In
—–END PGP SIGNATURE—–

UPDATE:

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

Release 1.4.2e

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.4.2e.zip

sha256:
85d5a5dc18a4ab603657da4cf77d39aa31e723e11971f0cdecf77c128a0ef420  nxt-client-1.4.2e.zip

Change log:

Additional validations of Monetary System transactions, and bugfixes
in existing validations.

Allow setting a different file as default page for the API server,
in nxt.apiWelcomeFile, default index.html.

Bugfixes in processing decimal point conversions in the UI, affecting
MS and AE transactions.

Bugfixes in currency minting and in MintWorker. The mint dialog has been
removed, you can mint using the mint worker utility or manually submit a
currencyMint transaction from the test page.

Fixed the UI issue of client not responding after submission of certain
MS transactions.

Fixed duplicate transactions on the dashboard UI issue.

The link to the founders table has moved from the currencies table to the
transaction info dialog. Other Monetary System UI improvements.

Improved peer networking to run the sending of blocks and transactions
to peers in a background thread.

This release will force a rescan on testnet only, deleting blocks after
159306.

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUltjDAAoJEFOhyXc7+e2AiuUQAJueFgOTx8giUneyE/8iUCfa
em38kauWCsAQADmb//JJf80BoYbhl+GN7fCcFh5dBblzLGwsl53nWJK+MlmSOhbz
ffwtYOxAEiWEfil2El/AfPZW6Ywwmw8z4qpUclIfgdpA0ps/RNbeXa4hlgG0Hiq3
6EvJftZDgXaR3oJFOf6JXhNmmJW5VKQfF21kqzxt9Vi6E1lZ+EGruaQg/WBzNnD5
W/wg9F9SIxId5OSTo55OVEHxsCL62oMYem0O0A2cf7FtRvJJPXEyg/j4+CQpPF5P
hhU8mre/3HzpHfWMjBeIrMk+dMVJ3URCC1nzaEtTAc3+dGGKfcZvWa7q2ugDR20q
/zenlx0k+UXYxrdRNKH0blPFofl3GaEpHR/P9njy2sULLUygWwCGerTXMNaXyLZx
wnkHDHOhrEjHmtjMEMqfKcc3vuNJPdXg5p/4ulamzrwCdkGUiPftmCJdNB/PNX0T
lbN+LcGH/Iz4ZafJbEszcTlGHhGyhkLF8V+vxZfCUg85aNT2rki4HmC9eCzoxNa2
eHMux55+B7xYgv2auUxX9mJyONKqSObp2ohgHaarqFiQU1AxapKWwKlYtmQtG+Ds
/qv2bb2PDCYD+bBPtNCaOANhTiFcvKhE/sGJPKQk7BsGAGqqJE3E0FW0uwMjzJq1
aphfIDnxhSmS6JVogeQO
=7QnL
—–END PGP SIGNATURE—–

UPDATE:

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

Release 1.4.1e

https://nxtforum.org/nrs-releases/nrs-v1-4-1e/

sha256:

2777a11b701170d7decc01bb82a9049abc37bd293374f852d1810c8195d9842b  nxt-client-1.4.1e.zip

Change log:

This is a bugfix release following 1.4.0e.

Fixed Currency Exchange Booth not working. Fixed currency decimals issue.

Fixed minor bugs in MS transaction validation.

Show total alias count in aliases page. Alias deletion and dividend payment
UI fixes.

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUkfhFAAoJEFOhyXc7+e2AlyQQAOUQHpZc+03kvf0aVQIy45oU
XtHKlt98PwjSKW0MdzyKXXTohdMFTHKR3vvaSRMFqVu+Bvf8ZCL1liLD/J0kidO9
E2AxCvcvAnNKwcNlJQPZjLsboR7aACHG1qwrICOXYeYuBBLrqlUx6UuPjFZdBHXB
BszYDcxpIZ8thUwa/dPhTVdq9Q0AmKoPMME/Jq0OH2tfM3SJEMRI4NkWQbQ8YjmB
1xCt8Z2aplKIJGYmo8pvxZBXvo52N277EKXBnZfn55LoHjIQL3hX4WMBc3GwshhA
9mvJNyMsS4ZTRREH2ZjwiVsu2p+sZ53JBzwhXSpzm2R6LoUrrVA9E6h0ZzKWSj/c
yFvkZjAvGobmmZ6a1kzAiRGKLildkpS2CIDOyy32NMHL9yu538jbbmMvtVVAr1oM
uZehyJxwym+49t0F6dtjwj60nbfYgJoEjXcdidyby+0AQOBHcx+uvhz1easxtsMd
1SgkJ77EdwntK1hXM1Dkx24vA6jABkjihZyBMn3IKQvaSToZFRPe9RXMdqtu+Or6
QmAoXuvy+65I361J6m0wbB1yFvpTgPlOdBAnRr/rx85v3Z+QnNBm6ApmIirINNy7
hRtsvdv6REnI/L8MJdjyGV63nfsuOFqiP32I50cy8XhiO87Cxtpr1SZCHXyk6t5V
iO9Z9Cznf748wQC1TW3u
=TfLA
—–END PGP SIGNATURE—–

 

Nxt NRS 1.4.0e

This is an experimental release!

Jean-Luc:

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

Release 1.4.0e

https://nxtforum.org/nrs-releases/nrs-v1-4-0e/

sha256:

9322c03f7e9ddc97278de25a4f14006f00d0c88974c10fabef8d3f031f1aa668  nxt-client-1.4.0e.zip

Change log:

This is the experimental release to test the new Monetary System major feature.
It is enabled on testnet, and those running testnet nodes should upgrade to this
release, even if they don’t plan to use the MS features, otherwise will be left
on a fork. This release is also possible to run on main net, but is not to be
considered stable for production use there. The Monetary System block is not yet
defined for main net.

New features:

Monetary System.
See https://bitbucket.org/JeanLucPicard/nxt/issue/205/monetary-system-documentation
for a detailed description.
See https://bitbucket.org/JeanLucPicard/nxt/issue/207/mint-worker-utility for a
description of the MintWorker tool for currency minting.

Dividend payment transaction. Asset issuers can make a dividend payment to all
asset holders with a single transaction. Required parameters are the blockchain
height at which asset holders shares will be counted (must be less than 1440
blocks in the past), and the amount to be paid per share.

Delete alias transaction. The owner of an alias can now delete it completely,
thus making the alias available for anyone to reserve again if desired.

Message pattern in AccountInfo. An account owner can set a regular expression
pattern in the AccountInfo for his account, using the setAccountInfo API.
Once such a pattern has been set, incoming transactions to this account are only
accepted if they contain a plain text message which matches this pattern. The
syntax follows the java.util.regex.Pattern specification.

API changes:

After MS block, adding a public key announcement when sending a transaction to
an account without a public key will be optional.

Added withMessage boolean parameter to getAccountTransactions and
getAccountTransactionIds APIs, to return only transactions having a message
attachment, either non-encrypted or decryptable by the account.

Added optional includeLessors, includeAssets, and includeCurrencies boolean
parameters to getAccount API. Set to false when retrieving those data is not
needed, in order to improve the getAccount performance.

After MS block, sending messages, selling aliases, and leasing balances, to the
Genesis account, will be disallowed.

The popOff debug API now allows pop off of more than max rollback number of
blocks, triggering a full rescan in such case.

Internal changes:

After the Monetary System block, the order in which transactions in a block are
executed will be determined by the block forger, instead of by id, default being
by arrival time at the forger’s node.

Improvements in blockchain download to prevent getting stuck on the wrong fork.
Nodes will download blocks in batches of not more than 719 blocks at a time
from a single peer, and after each such batch will verify  with
nxt.numberOfForkConfirmations other peers (default 5) if this is the best
fork, before continuing, unless the downloaded batch is of less than 10 blocks.

Rescan status is now saved in the database, to prevent the database from being
left in an inconsistent state when a rescan fails or is interrupted. Once a
rescan has been scheduled, it will be triggered again at restart, until it
completes successfully.

Improvements in the processing of unconfirmed transactions.

This release will perform a rescan on first start.

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUkN/4AAoJEFOhyXc7+e2ApfoQAIL+QkyZ1zvFXBy2D+u+onCS
4tzVxDmiCz0RNUvICq8XwNhLHxSt7v5FA22XRvX+tFECCiede0WOnVtK/FcSfpVI
J2mDJMLUQu13esXSUHPBu/yYbJIsD4/2eL71TNEmreXV6Hk65Eo6WErf5S6vovnK
XtAQpdpfziJ6mIeTWM7HxReJL7Ddv3w+l4b3qTESU/4aB16iE+1TFvt7z0lCF7AE
n4+0ZckzngB5SkaTPty7nguwwm9eLsPaqu5NdjEQszAclz8KxEchtRRDXEA3xSBE
FNAmS7qhcDgymR7C3sy/Rbk/dhF7m5hcDm48kyMbJOH/zeR6QoLBm8oSYA42QkaC
Ha9FitjIxUCnVWWui+mpcZEjXfpYqFGR+EoI+/AARbHdi3ezrxcfBFWLaZj96iEG
Lp8dx04kgvNxJoPd4kMHaviKSJG+uaav9/qaMRONq5nN5VcxVRmLqHFuQ1UplVvi
1UBie7hTjPMUTX7S03n+f0bZFMUdz6tSs64qcNBYv4yqMX9ycRrJ9DhvsvYHwFpt
PML1rE4bI6x8oeEOePo4TkoyjFNT1Ngz3x6etblkTrfeZk58uaUYbjzlL3J/OUuG
UIUS/uGyMaWuoaytR4aj8hPI2q2wIRXMKyD92sHDuXoa9u1MwFGoHHa4eOuLrsTt
fDATqlU/6JvTnXUnao7p
=tZtE
—–END PGP SIGNATURE—–