Ardor vs. the Competition, Pt. 4: Waves

This post is part of a series that compares Ardor to other blockchain projects with similar features or goals. You can find the previous posts here:

Until now, one of my main goals with this series has been to survey different approaches to scaling a distributed ledger. This week and for the next couple of posts, though, I’m shifting my focus slightly towards the business side of blockchain technology. I’ll attempt to explore the real-world problems that blockchains can solve and the ways that different projects have positioned themselves to suit their target markets.

These subjects are a bit outside my comfort zone, so I’ll thank you in advance for your patience with me in case I say something ignorant or naive. And as always, I greatly appreciate constructive criticism. 🙂

This disclaimer is especially important this week, because this week I studied Waves. As a newcomer to Nxt, I’ve read just enough about its history to know that the founder of Waves, Sasha Ivanov (a.k.a. Coinomat on nxtforum.org), had been an active member of the Nxt community until the turbulent period of early 2016, at which time he left to found Waves. I won’t attempt to rehash the debate over Ardor and the future of Nxt, which I understand ended with many asset issuers like Sasha leaving the community, but if you’re interested I’d highly recommend apenzl’s summary in SNAPSHOT and the references therein.

Instead, for this post I’ll mostly ignore the histories of Nxt and Waves, and will approach both projects with an open mind and a view towards the future. I do think there would probably be some value in a proper historical analysis, but I simply am not qualified to offer one.

With that out of the way, let’s talk about Waves.

Waves

At first glance, Waves looks a lot like a stripped-down version of Nxt. It is primarily a decentralized exchange (DEX), inspired by and conceptually similar to the Nxt Asset Exchange. Like Nxt, it uses a proof-of-stake consensus algorithm and allows users to lease their balances to other accounts in order to forge in pools. It recently added a way to associate a human-readable alias to an account number, partially replicating the functionality of Nxt’s Alias System. Even a couple features still in development–namely, a voting system and a way to send encrypted messages–duplicate functionality that Nxt already offers.

At the same time, Waves is missing many of Nxt’s most powerful features. For now, it doesn’t support anything similar to Nxt’s phased transactions or account control options, for example, though it is worth noting that both smart contracts and multisig transactions are on the agenda.

Additionally, the white paper suggests that crowdfunding will be one of the main uses of the Waves platform, but tokens on Waves lack the customizable properties that make Nxt’s Monetary System currencies so useful for this application. For example, the Monetary System offers the ability to condition the transfer of funds on meeting a fundraising goal, a la Kickstarter, and also the option to restrict trading so as to prevent scalpers from creating a secondary market. Using this latter feature, called a “Controllable” currency in Nxt’s terminology, it is even possible for issuers to dictate both a fixed asking price and a fixed bid for the currency, enabling them to offer buyers full or partial refunds for their tokens. Crowdfunding on Waves, in contrast, is limited to issuing a token essentially at the market rate.

These observations notwithstanding, in my opinion it would be a terrible mistake to dismiss Waves as just another Nxt copycat with fewer features. For one thing, Waves offers several key features that Nxt and other platforms do not have, which I’ll describe next. Perhaps even more importantly, though, the Waves team has built a strong brand and has offered a clear and consistent vision since the platform’s inception. The field is currently so crowded, and innovation so rapid, that the combination of a simple, clear message, a strong marketing effort, and a demonstrated ability to deliver on those promises might be even more important to the long-term success of a project than the richness or novelty of its underlying technology.

Unique Features

One interesting feature that distinguishes Waves from many other platforms is the design of its DEX. It is a hybrid approach that combines a centralized order-matching engine, called the Matcher, with decentralized settlement on the Waves blockchain.

When users place orders on Waves, the Waves client sends those orders to central Matcher nodes, which maintain the order books for all tradeable pairs. Each new order is either matched against existing orders or added to the order book for the pair in question, but either way the user who submitted the new order is notified immediately whether the order was filled. It is still necessary to wait for the next block(s) to be added to the blockchain to fully confirm the transaction, but in the meantime, the user knows with high confidence the result of the order.

This might not seem like a big improvement over a fully decentralized exchange, but from the handful of transactions I made on Waves, I must say I was quite impressed by the user experience. The ability to see real-time updates to the order book, and to know immediately whether my orders were filled, made a bigger difference than I had expected.

In principle, any full node can become a Matcher. The lite client currently only connects to Matchers at nodes.wavesnodes.com by default, though, so Matchers on the rest of the network probably do not see much volume. With new orders transmitted directly to these centralized nodes, and only broadcast to the whole network once they have been filled (I think), this design allows the order books to remain anonymous. I don’t know for sure how important it is for open orders to be anonymous, but it certainly seems like a feature that traders might value highly.

Another distinguishing feature of Waves is the ability to trade any token against any other token without first converting to WAVES. Combined with the integrated gateways that issue tokens pegged to U.S. dollars, euros, and several cryptocurrencies, this feature enables Waves to function as a decentralized foreign exchange market. It also allows token issuers to conduct an initial offering directly in fiat-pegged tokens. With the full client, it is even possible to pay fees in tokens instead of WAVES.

Additionally, it is worth noting that there are several features in development or on the roadmap that also distinguish Waves from other platforms. One is a reputation system that will score accounts by their age, transaction history, and other factors. There are not many details yet, but the goal is to provide users with at least a rough indication of how trustworthy a given token issuer is. The white paper even goes so far as to suggest that the reputation system will serve as “some form of decentralized KYC/AML” (know your customer/anti-money laundering) system. While it’s difficult to see how a decentralized reputation system could help issuers actually comply with KYC and AML laws, it’s not unreasonable to suppose that it could serve some analogous purpose in a blockchain community.

Speaking of compliance issues, Waves has also announced a new project, Tokenomica, that will provide a “100% compliant legal framework for different types of token crowdsales, including private equity crowdsales.” Unfortunately, that quote from the 2017 roadmap is just about the full extent of information I’ve been able to find about Tokenomica. My impression is that the project is still in its early stages, but it shows that the team is taking regulatory compliance seriously.

For completeness, I should probably mention that the Waves team is also planning to incorporate smart contracts into Waves. The scripting language will not be Turing complete, and there will be no equivalent to Ethereum’s concept of “gas,” presumably because there will be no loops. Beyond these details, there isn’t much other information available yet.

Finally, I must mention the approach that the Waves team has outlined for scaling. It consists primarily of two parts: a redesign of the forging process that breaks large blocks into “microblocks” to optimize bandwidth usage; and an optimization to how account balances are stored–or rather, not stored–that reduces memory requirements for full nodes.

The first of these two proposals, called Waves NG, is based on Bitcoin NG. In a nutshell, once a node has won the right to forge the next block, it immediately issues a key block, which is usually empty, and then broadcasts microblocks containing transactions every few seconds. The motivation for this design is that broadcasting one large block each block interval is a much less efficient way to use the network’s bandwidth, and the corresponding spikes in network activity place an artificially low bound on the number of transactions that the network can handle. By spreading transactions out over a sequence of microblocks, it is possible to increase the average data rate over the network but decrease the peak data rate, lessening the constraints that bandwidth and latency impose on the maximum transaction rate.

The second component of the scaling plan is to implement the ideas described in this paper by Leonid Reyzin, Dmitry Meshkov, Alexander Chepurnoy, and Sasha Ivanov. I admit I haven’t spent very much time with it, but the gist is that full nodes will not all be required to store every account’s balance of every token in memory in order to validate transactions. Instead, they will store a compact digest of this information, and forgers that do store it in full–or some subset of it, if they choose to only forge transactions involving specific tokens–will generate cryptographic proofs that they have updated the account balances correctly. The forgers will then include the proofs and an updated digest in the header of each new block. Nodes that have chosen not to record the balances of all tokens involved in those transactions will still be able to validate them by using their current digest and the forger’s proofs to compute an updated digest, which they can compare to the one the forger reported.

The authors argue that this approach can reduce the amount of memory required for a full node under realistic conditions by about a factor of four. Moreover, if this optimization is able to keep all required information in memory in cases where it would otherwise have to be stored on disk, the performance improvement could be far greater–about a factor of 20, the authors suggest.

Comparison with Ardor

Although a couple of the features described were not present in Nxt, there will be similar features available in Ardor.

Specifically, Ardor’s parent-chain/child-chain architecture will allow users to trade all pairs of child chain coins, some of which could be pegged to fiat currencies and other cryptocurrencies. It will also be possible to price assets in any of the child chain coins, and to pay fees in the child chain coin when transacting on a given child chain. It will not be possible to trade assets against each other directly, but most of those trading pairs would probably have such low volume that it wouldn’t really be worthwhile to add this feature anyway.

As for the improvements that the Waves team has made to their DEX by partially centralizing it, it should be possible to mimic this functionality pretty closely by building a centralized order matcher on top of Nxt/Ardor. Indeed, the InstantDEX project accomplished something similar in the past, using Nxt to settle transactions in a decentralized manner.

On the subject of scaling, the proposal to reduce in-memory storage requirements for full nodes is intriguing, but I wonder whether there might be a small trade-off with security. (If you’ve read the previous articles in this series, then you have probably figured out by now that I always suspect that performance improvements entail reductions in security.) In particular, if nodes are not required to store the current state of every account, and must use the proofs and digest in each new block’s header to validate the transactions contained in it, then I assume that means that nodes will not be required, nor even will they be able, to validate unconfirmed transactions before broadcasting them to their peers. I don’t know the consequences of allowing nodes to propagate potentially invalid transactions across the network, but the thought makes me a bit uneasy.

Ardor’s approach to scaling is for all nodes to validate all transactions, but for only the minimum possible amount of information to be permanently recorded on the Ardor blockchain. In particular, only those transactions that change the balances of ARDR, the forging token, need to be stored on the blockchain in order for other nodes to trustlessly verify that each block was forged by an account that was eligible to do so. In contrast, the whole history of transactions involving only child chain coins and the assets and currencies traded on those child chains does not need to be stored on the blockchain, and hence can be pruned away, leaving only cryptographic hashes of that information behind. The result is that the blockchain stays much smaller and grows more slowly than would be the case if it stored all of this extra information.

Which approach is better depends on whether permanent storage of the blockchain or in-memory storage of current account balances presents a bigger problem as the two platforms grow. I don’t know the answer to this question, but there are a couple of related points that are probably worth making. One is that the timescales of the two problems could be quite different: I could see an explosion of new assets on the Ardor platform placing an immediate strain on memory, whereas blockchain bloat would likely pose a severe long-term problem for Waves, especially if it reaches hundreds or thousands of transactions per second, which is the current goal. My other thought is that Ardor required an entirely new architecture to implement its scaling solution, whereas Waves’s approach will not. It would no doubt be easier for Ardor to incorporate Waves’s solution at some point in the future than for Waves to implement Ardor’s solution.

Finally, perhaps the most interesting subject in this comparison is the issue of regulatory compliance. Waves has positioned itself as a platform for creating and issuing tokens, with a special focus on crowdfunding. To that end, the Waves team has indicated that they are taking a serious look at the regulatory complications that go along with crowdfunding–which might involve selling securities, for example–in order to help users comply with the law. While the suggestion that a decentralized reputation system might eventually replace traditional KYC/AML requirements strains credulity, it could at least help suppress scams and reduce the opportunities for bad actors to take advantage of others. In that sense, it might accomplish some of the same goals that regulators aim to achieve.

Ardor, for its part, will offer a couple of enhancements over Nxt that will be quite valuable for regulatory compliance. One is the ability to issue assets that can only be traded with a certain type of phased transaction, and the other is the addition of a new phased transaction type, which allows an account to approve a transaction only if the account has a certain specific property. Combining these two features, a user can issue an asset which can only be purchased by accounts that have a property that, for example, a KYC/AML-compliant identity provider has added to designate that it has verified the owner’s identity.

If your asset represents shares of a company, or a mutual fund, or some other type of security, this feature would enable you to prove to regulators that you know who is purchasing your tokens. Moreover, if you are a user interested in purchasing those types of tokens, recording a proof of your identity on the blockchain via your account’s properties will hopefully allow you to spend less time trying to convince businesses that you are who you say you are and that you aren’t laundering money.

In addition, it will be possible to create child chains that support only a subset of the features that the Ardor platform offers. This will allow child chain creators to disable certain features, such as coin shuffling, that might raise red flags with regulators in some jurisdictions.

Conclusion

What, then, do we make of Waves? There is definitely something to be said for choosing one problem and trying to solve it better than anybody else can do. Abandoning Nxt’s “Swiss Army knife” approach and focusing instead on the single goal of building a great token-trading platform no doubt made it easier to pitch, develop, and market Waves. There is also a lot to be said for starting off well-funded, as Waves did with a $16M ICO.

At the same time, though, I’m not sure that an objective comparison of Waves and Ardor could conclude that Waves is as technologically mature as Ardor is. (For the record, I have tried to do a fair and objective comparison in this article, but I am not claiming that I succeeded. That’s ultimately your call.) Nxt is already capable of almost all of what Waves can do, not to mention all of the things that Waves cannot do, and Ardor is adding new functionality, too.

Perhaps Ardor’s biggest remaining challenge is to truly sell its vision the way that the Bitcoin community and the Ethereum Foundation have sold their visions, and this is where Waves has a sizable head start. Being capable of so many different things, but not purpose-built for anything in particular, Ardor faces a very difficult task here. The worst possible outcome would be for users and businesses to see it as “just another platform,” or perhaps to fail to grasp the full range of what it can do, and to simply ignore it as a result.

As for Waves, I’m excited to see what the future holds. The improvements that it has made to the Nxt Asset Exchange, though modest in my opinion, have nonetheless distinguished it as a formidable DEX. If the Waves team can follow through on their roadmap, Waves will be a fierce competitor among exchanges–centralized and decentralized alike.

Ardor vs. the Competition, Pt. 3: IOTA

This post is part of a series that compares Ardor to other blockchain projects with similar features or goals. You can find the previous posts here:

This week I studied IOTA, a distributed ledger that doesn’t use a blockchain.

Why Compare Ardor and IOTA?

At first blush, IOTA is about as different from Ardor as a distributed ledger can be. It uses a directed acyclic graph (DAG), which its developers call “the tangle,” to represent the history of transactions, instead of storing transactions on a blockchain. It is intended to be used primarily for machine-to-machine microtransactions on the Internet of Things (IoT), a vision enabled by the fact that IOTA requires no transaction fees. And it doesn’t (yet) support the “blockchain 2.0” features that form a core part of Ardor’s appeal. On the surface, it doesn’t really look like a competitor to Ardor.

So why include IOTA in a series entitled “Ardor vs. the Competition”?

As I’ve mentioned before, my main interest with this series is in exploring different distributed ledgers’ approaches to scaling, and this is where the IOTA community has made some extraordinary claims. As I learned more about IOTA to better understand how it scales, I eventually came to the conclusion that IOTA and Ardor offer complementary (or more bluntly, opposite) solutions to the scaling problem:

Ardor dramatically reduces blockchain bloat but requires all nodes of the network to agree about the strict ordering of transactions; whereas IOTA achieves potentially higher throughput by relaxing the consensus rules a bit, allowing temporary discrepancies between transactions, but faces a significant challenge in coping with the growth of the tangle. These tradeoffs, plus what I learned about the security of the tangle, seemed interesting enough to warrant a post in this series.

If you aren’t convinced, though, please still check in next week!

After this post, I plan to shift my focus away from scalability and towards features and market fit. Stratis, Ark, and Waves are on the agenda, but I’m not sure of the order, yet.

The Tangle

Without a doubt, the key distinguishing feature of IOTA is the tangle.

IOTA’s other unique features, such as its lack of transaction fees, the fact that transactions are not strictly ordered but still eventually consistent, and the notion that (some) spam actually increases the throughput of the network, all stem directly from the way the tangle works.

For this reason, and also because I want to sidestep at least some of the recent controversy surrounding the IOTA project, I will try to focus primarily on understanding and evaluating the tangle itself, rather than picking apart the details of IOTA’s specific implemetation of it.

The tangle is a directed acyclic graph whose vertices represent individual transactions, and whose edges represent “approvals” of previous transactions. Each time a node submits a new transaction to the network it must choose two previous transactions to validate, which it references in the new transaction it submits. As the new transaction permeates the network, each node adds it to its local copy of the tangle, with one edge pointed to each transaction that the new transaction approved.

I tried my best, but this description is probably confusing. This diagram should help. Each square represents a transaction, and the arrows that point from each transaction to two others represent that transaction’s approval of the two earlier ones. The genesis transaction is somewhere far off the left side of the diagram, and the newest transactions, called “tips” in the white paper, are on the right side, shaded in gray.

What does it mean to validate, and hence approve, a transaction? Conceptually, the node doing the validation must start at the two transactions that it is validating and walk all paths back to the genesis transaction, ensuring that it never encounters a contradiction (e.g., double-spend, insufficient balance, or the like). If there is a contradiction, it chooses another pair of transactions to approve, knowing that no other node would ever approve the transaction it is submitting if it had approved a set of inconsistent transactions.

Notice that this means that each new transaction not only directly approves each of the two transactions it has chosen to validate, but also indirectly approves the transactions that those two approve, and the transactions that those transactions approve, and so on all the way back to the genesis. This is part of the basis for “eventual consensus” on the tangle.

In case you’re wondering about the computational burden of doing this validation, in practice it can be optimized substantially. Notice from the figures on this page that as you walk the tangle from the tips (far right) towards the genesis, you eventually reach a point past which all transactions are (indirectly) approved by all tips. In these figures, transactions approved by all tips are colored green. You could, therefore, cut the tangle across arrows that point to green transactions, validate the paths from those particular green transactions to the genesis a single time, cache the results, and from that point forward only validate from your new transaction back to those green transactions. This optimization saves you the time of validating the entire tangle every time you submit a transaction, and also allows the tangle to be pruned. More on that below.

Consensus

One very interesting feature of a tangle-based ledger like IOTA is that nodes that receive new transactions from their peers don’t have to immediately validate them. In fact, the tangle can temporarily contain contradictory transactions. Eventually, though, a node must decide which of the contradictory transactions to approve (possibly indirectly) as it adds a new transaction.

How does it choose between conflicting transactions? Assuming that each transaction is valid if considered separately, then the short answer is that a node could choose to approve either one. It has an incentive to approve the one that the rest of the network will build on, though, so that its own transaction will eventually be approved, too. Most of the nodes on the network are assumed to run the reference algorithm for selecting transactions to approve, so in the event of a conflict, a node has an incentive to choose the transaction that the reference algorithm selects.

In order to understand the reference algorithm, it is important to first understand the concept of the cumulative weight of a transaction.

Each node that submits a new transaction must do some proof-of-work (PoW), which determines the “own weight” of the transaction. The cumulative weight of a transaction is then its own weight plus the own weights of all transactions that have directly or indirectly approved it. In a general tangle the node can decide how much work to do for a transaction, but in IOTA all transactions require the same PoW and thus have the same own weight. As a result, the cumulative weight of a transaction is proportional to the number of other transactions that directly or indirectly approve it.

What, then, is the reference algorithm? The author of the white paper calls it Markov-Chain Monte Carlo (MCMC, see section 4.1), which is a fancy way of saying that it is a random walk along the tangle that favors paths with greater cumulative weight. This post is already getting long, so I’ll skip the details. Suffice it to say that, when there are conflicting transactions, the MCMC algorithm resolves the conflict by tending to choose whichever transaction has the greater cumulative weight behind it. Eventually, one subtangle becomes dominant and the other is orphaned. This is analogous to the mechanism that blockchains use to resolve forks, and the cumulative weight of a transaction in IOTA is a rough measure of its finality in the same way that adding blocks to a blockchain confirms previous transactions with greater and greater certainty.

By the way, the fact that nodes don’t immediately need to validate each new transaction received from their peers has big implications for performance. Each node does less work this way, validating transactions only when it submits a new transaction, and taking for granted that transactions that are indirectly approved by all tips have already been validated by the rest of the network. Also, validations run in parallel across the network, as different nodes choose different subsets of transactions to approve.

Security

So far I have mostly just regurgitated the information found in the IOTA white paper. The issue of the security of the tangle, on the other hand, is where things get a lot more interesting. While I definitely recommend reading the analysis in the white paper of different attacks on the tangle–and the rest of the white paper, for that matter, because it is very well written–I won’t discuss most of that analysis here.

Instead, I want to focus on the most obvious threat, which is a 51% attack. The IOTA devs actually refer to it as a 34% attack, for reasons that I’m not sure I understand. I suspect it’s because an attacker who waits for a fork to occur naturally only needs enough hashpower to out-compute the nodes on each branch of the fork–i.e., more than 50% of the rest of the network’s hashpower. Anyway, the exact number isn’t important, and for the remainder of this article I will use the term “34% attack.”

With IOTA, a 34% attack would look roughly like this. An attacker issues a transaction that spends some funds, represented by the rightmost red dot, then computes (or perhaps has precomputed) his own “parasitic” subtangle, which anchors to the main tangle somewhere upstream of his transaction and which contains a double-spend transaction, represented by the leftmost red dot. His goal is to add enough cumulative weight to his parasitic tangle to convince the MCMC algorithm to orphan the main tangle and follow the parasitic one.

Hopefully, the analogies to the blockchain are clear so far, because there is one more important one. Like a PoW blockchain, the tangle is secured by the current hashpower of the network, since this hashpower is what adds cumulative weight to the legitimate tangle. Unlike a PoW blockchain, though, nodes on IOTA only do PoW when they submit transactions. The security of the tangle, therefore, depends only on the transaction rate and the amount of PoW per transaction. Take a second to let that idea sink in because it is absolutely central to understanding the security of the tangle.

Because the IOTA network is currently small and the transaction rate is low, the IOTA team has established a single trusted node, called the Coordinator, that is ultimately responsible for deciding the current state of the tangle. Its purpose is to protect against 34% attacks, among other attacks. I’m not going to spend any more time on it, but I encourage you to read this critique and the devs’ responses, and draw your own conclusions about whether IOTA can be called decentralized while running under the supervision of the Coordinator.

Let’s see if we can come up with an order-of-magnitude estimate of how secure the network could be without the Coordinator. A recent stress test achieved well over 100 transactions per second (tps) on a small test network. The team suggested that 1,000 tps is achievable. To be generous, let’s assume that IOTA will eventually scale to 10,000 tps. I don’t know what the current PoW requirement on IOTA is, but let’s suppose that the average IoT device is approximately a Raspberry Pi and it runs at 100% CPU for 10 seconds to do the required PoW. Again, I’m trying to be generous; many IoT devices are considerably less powerful than a Raspberry Pi, and pegging the CPU for 10 seconds for each transaction would probably be a dealbreaker.

With these assumptions, we conclude that the average computational power securing the network is roughly 10,000 x (# of computations by Raspberry Pi in 10 s) per second, or equivalently, 100,000 times the computational power of a single Raspberry Pi. There are a lot of nuances to properly benchmarking computers, but we’re not concerned about factors of two or three–we’re just going for an order-of-magnitude estimate–so we’ll use some numbers I found on the internet.

A Raspberry Pi3 can achieve hundreds of MFLOPS (megaflops, or millions of floating-point operations per second), while high-end GPUs clock in at thousands of GFLOPS (gigaflops, or billions of FLOPS), a factor of 10,000 greater computing power. So in our hypothetical scenario, an attacker with ~10 GPUs could out-compute the entire network. Throw in another factor of 10 because I was being sloppy–maybe integer operations are a bit slower on the GPUs than floating-point operations, for example–and you still only need 100 GPUs to execute the attack.

I’m sure there are plenty of holes to poke in this analysis. Perhaps IOTA won’t run on devices all the way at the edge of the network, for example. Instead, it might run on the gateways and routers that those IoT devices connect to, which are typically much more powerful.

Still, the point I’m trying to make is that PoW successfully secures blockchains like Bitcoin and Ethereum because it isn’t tied to the transaction rate, or any other factor besides the economic value of the network. As the value of the mining reward (in fiat currency) increases with the price of Bitcoin, miners add more hardware and consume more electricity to mine it. The economic incentive to mine ensures that the amount of hashpower securing the network increases with the network’s monetary value.

With IOTA, in contrast, there is no economic incentive to secure the network. Moreover, the hashpower securing the network is tied directly to the transaction rate, which naturally has some upper limit dependent on bandwidth and network topology.

On this last point, the IOTA developers have made a creative argument, not included in the white paper, that bandwidth limitations and network topology actually improve the security of the network. I haven’t found an official statement of it anywhere, but after some digging I stumbled upon this Slack conversation, which is the most complete defense I could find.

Essentially, one of the IOTA developers (specifically Come-from-Beyond, a.k.a. Sergey Ivancheglo, possibly a.k.a. BCNext, also one of the original creators of Nxt), argues that the IOTA network will consist of IoT devices peered exclusively with their nearest neighbors in a meshnet topology, and that an attacker will not even have the option of peering with more than a very small number of devices on each such mesh. That is, the vast majority of devices will not be accessible from the internet or some other “backbone” of the network, and the only way to send messages to them will be through the mesh of other devices.

The general idea is that the mesh as a whole will be capable of achieving a high throughput, but each individual link in the mesh has a low enough bandwidth that an attacker would easily saturate it by trying to add enough transactions to convince the network to follow his parasitic subtangle. Since the attacker only has a few entry points into the mesh, he saturates all of them before his parasitic tangle accumulates enough weight for his attack to succeed.

I’ll let you draw your own conclusions about this argument. I personally don’t think the IOTA team has made enough details public to thoroughly evaluate it.

Speaking of bandwidth limitations, let’s talk about scaling.

Scalability

Because each node must validate two other transactions before submitting its own transaction, the IOTA team likes to point out that spam actually tends to make the network more efficient. Other members of the IOTA community get carried away with this point, sometimes even making the absurd claim that IOTA is “infinitely scalable.”

Every node on the IOTA network must eventually receive every transaction in order to maintain a globally consistent tangle. Broadcasting transactions to remote nodes takes time, though, and if the transaction rate is high enough that a node receives a lot of transactions from nearby nodes before it receives the next transactions from distant nodes, the MCMC algorithm will continue to select tips submitted by nearby nodes. Eventually the tangle splits, with only nearby nodes transacting on the local copy of the tangle and remote nodes transacting on their own, divergent copy.

So bandwidth and network topology must place some limitations on the transaction rate of IOTA if the tangle is to be consistent across the entire network. We will have to wait for more stress tests to learn what these limitations are.

Additionally, like all distributed ledgers, IOTA must grapple with bloat. Each transaction on IOTA is approximately 1.6 kB in size, so a transaction rate of 100 tps would grow the tangle at a rate of 160 kB per second, or about 14 GB per day. Needless to say, that’s an unrealistic storage requirement for an IoT device.

IOTA currently solves this problem by taking periodic snapshots of the tangle, which map its current state into a new genesis transaction, allowing the transaction history to be pruned away. In the limit of very frequent pruning, a node would only have to store enough of the tangle to be able to run the MCMC algorithm.

Syncing a new node with the network is a different story, though. Either the node must download the latest snapshot from a trusted peer, or it must start at the original genesis transaction and work its way forward through the entire tangle. There is no way to trustlessly and efficiently join the network.

Finally, it’s worth noting that the IOTA team has proposed a type of horizontal partitioning of the tangle that they call a “swarm,” where many nodes together store the complete tangle but no one node stores all of it. Unfortunately, there aren’t many details yet on how this works.

Compared to Ardor

So what does any of this have to do with Ardor?

In my opinion, there are two main comparisons to draw, namely on the issues of security and scalability.

Regarding security, it isn’t clear to me that IOTA could possibly reach a high enough transaction rate to be considered secure without the Coordinator, given the monetary value of even the current network, without choosing a very high PoW requirement.

Ardor, in contrast, has the advantage that its child chains are all secured by the single parent chain.

A “small” child chain wouldn’t need a trusted node like IOTA’s Coordinator to protect it because consensus is established by the entire network and recorded (via hashes of child chain blocks) by forgers on the parent chain.

On scalability, IOTA and Ardor both currently share the requirement that each node of the network process all transactions. With IOTA, this simply means adding transactions to the tangle, which is computationally cheap, whereas, with Ardor, every node must validate every transaction. Moreover, the clever design of the tangle ensures that the confirmation time for a transaction actually decreases as the network gets busier. I would not be surprised to see IOTA achieve higher throughput than Ardor as both networks grow.

On the other hand, IOTA faces a tremendous challenge in combating tangle bloat if it is ever to achieve hundreds of transactions per second, whereas Ardor has largely solved this problem.

Finally, it’s worth noting that a proposal on the Ardor roadmap would delegate child chain transaction processing to dedicated subnets of the network. This would potentially achieve a computational gain similar to IOTA’s “swarming” proposal, possibly allowing similarly high throughput.

Final Thoughts

If you’ve read this far (thank you!!) and were already familiar with IOTA, then you’ve undoubtedly noticed that I left out a lot of details, including its homebuilt hashing algorithm, the deliberate flaw in this algorithm that Come-from-Beyond included as a copy-protection mechanism, the use of ternary encoding, and the mysterious Jinn processor that will provide hardware support for IOTA in IoT devices. In the course of my research, I’ve formed fairly strong opinions on all of these things, but I was reluctant to share them here for two reasons.

First, I don’t have sufficient information to make objective statements on these issues. I’m not a cryptographer, and I know next to nothing about ternary computing or Jinn. The best I could do would be to offer subjective judgments of the design decisions the IOTA team made, but that would have simultaneously weakened the focus of this article and opened it to criticism from people who have made different subjective judgments.

Secondly, and more importantly, I’m more interested in the fundamental concepts behind the tangle than IOTA’s specific implementation of it. Regardless of whether IOTA succeeds or fails, the tangle is a beautiful idea and deserves all the attention we can muster.

So what can we say about the tangle, then? While I’m positively enamored with the elegance of its design and the nuances of its consensus mechanism, at the end of the day I’m afraid I’m quite skeptical of its suitability for the Internet of Things. Drop that aspect, increase the PoW requirement by several orders of magnitude, and find a way to tie the PoW threshold to the monetary value of the network without cutting ordinary users off from their funds, and I think the tangle has tremendous potential as a distributed ledger.

The last missing piece is how to cope trustlessly and efficiently with bloat, a problem that Ardor have solved extremely well. Perhaps somebody will find a way to combine the best elements of both designs at some point in the future. A lot could happen by then, especially in cryptoland.

P.S. – I promise the next article will be shorter. 🙂

Ardor vs. the Competition, Pt. 2: NEM/Mijin/Catapult

This post is part of a series that compares Ardor to other blockchain projects with similar features or goals. You can find the previous posts here:

This week I studied NEM, a public blockchain similar to Nxt in many ways. As I’m primarily interested in each blockchain project’s approach to scaling, I also researched Mijin, a version of NEM for private blockchains, and Catapult, a rewrite of Mijin which promises large performance gains and which will also be incorporated into future releases of NEM.

NEM

Although NEM’s core developers abandoned their initial plan to start NEM as a fork of Nxt, choosing instead to start the project from scratch, NEM and Nxt are still fairly similar. Like Nxt, the NEM platform provides a predefined set of allowed transactions which applications can use as building blocks to create more complex features, as opposed to using a low-level scripting language to construct transactions, like Bitcoin or Ethereum.

Both platforms support a variety of “blockchain 2.0” features, like sending messages, creating and transfering assets, and sending transactions requiring the approval of multiple accounts (m-of-n multisig). And both platforms expose their functionality through HTTP-based APIs, so developers can use virtually any language to write applications for them.

Despite these similarities, NEM also has some notable differences compared to Nxt.

Perhaps the most fundamental one is its novel consensus algorithm, called proof-of-importance. This algorithm is similar to proof-of-stake, except the probability that an account may harvest (i.e., forge) the next block depends not only on its stake of XEM, which is the native coin on NEM, but also on how recently it has transacted with other accounts and how much XEM was exchanged. Accounts that hold a large stake of XEM and which transact frequently and in high volume harvest more blocks than accounts with less XEM or accounts which only rarely transact.

The authors of the NEM Technical Reference argue that, compared to proof-of-stake, the proof-of-importance algorithm gives somewhat less weight to the wealthiest accounts when determining the right to forge/harvest the next block (Section 7.8). Proof-of-importance is also central to NEM’s spam filter, which requires that an attacker not only control a lot of accounts, which is easy to do, in order to spam the network with a large number of unconfirmed transactions, but also to hold a large stake in each account and transact frequently with other high-importance accounts.

In my view, another main difference between NEM and Nxt is the extent to which each platform’s “blockchain 2.0” features are integrated directly into the API. For example, NEM’s assets, called “mosaics,” share several features with the Nxt Monetary System’s currencies, but NEM does not have a built-in decentralized exchange for mosaics. (As a side note, the NEM Foundation has contracted with Blockchain Global to create a traditional, centralized exchange featuring mosaic-based ICO tokens.) Similarly, while you could certainly build a decentralized marketplace on top of NEM where users could buy and sell goods and services, NEM does not have such a marketplace built into its API the way that Nxt does.

Finally, one subtle but very important difference between NEM and most other blockchains, including Nxt, is the way that it handles multisignature transactions. Instead of allowing any account to generate a multisig transaction, NEM introduces the concept of a multisig account and requires that all multisig transactions originate from such accounts. Any co-signatory on the account can initiate a transaction from it, and the transaction is only executed if a sufficient number of the other co-signatories approve it.

At first this might appear to be a limitation, since it requires a separate multisig account for each set of co-signatories a user wants to cosign with, but it has two key advantages: the multisig account is a full account, capable of receiving payments, messages, and mosaics, for example; and co-signatories can be added and removed, so custody of the multisig account can be transferred. It is possible to create a “1-of-1” multisig account, i.e., an account with a single custodian who can transfer it to a different custodian if desired. In this way, multisig accounts on NEM can act like transferable containers for XEM, mosaics, and messages.

One particularly impressive application of this concept is a notary service built on NEM called Apostille. With Apostille, the process of notarizing a document looks like this:

  1. Hash and sign the name of the document.
  2. Create a multisig account for the document derived from the resulting signature.
  3. Hash and sign the contents of the document.
  4. Send a message containing the result to the document’s multisig account.

Note that the last step also attaches a timestamp to the document, since the transaction that transfers the document’s signed hash to the multisig account is recorded on the blockchain.

As an example of a potential application of Apostille, the authors of the white paper consider a case where the notarized document is a car title. Ownership of the car can be transferred by changing co-signatories on the multisig account that contains the title; messages describing maintenance and repairs can be sent to the multisig account to record the car’s service history; and mosaics issued by governments or insurers could attest to payment of fees. In this way, the multisig account represents both the car itself and the history of other accounts’ interactions with it.

Anyway, that’s quite enough about NEM. Next, Mijin.

Mijin

At a high level, Mijin is a version of NEM that three of the core NEM developers and a company called Tech Bureau developed as a private, permissioned blockchain product. Like any private blockchain–and in contrast to NEM, which is public–a Mijin blockchain is owned and controlled by a central authority, such as a company.

This isn’t the place for a full debate about the utility of private blockchains, but as Mijin and Catapult are an important part of the NEM ecosystem, please indulge me for a minute. In my opinion, the more “private” a private blockchain becomes, the less useful it is. While I can see a case to be made for “consortium” blockchains, where a handful of independent organizations who don’t necessarily trust each other cooperate to secure the network against abuses by any one member of the group, I have trouble seeing the value in a blockchain controlled by a single authority. In my view, a blockchain without trustless consensus is basically just an extremely slow, extremely inefficient database.

I know there are plenty of people who disagree with me, though, so for the remainder of this post I’m going to assume private blockchains have value and that there is a market for them, especially in financial services, which seems to be the main industry that Tech Bureau intends for Mijin to serve.

There is not nearly as much information about Mijin available on the internet as there is about NEM, but I did learn some interesting facts that hint at its potential. For one thing, although Mijin and NEM are completely separate projects, Mijin does share the NEM API (or at least the two APIs overlap substantially), which suggests that it will be relatively easy for developers to write applications that run on either platform. The common API might also facilitate interactions between Mijin chains and the public NEM chain, but I haven’t found any information about the details of those interactions.

Additionally, the Mijin website states that Mijin will support smart contracts, though the Catapult white paper seems to slightly contradict that statement when it says, “the approach here is to make the smart contract an external component, whether centralized (i.e., status quo with existing systems) or decentralized. The outputs of these smart contracts will then enter their transactions into the ledger through a secure transaction process.” To me, this implies that the contracts themselves will be neither stored on the blockchain nor executed by all nodes on the network.

Speaking of Catapult…

Catapult

Catapult is a rewrite of Mijin with a focus on increasing the rate at which transactions can be confirmed. Judging from the white paper (linked above), the first deployments of Catapult will be at banks and other financial institutions, where the author envisions it will replace patchworks of “disjointed monolithic systems” that he says are commonly used today. Eventually, the developers also plan to integrate Catapult into NEM to facilitate scaling the public blockchain as well.

Like Mijin, Catapult is currently closed-source and many technical details are not public. I was able to find some good information digging around the NEM blog, though, especially in this thread by one of the developers.

Catapult divides the work that the network does among three types of nodes:

  • P2P nodes, which add new blocks to the blockchain and maintain consensus about its state;
  • REST nodes, which present client applications with all the features they can use from the Catapult API; and
  • API nodes, which, like P2P nodes, store the blockchain and can read directly from it (I think), but which do not add blocks to it. These nodes serve data to the REST nodes to fulfill client applications’ requests.

This breakdown appears to roughly correspond to the three-tier architecture commonly used for web applications, where the blockchain (P2P nodes) is the database, the REST nodes are the front-end, and the API nodes handle the business logic of interpreting and interacting with data in the database.

If this analogy is correct, then presumably the goal of this architecture is to allow each tier to scale independently. Especially for a private blockchain, the optimal number of P2P nodes used to establish consensus might be much smaller than the number of REST and API nodes required to handle all of the requests that applications send to the network. Delegating these responsibilities to separate nodes on the network should allow nodes of each type to be added or removed as needed to optimize performance.

Apart from this new architecture, Catapult also makes some other optimizations to improve performance. Whereas Mijin and NEM are written in Java and use HTTP for communicating with full nodes, Catapult is being written in C++, and communication between at least the API nodes and REST nodes uses full-duplex sockets (via ZeroMQ), potentially allowing for lower latency than HTTP.

A performance test of three Catapult nodes located in the same datacenter and configured to service requests from 10.8 million accounts showed that the network was able to process just over 3,000 transactions per second. It isn’t completely clear from the press release, but it sounds like each of the three nodes in this test played all three roles: P2P, API, and REST. Confusingly, the accompanying diagram appears to refer to API nodes as “blockchain data ingestion servers” and to REST nodes as “API gateway” servers.

Compared to Ardor

How does NEM compare to Ardor, then?

Really, there are (at least) two separate questions: how do NEM’s features compare to Ardor’s features? And how does NEM’s approach to scaling compare to Ardor’s approach?

Since Ardor (the platform, not the parent chain) will support all of Nxt’s current features, the comparisons I noted above between NEM and Nxt apply equally well to Ardor.

In particular, Ardor’s child chains will have at their disposal a somewhat larger variety of built-in transaction types that support a richer set of features.

For example, NEM does not natively support a peer-to-peer exchange for mosaics, dividend payments to mosaic holders, transactions conditioned on votes by mosaic holders (or most of Nxt’s phased transaction types, for that matter), account properties, a decentralized marketplace, or anything like Nxt’s shuffling and alias systems.

Ardor’s parent-chain/child-chain architecture will add some extra functionality, too.

In particular, users will be able to exchange different child chain tokens for one another directly, without first converting to ARDR. This will be especially useful on pegged child chains, where users will be able to trade dollar-pegged coins directly for bitcoin-pegged coins (for example), whereas on NEM, somebody holding a dollar-pegged mosaic would have to sell it for XEM, then buy a bitcoin-pegged mosaic.

These differences notwithstanding, NEM still offers a rich set of features that application developers can use in interesting ways. Perhaps the best example is Apostille’s creative use of NEM’s unique multisig accounts. I’m not sure how easy it would be to replicate that kind of functionality on Ardor.

[EDIT]: Lior Yaffe, core dev and co-founder of Jelurida, has the following comment:

With NXT this can be achieved by issuing a singleton asset for each license registration and sending it between accounts.

On the question of how to scale, the two platforms differ much more dramatically.

Catapult’s approach, which NEM will eventually incorporate, is twofold: a new three-tier architecture to distribute the network’s responsibilities among three specialized types of nodes; and a series of application-level optimizations, e.g., using C++ instead of Java. We will need to defer judgment of the latter approach until additional benchmarking tests are available, but we can still cautiously speculate about the implications of the new architecture.

The biggest advantage seems to be for private blockchains, where the owner can fine-tune the quantities of the three types of nodes and the topology of the network to optimize throughput. Moreover, in such a context, blockchain bloat isn’t as severe a problem as it is for a public blockchain since companies can easily dedicate terabytes of storage on their servers to storing the blockchain.

The improvement in NEM’s performance with this new architecture, on the other hand, is much harder to predict. It is not clear whether each peer on the network would have to run all three services (P2P, API, REST) or just one of the three. In the former case, the scaling advantage to the new architecture would presumably be lost. In the latter case, the classic trade-off between speed (fewer P2P nodes, more API and REST nodes) and security (greater fraction of P2P nodes) would remain. And since nobody could control the number of each type of node on a public network, the question of what the optimal balance is would be moot.

In contrast, Ardor’s design does not try to achieve the highest possible throughput, at least initially. Rather, Ardor’s main scaling goal is to greatly reduce the size and rate of growth of the blockchain. It does this using a unique parent-chain/child-chain architecture, where all nodes on the network validate all transactions, but only those belonging to accounts holding the parent chain coin (ARDR) forge. Since the child chain coins can’t be used to forge, the child chains’ transaction history is irrelevant to the security of the network and can be pruned away.

It is worth noting, however, that computational scaling is on the Ardor roadmap.

Specifically, it is possible that child chain transaction processing will be delegated to separate subnets of the Ardor network in the future, allowing most nodes to ignore most transactions.

Conclusion

Ardor and NEM both offer rich, largely overlapping sets of features.

Overall, my impression is that developers will probably be able to build similarly complex applications on either blockchain with comparable ease. In that sense, the two platforms are direct competitors.

In their approaches to scaling, though, Ardor and NEM are quite different.

While Catapult will likely achieve a significant improvement in the rate that private blockchains can confirm transactions, I am somewhat more skeptical of the performance improvement that can be achieved on a public blockchain like NEM using the same approach.

Ardor, on the other hand, does not attempt to address the computational scaling problem (for now), but has found a very effective solution to the problem of blockchain bloat.

I suppose time will tell whether computational scaling or blockchain bloat is ultimately going to pose the biggest long-term problem for blockchain tech, and time will also tell whether either platform has found an adequate solution.

Ardor vs. the Competition, Pt. 1: Lisk

I recently decided to start a series of posts that compare and contrast Ardor with other blockchain projects that appear to have similar goals or features. Roughly each week, I'll pick a project whose scope overlaps at least a little with Ardor's, study its technical documentation, and post a summary of my findings here for you to critique.

This week, I've been reading about Lisk.

Lisk

In a nutshell, Lisk is a platform for developing decentralized applications (dapps) that run on sidechains anchored to the Lisk mainchain. It uses a delegated proof-of-stake (DPOS) consensus mechanism to secure the mainchain, while sidechains are each responsible for their own security (sort of, but see the description of the delegate marketplace below). The protocol uses a set of predefined transactions, rather like Nxt and Ardor, as opposed to a low-level scripting language like Bitcoin or Ethereum.

Before I get into the details, I should start by saying that Lisk is definitely in an early stage of development. The team is currently in the middle of rewriting the Lisk SDK, which will support sidechain development, and is continuously refactoring Lisk Core, which is the full node.

With the code in flux, some important architectural questions, particularly about sidechains and how they will interact with one another and with the mainchain, do not appear to have been settled yet. On the other hand, I had some difficulty finding a current, authoritative source of technical information about Lisk, so what I present here might be out of date. The best information I could find was in the wikithis article by one of the co-founders, the roadmap, and these YouTube videos. None of the first three sources are recent, unfortunately, and even the videos don't go into much depth (though I admit I haven't watched all 6+ hours of them). If you've found better references, I'd be grateful if you could send them my way.

The marketing buzz surrounding Lisk seems to focus on the SDK, the goal of which is to make it easy to build, deploy, and secure a dapp running on a customizable blockchain. The devs wrote the SDK in JavaScript because they want to make Lisk accessible to as wide an audience as possible, and they also wrote the backend in JavaScript (Node.js) because...well, I guess I'll never understand why people insist on using JavaScript on the backend. 🙂

But clearly, ease of developing and deploying a custom blockchain is not the only goal of Lisk. If it were, then what purpose would the mainchain serve? You might as well clone Bitcoin or Nxt if all you want is a good starting point for building your own blockchain.

The mainchain/sidechain architecture is the real distinguishing feature of this platform. As far as I can tell, the mainchain serves at least three important functions:

  1. The Lisk API will allow deposits of LSK on the mainchain to be transferred to and from sidechains. With two such transactions, it will be possible to send LSK from one sidechain through the mainchain and to another sidechain. Unfortunately, according to the article by one of the co-founders linked above, it sounds like transferring LSK onto a sidechain will require sending it to the sidechain's owner, which obviously requires some degree of trust. To avoid this problem, it will be possible to create sidechains that use their own forging tokens instead of LSK. This token would then need to be traded for LSK in order to transact through the mainchain with another sidechain. Alternatively, it might be possible for one sidechain to transact directly with another sidechain without going through the mainchain, but the developers are still researching how this would work.
  2. Eventually, the team plans to build a "delegate marketplace" where delegates who are not securing the mainchain can offer to secure sidechains and are paid "either by the [sidechain] application owner or its users." Again, the details are a little fuzzy, but there seems to be a lot of value here: presumably the Lisk network is already far larger than a typical brand new blockchain network, and the delegate marketplace gives sidechains an "off-the-shelf" set of nodes that they can use to secure themselves in their infancy.
  3. Some nodes on the network (not sure which ones) will periodically hash sidechains and store the hashes on the mainchain as a "basic validation of sidechain integrity." I haven't been able to find any details about how this mechanism will work, though.

Apart from these functions, and from the obvious role it plays in transferring LSK between accounts, the mainchain itself doesn't seem to have any other intended uses. All of the business activity is supposed to occur on the sidechains.

Compared to Ardor

How does this architecture compare with Ardor's parent chain and child chains?

Maybe the most obvious difference is that each sidechain must have its own set of nodes to secure it, whether these are provided by the sidechain creator, the users, or eventually the delegate marketplace.

With Ardor, in contrast, every node on the network validates child chain transactions, but only accounts holding ARDR forge. The fact that accounts holding child chain tokens don't forge with them means that it doesn't matter how small child chains are or how unequal the distribution of tokens on them is; they are all just as secure as the parent chain.

One additional note about Lisk is that, until the delegate marketplace opens, sidechain creators choose the nodes that forge on their chains, which seems to require that users place a great deal of trust in them. On the other hand, the team has also suggested that Lisk will be flexible enough to allow sidechains to use an entirely different consensus algorithm, like proof-of-work, so it seems that sidechain creators wouldn't determine which nodes secure the chain in that case.

There are also plans to allow existing sidechains to switch consensus mechanisms even after they launch, but again I haven't been able to find details.

Clearly, both Lisk and Ardor intend to offer scaling advantages over traditional blockchains. With Lisk, the computational scaling advantage is obvious, since each forging node validates only the transactions on a single blockchain, either the mainchain or a sidechain. The reduction in required storage space (i.e., blockchain bloat) is less clear, though. Compared to Ethereum, say, it's obvious that for a similar level of total activity, the many chains in the Lisk ecosystem will each grow more slowly than the single Ethereum chain, simply because sidechains will not store each other's data.

Compared to Ardor, though, the storage savings would be modest. Ardor's parent chain will grow at a similar rate to the Lisk mainchain--as both will store only hashes of sidechain or child chain data instead of the data itself--but on Ardor the child chain data will be pruned away, eliminating the blockchain bloat problem that Lisk will still have on each sidechain.

Conclusion

What, then, should we make of Lisk? Honestly--and I'm very disappointed to write this--I think it's simply too early to tell. Too many important details have yet to materialize:

  • Will it be possible to convert one sidechain's token directly to another sidechain's token without converting to and from LSK? How?
  • When the delegate marketplace opens, will it be possible for users to elect delegates using sidechain tokens? Or will they have to use LSK? Or will sidechain owners maintain control over which delegates forge?
  • What will Lisk do with the hashes of sidechains that are stored on the mainchain? Will it be possible to roll back recent transactions on a sidechain to "restore" it to the state it had when it was hashed? If so, will there be some time after which this will not be possible, so that the sidechain can still be considered immutable?
  • Will the Lisk SDK provide some clean mechanism for changing the consensus algorithm on an existing sidechain? I'm not sure what this would look like.
  • What happens if a sidechain that uses LSK forks? Obviously, the LSK tokens on both resulting sidechains cannot be simultaneously backed by the same LSK reserves on the mainchain. I would assume the sidechain creator effectively gets to choose which chain is the "real" one, since he or she is the one holding the reserves on the mainchain, but I don't know for sure that this is correct.
  • Depending on how Lisk will support transactions directly between sidechains, this same concern could require additional trust between sidechain creators. In particular, if sidechain creators must hold reserves of each other's tokens to enable cross-chain transactions, which seems like one plausible way to do it, then a fork in one sidechain could give the other sidechain's creator some influence over which branch of the fork is honored. Moreover, if the forking sidechain transacts with several other sidechains, each of which hold reserves of the split token, then the situation could get ugly pretty quickly.

In my opinion, the most important advantage Lisk has over most blockchain platforms, including Ardor, is that it will accomplish a natural computational scaling by segregating each dapp onto its own blockchain. If, in addition, sidechains will be able to transact seamlessly and trustlessly with one another, then it seems like the design has immense potential.

If we're making the assumption that the Lisk team will successfully implement all the features required to make this happen, though, then we ought to grant Jelurida the same courtesy and assume that they'll be able to carry out their own scaling plans. In particular, one potential improvement on the Ardor roadmap is to confine child chain transaction processing to dedicated subnets of the Ardor network. It seems to me that this would accomplish a similar computational scaling to Lisk, while preserving Ardor's substantial advantage in reducing blockchain bloat.

In conclusion, Lisk's mainchain/sidechain architecture could potentially help it scale to accommodate a large number of dapps that could interact in interesting ways, but right now there seems to be a lot of uncertainty in the technical details. Ardor's approach is technically quite different but solves some of the same problems, namely blockchain bloat, potentially computational scaling, and the ability to transact easily between separate chains.

It will be very interesting to see how Lisk develops in the next two or three years, but then again, by that time Ardor will have been live for a long time already.

- segfaultsteve

Easter Egg Hunt

Just wondering if no one knows or no one cares about picking up free money anymore.

Quoting this week’s Nxt Newsletter:

A new transaction has been sent to the alias EasterEggs.

Here’s a clue: Twitter handle @OPeasterEggs.

 

Some cared to check @OpEasterEggs and even #OpEasterEgg:


Now, just follow the white rabbit. Find the secret words that unlock the transaction.

tl;dr:

1 JINN asset has been sent as a phased transaction to an account that anyone can access.

Log in to the account using its passphrase.

Unlock the transaction by typing its hashed secret.

Transfer the asset to your own Nxt account.

You have now picked up this week’s Easter egg: 1 Jinn, current value ~1000NXT~160$.

Deadline is Block 1359698.

Need more clues?

In the end of the section about NxtBridge OFFLINE in our latest Nxt Newsletter we wrote:

OOOPS: Did I really expose the passphrase to the demo account in that video? Oh boy. The first who logs in to the account can have the NXT and ARDR in it. There’s also a clue to follow if you log in, which leads to another asset Easter egg!

Few hours later a user had not just emptied the account for NXT and ARDR, but also found that the encrypted Charles Bukowski quote which had been received by the EasterEggs account could be used to open a password-protected file which had recently been uploaded to the Nxt Data Cloud. This revealed 12 random words, the passphrase to an account that held 100 NXTP assets.

Those are long gone now. Congrats to the Nxter that won and who, by the way, surprised us by using the Eastereggs account to cast a vote in Nxter Magazine’s newsletter-poll. – Nice one! 🙂


Bitcoin wars, miner problems, scaling issues and… ARDOR

It’s been some really quite interesting weeks lately in crypto land.

Scaling hasn’t been much of topic for the last years – and boom – now it’s front and center. Bitcoiners used to clobber anyone who thinks miners having different incentives than currency holders is a problem.

Now it’s suddenly consensus on r/bitcoin. Not only are there repeated threads saying a change of the Proof of Work algorithm might be necessary, I’m actually seeing more and more suggestions to switch to Proof of Stake! I can’t believe my eyes! Just the mere mention of it even half a year ago would have brought you into downvote hell and 500 angry “nothing at stake” chants, before your post got shadow banned. I’m not saying that it’s a majority position by any means, but what a difference!

Crypto alts’ cap goes ^

The changing tides are sweeping a lot of money into the alts. The combined crypto cap is exploding:

While Bitcoin’s share of it is decreasing. The pace is accelerating towards parity. That could be a huge deal with unclear implications (…but don’t dare mention this on r/Bitcoin).

How Ardor fits into the mix

There is a major sea change going on, and props to the Jelurida dev team to see this long ahead: Designing Ardor specifically around scaling capabilities, puts it in a position to take advantage of the situation. Now there is just the question if this can somehow get attention. So far it is always Ethereum that gets used as example for Proof of Stake. Once again, it took the spotlight. It also gobbled up the biggest gains. Ardor seemed to have merely been swept up with the tidal wave that took all alts along.

I don’t know if all that will change to the best of Ardor and NXT. But I’m sure: This ain’t over. And people are still either in denial or stuck in old ways of thinking.

  • The Bitcoin wars will get worse.
    First off, there is AsicBoost, which is worth millions in advantage for parasitic miners. Why would they give that up for anything? Higher market cap doesn’t help their bottom line, they live of higher margins. A fork of some sort either will happen or must at least come close enough that these miners must fear trashing their hardware.
  • Disruption will be huge either way. The user experience will be a disaster. Alts will pick up refugees… but if Bitcoin suffers too much, all crypto will take a hit.
  • The miner problem is, of course, deeper anyways. It’s an incentive problem that will return. Miners, they only care about users and hodlers if it somehow helps their short-term earnings.
  • What also clearly came to light is that the monopoly is even worse than anyone thought: It’s the hardware! That’s all done by basically one manufacturer in one location – with the ability to legally block supply for anyone who doesn’t agree with their plans. Bitmain is abusing this already. That skews not just which miners can join, but also how much existing ones dare to contribute to debates.
  • People still don’t understand the scaling issue. It seems bizarre to me that Ethereum/Monero/Dash are seen as solutions. All these have exponentially worse situations should they ever catch on remotely as much as Bitcoin.
    It’s just that neither Ether or Litecoin are used enough to make clear to everyone that they have the exact problem Bitcoin has – or worse.

So there is Ardor, with an actual solution. My fear is that people might once again overlook it, just like NXT was laughed at when it pioneered what is now the altcoin standard. Maybe it’s premature optimization. But it might be the right unique selling point at just the right time.

One joker card could be the Lightning network or the “sharding” that Buterin promises. Basically, they could change the landscape of the scaling discussion – and make it a non-issue. But it’s just promises so far. Maybe someone more knowledgeable can shed some light one that angle.
Anyways, the potential in the upcoming year is huge – and that’s what speculators are trading on.

This article was first posted in https://nxtforum.org/general-discussion/price-speculation

Does Ardor mean the death of Nxt?

The Ardor snapshot phase is over and the Ardor assets (ARDR) have been distributed. The amount of NXT in an account no longer influences the number of real ARDR forging tokens it will receive once the Ardor network goes live. Watching the price of NXT fall these last few months should give a good hint to everyone – there is no longer any reason to hold NXT. Ardor and its child chains are the future. Make way!

Really? I don’t think so.

make-way

Going on the Nxt road in 2017?

1. Ardor won’t be there until the third quarter of 2017

The recent “Ardor” distribution is only an asset that will determine how much real ARDR tokens you will get once the Ardor platform goes live. It is not the real thing and won’t be soon.

The Ardor testnet is expected to go live in the first quarter of 2017, but the production network completion is planned for later in 2017. Why not use Nxt until then? It is still secure, fully functional, and also supports many assets and coins which are trading on multiple external exchanges.

2. Nxt will still be maintained

The core development team has promised to support Nxt for at least one year after the release of Ardor. We are talking about software that will be actively maintained until at least the end of 2018. And after that, motivated developers may still adopt the project and maintain it.

Even if new features probably won’t be added, the software is still functional and has proven itself trustworthy during these last three years. Some assets and coins will move to the Ardor platform but others will still use the Nxt 1.0 platform.

Many altcoins are not developed anymore or do not have major updates but are still trading actively.

3. Ignis snapshot will benefit Nxt

In Q3 2017, the snapshot for the Ignis distribution, the first Ardor child chain, will most likely attract a lot of speculators. Ardor is the fuel of the network but Ignis is the first currency with all the features we love in Nxt : voting, coin shuffle, aliases,…

This second snapshot will be a good occasion for people to learn about Nxt and attract newcomers.

look

Trying to guess the future value of cryptocoins

However the fall of the NXT price may be faster than the rise. After the snapshot, it will most likely drop again. How much is the question.

4. Jelurida is watching

Jelurida exists to protect the intellectual property of the Nxt code. To commercially succeed, it needs Nxt to succeed. Having a team working full time to improve and protect Nxt would make sense for its future.

During the Q&A session about the creation of Jelurida, the following question was raised:

> @josenxt
> Will we see in 6 months from today another big surprise (like Jelurida’s) which is currently being cooked behind the scenes?

> @jean-luc
> hopefully sooner

Let’s hope it will benefit Nxt.

5. Existing applications are still functional

The Nxt API is very stable and easy to use. Many developers have built their own applications based on Nxt (MyNxt, SuperNET, nxtportal, Nxter.org, Nxt3D…). Even if the Ardor API ends up being very close to Nxt’s (which is not sure), it will require some work before such applications can be ported to Ardor (if ported at all). But, they will work on the Nxt 1.0 platform no matter what.

Nxt has a rich ecosystem and it will take some time for Ardor to catch up with it, even after the release.

6. Cheap NXT means cheap transaction fees

Nxt has always used transaction fees of 1 NXT for most operations. In June 2016, when 1 NXT was worth 13000 Satoshi, a transaction fee cost around 8 euro cents per transactions (still cheaper than Bitcoin by the way). Now, at almost 1000 Satoshi, these fees are only worth 0.6 cents. It’s basically free.

Those who consider NXT to be a currency will be disappointed. Those who see Nxt as a platform of asset exchanges, discussions, or distributed hosting will be glad.

A coin shuffle costs 12 NXT, or 0.07€. Isn’t it a good time to anonymise some coins or assets? How about starting that asset you were thinking about? Issuing an asset only cost 1000 NXT or around 6€ today.

nicholas

The future is bright

Also read: http://test.nxter.org/developers

As long as there are just a few people holding and forging Nxt, the network will be functional. Remember that for all those selling their NXT, there are buyers who think it is worth it to buy.

This opinion post was submitted by mart_e: NXT-XZ53-H97E-6FK5-9RHAS

Do you want a blog post published on nxter.org? Contact us and let your voice be heard.

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

How to market a decentralised, open source organisation

nxt-evildave

By: Dave ‘EvilDave’ Pearce

Origins of the Nxt Foundation….

One of the great strengths of Nxt, and of the wider Nxt community, is that it has always been intended, from the initial Nxt concept onwards, that Nxt would be a strongly decentralised community.

A very useful guide to the basic principles of decentralised organisation can be found in ‘The Starfish and the Spider’ by Ori Brafma:  https://en.wikipedia.org/wiki/The_Starfish_and_the_Spider

A decentralised organisation may be fine for certain applications (such as an activist movement) but for a software system that needs to interface with the wider business community, how can decentralisation work effectively ?

This issue cropped up very early on in Nxt development, giving rise to further questions:

  • Nxt is a brilliant system to build business applications on, but how does a business get in touch with a decentralised movement like the Nxt community?
  • How does a business enter into a legal agreement with Nxt, or receive support?
  • How can Nxt be promoted to businesses, or carry out PR ?

The answers to all of the above led to the set-up of the Nxt Foundation, which (if we go back to the ‘Starfish’ analogy) can be seen as a specialised organ for Nxt, like an extra leg for the starfish.

forkpay-banner3

The Foundation was created to act as a sub-section of the Nxt eco-system that is responsible for linking the decentralised, open-source community of Nxt with the very much centralised mainstream business and finance world. In effect acting as a gateway between the decentralised crypto world and the centralised mainstream worlds of business, finance and governance.

The Foundation was initially (informally) set up in mid 2014, by a group of veterans of the fledgling Nxt community. The main personnel involved are: Tai ‘Tai Zen’ Duong, David ‘EvilDave’ Pearce, Bas ‘Damelon’ Wisselink, Dirk ‘LocoMB’ Reuter and Ian ‘Chanc3r’ Ravenscroft. As befits a decentralised orgainisation, the initial founding members represented a wide range of viewpoints and possessed a very wide range of skills.

This group first met in real life as representatives for Nxt at the groundbreaking BitCoin2014 conference, held in Amsterdam, and worked so well together that they decided to carry on under the then informal banner of the Nxt Foundation.

Initially simply a loose group intended as a contact point for businesses, the Nxt Foundation proved themselves to be very useful to Nxt, and began to evolve into a fully fledged business unit with wider ranging responsibilities.

The Foundation was registered and incorporated at the start of 2015 as a non-profit business in the Netherlands, under the title of ‘Stichting Nxt/Nxt Foundation’ with the goal of supporting Nxt development and expansion.

Since then, the Nxt Foundation has continued to function as a contact point for businesses who wish to work with Nxt , and has also taken on other responsibilities: the purchase and maintenance of essential software, such as SSL and code signing certificates, developer licenses and hosting for Nxt-core related sites.

Most recently, the Foundation identified some areas that needed to be improved within Nxt, and set up the Tennessee project to address those areas.

Entering Tennessee…..

Towards mid-2015, it became increasingly obvious that Nxt needed to change to meet the demands of a rapidly changing crypto-currency market: many mainstream players were entering the market, bringing with them from the mainstream business/finance world a more professional approach to project management and a much more aggressive approach to PR and marketing.

A decentralised (and somewhat under-funded) project that relied on volunteer work, like Nxt, could not compete on an equal footing with the professional marketing and PR employed by this new wave of crypto projects.

Individual projects based on Nxt, usually with a defined project leader or a small group of leaders, could easily choose for themselves whether or not to follow this trend, or how to respond to the changes in the market, but for the Nxt core (and the wider Nxt community) a solution had to be found to address this situation.

Thus the Tennessee project was proposed: the Nxt Foundation analysed and explained the current market situation to the community, and asked them to donate to a Foundation- administered fund set up purely to professionalise and improve two basic elements of the Nxt core project: Marketing/PR and the user experience. The estimated budget to run Tennessee for a year (on the basis of two part-time employees) was approximately $70,000 or 10 million NXT.

tnsse-crowdfunding-nxt

This sum was raised via crowdfunding (using the Nxt Monetary System) inside 2 weeks, and Tennessee went live at the start of November 2015.

TNSSE has now been officially in existence for just under 4 weeks and has, so far:

Organised salary payouts for the 2 main (part-time) Tennessee personnel for the following 12 months, ensuring that there will be a coherent marketing/PR presence for Nxt over that time.

Hired a media contact consultant, the UK-based John Mcleod, on a contract basis, initially for 3 months with the possibility to extend that period. John’s function is to pro-actively seek out and cultivate both mainstream and crypto media contacts for Tennessee and Nxt.

With John’s help, Tennessee has created and published 2 stories on aspects of Nxt over the last week:

https://news.bitcoin.com/interview-nxt-foundations-dave-pearce/

http://allcoinsnews.com/2015/11/21/nxt-foundation-positions-platform-to-entirely-replace-legacy-banking-systems/

And one radio interview:
https://www.mixcloud.com/Resonance/password-18-11-15/

These three pieces are just the start of the media campaign. TNSSE allows Nxt to build up longer term relationships with media outlets, and these relationships will lead to more regular information about Nxt appearing in crypto (and more mainstream) media.

Tennessee has also began the process of overhauling the Nxt web presence, with www.nxt.org as the first site to be updated, using Farla Webmedia as an external contractor.

An important feature of the new www.nxt.org site will be an easy to use helpdesk system, which will give Nxt a unique advantage over other crypto-currency projects.

The Nxt Foundation/Tennessee has also begun to work out a conference attendance strategy for the following year, with a proposed Nxt-centred conference in the first half of 2016, and a Nxt presence at the upcoming d10e event in Amsterdam:
http://www.d10e.org/#amsterdam

So, coming back to the original question: how does a decentralised community promote itself to the outside world ?

Nxt has shown, with the creation of the Nxt Foundation and subsequently the Tennessee project, that organically created specialised systems can be set up to fulfil this specific function, without sacrificing any of the openness and decentralisation that give the Nxt community a great degree of both flexibility and strength.

The value of crypto coins

Nxt and SuperNET to the rescue!nxt-iphone

There is only one reason that 7 billion people are suckered into the game of Central Banking, and that is FEAR. People FEAR others will take their VALUE away from them and they run to centralized bankers for help.

But, given that 97% of it is based on debt, how can the mainstream fiat monetary system which we’re still obliged to use meaningfully represent people’s VALUE – i.e. their economic self-sufficiency? Surely debt is the opposite of value, unless you’re a bank.

It seems intuitively obvious that money based on something tangible and in short supply, e.g. gold or silver, must be better for society than a minority elite creating money out of nothing. Indeed, until 1971 most national currencies were still based, albeit indirectly, on gold which at least is something that most people believe has intrinsic worth and which, more importantly, acted as some sort of restraint on the amount of money that could be created. But nowadays of course the (privately owned) banks simply create money without any effective restraint at all.

Result: the minority elite game the system and in the process steal more and more of our VALUE. It’s been going on now for a long time but it’s coming to an end. The fiat monetary system is broken beyond repair. The minority elite know it and they’re running scared.

Thanks to information technology and cryptography (and of course to ‘Sataoshi Nakamoto’), we now have a way whereby a minority elite can no longer continue to directly CONTROL nearly 100% of the VALUE. They can neither possess 100% of the physical and tangible NOR can they directly control the ledger.

Over the centuries, money has taken a wide variety of forms, including (to name but a few) gold, silver, iron ingots and cowrie shells and, since 1971, debt-based representative paper (i.e. fiat money) and, more recently, electronic digits in computer memories.

But whatever form it takes, money has no intrinsic value of its own independent of the value ascribed to it by those who use it.

WE ARE THE VALUE

To thrive, people need an honest ledger of account that is not easily co-opted. We need a neutral, unbiased record keeper. Gold is far superior to being an honest ledger than fiat, since gold is much more limited and can be held directly by the one who created the value. You can’t just hit the print button and have infinite gold come spewing out.

The Elite can use fiat to buy up most of the Gold, Silver, Opal, Diamonds, Platinum, etc etc etc, but the elite cannot ever buy up all the real value because real value resides in the people.

People may wonder what currency has the potential to hold its value the best. Another way of asking this is, what ledger is the most honest and the most difficult to control and manipulate?

Gold itself is not modern technology, therefore it does not play well with the Internet. Gold may never be able to integrate disjointed technologies. You have to take gold with you or you have to trust someone to hold it for you. If you pack gold with you it holds you back and if you keep it in a Centralised suppository it disappears.

To a certain extent, the private ownership of gold, at least in theory, is effectively a decentralised financial system, in that it enables transactions to take place between private individuals without the need for any centralised control, unlike fiat which of course is controlled by banks and governments. However, in practice gold only operates as a very basic, costly and limited form of decentralised financial system.

THE REVOLUTION WILL NOT BE LICENSED

Everything needed to replace the elite’s technology has already been built. Everything needed to render their tech obsolete and hence rendering them obsolete has already been built.

Fortunately, we now have available to us the ultimate means to have an honest, decentralised and extremely difficult to manipulate ledger; moreover, one that is becoming more flexible, integrated and powerful by the day. Unfortunately, very few People have so far adopted this technology, mostly because it is still not well integrated.

DeCentralised Technology is one of KEYS to releasing the shackles on humanity, and you can keep LOCKING it back up or support those trying to steal the keys.

A few months ago, while sitting on a plane, I fell into a bit of a meditative state where I picked up on some things I would never have realized only from conscious thought. I am a long time ‘spiritual’ person, of which there is literally almost ZERO support in the CRYPTO world, even though CRYPTO has immense power to aid the freeing of the world. I am also a bit of a CRYPTO fan and I was shown how the CRYPTO world was trapped in a SHOW ME THE MONEY, LINEAR, very male dominated type LEFT brain mentality. So, I thought I might dabble in trying to bridge the two and see what barriers I come up against, almost as an experiment. It’s as one might expect. The spiritual, new thought, more right brain types, don’t get crypto but are generally positive so crypto info is basically ignored with a few ‘interesting’ type comments, but very little interest.

Spiritual freedom is not well understood by the almost dismissive knee jerk reaction of the very male orientated left brain crypto world. I watch patiently waiting for the two to converge.

Also read:
The value of 10 NXTs
SuperNET CORE coins
Nxt [CORE]: Monetary System

Write for NXTER.ORG and get paid in crypto currency

Imagine

Imagine a Nation of Teachers all resigning at once and each creating their own educational systems.  Some systems fail miserably, some turn out to be spectacular. Some of the teachers who had the least success revamp their systems after looking closely at successful systems and those who refuse to change get abandoned by their students who then move to the more successful systems. Imagine this goes on for 5 years, for 10 years, and then try to imagine the vast and nearly limitless range and scale of the ideas of the unshackled minds of the kids (now adults) who are no longer suppressed by the Centralised Educational systems whose primary purpose is to keep you a Slave.

Imagine a Police Officer, who has choked a man to death for selling a cigarette, allowing himself to reflect deeply and truthfully on the enormity of what he did and thereby see himself as we all see him. Imagine that Police Officer then announcing to the world how sorry he is for allowing the institutional violence perpetrated upon him by his centralised seniors to so badly affect his basic common sense and innate humanity. The other officers, so moved by this Police Officer’s contrition, join forces with the people, realizing that people are NOT inherently bad or violent. On the contrary, the people are generally good, it’s just that we have all been tricked and divided and falsely led by the Media and our Leaders.

Imagine what the world would look like if those who are meant to protect, stop entrapping, stop having a primary purpose of revenue generation, stop using civil forfeiture, stop arresting for victimless crimes and stop trying to cover up the truth.

Imagine what the world would look like if the people, in their masses, decided to start supporting truly Organic Farming, sustainable practices, a shorter work week, non-debt based societies, and a belief in abundance vs scarcity. Imagine a world without big AGRA pollution and franken foods and the slow destruction of the beautiful humus soil that so nurtures our planet and all of its species.

Imagine millions of people worldwide, having finally had enough of Central Banking and being spied on,  start genuinely looking for alternative ways of communicating, alternative ways of financing, real security and privacy on the Internet, and so much more.

When I imagine this, I always see Nxt and the SuperNET as an integral piece of the solution.

nxt-java-blockchain

Why Nxt?

There are so many coins out there, why should anyone support Nxt?

nxt-gold-standard

Here are my thoughts.

I discovered Nxt around Christmas 2013. I read through the forums and documents and immediately liked it. I was already aware of Bitcoin and some other altcoins, but disliked the energy waste of more and more high electricity consumption mining – but Nxt, this Nxt is different. There are so many great ideas and visions for this coin. It’s also green and highly efficient with an awesome community.

In January 2014 I installed the client and played around with it for a while but honestly was a bit disappointed because of the interface’s look and feel at that time. So many colors that reminded me of candy instead of an honest currency. Also, in the early days of its existence it wasn’t possible to divide one NXT coin into smaller fractions which was a problem for me and, to make maters worse, the client got lost in a fork nearly every single day. I thought: Give it some time – and indeed some weeks later Nxt had already improved a lot and was becoming more and more professional. This was the time I bought my first 2000 NXT coins, at what is still the all time high.

Today I am highly impressed by how much has been achieved in a very short amount of time. Although it’s only been in existence for a year, and therefore still very young Nxt is ahead of most other crypto-coin projects. The community is awesome and is able to find consensus about important questions. In contrast to other crypto-currencies that promise much but don’t deliver, in Nxt things are getting realized and becoming reality. The developers (both core and third party) simply get on and do it. So many features have been developed and implemented by highly skilled people and so many inspiring ideas are on the future roadmap.

Also read: Nxt – The Economy Platform

Nxt has managed to build its own identity, it is much more than just a coin. Nxt has one of the best clients and I really like the blue design as well as the layout of the whole brand. For me Nxt is an optimal platform for companies and businesses to develop applications on top of. As can be seen from this description of the current features, the possibilities, even in this early stage of development, are nearly unlimited and provide scope for completely new business ideas. Nxt is a trusted and fully working platform and many smart people are already providing 3rd party applications.

I am wondering how a simple messenger can get sold for billions of dollars while Nxt, being a complete, decentralized, independent financial platform, seems currently very undervalued. I hope more people as well as companies take the opportunity to discover the possibilities and opportunities, become part of Nxt and join the movement.

I’m not a big stakeholder, nor an early adopter and I lost money by investing in NXT but still believe that this could be huge. From a crypto-enthusiast’s point of view I really like what I see.

The future looks bright, let’s start the N(e)XT big thing today!

Guest author: McFly
NXT-FLY2-LNXY-U464-AXBZL

The 6 Phases of the DeCentralised r/EVOLution

Notice that in r/Evolution, both ‘love’ (albeit, as in real life, not always immediately apparent) and ‘evolution’ co-exist.

The 6 phases of the DeCentralised r/Evolution are:

1) Realization – The Awakening to our blind faith in Centralisation – the giving away of all OUR (the masses’) power to a Monopolizing Elite in return for the hallucination of perceived safety. The realization that our ‘safety’ is a Hallucination is the first step.

But this, the first of them, is perhaps the hardest step of all to take because SEPARATENESS in the minds of ordinary people has allowed Monopolizing Elites in countries all around the world to emerge and to rule by default and the most powerful of these Elites are now colluding together to impose their centralised control globally.

The Monopolizing Elite use Divide and Conquer techniques as a method of Separation.  We are divided by imaginary borders, shades of skin color, nationality (which is an illusion itself).

2) Empowerment – Could also be called Personal Responsibility – in effect, the outwardly directed action part of phase 1. Here, in the empowerment phase, having woken up to the delusion of our ‘safety’, we start to take active steps, usually tripping and stumbling to begin with. Empowerment is new to us and at first we don’t handle it well.  It can be quite difficult being the only sheep in the herd not being chased around by dogs.

3) Emergence – The Emergence of Inner Power leading to the Emergence of DeCentralised Technology – Disparate Technologies – going in various directions, competing instead of co-operating.  Before technology can exist in the real world (outer technology), it must first have existed in the mind’s imagination (inner technology). Everything created first had to be imagined.

4) Convergence – Inner realization of the powerlessness of SEPARATENESS – leads to the outer realization that working together is unstoppable.

Despite the inherent differences in how we see the world and our place in it, people from all around the world naturally begin to Unify, thereby unleashing our combined potential to bring about fundamental, r/Evolutionary global change.

5) Mass Adoption/Chaos – this phase is simultaneously the most FUN and the most SCARY.  As DeCentralised power takes over and the old powers start to collapse, we enter a period of Chaos.  There are two reasons:  A) The massive changes alone can be scary and whilst some people will immediately embrace those changes, others will try to cling to the old ways, coupled with B) The OLD power will NOT want to let go and will therefore make sure that if they are going down they will wreak all the havoc they can.

6) Harmony – once the dust settles – society as a WHOLE will be much better off – a veritable UTOPIA.  Starvation, Poverty, Lack, Rage, Revenge, Fear, etc. will become become less and less and less, while Abundance, Joy, Love, and Freedom will GROW and GROW and GROW…

Nxt became real

Investing has always been a passion of mine. I started, aged 19, when I bought my first stock in Vestas. Oh what a day… Soon after that I got an ok paying job as a pizza delivery man which helped sustain me through college and pay for my hobbies. Little did I know that in 7 years I was to turn that one Vestas stock into a nice little portfolio worth around 40K dollars.

Early 2014 I made a fool’s mistake. I stopped thinking like an investor and started thinking like a speculator. I sold all my stock holdings and put all my money into forex. With a 500:1 leverage that seemed like a great deal. Six months later I was penniless and 10k in debt. Forex gave me a God complex. It made me greedy and impatient. I was taking greater risks than I could afford. And so I lost it all…

In June 2014 I discovered NXT. It was still quite raw at the time and the first assets were just being launched. I saw it as an altcoin at first and struggled to understand what the hype was about. I didn’t see it. So I redirected my attention to other coins and started trading. Again, I was speculating and again I got burned. A few months later I saw an article about NXT on some random webpage and I suddenly remembered I had seen this before. So I started researching. I came across the nxtforum and saw the beautiful community that had grown from a simple concept. I started reading about the developments, projects and assets and only then did I realize that NXT was not some new shitty altcoin, but rather a platform; a platform to great things. The possibilities were endless and the projects, those already launched and those still in development, have really got me stoked up.

It was then that I knew that this is the place to be. Too many times I have relied on old fashioned instruments like stocks and bonds, which never had the level of transparency that I desired. I hope NXT will solve that for me, and I believe it will. I am technologically handicapped and don’t understand a single string of code, but what I learned throughout my investing years is to spot a good deal and take it. I see NXT from a financial point of view, and I realize that all the private ventures on this platform have huge potential to change the way we now think about the world, as well as bring a nice income on the side. NXT became real, tangible, something I want to be a part of.

At the time I’m writing this I’m 5000 USD in debt, but still hoping for a better future.

I recently purchased my first assets of about 3000 NXT in value. I know it’s not much, but it’s a start. It’s my way of showing faith. I want to put my money where my mouth is, even if that’s only 60 dollars to begin with. In the following weeks and months I will slowly start to acquire more and more of these assets, and I hope that by February next year I will be able to pay off my 5000 dollar debt and really get into NXT.

For all those that read this article, and to the members of the community and forum I send out a giant THANK YOU for opening a new world for me.

This article was written by mynxtventure, NXT-URRX-HF6C-NCYJ-EEUZZ

New thought, new technology

There must be many hundreds of thousands, if not millions, of people worldwide who are a natural fit for Nxt and SuperNET, not just bloggers, activists and other protesters but a whole, massive community awakening to the dark shadow that’s been cast over their lives by Central Banking, False Justice, and Propaganda. The Crypt/Alt Platform that first embraces these guys and gets them on board will be the WINNER by default. These people want an alternative – they have been beat up and knocked down, they spend their lives working, just to have their homes foreclosed on, they live pay check to pay check.

They have moved beyond being angry and for the most part have even move beyond thinking of themselves as victims.

But trying to get people to see that Nxt or SuperNET can a be a massive part of the solution seems as hard as convincing a crypt/altcoin that they need to put more than CRYPT NEWS on their website.

In fact it shouldn’t be hard at all –  we simply need to listen to what they’re saying. They want to be heard, they want an alternative to the current banking system, etc. etc. Well, Nxt and SuperNET already provide 50% of everything they need, and the only thing keeping Nxt and SuperNET from full-on explosive growth is mass adoption. Hmmmm, seems easy to connect the dots to me. If you follow the Nxt/SuperNET forums it would appear there are no less than 5 gambling ventures getting ready to come on board, and while that is great, it’s not of course enough: we also need to take as much financial power as possible away from the banksters and put it into the hands of the people.

There are two organizations I know of (New Earth Nation and I-UV with Project 13) which have spent or are spending untold amounts of money on programmers and other resources to create alternative digital societies; in the meantime, Nxt/SuperNET is already sitting there ready to be used and capable of delivering far beyond anything they have. But, when people take a look at Bitcoin, Silk Road and the Dark Market, they stay far, far away. If they go to Nxt and SuperNET and see all the superficial fudding, the ‘get rich quick’ mentality of I want my $ to grow to $$$$$ by tomorrow, Tom Cruise type characters yelling “show me the money”, and others crying, snivelling and complaining, they are not interested.

Which Crypt/Alt is going to be the first to adopt a WIN WIN ABUNDANCE FOR ALL ATTITUDE? What happens when I show them Nxter.org and Nxtforum and all they see is white papers on telepathy and bitching and moaning about Ripple or OpenBazaar or BitShares?

The day will come when NEW THOUGHT meets NEW TECHNOLOGY in one platform and that platform will have growth like nothing ever seen in the history of mankind. Will it be Nxt and SuperNET? Not sure…

NOOB

I’m gonna take the chance. Here’s my blog post. The more I write, the more I get paid. So blablablablabblah, blablablablabblah, blablablablabblah, blablablablabblah, blablablablabblah, blablablablabblah.

Damn, how to start this.

I got into cryptocurrencies 5 months ago. Yeah laugh, I’m a loser, a noob which is why I lost almost all the money I invested and have no idea how to get it back. Maybe I’ll be in debt forever so, yeah, have a good laugh, it helps me to see the funny side…  When I hang out in trollboxes or read BTT comments I see that I’m not alone, not that I trust anyone. But I think that’s real. That I’m not the only one who invested more than I could afford to loose and lost it. I know. I broke the rules, so I’m the one to blame: Don’t invest more than you can afford to loose. But I did.

You may all be first movers and wonderful traders and rich from the BTC you bought in 2010 and laugh yo ass off, but this market is hard to understand when you’re new to it. You have difficulties making your first EUR transaction into BTC, then figuring out how to place bids, and move crypto between exchanges, but you’re full of hopes, because you read all the latest announcements on the altcoin pages of BTT, and you were lucky to have got in early.

I bought when the coins were cheap. Or at least when I thought they were. Just before they crashed and I realized they’d been pumped. I still don’t even know if you’re supposed to ‘Buy the rumor, sell the news’ or the other way around. And every time the price rose or coins crashed trollboxes cried “China wake up!”, or “it’s caused by the latest news”, and whatever the news was I never saw it coming. I’ve bought both before and after news hit. I’ve bought when it looked like nobody else was. And I’ve bought when the great pump’n’dumpers told me to buy, like all the other dumb noob “fishes”. Turns out though that even pumpers aren’t in control, because when a larger whale dumps, we’re all going under, and we’re all fucked. I’m not sure that’s what Satoshi wanted.

MY DREAM

I’ve had dreams about being a whale. In my dreams I made markets and calculated moves. I’m sure that in reality I would’ve lost my money no matter the size of my portfolio. Even if I was the richest of all mothers I would’ve chosen the worst coin ever, invested all, tried to drive markets up, then sold too late, bought back in too soon, and I’d stand exactly where I stand now, because, frankly, I DON’T KNOW what I’m doing.

Now my real dream is that someone steps up and just yells at me: WAKE UP! Then I wake up. And it has all just been a nightmare, here you go dude, here’s all your money back. 5 months is a long time, when it comes to loosing money, but you survived man, you’re a strong man, and this is your reward: It was all just a nightmare!

Is it possible?

Maybe I should leave this crypto world ASAP. Earn fiat, pay off my debts little by little, go and live on a rock somewhere. But then again.

I’ve discovered magic. Yeah, some so-called geniuses out there will keep telling me they make coins. They don’t. They make clones of shizzle. Don’t listen to them. I don’t have anything left to invest, but I won’t ever fall into a clone trap again. I think investing is about doing your due diligence properly before spending. Magic comes with true innovation. There are those who talk about it, and there are those who deliver it. Also, a good community is more than a plus, it’s the key. Nxt has a qualified and supporting community, and I’m done with BTT.

I write this post because if NXT succeeds, the NXTP I get for it (if nxter.org chooses to publish me!) could – if not fly me to the moon – lift me just a few inches off the ground. If it crashes I won’t have lost a thing. Except for my life of course: I will fucking die at the hands of my girlfriend if I tell her that ‘I can’t get my money back but at least I tried!

I believe there’s a good chance that NXT will outperform everything else ever announced on BTT. Unfortunately I found NXT too late to make the really big money the founders did, so I can’t invest in the hope of getting rich quick. But I think there’s still plenty of scope for getting relatively rich relatively quickly and in any event I can at least follow Nxt’s progress and write about it.

OK, so that’s my blogpost. Like it or leave it.

I know my writing ain’t deep or technical and maybe not even newsworthy so if you dismiss it, it’s OK. But then please make a series about a noob who doesn’t understand crypto. I’m sure it will be of interest to your readers. I for one will be reading along, I’m not an expert yet!

Author:
ZockPop

PS. I would like to be paid for my blog.

Nxt ID:
NXT-6LGH-DKMT-2NPU-BY66Y

Unlock the inner slave

All my work is the work of a simple philosopher.

Using language to unlock the inner slave – freeing 1 slave at a time.

The dark shadow cast by the centralisation of power in the hands of a monopolistic few has long hidden the truth from view. But now there are cracks in the dam. They may be little cracks, but the naughty powers that be (now referred to as the powers that were) are quickly running out of fingers to plug them – Nxt, Btcd, and the SuperNET ‘aka UNITY’ (love that one) are chipping away – “Human Race – Get off your knees” – The naughty ones control the educational systems, more accurately called “sheep makers”. The naughty ones control the media, more accurately called “fear porn”. The naughty ones control the money supply, more accurately called “the lie about lack”. The game they play is “problem, reaction, solution”. They create the problem themselves, fan the flames for a huge reaction, then magically arrive on their shiny white horse with a solution.

Here are the real facts, all of them easy to see with the naked eye, and you don’t need a jury to decide.

1) As the cost of education goes up, we get dumber.
2) As the cost of health care goes up, we become more ill.
3) As the cost of protecting the Earth goes up, the Earth’s condition continues to decline.
4) As the cost of welfare goes, the more homeless and hungry people we have.

The real solution is to stop asking Egotistical Megalomaniacs to create policy (eleventy billion rules and counting) to save us from “bad” people  –  it doesn’t work when we hire BAD people to save us from the bad people.

Instead:

1) When the people educate themselves, our collective, creative genius will be freed.
2) When the people take care of each other, the world will become whole again.
3) When the people take personal responsibility for protecting the Earth, GAIA will become one giant Garden of Eden.
4) When the people manage their own wealth, there will be abundance for all (thank you Nxt / SuperNET / BitCoinDark / VeriCoin / BoolBerry / ChanceCoin).

Make a small difference today, help someone in some small way, just to be of service to humanity and for no other reason.

Since it’s an immutable natural law that you reap what you sow – sow Kindness and Joy!

Author: DAMON
Nxt ID: NXT-HTB8-GGJG-ZDRK-6N3LC