elective-stereophonic
elective-stereophonic
Whitepaper  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

Author Topic: Whitepaper  (Read 4761 times)

devlux

  • Board Moderator
  • Sr. Member
  • ****
  • Karma: +67/-2
  • Offline Offline
  • Posts: 307
    • View Profile
    • Gemspace
Whitepaper
« on: April 15, 2016, 01:29:52 am »

Ok everyone.  I'm posting the whitepaper as it stands right now.
Please read it and especially when it comes to NXT assertions please fact check it.  If I'm wrong anywhere, let me know and I'll fix it.
Keep in mind that NXT was a late decision.  Originally this was intended for Bitcoin and derivatives, it was only after talking to the DOGE community a bit about it and having them poke holes in the idea, that we realized it would be easier to use an existing coin with a message box feature than to tack on some of these features to a coin that doesn't support them, or to try and spin up our own coin for this.

As you read this, realize it is NOT a marketing document.  It's meant as a reference document which is part of the standards process.
Something we can show to other companies to get their support for this global standard.  Ergo there is more indepth explanation about what a blockchain is and what it can and cannot do, than there would be for a document targeting the crypto currency community.  Also you might take exception with some of the descriptions, but realize the intended audience MAY have heard of bitcoin from the news once, but otherwise has no clue about the tech.  They're thinking Excel spreadsheets, MSSQL server etc.

https://jumpshare.com/v/hYuIQfdCboVxZ6iKLzHt
Logged
Evolution NEXT D.A.C.
NXTAE:3385321989487982138 (EVOLVE)

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +439/-42
  • Offline Offline
  • Posts: 1790
    • View Profile
Re: Whitepaper
« Reply #1 on: April 15, 2016, 06:17:53 am »

I scanned through the White paper and my initial impression is that you are describing pretty much the existing NXT voting system.
Have you considered using the NXT voting system at least for the pilot ?
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

devlux

  • Board Moderator
  • Sr. Member
  • ****
  • Karma: +67/-2
  • Offline Offline
  • Posts: 307
    • View Profile
    • Gemspace
Re: Whitepaper
« Reply #2 on: April 15, 2016, 06:57:48 am »

I scanned through the White paper and my initial impression is that you are describing pretty much the existing NXT voting system.
Have you considered using the NXT voting system at least for the pilot ?

Using the NXT built in system is a potential fallback position if we can't roll this out in time for the primary, but it's not a long term solution.
 
The biggest problem with using the inbuilt NXT voting system is bespoke or write-in options, I don't see a way to put that in or account for it at all, but it is vital.

Additionally, as far as I can tell the NXT voting system is not multilingual, whatever language the ballot is in, gives us the only option for text.
But there are locations that mandate a ballot be available in the users choice of language. 

There may also be accessibility concerns for those who are vision impaired, but those types of concerns would be addressed in the client, however the votescript standard does specify certain things to make accessibility easier to implement.

Other limits not covered by NXT are things like images and enhanced descriptive text (click here for further details on this proposal)

Hence the whitepaper, but yes this version does incorporate a bit of the NXT design where appropriate because it's intended for a standards track and the folks who will be reading it have likely never heard of NXT. 

Thank you for reading it though!
Logged
Evolution NEXT D.A.C.
NXTAE:3385321989487982138 (EVOLVE)

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +439/-42
  • Offline Offline
  • Posts: 1790
    • View Profile
Re: Whitepaper
« Reply #3 on: April 15, 2016, 07:22:28 am »

Quote
The biggest problem with using the inbuilt NXT voting system is bespoke or write-in options, I don't see a way to put that in or account for it at all, but it is vital.

Each vote transaction can have a message attachment where you can add arbitrary data if that's what you mean.

Quote
Additionally, as far as I can tell the NXT voting system is not multilingual, whatever language the ballot is in, gives us the only option for text.
But there are locations that mandate a ballot be available in the users choice of language. 

This is a minor client side issue. You can use localization in JavaScript to provide multi-lingual support the same way the existing wallet supports it.

Quote
There may also be accessibility concerns for those who are vision impaired, but those types of concerns would be addressed in the client, however the votescript standard does specify certain things to make accessibility easier to implement.

Other limits not covered by NXT are things like images and enhanced descriptive text (click here for further details on this proposal)

In any case, you'll have to develop a client side application which uses the voting or messaging APIs to address this.
And frankly, today is April 15th, if you need something ready by June 7th it's way too late to develop the scripting system you proposed from scratch.
My recommendation for you is to create simple UI around the existing voting system, use it to get feedback and funding, then if still necessary implement the scripting system.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

devlux

  • Board Moderator
  • Sr. Member
  • ****
  • Karma: +67/-2
  • Offline Offline
  • Posts: 307
    • View Profile
    • Gemspace
Re: Whitepaper
« Reply #4 on: April 15, 2016, 07:52:03 am »

Ok I'm getting lost in nested quotes here so forgive me.

Quote
Quote
Additionally, as far as I can tell the NXT voting system is not multilingual, whatever language the ballot is in, gives us the only option for text.
But there are locations that mandate a ballot be available in the users choice of language. 

This is a minor client side issue. You can use localization in JavaScript to provide multi-lingual support the same way the existing wallet supports it.

If the client is written in Javascript that would make sense.  But there is no guarantee of this and it's extremely unlikely to be the case given that most voting hardware is still on Windows CE.  We cannot force a manufacturer to choose one platform or another, the best we can do is take steps to guarantee that the voter sees the same ballot options no matter what the vendor selected.  Votescript spells out that ANY text presented to the use is part of a ballot item, the ballot item is referenced by it's SHA256 hash.  This is there to prevent tampering with a ballot after distribution.

Quote
Quote
There may also be accessibility concerns for those who are vision impaired, but those types of concerns would be addressed in the client, however the votescript standard does specify certain things to make accessibility easier to implement.

Other limits not covered by NXT are things like images and enhanced descriptive text (click here for further details on this proposal)

In any case, you'll have to develop a client side application which uses the voting or messaging APIs to address this.
And frankly, today is April 15th, if you need something ready by June 7th it's way too late to develop the scripting system you proposed from scratch.
My recommendation for you is to create simple UI around the existing voting system, use it to get feedback and funding, then if still necessary implement the scripting system.
[/quote]

Ok two problems with the statement. 

It assumes we're starting from scratch here and we're not.  A votescript enabled client was the first thing we built and that was back in October of last year.  What we do need to do is get it to encode and interface with NXT instead of DOGE + Bitmessage, but that's a handful of API calls.  There is still software to develop but that's on track for last week of May so no worries there.

The other problem with the statement is that the whitepaper describes a standard that integrates NXT, we will be doing everything we can deliver a full reference implementation in time for June 7th of course.  However the initial implementation will be quite limited in it's capabilities.  The biggest concern right now is adapting a block explorer to understand the tally procedure.  That constitutes the bulk of the work to be done.

Ideally anything NXT specific such as message size limits, or any confusion the paper might be casting towards the capabilities of NXT as a platform for this, i.e. unfounded or incorrect assumptions about NXT are what we're seeking to weed out with the whitepaper review.

Quote
Quote
The biggest problem with using the inbuilt NXT voting system is bespoke or write-in options, I don't see a way to put that in or account for it at all, but it is vital.

Each vote transaction can have a message attachment where you can add arbitrary data if that's what you mean.
Very interested in this, can you please link me the docs on it?
Logged
Evolution NEXT D.A.C.
NXTAE:3385321989487982138 (EVOLVE)

NxtSwe

  • Hero Member
  • *****
  • Karma: +124/-9
  • Offline Offline
  • Posts: 657
    • View Profile
Re: Whitepaper
« Reply #5 on: April 15, 2016, 08:05:55 am »

Quote
Quote
Quote
The biggest problem with using the inbuilt NXT voting system is bespoke or write-in options, I don't see a way to put that in or account for it at all, but it is vital.

Each vote transaction can have a message attachment where you can add arbitrary data if that's what you mean.
Very interested in this, can you please link me the docs on it?
A message can be attached to any transaction.
All the message properties that can be used in sendMessage api can be used by any transaction. You can have both plain message, encrypted message and message to self in the same tx.
https://nxtwiki.org/wiki/The_Nxt_API#Send_Message

When using the built in voting system, the voter is still constrained to choose one of the pre-defined choices, and the attached message will have no effect on the counting of votes.
Also, with the built-in voting system you'll need one account per voter.
« Last Edit: April 15, 2016, 08:49:18 am by NxtSwe »
Logged
Check out the NxtLib, the .NET Framework API for the Nxt platform.

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Whitepaper
« Reply #6 on: April 15, 2016, 08:50:17 am »

About your suggestions about improving protection against 51% attack:

Adding a restriction that consecutive blocks must be forged by different accounts will not be effective, because an attacker with >51% stake can always split it over multiple accounts. In fact, even in the absence of such restriction, a prospective attacker accumulating stake will do that, to avoid raising suspicion by having too much funds in a single account.

Restrictions based on IP address also will not work, as the IP of the node that forged a block (or submitted a transaction) is always unknown. You can't tell when receiving a new block or transaction from a node whether it was this node that created it, or is just forwarding it as received from others. This is intentional, to protect privacy. And even if such restrictions were to be added, would be trivial to circumvent, e.g. by broadcasting blocks over Tor, using VPNs, renting cheap VPS servers in multiple countries, hiring a botnet, and so on.

Some features of Nxt you may find helpful:

Indeed, each transaction can have a prunable message attachment of up to 42k. This includes the transaction that creates a new poll (e.g., you could attach an image to it), or each voting transaction (for some custom options). This is how we achieved adding images to the marketplace, without requiring any new transaction types or a hard fork, just taking advantage of the existing ability to attach arbitrary message to any transaction, in this case the digital goods listing transaction.

We have referenced transactions feature, so a transaction can refer to another transaction (which must be in the blockchain before the referring transaction is accepted). This way, if the above message attachment feature is not enough, you can chain transactions, e.g. upload some document to the data cloud, then have the poll creation transaction refer to the transaction id of that document, in addition to having its own message attachment. This way you get more data effectively linked to the same transaction, i.e. can attach both an image (as attachment) and a pdf file (in the data cloud). Will need some custom client support to check if there is such referenced transaction and do something about it, but you need custom client work for your voting system anyway.

Account properties, name/value pairs that each account can set for itself, or for other accounts, might also come useful to label some accounts, or authorize them (again such authorization to be interpreted client side).

You might have noticed that we already support "time locked" transactions, implemented as phased transactions with deferred execution, to happen at a specific block in the future.

And since we don't have "wallet" files, there is no really issue of voting machine going out of order, needing to be drained of funds and so on - use multisig accounts that could be controlled from anywhere, no need to tie them to a physical wallet file located on specific hardware.

Trying to see how this can fit with the existing voting system in Nxt. What I would suggest is to issue a controlled MS currency, by which voting will be weighted. Each voter account should get one unit of this currency, to be used as a voting token. At each polling location, you run a custom program that generates the same number of random secret phrases, derives the corresponding account number and public key for each. The secret phrases must be distributed to voters randomly, without keeping track of who gets which. The account numbers are then submitted to the currency issuer (off-blockchain), who sends one unit of the currency to each. Being a controlled currency, it cannot be transferred or traded between accounts, but only back and forth to the currency issuer account. This transfer should all be done before the voting starts, so that it can be verified that each of the accounts at each polling location has received its voting token.

For the actual voting, each voter uses the secret phrase allocated to him to submit a voting transaction. Here you need some custom software to preserve anonymity. If each such transaction is broadcasted immediately to the blockchain, an outside observer can tell who submitted which vote by just observing the order voting transactions appear on the blockchain and correlating this with time and order of voters submitting their votes. So you should not broadcast the transaction immediately, but create it (and use the same transaction timestamp for all, some fixed time in the past), keep it locally (with some redundant backup in case the machine crashes), then broadcast accumulated transactions in batches, sufficiently large to provide statistical anonymity. Now, you can't prevent double voting for transactions that are not yet in the blockchain, so the local machine needs to do some checking against duplicate voting attempts for transactions that it has cached locally but not yet submitted to the blockchain. All this complication can be avoided by broadcasting transactions immediately, at the cost of reduced anonymity.

Note that while two voting transactions from the same account and for the same poll cannot co-exist in the blockchain, such conflicting transactions can still be created and even co-exist in the unconfirmed transaction pool in memory. Only one of them will eventually be included in a block, and at this point the other will become invalid and eventually expire. But which transaction will be included cannot be guaranteed - by default it will be the first one that the node which forges the block has received, but a forger is free to decide to include the other one instead.

Also, since there is no local wallet file, anyone knowing one of those secret phrases can create and broadcast a voting transaction from anywhere in the world. To prevent that, again you need some custom client software, to tie those passwords with a local wallet file at each polling location, which file contains in encrypted form the real secret phrases.

To prevent further use of a voting account after the voting transaction has been cast, the account could be locked using account control by e.g. making it require the approval of Genesis account for any transactions. Since Genesis can't issue transactions, this makes the account effectively unusable. Such locking must be done after the voting transaction has already been accepted in the blockchain. Without such locking, someone knowing the secret phrase can send the currency token back to the issuer account, before voting has finished, thus making the vote not count as the account will not own the token when counting is done. If this is an acceptable risk, locking is not needed, I can't think of other possible malicious transactions after the vote.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

devlux

  • Board Moderator
  • Sr. Member
  • ****
  • Karma: +67/-2
  • Offline Offline
  • Posts: 307
    • View Profile
    • Gemspace
Re: Whitepaper
« Reply #7 on: April 15, 2016, 09:25:16 am »

About your suggestions about improving protection against 51% attack:

Adding a restriction that consecutive blocks must be forged by different accounts will not be effective, because an attacker with >51% stake can always split it over multiple accounts. In fact, even in the absence of such restriction, a prospective attacker accumulating stake will do that, to avoid raising suspicion by having too much funds in a single account.

Restrictions based on IP address also will not work, as the IP of the node that forged a block (or submitted a transaction) is always unknown. You can't tell when receiving a new block or transaction from a node whether it was this node that created it, or is just forwarding it as received from others. This is intentional, to protect privacy. And even if such restrictions were to be added, would be trivial to circumvent, e.g. by broadcasting blocks over Tor, using VPNs, renting cheap VPS servers in multiple countries, hiring a botnet, and so on.

Excellent info all around, still digesting it, going to be awhile before I can reply to the whole post.
The 51% attack remediation was left over from a previous draft, I thought I had cut that out to put into a separate white paper.  Part of a larger solution I planned to discuss with you at another time.  Nice analysis though!

I'll pull that part out and update the whitepaper in the morning, getting pretty late here.
Logged
Evolution NEXT D.A.C.
NXTAE:3385321989487982138 (EVOLVE)

bob_ggg

  • Jr. Member
  • **
  • Karma: +9/-0
  • Offline Offline
  • Posts: 90
    • View Profile
Re: Whitepaper
« Reply #8 on: April 15, 2016, 10:53:06 am »

It is very interesting to follow this discussion since the analysis of a real-world case provided by JL is very instructive. As a side suggestion, these posts should be collected and, when possible, expanded, with an actual example of the procedure flowchart.

In addition to the sequence suggested by JL, the voting procedure could include a message that is broadcast as soon as the vote is cast. This message provides a proof of publication and allows client-side software to block any additional attempt to double vote.
The procedure is equivalent to the one is use today, where the attendance of a voter is immediately registered on paper and made public.
Logged

bob_ggg

  • Jr. Member
  • **
  • Karma: +9/-0
  • Offline Offline
  • Posts: 90
    • View Profile
Re: Whitepaper
« Reply #9 on: April 15, 2016, 04:04:10 pm »

Thinking to the way the system works in my country, polls are open at least 18 hours and sometimes more. Participation stats are provided in real time, while counting must start after the end of the ballot. These requirements create a few problems:
 
  • if a vote is not broadcast, how can I know that it is not canceled? A reason to do that is because physical attendance can not be concealed. If system administrators were "convinced" to cancel a vote cast by a specific voter that would be easy to do and difficult to detect. My previous suggestion was meant to avoid this problem
  • however, using the messaging system to guarantee that the vote count can not be tricked as per my previous suggestion does not work since a simple (physical) timing analysis would allow to break the anonymity of the vote due to the possibility to associate the vote and message coming from the same account;
  • relying on custom software for these critical task is a no go; if custom software is required for key tasks, then it is better to go custom everywhere.
Of lesser relevance, publishing of blocks of votes would allow to perform partial counts; this is forbidden in many countries.
If the previous points are correct, then a solution should rely on two accounts, one for voting and the other for posting to the blockchain that a vote has been cast.
Logged

devlux

  • Board Moderator
  • Sr. Member
  • ****
  • Karma: +67/-2
  • Offline Offline
  • Posts: 307
    • View Profile
    • Gemspace
Re: Whitepaper
« Reply #10 on: April 15, 2016, 10:28:27 pm »

Quote
Some features of Nxt you may find helpful:

Indeed, each transaction can have a prunable message attachment of up to 42k. This includes the transaction that creates a new poll (e.g., you could attach an image to it), or each voting transaction (for some custom options). This is how we achieved adding images to the marketplace, without requiring any new transaction types or a hard fork, just taking advantage of the existing ability to attach arbitrary message to any transaction, in this case the digital goods listing transaction.
I can see this being very helpful.  One thing we had considered for the independent audit was a way of ensuring that the auditors remain honest via a paper sign in sheet with signatures and a number column next to them.  This would allow us to randomly sample and verify that someone had signed the sheet.  Again it's about providing rock solid evidence that can stand up in a court of law should the need arise.

Quote
We have referenced transactions feature, so a transaction can refer to another transaction (which must be in the blockchain before the referring transaction is accepted). This way, if the above message attachment feature is not enough, you can chain transactions, e.g. upload some document to the data cloud, then have the poll creation transaction refer to the transaction id of that document, in addition to having its own message attachment. This way you get more data effectively linked to the same transaction, i.e. can attach both an image (as attachment) and a pdf file (in the data cloud). Will need some custom client support to check if there is such referenced transaction and do something about it, but you need custom client work for your voting system anyway.

Account properties, name/value pairs that each account can set for itself, or for other accounts, might also come useful to label some accounts, or authorize them (again such authorization to be interpreted client side).

You might have noticed that we already support "time locked" transactions, implemented as phased transactions with deferred execution, to happen at a specific block in the future.
I did notice these items.  In the whitepaper we mention that the NXT data cloud makes perfect sense for uploading the ballots themselves.
How we would do it, is each ballot item would be referenced by a unique hash, this would be it's datacloud name.  Then the official ballot would be another file (again in the data cloud) which basically says "download these ballot items and present them in this order".

Quote
And since we don't have "wallet" files, there is no really issue of voting machine going out of order, needing to be drained of funds and so on - use multisig accounts that could be controlled from anywhere, no need to tie them to a physical wallet file located on specific hardware.
Ehh, that's sort of the opposite of what we want.  If a machine goes out of order, then any service could be seen as tampering.
The part about taking it out and bringing it back into service is targeting independent auditors who are running a parallel vote.  They are able to service their machines, but there are checks in place to make say "hey this machine did something wonky, ergo this auditors results need closer scrutiny".

In a professional voting machine in a real election, the account "key" would literally be soldered to the motherboard and the signing process would take place in dedicated hardware on the device.

What we're really doing here is saying
"This machine cast these votes.  This machine was in location x for y amount of time and saw n voters while in service.  During it's time in service the machine produced these votes which are exhbit a."

Quote
Trying to see how this can fit with the existing voting system in Nxt. What I would suggest is to issue a controlled MS currency, by which voting will be weighted. Each voter account should get one unit of this currency, to be used as a voting token.
This is a great idea and something only possible on NXT.  In the whitepaper we take it for granted, it's implied but not stated specifically.  Simply refer to any derived currency though by the name of it's parent.  This is why we say "for our purposes coin or currency refers to whatever is used to confer the ability to write to the blockchain".

Quote
At each polling location, you run a custom program that generates the same number of random secret phrases, derives the corresponding account number and public key for each. The secret phrases must be distributed to voters randomly, without keeping track of who gets which. The account numbers are then submitted to the currency issuer (off-blockchain), who sends one unit of the currency to each. Being a controlled currency, it cannot be transferred or traded between accounts, but only back and forth to the currency issuer account. This transfer should all be done before the voting starts, so that it can be verified that each of the accounts at each polling location has received its voting token.
I don't dislike this idea, but it makes keeping the identity of the voter secret much harder, also you encounter a problem with vote selling.  The voter can prove specifically that they voted a certain way.  There are two forms of vote selling we're trying to break here.  The first is the outright sale, i.e.  "Here's proof I voted for your guy, now give me my $1".  There's also the more insidious kind where a boss or a company wants a specific outcome and they tell their employees, "Make sure to bring in your reciept to prove you voted for the initiative, it will be great for our company. Times are tight, we need everyone to be a team player here, you do like your job don't you?  Besides everyone who does this will be entered into a special drawing for employee of the month!"

If the user can prove that they voted a certain way, then voting selling becomes possible.  Ergo we break this by making everything on the technical end all about the machine.  Where was the machine, what was it doing during time frame x.  So when we give the voter proof of their vote we don't give them anything about the account or the internal workings of the machine.  We give them a number, this number gives a broad timeframe of around an hour or so.  They can look and see that votes were cast during that time frame for their candidate.  They have strong assurance that one of those votes is theirs, but they have no direct proof, merely circumstantial evidence.

Quote
For the actual voting, each voter uses the secret phrase allocated to him to submit a voting transaction. Here you need some custom software to preserve anonymity. If each such transaction is broadcasted immediately to the blockchain, an outside observer can tell who submitted which vote by just observing the order voting transactions appear on the blockchain and correlating this with time and order of voters submitting their votes. So you should not broadcast the transaction immediately, but create it (and use the same transaction timestamp for all, some fixed time in the past), keep it locally (with some redundant backup in case the machine crashes), then broadcast accumulated transactions in batches, sufficiently large to provide statistical anonymity. Now, you can't prevent double voting for transactions that are not yet in the blockchain, so the local machine needs to do some checking against duplicate voting attempts for transactions that it has cached locally but not yet submitted to the blockchain. All this complication can be avoided by broadcasting transactions immediately, at the cost of reduced anonymity.
Ok so the problem here comes down to account control.  The voter has an account in the system you describe.  As long as the voter has an account, then no matter what we do, this means there is a direct link between voter and vote possible.  Now what we really need to address here is that as I mentioned before, "the machine's the thing".  How do we stop someone from just sitting in the booth and voting over and over again.  This is an implementation specific detail, that has a solution in people not technology.  What we do here is we keep the sign in process, voter comes in shows their voter registration card and signs a role sheet and waits in line.  At the end of the line is a large fishbowl.  In the fish bowl are slips of paper with randomly generated numbers.  The voter pulls one number out of the bowl and proceeds to the first available voting booth.

The "login" is just to enter the number.  The device compares the numbers to a database to determine if that number is in the lottery list and denies access if it's been seen before.  Otherwise the voter votes and the process of query cancels out the number from future use.  Once an hour or so, the device broadcasts a list of numbers in numerical ascending order over the past hour to the blockchain.  This is picked up by the tools used to show the voter the votes that occured within their time window.
Quote
Note that while two voting transactions from the same account and for the same poll cannot co-exist in the blockchain, such conflicting transactions can still be created and even co-exist in the unconfirmed transaction pool in memory. Only one of them will eventually be included in a block, and at this point the other will become invalid and eventually expire. But which transaction will be included cannot be guaranteed - by default it will be the first one that the node which forges the block has received, but a forger is free to decide to include the other one instead.
That's another reason to push out the votes as they occur and to keep miners close at hand at each precinct.  The mining nodes would have first dibs, but would also relay the transaction to the broader blockchain network.  The voter could reasonably be expected to wait until their vote had a single confirm.

Quote
Also, since there is no local wallet file, anyone knowing one of those secret phrases can create and broadcast a voting transaction from anywhere in the world. To prevent that, again you need some custom client software, to tie those passwords with a local wallet file at each polling location, which file contains in encrypted form the real secret phrases.
Thanks this is addressed at least in part by the "pull a number out of the hat" method. 

Quote
To prevent further use of a voting account after the voting transaction has been cast, the account could be locked using account control by e.g. making it require the approval of Genesis account for any transactions. Since Genesis can't issue transactions, this makes the account effectively unusable. Such locking must be done after the voting transaction has already been accepted in the blockchain. Without such locking, someone knowing the secret phrase can send the currency token back to the issuer account, before voting has finished, thus making the vote not count as the account will not own the token when counting is done. If this is an acceptable risk, locking is not needed, I can't think of other possible malicious transactions after the vote.
That's a fantastic idea, but works around a feature of the system.
The entire system is premised on the idea that we following the flow of funds.
However we only count what occurs during the time of polling.
Manufacturers and auditors can test the machine, it can still vote all they want.  But votes cast outside of the polls or outside of normal voting hours are logged, but discarded for counting purposes.

Imagine you're a polling judge (person who has volunteered to take on the setup and teardown of the voting machines).
Legally in most places, you need to be able to verify that every machine in service is functioning correctly.
You have to do this before polls open and you have to do it after polls close.
So we allow the machine to do what it does, but the tally software which is someplace far, far away, just flags it as suspicious activity (which is why we log all maintenance thoroughly).

Jean Luc, thank you for a very thorough analysis.  As I've been writing some of this I can see places where we can improve the proposed standard and that's incredibly valuable feedback.

Thanks to everyone!
Logged
Evolution NEXT D.A.C.
NXTAE:3385321989487982138 (EVOLVE)

bob_ggg

  • Jr. Member
  • **
  • Karma: +9/-0
  • Offline Offline
  • Posts: 90
    • View Profile
Re: Whitepaper
« Reply #11 on: April 15, 2016, 11:07:30 pm »

To prevent further use of a voting account after the voting transaction has been cast, the account could be locked using account control by e.g. making it require the approval of Genesis account for any transactions. Since Genesis can't issue transactions, this makes the account effectively unusable. Such locking must be done after the voting transaction has already been accepted in the blockchain. Without such locking, someone knowing the secret phrase can send the currency token back to the issuer account, before voting has finished, thus making the vote not count as the account will not own the token when counting is done. If this is an acceptable risk, locking is not needed, I can't think of other possible malicious transactions after the vote.
Locking the account only after broadcasting the vote makes it possible to modify the vote by a third party. I think that this point needs additional refinements.
Logged

martismartis

  • Hero Member
  • *****
  • Karma: +73/-10
  • Offline Offline
  • Posts: 1237
    • View Profile
Re: Whitepaper
« Reply #12 on: April 16, 2016, 04:17:42 am »

Isn't voting account with only 1 NXT in it forbid voting second time from it? Fund voting accounts with only 1 NXT and it will vote only one time :)
Logged

futurist

  • Full Member
  • ***
  • Karma: +33/-7
  • Offline Offline
  • Posts: 193
    • View Profile
    • CORE Media
Re: Whitepaper
« Reply #13 on: April 16, 2016, 05:29:05 am »

Isn't voting account with only 1 NXT in it forbid voting second time from it? Fund voting accounts with only 1 NXT and it will vote only one time :)
You are on to something
Funding Monitor
https://nxtforum.org/nrs-releases/nrs-v1-8-0e/
« Last Edit: April 16, 2016, 05:34:49 am by futurist »
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Whitepaper
« Reply #14 on: April 16, 2016, 06:42:57 am »

I think most of the issues with using the Nxt voting system directly can be resolved by using a custom client software and even hardware, which does the steps to protect the real secret phrases for the accounts and the voters identity.

You will have a wallet file on each voting machine. When it generates the voting accounts with their public keys and secret phrases, the software keeps those secret phrases encrypted in the wallet file, and only prints out the decryption password for each, to be put in that fish bowl from which voters pick one out randomly. The software will not allow doing anything else with such a password other than submitting a single voting transaction (again with caching and submitting in batches). Once used, it can even destroy the secret phrase. Even if the decryption password leaks out (e.g. the voter remembers it), nobody has the real secret phrase and can't even tell which account it maps to. So no need to do account locking or try to prevent duplicate voting in any way, other than making sure the voting machine custom software is secure and audited, and in a real election parts of it will be in hardware, e.g. like smart cards storing private keys with pin codes to do transactions but no way to extract the key, and single use only.

Since the list of voting accounts will be published before voting starts, and each of those accounts funded with a single voting currency token, after the voting you can verify that only votes from those accounts were submitted, and that their count matches the physical count of voters that cast a vote from that location. And you can still add in a message attachment to each voting transaction a sequence number or nonce.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

devlux

  • Board Moderator
  • Sr. Member
  • ****
  • Karma: +67/-2
  • Offline Offline
  • Posts: 307
    • View Profile
    • Gemspace
Re: Whitepaper
« Reply #15 on: April 16, 2016, 07:28:30 am »

I think most of the issues with using the Nxt voting system directly can be resolved by using a custom client software and even hardware, which does the steps to protect the real secret phrases for the accounts and the voters identity.

You will have a wallet file on each voting machine. When it generates the voting accounts with their public keys and secret phrases, the software keeps those secret phrases encrypted in the wallet file, and only prints out the decryption password for each, to be put in that fish bowl from which voters pick one out randomly. The software will not allow doing anything else with such a password other than submitting a single voting transaction (again with caching and submitting in batches). Once used, it can even destroy the secret phrase. Even if the decryption password leaks out (e.g. the voter remembers it), nobody has the real secret phrase and can't even tell which account it maps to. So no need to do account locking or try to prevent duplicate voting in any way, other than making sure the voting machine custom software is secure and audited, and in a real election parts of it will be in hardware, e.g. like smart cards storing private keys with pin codes to do transactions but no way to extract the key, and single use only.

Since the list of voting accounts will be published before voting starts, and each of those accounts funded with a single voting currency token, after the voting you can verify that only votes from those accounts were submitted, and that their count matches the physical count of voters that cast a vote from that location. And you can still add in a message attachment to each voting transaction a sequence number or nonce.

Pretty much exactly this.  In a professional, fully compliant machine, there will be hardware based, hardwired crypto in order to limit the damage from tampering.

There is no reason a smart card could not be used for the crypto tasks though.
Something like this, but with the appropriate curve installed.  https://secure.zeitcontrol.de/shop/Chip-cards

If that were the case, then the card could be what is pulled out of the fishbowl.

For simple independent audit though, we need to be a bit less ambitious.  Just a standard android device with a custom client that can interact with NXT via the JSON API to fetch the votescript data and present it to the user.  Wallet is randomly generated at install time and a single wallet per device.  Perhaps display a QR code for provisioning, so that whomever is funding the device knows which wallets get funds.
« Last Edit: April 16, 2016, 07:34:46 am by devlux, Reason: Had wrong link in original version »
Logged
Evolution NEXT D.A.C.
NXTAE:3385321989487982138 (EVOLVE)

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1763
    • View Profile
Re: Whitepaper
« Reply #16 on: April 16, 2016, 09:24:33 pm »

I agree with Riker - you are mostly describing a voting system implementation on the blockchain which is implemented as the NXT voting system and can be trivially implemented on top of NXT messaging system.
Let's abstract away from implementation details and check through high level ideas. Suppose we have votes calculated with the help of NXT voting system and it is good enough for us. Please describe a typical use case scenario for such a system. Imagine I am a simple US citizen willing to vote for a president. I enter the booth and... What happens next?
Logged

Ludom

  • Hero Member
  • *****
  • Karma: +197/-15
  • Offline Offline
  • Posts: 1733
    • View Profile
    • Plaisir & Valeur d'histoire
Re: Whitepaper
« Reply #17 on: April 18, 2016, 02:05:04 pm »

I'm not a specialist but I think there is a lot of tools to organise secure votes on Nxt.
I see some steps.

System without anonymity of the vote

The organiser of the vote issue a new token (Asset or MScoin) with the exact number of tokens.
1st Transaction : Issuing an asset (1000 NXT) or MScoin (30 NXT), controlable coin or asset can be good if you fears about selling vote.

The organiser send to the voters one token + some NXT to pay the voting fees.
2nd Transactions : Sending token to each voters (X NXT)
3rd Transaction : Sending NXT with dividend transaction (1 NXT)

The organiser launches the vote.
4th Transaction : Issuing a Poll (depend of the question

The voters vote.
5th Transactions : Answer to the Poll (X NXT)

And that it.
About with which account the voter will vote, two solutions :
1) The voters choose their passphrase and inform the organiser of their account ID
2) The organiser generates the passphrase of each account and send it to the voters.

Anon system of vote

The organiser of the vote issue a new token (Asset or MScoin) with the exact number of tokens.
1st Transaction : Issuing an asset (1000 NXT) or MScoin (30 NXT), non controlable token.

The organiser send to the voters one token + some NXT to pay the shuffling fees.
2nd Transactions : Sending token to each voters (X NXT)
3rd Transaction : Sending NXT with dividend transaction (1 NXT)

The voters can send their token with the Shuffling system.
4th Transaction : Shuffling of the tokens. (12*X NXT)
(5th Transaction : Sending back the 1000 NXT to the organiser. (X NXT))

The organiser send some NXT to pay fees of the vote.
6th Transaction : Sending token to each voters (X NXT)

The organiser launches the vote.
7th Transaction : Issuing a Poll (depend of the question)

The voters vote.
8th Transactions : Answer to the Poll (X NXT)

All this transactions can be invisible and automatised for the users (organiser and voters).

The only problem I see for a real democratic vote is that the score of the vote is public before the end of the vote.

But this system is much more secure of the voting system of Switzerland (and we vote/elect 4-5 times each year).
Logged
Support us to publish "The first book about Nxt"
 

elective-stereophonic
elective-stereophonic
assembly
assembly