Show Posts - kushti singapore
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Nxt Client: Nxt 1.12.2

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - kushti

Pages: [1] 2
Core Development Discussion / ZKCP for Nxt?
« on: February 28, 2016, 09:40:22 pm »
"I am happy to announce the first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network."


Well, it seems Nxt can do this as well with phased transaction to hash preimage  :)

Nxt General Discussion / Anonymous Voting
« on: February 25, 2016, 07:57:31 pm »
As you know Voting System is pseudonymous. There was a request for anonymous voting, but it requires some specific things(e.g. additively homomorphic encryption w. zero knowledge proofs of range or membership) way too heavy to include into core. So it should be implemented as a service I guess. I can make a backend(open-sourced and CC0-ed for sure):

1. Who will make a frontend?
2. What is a need in that? Is a need a real?

Consensus Research / Permacoin Implementation
« on: February 25, 2016, 07:41:45 pm »
Well, that was done under different umbrella that Consensus Research, but following previous work  :)

 Permacoin is non-interactive Proof-of-Retrievability scheme for blockchain consensus protocol proposed by A. Miller et al: http://cs.umd.edu/~amiller/permacoin.pdf . Scorex devs have implemented Permacoin as Scorex module. Notes on implementation details: https://github.com/ScorexProject/Scorex-Lagonaki/wiki/Permacoin-Implementation .

Testnet is ready to be public. So we'll announce it soon to test things in the wild. Nothing is planned for production.

Scorex is now under IOHK Research wing (https://iohk.io/).

Now I'm finishing a new paper with a working title "A Scalable Blockchain System Based on a Non-Interactive Proofs of State History Retrievability", basically a Permacoin repurposed for storing blockchain system state snapshots to provide fast bootstrapping for new nodes and safe blockchain pruning.

Secure Asset Exchange / Secure Assets Exchange is Shutting Down
« on: January 20, 2016, 07:53:39 pm »
Hi guys!

Unfortunately, Secure Assets Exchange will not survive 1.7 hardfork.

We(I and Sergey, then also Wesley and Steve Ellis) are started project in May, 2014 just few days after Nxt Assets Exchange release. Unfortunately, due to regulations issues (those 3-letters US agencies I dunno much about) new features were not developed since September, 2014. The team switched to SmartContract.com(also Nxt-based).

Since Nov, 2015 I'm not working with Steve&Sergey for many reasons(Wesley left us around Jan, 2015). Initially we came to agreement to continue maintenance of SAE, but later disagree on conditions.

Well, the best I can do here is to open-source SAE backend(as I'm author of it). I'm not sure the guys will do the same.

Farewell letter on the website:


Due to recent increases in maintenance costs and the limited resources/time of any startup that needs to prioritize its initiatives, Secure Asset Exchange will no longer be available as of January 21st, 2016 (NXT block 621,000); please plan accordingly.

We are deeply grateful to all of our users and supporters up to this point and look forward to focusing our energy on making the next generation of great blockchain-based applications, which our now global society can truly benefit from.

Your ability to use your NXT or any of your assets will not be affected by our availability because your account and all of its assets can be accessed through the official NXT client.

To access your account using the password created on trade.secureae.com, simply combine your username with your secret phrase, with no spaces between the two; this will create the password to your NXT account for the official client. For example, if your username is “joe” and your secret phrase is “joe likes coffee” then your account’s password for the official NXT client will be “joejoe likes coffee”. Please make sure to take capitalization and spacing into account, they do matter.

If you have any questions, please feel free to contact us at support@secureae.com.

Consensus Research / Interactive Proof-of-Stake
« on: January 05, 2016, 07:54:46 am »
Hi guys! And Happy New Year!   ;D

A new proposal for a new pure Proof-of-Stake protocol by me(solely this time):



1. Nxt has similar %% against private fork attack with better distribution (with 28.57% online stake an attacker has ~10% chance to generate a better chain of 10 confirmation, ~.1% to generate a better chain of 60 confs).

2. Dunno anything about implementation. Probably will be implemented in Scorex, mb in form of hybrid though.

Conferences / Blockchain Hackathon Moscow
« on: October 24, 2015, 12:59:21 pm »
High School of Economics, Lykke & Qiwi(the big national payments company) are going to organize Blockchain Hackaton in Moscow:


I've contacted with organizers and probably will give a talk there and support teams with technical expertise as well.

General / Nxt and Smart Contracts
« on: October 16, 2015, 07:08:08 pm »
Guys, you know we have a lot of hot discussions on AT Project then Smart Contracts proposal from cfb. I wasn't a fan of AT project(I wasn't strictly against that as well though). And I was strictly against Smart Contracts, I really don't like the idea of projecting core implementation details into the blockchain.

Having a job during last days to investigate current state of Ethereum, I would like to say it's good Nxt has delayed AT project adoption. It's not a scalable approach, it has a lot unexpected properties and so on.

Quick example, its possible to write some random crap into blockchain as contract code, e.g. https://etherscan.io/tx/0x4bb32548d3b28d8bbdbe969888dff6285a0404bb314b7a8e5d81a61a313781eb (contract https://etherscan.io/address/0x190cf16a720f69d1b1ac68e873d9c5b06c1f0f2b). It starts with invalid instruction 2f then some meaningless stuff. Fee is minimal as code execution aborts immediately. Trying to submit something about 60kb after this 1kb tx, I've got my geth stuck and broken  ;D

And please note this is not a bug, even more, this is the best behaviour probably(and with arbitraty-input JMP instruction it's not possible to analyze code execution correctness at all, probably).

And scalability would be a problem for Eth. Considering the same logic, e.g. polling to get done against Nxt & Eth, in the former case it's code running
on top of JVM while in latter it's about code running on top of EVM which is running on top of JVM/pyVM/LLVM.

Some researchers around are working on solving general problems of Ethereum-like contracts, namely scalability and privacy. I made the blogpost comparing two known proposals, Hawk and Enigma http://chepurnoy.org/blog/2015/10/towards-a-new-frontier-of-the-smart-contracts-hawk-and-enigma/ .

In both cases contract execution is happening off-chain, and blockchain is being used to store commitments / MACs or CRSes(common reference string for non-interactive Zero Knowledge Proof with size of tens kilobytes).

Surprisingly(or not), Nxt is already well ready for storing that complementary data. The only thing we need is to promote Nxt chain for being used for things like that(so to use Nxt  in both systems). Thoughts?

General / Proof-Of-Burn for Nxt?
« on: July 21, 2015, 10:44:40 pm »
For Proof-of-Burn details, see Bitcoin Wiki https://en.bitcoin.it/wiki/Proof_of_burn .

My idea is to make super-lightweight listener for Nxt blocks looking for burning transactions(sending something without recipient provider). Nxts / Assets / MS tokens could be burnt, and as result, some tokens will appear in another system(e.g. blockchain).

Possible use cases:
1. A CryptoCurrency backed by Nxt or assets
2. BitMessage-like messenger where some amount of nxts/assets is needed to be burnt to send a message(BitMessage's PoW has a lot of drawbacks).

PoB proof-of-concept sounds like a good idea for incoming hackathon ( http://jnxt.org/nxthacks:)


There are two huge problems around cryptocurrencies development project Scorex aims to help to solve:

* Bitcoin source code contains more 100K lines of code(80K of C++ only), Nxt is about more than 45K lines of Java code. All parts of the design(network/transactions/consensus layers) are mixed in a hard way.  So researchers & developers are definitely not in a good start position to make any experiments.  In opposite, Scorex is less than _4K lines of Scala code_. Transactions layer is as simple as just tokens transfers. Consensus algo  could be switched easily(with two consensus algos out of the box,  one could be replaced with an another with just one line of code edited!)

* Major coins forks are trying to make IPO immediately, often having just one or two pretty controversial features introduced. **Scorex is intentionally not production-ready**, so please participate in any  non-commercial experiments built on top of it, but don't buy tokens unless you are 100+% sure what are you doing.


* Two 100% Proof-of-Stake consensus algos out of the box, Nxt-like and Qora-like. One algo could be replaced
with an another with just one line of code edited (in Constants.scala)
* Simplest transactions model
* Asynchronous network layer on top of TCP(with Akka I/O)
* Command line client for the JSON API
* Curve25519 for signatures
* CC0(Public Domain) license
* Compact, functional, actors-powered code
* Scala / Akka


This release is named Lagonaki (after picturesque mountains resort in West Caucasus https://yandex.ru/images/search?text=%D0%BB%D0%B0%D0%B3%D0%BE%D0%BD%D0%B0%D0%BA%D0%B8 ), the current version is 1.0. It is the initial release aiming to provide modular and simple product to improve.
There are some issues/todos to be solved in upcoming 1.1 then 1.2 versions.           
And new branch will be forked very soon, with a brand new Proof-of-Stake algo having no whitepaper atm. More details soon. Nxt forging algo improvement proposal will be derived then from testing results. 


Scorex is made by [Consensus Research microteam](https://github.com/ConsensusResearch) previously worked on Proof-of-Stake investigation:

Alexander Chepurnoy aka kushti - Nxt developer & smartcontract.com cofounder. Has few published papers in Computer Science field(finite state systems related), writing PHD at the moment.   

andruiman - serial entrepreneur with theoretical physics background, a big fan of Coq interactive theorem prover & functional programming.   


We're highly welcome contributions in form of pull requests, testing, issues reporting, and forking for sure :)


Also we would be happy to get donations. You can buy our asset on Nxt Assets Exchange: https://trade.secureae.com/#5841059555983208287, Bitcoin wallet is **17YksFD7eRB4NhPfEtGrGnuvuwpkAeBd7f** .   

Repository URL

The main link to follow is the GitHub repository:



Consensus Research / Consensus Research is Alive!
« on: June 12, 2015, 12:41:05 pm »
No activity in the subforum for last months, but we continue to work!  :)

1. Scorex, our fully working cryptocurrency prototype, was pre-announced on BitcoinTalk. Hopefully, will be announced soon here & on BitcoinTalk. We plan to use it to check our ideas in the close-to-real-world environment. https://github.com/ConsensusResearch/Scorex-Lagonaki

2. I made alternative constructive proof of the FLP theorem with Coq: https://github.com/ConsensusResearch/flp . Hope to publish a paper about that in a peer-reviewed journal. andruiman has some Coq code done around CC transactions layer, will be published later.

3. We have some proposals on PoS improvements, preparing to publish them along with possible attack vectors, in form of blogposts and/or reviewed papers(seems we will write no non-reviewed internet papers on that).

4. We're starting to work with jl777 on research around crypto777. andruiman is starting to check its' pegging ideas.

5. More news soon :)

So progress is not super-fast, but we're making it :)

Hi guys!

Made voting system guide comply to 1.5 based on previous specs but hardly reworked.


I would be happy to get feedback / additions to the doc.
Also it would be great if some videos will be done for simple use cases for ordinary users. A

And welcome aboard application developers! Make apps on the top of the VS!

Conferences / Mind the Gap online conference - May, 5th, 2015
« on: May 04, 2015, 12:02:05 pm »
On the 5th of May 2015  14:30 GMT the financial and the crypto community will gather online to network, exchange information and discuss the future of the blockchain technology.

Keynote speaker
Alex Batlin Research and Development Director in Group Technology at UBS, and leader of UBS's Crypto 2.0 Pathfinder program.

Alex is a panel member of the Fintech50 and mentor for both Fintech50 and Level 39. He has over 15 years hands-on IT development experience in blue chip financial services

Special announcement from Brian Kelly - investor, author, and financial markets commentator.

Join now @ mindthegapexpo.com and enjoy the opportunity to meet repersentatives from some of the leading financilal organizations, international corporations, blockchain and crypto companies and developers.

Among the event attendees you will be able to find people from IBM, CitiBank, PWC, KPMG, Standard Bank, Swisscom and many blockchain and crypto companies.

Participate in a live debate featuring some of the leading blockchain platforms such as NXT, Ethereum, Blackcoin, Omni, Factom and Getcredits, To establish who is a market leader and who is vaporware in this the Blockchain Crypto 2.0 space.

Q&A- Get your questions ready and if you like you send them before the event and we will make sure that our panelists will get them.
send to info@cryptomoneyexpo.com

Who are the Panelists?

Moderator: Ron Quaranta - Ron is co-creator of the Bitcoin Volatility Index (xBVIX), and previously served as director at Falcon Global Capital, one of the first bitcoin investment funds. In addition, he is co-founder of the Wall Street Bitcoin.

Representing NXT  : Alexander Chepurnoy - Nxt developer & smartcontract.com cofounder

Representing Ethereum : Vitalik Buterin - Vitalik Buterin is a programmer, writer, founder of Ethereum, the decentralized web 3.0 publishing platform and co-founder of Bitcoin Magazine
Representing Factom: Peter Kirby - President at Factom Representing Omni: David Johnston board member at  Omni foundation and Dapps fund MD
Representing Getcredits: Nick Williamson CEO and  founder of Pythia, the startup behind the cryptocurency Credits protocol.
Representing Blackcoin:David Zimbeck Blackcoin Core  Developer             

Join at  www.mindthegapexpo.com for a concentrated 60 to 90 Mins starting from 14:30 GMT "share this around your co-workers and communities this will be one of a kind virtual seminar

Consensus Research / Consensus Research 2015
« on: January 16, 2015, 12:39:52 pm »
We didn't lose time during the holidays, and happy to publish recent news & our plans for 2015!

After a lot of research made & few papers published we're understanding attacks on proof-of-stake pretty well. The summary from the BTT topic (https://bitcointalk.org/index.php?topic=897488.msg10152632#msg10152632)

1. Short-range attack  - attacker can offer better chain started few blocks behind current canonical chain. The attack is possible at the moment, the only likely outcome though is just gathered fees increase for an attacker. In our simulations this kind of attack is possible mostly when a long delay occurs due to low target. By the way, the attack has positive aspect for network, as it shorten delays average between blocks. So attacker gets extra fees for a good job done  Grin

2. Long-range attack - attacker can start fork hundreds or thousands blocks behind current chain. From our investigations the attack isn't possible. 

3. Nothing-at-stake attack - not possible at the moment! Will be possible when a lot of forgers will use multiple-branch forging  to increase profits. Then attacker can contribute to all the chains(some of them e.g. containing a transaction) then start to contribute to one chain only behind the best(containing no transaction) making it winner.  Previous statements on N@S attack made with assumption it costs nothing to contribute to an each fork possible and that makes N@S attack a disaster. In fact, it's not possible at all to contribute to each fork possible, as number of forks growing exponentially with time. So the only strategy for a multibranch forger is to contribute to N best forks. In such scenario attack is possible only within short-range e.g. with 25 confirmations needed 10% attacker can't make an attack. And attack is pretty random in nature, it's impossible to predict whether 2 forks will be within N best forks(from exponentially growing set) for k confirmations. So from our point of view the importance of the attack is pretty overblown.

4. History attack - attacker can buy whale's private key for $5 and build alternative story. Solved with some checkpoints now, located behind max rollback possible, so the solution is not so scary in terms of centralization etc.

There are also issues we want to resolve e.g. long delays. So we have no any deadly threat, but several annoying issues.

From playing a lot with simulation tools we realized most of problems will be less important with a better measure(than just cumulative difficulty). andruiman finished a new paper with a simple but working proposal, will be sent to investors very soon. Even with singlebranching pos better measure would be very helpful. Then we'll play with more complicated proposals, including proof-of-stake + proof-of-activity hybrid.

Papers & articles
andruiman has the nice plan for next papers to be published:

1. Comprehensive analysis of the blockchain measure influence on the multibranch forging convergence

2. Theoretical physics and abstract math analogues and inspiration for the world of CC economy (mostly philosophical stuff)

3. Proof-of-Stake "algebra" and its formal Coq specifications (with publishing in truly scientific journals)


Regarding multiple-branch forging, it seems promising in theory, but there are some questions regarding effective implementation. As Nxt core is pretty bold these days(40+K lines of code), I worked during few weekends on Qora code simplification. Started with original 24K I have 9K now with 3K in Scala and 6K in Java. Finally I'll have a coin prototype with no production quality but in just 5-6K lines of Scala code. I've chosen SCOREX name for that(SCala&qORa-based blockchain-driven network for EXperiments). So we will use it for experimental multiple-branch implementation, and will invite enthusiasts to set up nodes for the experiment(>10 nodes are enough I guess). Later well-tested results will be incorporated into Nxt core(or not in case of failed experiment :)  SCOREX also will be outsourced for other researchers need(to make cryptocurrency-related experiments quick to implement).

Consensus Research / The Paper on Long-Range attack & Nothing-at-Stake
« on: December 18, 2014, 11:24:30 am »
Paper on different attacks related to multibranching forging is published by Consensus Research https://github.com/ConsensusResearch/articles-papers/blob/master/multistrategy/multistrategy.pdf

TL/DR version and consequences:

- multibranch forging gives measurable possibility to earn more fees. I guess Nxt should not ignore it in long-term as the profitable activity will be implemented by somebody sooner or later

- there's no long-range attack against a blockchain V. Buterin described, only short-range. The short-range attack doesn't allow double-spending but gives multibranching forger possibility to earn more fees in singlebranch environment by producing few blocks in a row. However producing few blocks in a row could be an issue too (e.g. evil forger may postpones orders submissions etc) but not critical at the moment.

- not explicitly stated in the paper but easily derived, a long delay between blocks not only annoying but also a security problem as it's the moment for short-range attack could happens

- we have formally defined nothing-at-stake attack(again, using Buterin's informal definition) and made initial simulations. We haven't included their results in paper as they are seems to be too raw, but I can reveal them here: N@S attack could happens only in short-range, e.g. for within 20 blocks for 10% stake, so with 30 confirmations we haven't observed the successful attack. Also please note the attack has pretty unpredictable nature for attacker, so he can hardly enforce it, even in theory(in practice it's even harder to get it done properly). The correlation with stake size is still the open question, but it's nearly impossible to attack a proof-of-stake currency with "1% stake even" as stated by Buterin

- the N@S simulation tool is published also https://github.com/ConsensusResearch/MultiBranch  so feel free to make your own experiments

- had 2-hours long conversation with andruiman yesterday. Probably we have elegant(not Slasher  ;D) solution to make consensus algorithmically enforced(like proof-of-work has) but a lot of experiments needed

Consensus Research / Phase 1 results / Phase 2 start
« on: December 15, 2014, 11:49:07 pm »
A lot of things made since the first fundraising letter:

- Executable forging simulation tool for a proof-of-stake with three blogposts about ( http://chepurnoy.org/ )
- Executable multibranch forging simulation tool with the paper about it

All those papers, articles, and both tools could be found on GitHub: https://github.com/ConsensusResearch

- And the final result of the phase - our paper on long-range attacks and N@S is already sent to investors & active Nxt contributors and will be publicly released this week.

So we made first milestones (https://nxtforum.org/consensus-research/first-fundraising-letter/) for the price of one! And we're starting phase2 now!

Well, after playing with multibranch forging we think it's better not to punish it(slasher etc) but use it officially. However it leads to the consensus with explicit multiple states(we're calling it "quantum consensus"), so instead statements like "i got 5K 2 blocks ago" more flexible "i got 5K recently with 99.99% probability(becoming 100% after >=n confirmations for k most powerful branches)" statement will be used (in fact we have it now implicitly with all cryptos, mostly with proof-of-stake though). And there are many concerns & problems around to solve. So we think to get deeper into this after New Year holiday.

And next two or three weeks we'll spend on experiments with blockchain quality measure. Cumulative difficulty being using currently seems to be not a good option as in multibranch environment all branches are likely to be very close so there's literally no significant difference between bad and good branches. In single-branch environment(Nxt has now) that means simplicity of blockchain to be overtaken by opponents. So better measure matters in any case. We have some proposals how to improve the measure but investigations needed.  Also we'll spend a lot of time on discussions around N@S paper probably  ;D  and I have a plan for a bunch of easy-to-read-articles about different aspects of consensus algos we're playing with.  Planned budget for phase2 is 200,000 (for two people).

Consensus Research / Report 02-Dec-2014
« on: December 02, 2014, 09:30:31 pm »
Our first bi-weekly report shows a lot of work done, I hope so :)

1. andruiman has finished & published multi-branch forging simulation tool https://github.com/ConsensusResearch/MultiBranch with some formal proofs around that. Paper about multibranch forging and its relation to Transparent Forging is published https://github.com/ConsensusResearch/articles-papers/tree/master/multibranch

2. I have finished Nxt-like 100% Proof-of-Stake forging simulation & just published it https://github.com/ConsensusResearch/ForgingSimulation. It's possible to play with Nxt forging algo and test changes without costly NRS modification from now  :)

"Inside a Proof-of-Stake cryptocurrency" series is also finished. Finally it has 4 articles being published:

Nothing-at-Stake - by mixing both blockchain & blocktree simulations together famous Nothing-at-Stake attack could be simulated as well, e.g. we can mix "attacker" doing blocktree forging with nodes doing blockchain forging Nxt has now. Even more, we already have some simulations done! First results have been sent yesterday to some Nxt core devs, few days later a paper will be sent to investors(spent at least 10K), some active contributors and guys we're highly welcome feedback from(Damelon, benjyz, mthcl), few days after that it will be available publicly.

PS. Our Phase 1 tokens are still for sale: https://trade.secureae.com/#5841059555983208287

PPS. If you want and can do cross-checking, please write me, I'll give you early access.

Consensus Research / First Fundraising Letter
« on: November 14, 2014, 11:29:24 am »

Consensus Research is the first independent research group going to bring formal verification to the world of

The Problem & The Solution

While formal approach (https://en.wikipedia.org/wiki/Formal_verification) is being widely using in hardware industry and some critical software(medical, aerospace, compilers), cryptocurrencies suffer from unproven claims, bold statements, low-quality "papers" and naive implementations, though a cost of an error could be very high (USD$ millions).

ConsensusResearch group is going to improve overall quality of thinking about cryptocurrencies with:

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


In October I published two blogposts about Nxt forging algo, "Inside a Proof-of-Stake Cryptocurrency" part1 ( http://chepurnoy.org/blog/2014/10/inside-a-proof-of-stake-cryptocurrency-part-1/ ) & part2 ( http://chepurnoy.org/blog/2014/10/inside-a-proof-of-stake-cryptocurrency-part-2/ ). Later andruiman published paper on some statistical properties of Nxt forging in his Nxt forging algorithm: simulating approach ( http://www.scribd.com/doc/243341106/nxtforging-1 , scroll down to view).

Right after(and pretty famous topic https://nxtforum.org/general/nxt-forging-algorithm-simulating-approach/ ) he made an impressive amount of work converting my model described in Haskell into Coq, proving some basic properties as theorems, and introducing multibranching forging for that(which could be turned into so-called Transparent Forging during implementation and also open door to Nothing-at-Stake investigation).


We think that community would respect our goals and approach and therefore we offer our assets as a compromise between donations and investments. The asset mechanism lets to benefit both the developers and coins investors through the transparent model of research and core development.

We've issued 10,000,000 assets with initial price of 1 Nxt each. Assets will be sold in lots corresponding to milestones. The name of the asset is "consensus" (id:  5841059555983208287, https://trade.secureae.com/#5841059555983208287 )

Digital Board of Asset Holders

After voting system & 2-phased transactions inclusion into the core we'll use the features intensively. So having "consensus" tokens you will be able to drive a research. For example, you'll be able to vote on tasks priority or decide whether to pay a developer for e.g. visualization tool or not.

There is a risk here for sure. Sometimes democracy is not the best way, but we think our partners are smart so it should be the essential tool of Consensus Research!


1. Executable simulation tool for Nxt-like 100% Proof-of-Stake forging(with delays & transactions). Executable
multibranching forging simulation tool(to estimate properties & computational requirements of Transparent Forging).
Some proofs around the code. 1 paper + 5 articles at least.

Estimated duration: 2-4 weeks
Corresponding lot size: 300,000 Nxt

2. Research on Consensus properties of multibranch forging. In particular, Nothing-At-Stake problem will be formally
defined and analyzed after this milestone.

Estimated duration: 6-8 weeks
Corresponding lot size: 400,000 Nxt

3. Formally proven and secure proof-of-stake forging model(with reference implementation in Haskell w. Coq)

Estimated duration: 6-8 weeks
Corresponding lot size: 400,000 Nxt

Well, further milestones will be clear after. Finally, we're looking for the cryptocurrencies networks algorithms where consensus itself would be much more profitable than forging (or mining) and we believe that our approach could demonstrate the benefits in a rational formal way.

We'll publish bi-weekly reports on progress.

The Value

The main commercial profit from our activity is increased trust in Nxt and/or other cryptocurrencies willing to work with us and cryptocurrency industry at whole. Also we'll consult core developers to make better products. So coin teams  and whales are biggest beneficiaries, and our biggest sponsors, we hope so. We'll no pay dividends,  so the asset issuance is the kind of crowdfunding.

P.S. again, the name of the asset is "consensus" (id:  5841059555983208287, https://trade.secureae.com/#5841059555983208287 )

General / 2-Phased Transactions Post-Implementation Specification
« on: November 11, 2014, 02:35:02 pm »
Two-Phased Transactions

Two-Phased Transactions is multisig transactions implementation in Nxt but much more powerful.

Simplest example, Alice starts a Two-Phased transaction. In the first stage a transaction is included in a blockchain but it isn’t processed immediately and has the status of ‘pending’. For it to be processed, Bob has to complete the second phase of the transaction by approving it. This has to be done before the deadline set by Alice has elapsed.

Use cases

* Bob approving a transaction of Alice

* Shareholders voting whether to send another 1M Nxt to a marketing service or not

* Nxt whales voting on whether to pay bounty or not

* Multisig wallet protected from a hacker(think about BTER case etc)


* any kind of transaction could be 2-phased

* M-of-N consensus or by-balance consensus or shareholders voting to release transaction

* possible vote threshold setting(e.g. only accounts with 1M+ Nxt or 100+ assets balance could vote)

* whitelist of voters

* blacklist of voters

* transaction could be released only prior to maxHeight


* MaxHeight - transaction has to be released before the mandatory height provided or it will be cancelled

* whitelist - list of accounts able to vote on transaction releasing. Max 10 accounts. If no given, any account has a right to vote! Mandatory for by-account voting

* blacklist - list of accounts voting is prohibited for. Only for by-balance & by-asset voting. Couldn't be combined with whitelist(so pending transaction submitter has to choose whether to use whitelist  or blacklist).

* Voting option: by account, by balance, by asset.

* Consensus quorum - transaction released when gathered

* Vote threshold - min balance to vote. Only for by-balance & by-asset voting.

Example: accounts A(balance = 1000 nxt),B(700 nxt),C(400 nxt),D(200 nxt) are able to vote. Vote threshold is 300 nxt, so D can't vote. Consensus quorum is 1500 nxt, so transaction will be released only if A & B vote on this. The example doesn't take money transfers & heights into account.

Voting, Multivoting, Counting

It's possible to vote for multiple (max 10) pending transactions withing one voting transaction. It gives
possibility for trustless escrows etc.

In case of by-account(M-out-of-N) voting a pending transaction will be released on block Mth vote being including into a blockchain.

In case of by-balance or by-asset voting following algorithm is applied:

* votes weights are stored into database

* on getting a vote if vote weight + cached weights >= quorum weights rechecking with database update is taking place. if sum(updated weights) >=
quorum transaction is going to be released

* on maxHeight block there's is a final recheck

* this algo means in some cases of balances moving pending transaction could be released on maxHeight only

Trustless escrows

With 2-phased transactions some kinds of trustless escrows are possible. E.g.
        Tx 1. Alice publishes into blockchain a pending transaction to Bob which will be released only when both Alice and Bob vote for it
        Tx 2. Bob publishes into blockchain a pending transaction to Alice which will be released only when both Alice and Bob vote for it
        Tx 3. Alice generates  transaction bytes for a multivote transaction with votes for both transactions 1 & 2  & sends unsigned transaction bytes, the full transaction hash, and the signature hash to Bob
        Tx 4. Bob sends to the unconfirmed transactions pool a transaction with votes for both transactions 1 & 2  & reference to hash of transaction #3

See https://nxtforum.org/general/trustless-escrows-are-coming!/ for details


To implement 2-phased transactions, 1 new Appendix type & 2 new Transaction types are needed.

* TwoPhased appendix to each type of transaction will mark 2-phased transactions from ordinary ones. Appendix parameters will specify max height to gather consensus to release transaction & poll options(by-account / by-balance / by asset voting), consensus quorum,
list of accounts able to vote, max 10)

* PENDING_PAYMENT_VOTE_CASTING transaction type to for transaction(s) to release (if an account doesn't want this, it should skip voting at all). Max 10 votes possible, so voter can vote up to 10 pending transactions at once. Transaction will be released when quorum(specified by threshold) will be gathered. It will be cancelled if no consensus being gathered @ height maxHeight provided in pending transaction params.

Java API

Let's consider sort of classic example: Alice pays 50 Nxts to Chris, but only after Bob's approval and within 30 blocks after pending transaction issuance. Please note TransactionBuilder got `twoPhased` method which accepts `TwoPhased` appendix object. We use `TwoPhased` constructor accepting maxHeight, voting model, quorum, vote threshold, whitelist, blacklist as params. Scala language is used, but code is very like Java in the example.

        val Fee = Constants.ONE_NXT
        val h = Nxt.getBlockchain.getHeight

        val tb = Nxt.getTransactionProcessor.newTransactionBuilder(alicePubKey, 50*Fee, Fee, defaultDeadline, Attachment.ORDINARY_PAYMENT)
        tb.twoPhased(new TwoPhased(h+30, Constants.VOTING_MODEL_ACCOUNT, 1, 0, Array[Long](voterId), null))

        val tx = tb.build()

Now Bob's turn to vote on transaction:

        val vatt = new Attachment.PendingPaymentVoteCasting(tx.getId)
        val vtb = Nxt.getTransactionProcessor.newTransactionBuilder(bobPubKey, 0, Fee, defaultDeadline, vatt)
        val vtx = vtb.build()

And on block height when transaction is going into the blockchain balance of Chris is increasing by 50 Nxt
(if this height within 30 blocks after Alice's transaction block).


From now every kind of API call creating a transaction has additional parameters:

* pendingVotingModel - mandatory - could be 0,1 or 2 according to following constants:

        public static final byte VOTING_MODEL_BALANCE = 0;
        public static final byte VOTING_MODEL_ACCOUNT = 1;
        public static final byte VOTING_MODEL_ASSET = 2;

* pendingMaxHeight - mandatory - height to refuse transaction if there's no quorum @ this height. Not less than
  10 blocks from current height.

* pendingQuorum - mandatory - number of accounts/total Nxt/assets balance to get transaction released

* pendingMinBalance - optional - vote threshold. 0 if skipped

* pendingAssetId - mandatory if pendingVotingModel == 2 (e.g. by-asset voting)

* pendingWhitelisted - mandatory if by-account voting, provide multiple values if needed (e.g. `pendingWhitelisted=${account1Id}&pendingWhitelisted=${account2Id}`)

* pendingBlacklisted - optional, couldn't be combined with whitelist, provide multiple values if needed


Poll will be created only after approval of the account 7926777737834261541:

curl -d 'name=cryptos&description=rate+cryptos+you+like&finishHeight=112000&votingModel=1&minNumberOfOptions=1&maxNumberOfOptions=2&minRangeValue=-5&maxRangeValue=5&secretPhrase=secret+phrase&deadline=1000&feeNQT=1000000000&option1=nxt&option2=btc&isPending=true&pendingVotingModel=1&pendingMaxHeight=111800&pendingQuorum=1&pendingWhitelisted=7926777737834261541' http://localhost:6876/nxt?requestType=createPoll

Also there are some new API calls to get pending transactions, for now just:

* GetAccountPendingTransactionIds - to get pending transactions issued by some account. Possible parameters are "account", "finished", "firstIndex", "lastIndex", where "finished" could be empty or skipped.

* GetAccountPendingTransactionToSignIds - to get pending transactions where account is whitelisted. Parameters are the same as above.

* GetAssetPendingTransactionIds - to get pending transactions where some asset mentioned. Parameters are as above but "asset" instead of "account".


In case of by-balance & by-account voting pending transaction should be a subject for a higher fee probably,
as a lot of computations could be needed on vote processing. For now fee is standard (i.e. 1 Nxt) though.

Voting System / Voting System got massive updates
« on: November 04, 2014, 11:35:11 pm »
During last days voting system got massive update. Most valuable things done:
  • Simplified but more powerful voting model with number of options & values ranges
  • As consequence, simplified results as well.
  • By-account voting now possible with asset balance threshold (e.g. all shareholders having more than 1000 assets have equal weight in voting)

Detailed description below:

Voting system specification

This document describes voting system in details and its implementation.


* Different voting models supported(see also community proposals gathered prior this implementation https://wiki.nxtcrypto.org/wiki/Voting_System): voting by account(1 account=1 vote), balance(1 NXT=1 vote) or asset balance(1 QNT=1 vote)

* Poll has minimum and maximum number of options to provide opinion for. E.g. choose from 2 to 5 options out of 8

* Range is also parameter. E.g. give a rate from 0 to 10

* By combining number of options & range a lot of specific poll types could be done. E.g. binary poll is poll where range is from 0 to 1 (i.e. no or yes).

* Voting has finite predefined duration(finish block height, to say preciously)

* Anonymous voting is not supported for now. It could be implemented with Blind signatures(https://en.wikipedia.org/wiki/Blind_signature) but it's not known for now how to implement that over blockchain. Anonymous voting could be implemented by trusted 3rd party services.

* Leased voting - not implemented for now

Voting models

There are three models for now:

* By account, 1 account = 1 Vote, where minimum balance in nxts or assets could be set also

* By balance, 1 Nxt = 1 Vote.

* By asset, 1 Asset QNT  = 1 Vote. Additional parameter specifies an asset ID.

All models could be enhanced by additional parameter, describing min balance(in NXT / QNT).


Counting happens at the finish block height stated during poll creation. And a vote being counted only if it satisfies poll parameters(min balance etc) at that finish height. Please note, voter could vote with balance < min balance needed to vote(at height where vote has been sent), and it's valid, but a vote could be counted only if balance >= threshold balance at poll finish height.

Mandatory Parameters

* name - a poll's title

* description - detailed poll description

* options - possible options to choose from and give a rate to

* votingModel - three possible values for by-account, by-balance, by-asset voting

* finishHeight - block height in future poll is finishing and counting taking at

* minNumberOfOptions, maxNumberOfOptions - minimum and maximum number of options a voter can choose

* minRangeValue, maxRangeValue - a voter value within this range

Optional parameters

* assetId - for voting by assets, also used for min_balance in by-account voting(i.e. if assetId!= 0 minBalance is in assets, otherwise in Nxts)
* minBalance - 0 by default. Vote counts only if account balance @ counting height (in NXT or QNT) >= minBalance


* 10 confirmations limit used for balance calculation
* Voting by asset could be started by anyone, not just asset issuer or even asset owner.



There are two kinds of attachments related to voting system: MessagingPollCreation & MessagingVoteCasting. As MessagingPollCreation. Also please take a look PollBuilder helper implementing Builder pattern to MessagingPollCreation objects:

val pb = new PollBuilder(question, desc, options, finishBlockHeight, votingModel,
                                       minNumberOfChoices, maxNumberOfChoices, minRangeValue, maxRangeValue)
minBalanceOpt.map(mb => pb.minBalance(mb))
assetIdOpt.map(ai => pb.assetId(ai))

issueTx(phrase, new Attachment.MessagingPollCreation(pb))

Transaction types

There are two transaction types related to VS: POLL_CREATION and VOTE_CASTING.

Java API
Examples below are in Scala but should be easily understandable for an every Java develope too:

Shareholders voting, a shareholder has to have 100 shares of 1000 at least. Please also read description:

val question = "What are the next features to get done?"
val description = "Please take voting seriously as we have very limited amount of resources. So you have to choose from 1 to 3 features out of 5 and rate them from 1 to 5"
val finishBlockHeight = Nxt.getBlockchain.getHeight + 10000

val options = Array("feature A", "feature B", "feature C", "feature D", "feature E")

val votingModel = Constants.VOTING_MODEL_ASSET

val pb = new PollBuilder(question, desc, options, finishBlockHeight, votingModel, 1, 3, 1, 5)

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

Poll is created! Now time to send a vote. Please note skipped answers should be marked with Byte.MIN_VALUE value
(i.e. -128):

val poll = Poll.getPollsByAccount(accountId, 0, -1).iterator.toSeq.find(_.name == question).get
val vote = Array(3.toByte, Byte.MIN_VALUE, Byte.MIN_VALUE, 5.toByte, Byte.MIN_VALUE)
val attachment = new Attachment.MessagingVoteCasting(poll.getId, vote)
issue(phrase2, attachment)

Please note that vote will be not counted if acoount has less than 100 shares.

Say, we have 4 voters, one has 50 shares(so a vote isn't being counted), second has 4 options chosen(so vote is invalid), third has 200 shares and gave a 5 to first option , fourth has 400 shares and gave 3 to both first&second options. After poll is finished here is the code to get results:

val results = Poll.getResults(poll.getId())

assert(resultsOpt.isDefined) //check we have results
assert(results.find(_.getFirst == "featureA").get.getSecond == 2200
assert(results.find(_.getFirst == "featureB").get.getSecond == 1200
assert(results.find(_.getFirst == "featureC").get.getSecond == 0
assert(results.find(_.getFirst == "featureD").get.getSecond == 0
assert(results.find(_.getFirst == "featureE").get.getSecond == 0


Create poll


name - mandatory - poll title, not longer than 100 chars

description - mandatory - detailed poll description, max 1000 chars

finishHeight - mandatory - height of block when voting will be finished i.e. counted(should be > current one)

votingModel - mandatory - by-asset, by-account, or by-balance. see corresponding numeric value below

minBalance - optional - min amount of money or assets to vote, in nxt or qnt. by default 0(if skipped)

minNumberOfOptions - mandatory - min number of options to choose

maxNumberOfOptions - mandatory  - max number of options to choose

minRangeValue - mandatory - min vote value possible, no more than 100

maxRangeValue - mandatory  - max vote value possible, no less than -100

assetId - mandatory in case of by-asset voting, could be also usedin addition with minBalance in by-account voting - asset id in unsigned form

option1,option2,option3,option4,...option100 - titles of corresponding options

Use following values to set voting model:



curl -d 'name=cryptos&description=rate+cryptos+you+like&finishHeight=120000&votingModel=1&minNumberOfOptions=1&maxNumberOfOptions=2&minRangeValue=-5&maxRangeValue=5&secretPhrase=very+secret+phrase&deadline=1000&feeNQT=1000000000&option1=nxt&option2=btc' http://localhost:6876/nxt?requestType=createPoll

Vote casting [/i][/u]

curl -d 'poll=12528572507118413418&secretPhrase=secret+phrase&deadline=1000&feeNQT=100000000&vote1=1&vote2=0' http://localhost:6876/nxt?requestType=castVote

Get poll data


Get poll results


Get polls created by an account

curl -d 'account=7926777737834261541&firstIndex=0&lastIndex=5'  http://localhost:6876/nxt?requestType=getAccountPolls

P.S. Jones is working on UI now!

General / Trustless Escrows are Coming!
« on: October 23, 2014, 10:16:03 pm »
With 0.9.9 release ( https://nxtforum.org/nrs-releases/nrs-v0-9-9/ ) we've got ability to have trustless escrows though not working in some rare cases(so the approach is suitable for small-value transactions only):

Quote from: Jean-Luc
Alice prepares and signs a transaction A, but doesn't broadcast it (setting the
broadcast=false parameter introduced in this release). She sends to Bob the
unsigned transaction bytes, the full transaction hash, and the signature hash.
All of those are included in the JSON returned by the API. (Warning: make sure
not to send the signed transaction bytes, or the signature itself, as then Bob
can just broadcast transaction A himself).

Bob prepares, signs and broadcasts transaction B, setting the
referencedTransactionFullHash parameter to the full hash of A provided by Alice.
He can verify that this hash indeed belongs to the transaction he expects from
Alice, by using the new calculateFullHash API, which takes unsigned transaction
bytes and signature hash (both of which Alice has also sent to Bob). He can also
use the parseTransaction API to decode the unsigned bytes and inspect all
transaction fields.

Transaction B is accepted in the unconfirmed transaction pool, but as long as A
is still missing, B will not be confirmed, i.e. will not be included in the
blockchain. If A is never submitted, B will eventually expire - so Bob should
make sure to set a long enough deadline, such as the maximum of 1440 minutes.

Once in the unconfirmed transactions pool, Bob has no way of recalling B back.
So now Alice can safely submit her transaction A, by just broadcasting the
signed transaction bytes she got in the first step. Transaction A will get
included in the blockchain first, and in the next block Bob's transaction B
will also be included.

Note that while the above scheme is good enough for a simple escrow, the
blockchain does not enforce that if A is included, B will also be included. It
may happen due to forks and blockchain reorganization, that B never gets a
chance to be included and expires unconfirmed, while A still remains in the
blockchain. However, it is not practically possible for Bob to intentionally
cause such chain of events and to prevent B from being confirmed.

Two months ago I published specification for 2-phased transactions ( https://nxtforum.org/general/2-phased-transactions-pre-implementation-specification/ ). Implementation is done according to the spec(though minHeight parameter is missed), so I'm going to investigate real-world use cases for 2-phased transactions & possible changes to spec&implementation before release(which is planned for 1.4.x):

1. Multivoting

By adding ability to vote for few pending transactions release at the same time trustless and 100% reliable escrow scheme possible with 4 transactions:

Tx 1. Alice publishes into blockchain a pending transaction to Bob which will be released only when both Alice and Bob vote for it
Tx 2. Bob publishes into blockchain a pending transaction to Alice which will be released only when both Alice and Bob vote for it
Tx 3. Alice generates  transaction bytes for a multivote transaction with votes for both transactions 1 & 2  & sends unsigned transaction bytes, the full transaction hash, and the signature hash to Bob
Tx 4. Bob sends to the unconfirmed transactions pool a transaction with votes for both transactions 1 & 2  & reference to hash of transaction #3

Then... read JLP's explanations above, but in (pretty unusual but possible) case of having transaction #4 lost both Alice & Bob loses nothing except of transactions fees(transactions #1 & #2 will be refused after deadline)

2. Vote-for-hash & votable appendix

In 1.2.x(I've forgotten 'x' unfortunately) transaction appendages were introduced. E,g, with message appendix every transaction could has message included, with pendable appendix it will be possible to create pending transaction to be released  when voting quorum met or refused on deadline etc
 I think we can introduce Votable appendix as well means transaction doing voting on another transaction in addition to its main purpose.

Another promising feature is voting for transaction hash(so transaction couldn't be presented into blockchain but a vote for it is already there).

With those additions trustless escrow could be done with just 2 transactions:

1. Alice generates  transaction bytes for a pending transaction to Bob which will be released only when Bob votes for it. Then she sends unsigned transaction bytes, the full transaction hash, and the signature hash to Bob
2. Bob sends to the unconfirmed transactions pool a transaction to Alice with tx #1 hash within voting appendix. 

Then again, JLP's turn to explain :)

Feedback & Contribution are needed

What features to implement? Multivoting is simple, vote-for-hash & votable appendix is a harder task. It also depends on community needs so let's think together about possible use cases of phased transactions!

(More contracts further)

Pages: [1] 2