whitepaper.tex

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{url}
\usepackage{listings}

\title{The Pluscoin Cryptocurrency}
\author{thatlittlegit}
\date{}

\begin{document}
\pagenumbering{roman}
\maketitle
\tableofcontents
\newpage
\pagenumbering{arabic}

\section{Introduction.}
Pluscoin is a cryptocurrency intended to be easy to use and not use as many
resources as Bitcoin and its derivatives in mining. This document states the
requirements for an implementation of Pluscoin. \textbf{There is no current
implementation of Pluscoin. If you are interested in making one, feel free
to ask for clarification or suggest changes.}

\paragraph{A note on hashing.} Several times in this document, it suggests to
hash a string; this shall be done with a SHA3-512 hash, with the output in
hexadecimal.

\section{Choosing the Lucky Stakeholder.}
The lucky stakeholder shall be chosen {\it{individually}} by each user after
each transaction, and the user in question {\it{should}} calculate itself. We
can find the user by finding the hash of the object. The winner of is to be
calculated by finding the account that is closest to the XOR of the hashes.
This is to be done by finding the account with the most bits at the beginning
in common. If there are two matches, the one with the most Pluscoin wins.

\paragraph{Rewards.} The user who is found to be the stakeholder of a
transaction shall recieve $2.5$ currency. This currency shall not be
represented in a 'transaction'; rather, it should be implied when a
transaction's stakeholder is the user they gain $2.5$ currency in their wallet.

\label{net}
\section{Networking.}
A Peer-to-Peer (hereforth referred to as P2P) network is necessary for a
decenteralized currency. Pluscoin uses an HTTP API to communicate. All data to
or from this API should be in JSON\footnote{See \url{https://json.org}}.

\paragraph{Creating a Transaction.} To create a transaction, the sender (Alice)
broadcasts to all nodes she knows that she has a transaction to the recipient
(Bob), in the form of a HashedTransaction.  This hash is then signed with
Alice's private key, and then redistributed.

\paragraph{Account Creation.} An application shall use an AccountCreation
message to create an account. \verb|publickey| should be set to the Base64'd
public key. The wallet will be identified by the key's hash.

\paragraph{Signing.} Signing and account keys should be valid PGP keys.

\label{prop}
\paragraph{Propagating a Transaction.} A signed transaction is to be sent to all
known nodes. All nodes recieving this transaction are then to validate
it; if the transactions is incorrect, the transaction is to be {\it{discarded}}
and {\it{not propagated!}} However, if it is deemed valid the transaction is to
be propagated.

\paragraph{Verifying a Transaction.} A transaction is to be verified by first
checking if the chain identifier (chainid) is equal to what is
expected\footnote{$0$ shall be used on the main network.}. It shall also be
checked that the wallet exists.
This can be done by looking in the chain to see if a special transaction
as described above happened with the hash\footnote{It may be useful to cache
this, thus preventing unnecessary hash computing.}. If the wallet does not
exist, the transaction shall be marked invalid. It then shall be checked if the
value of the transaction is 0 currency. If it is, and it is not to
a special address, then the transaction is invalid. It then shall be checked
that the wallet has enough money to send. If it does not, it shall be invalid.
This can be found by searching backward through the chain\footnote{Once
again, this may be useful to cache.}$^,$\footnote{If/when Pluscoin is used
daily, and thousands of transactions occur per day, it may be useful to
stakeholders to periodically move their funds to and from a temporary account.
This would reduce the amount of entries {\it{necessary}} to search, thus
increasing the speed of their transactions.}. It shall then finally be tested
if the transaction's signed hash matches the public key in the account-creation
transaction. If not, it is invalid. Otherwise, it is valid and can be
propagated as such.

\paragraph{Chain Problems.} Pluscoin is one network with Transactions,
which contain all necessary metadata. If a transaction is found invalid, the
transaction shan't be stored or distributed\footnote{Unless it is easily fixed;
in which case it is fixed and distributed. An example of a simple fix is if the
transaction is based on an invalid transaction yet is still valid if it is set
on a valid transaction.} and optionally the sender notified of the invalid
transaction\footnote {To prevent differing implementations,
\texttt{REBUILD\_CHAIN} shall be used to indicate a chain-rebuild may be
necessary. This {\it{can}} be ignored, and {\it{can}} be not sent by an
implementation.}.

\paragraph{Syncing the Chain.} The chain is to be synced (rebuilt) by
contacting all known nodes and sending a GenericMessage containing
"{\texttt{BLOCKHASH}}", which shall be responded to by sending the hash of the
{\it{previous transaction}}, not the $x$ transactions before. Another
GenericMessage "{\texttt{REQUEST\_CHAIN {\it{p}}}" shall then be sent to
all known nodes, which shall respond with as up to
65536 transactions starting at number $p$ via a Brotli-compressed JSON array in
the form of a \verb|Transaction[65536]|. The response shall be at most
$2^{32}$ bytes in length. The uncompressed` shall also be RSA-signed with the
private key of the sender.

\section{Classes \& Structs.}
\paragraph{Some notes.} The classes and structs defined herein should be used
vertabim. It is entirely possible, indeed recommendable, to change these to fit
the standards of the programming language, however when sent should reflect
these. A client is to ignore invalid structs. All hashes are to be made from
a JSON2-serialized version of the struct.

\paragraph{Communication of Structs.} A struct is to be broadcasted via a
object in JavaScript Object Notation (JSON) 2 corresponding to the struct.
Note that structs over 10 megabytes ($10 \times 1024^2$ bytes) may be ignored
(and if necessary, the connections cut prematurely). Structs are to be
differentiated by the \verb|__STRUCT__|  byte.

\paragraph{Compression.} Brotli\footnote{See
\url{https://github.com/google/brotli} and IETF RFC 7932.} compression may be
used. All clients must support these, and accept structs not implementing these
modifications.

\paragraph{Definitions.} The definitions are provided as Protocol
Buffers\footnote{See
\url{https://developers.google.com/protocol-buffers/docs/proto3}}.
\begin{lstlisting}
syntax = "proto3";
\end{lstlisting}

\subsection{Transaction}
\begin{lstlisting}
message Transaction {
	required string sender;    // The sender's public key, ASCII-armoured
	required string recipient; // The hash of the recipient's public key (hexadecimal)
	required double currency;  // The currency to send. No more than 16 decimal points.
	required string message;   // The associated message in UTF-8.
}
\end{lstlisting}

\subsection{HashedTransaction}
\begin{lstlisting}
message HashedTransaction {
	enum CryptoType {
		RSA = 0;
	}
	required CryptoType version;
	required string signature;
	required Transaction transaction;
}
\end{lstlisting}

\subsection{GenericMessage}
\begin{lstlisting}
message GenericMessage {
	required string message;
}
\end{lstlisting}

\subsection{AccountCreation}
\begin{lstlisting}
message AccountCreation {
	optional string name;
	required string publickey;
}
\end{lstlisting}
\end{document}