Minor edits prior to release

docs/source/whitepaper/corda-introductory-whitepaper.tex

@@ -1,6 +1,6 @@
 \documentclass{article}
 \author{Richard Gendal Brown, James Carlyle, Ian Grigg, Mike Hearn}
-\date{\today}
+\date{August, 2016}
 \title{Corda: An Introduction}
 %%\setlength{\parskip}{\baselineskip}
 \usepackage{amsfonts}
@@ -31,7 +31,7 @@
 
 \begin{abstract}
 
-A distributed database made up of mutually distrusting nodes would allow for a single global ledger that records the state of deals and obligations between institutions and people. This would eliminate much of the manual, time consuming effort currently required to keep disparate ledgers synchronised with each other. It would also allow for greater levels of code sharing than presently used in the financial industry, reducing the cost of banking for everyone. We present Corda, a platform which is designed to achieve these goals. This paper provides a high level introduction intended for the general reader. A forthcoming technical white paper elaborates on the design and fundamental architectural decisions.
+A distributed ledger made up of mutually distrusting nodes would allow for a single global database that records the state of deals and obligations between institutions and people. This would eliminate much of the manual, time consuming effort currently required to keep disparate ledgers synchronised with each other. It would also allow for greater levels of code sharing than presently used in the financial industry, reducing the cost of banking for everyone. We present Corda, a platform which is designed to achieve these goals. This paper provides a high level introduction intended for the general reader. A forthcoming technical white paper elaborates on the design and fundamental architectural decisions.
 \end{abstract}
 \newpage
 \tableofcontents
@@ -69,7 +69,7 @@ In the long-term, one can envision a ``global logical ledger" with which all eco
 Principles underpinning a possible end-state using distributed ledger technology may include:
 \begin{itemize}
 	\item Facts recorded by the ledger are by contract accepted as admissible evidence and legally binding by all parties in any dispute.
-	\item Settlement occurs on the ledger, not through the ledger.
+	\item Facts recorded by the ledger are regarded as authoritative rather than `shadows' of authoritative data held elsewhere, enabling settlement to take place directly across the platform.
 	\item Once all parties to an agreement have assented, facts recorded on the ledger are final and immutable; errors, unwinds, etc., must be processed through a subsequent transaction. Firms will be under pressure to re-engineer their internal processes to increase accuracy and quality.
 	\item Any authorized actor may, in principle, connect directly to the ledger and use it to record agreements with its counterparts. No actor is compelled to deal with any other but we may see a decline in ``tiered" or hierarchical market models. 
 	\item By promoting open standards and inclusive access, existing and new service providers can connect and compete to offer differentiated services, promoting choice and competition.
@@ -157,7 +157,7 @@ Corda has ``pluggable" uniqueness services. This is to improve privacy, scalabil
 It is important to note that these uniqueness services are required only to attest as to whether the states consumed by a given transaction have previously been consumed; they are not required to attest as to the validity of the transaction itself, which is a matter for the parties to the transaction. This means that the uniqueness services are not required to (and, in the general case, will not) see the full contents of any transactions, significantly improving privacy and scalability of the system compared with alternative blockchain designs.  This design decision represents an important decision as to the acceptable tradeoffs in shared ledger architectures and is explored more fully in the forthcoming technical whitepaper.
 
 \subsection{Business Logic}
-Corda enforces business logic through smart contract code, which is constructed as a pure function that either accepts or rejects a transaction. The functions interpret transactions as taking states as inputs and producing output states through the application of (smart contract) commands, and accept the transaction if the proposed actions are valid. Contracts define part of the business logic of the ledger, and they are mobile: nodes will download and run contracts inside a sandbox without any review in some deployments, although we envisage the use of signed code for Corda deployments in the regulated sphere. 
+Corda enforces business logic through smart contract code, which is constructed as a pure function that either accepts or rejects a transaction, and which can be composed from simpler, reusable functions. The functions interpret transactions as taking states as inputs and producing output states through the application of (smart contract) commands, and accept the transaction if the proposed actions are valid. Contracts define part of the business logic of the ledger, and they are mobile: nodes will download and run contracts inside a sandbox without any review in some deployments, although we envisage the use of signed code for Corda deployments in the regulated sphere. 
 
 The virtual machine we have selected for contract execution and validation is the Java Virtual Machine\cite{JVM}, as it has a wealth of existing libraries and a large skill base, and reusing an industry standard makes it easier for banks to reuse their existing code inside contracts. However, we augment it with a custom sandbox that is radically more restrictive than the ordinary JVM sandbox, and it enforces not only security requirements but also deterministic execution. Like Ethereum, the choice of standardising a bytecode set rather than a language enables users to innovate in contract language design, or reuse well known languages, according to taste. It also makes it easy to directly use contract code from internal applications, once that contract has been reviewed, which should simplify app development considerably.
 
@@ -208,10 +208,10 @@ Corda has some significant similarities to Bitcoin:
 \item{A contract is pure function; contracts do not have storage or the ability to interact with anything. Given the same transaction, a contract's ``verify" function always yields exactly the same result.}
 \end{itemize}
 
-However, a Bitcoin transaction has a single, rigid data format. A ``state" in Bitcoin is always a (quantity of bitcoin, script) pair and cannot hold any other data. Some people have been known to try and hack around this limitation by embedding data in semi-standardized places in the contract code so the data can be extracted through pattern matching but this is a poor approach. By contrast, our states can include arbitrary typed data. Our transactions invoke not only input contracts but also the contracts of the outputs. A Bitcoin transaction's acceptance is controlled only by the contract code in the consumed input states. We use the term ``contract" to refer to a bundle of business logic that may handle various different tasks, beyond transaction verification. For instance, currently our contracts also include code for creating valid transactions (this is often called ``wallet code" in Bitcoin).
+However, a Bitcoin transaction has a single, rigid data format. A ``state" in Bitcoin is always a (quantity of bitcoin, script) pair and cannot hold any other data. Some people have been known to try and work around this limitation by embedding data in semi-standardized places in the contract code so the data can be extracted through pattern matching but this is a poor approach. By contrast, our states can include arbitrary typed data. Our transactions invoke not only input contracts but also the contracts of the outputs. A Bitcoin transaction's acceptance is controlled only by the contract code in the consumed input states. We use the term ``contract" to refer to a bundle of business logic that may handle various different tasks, beyond transaction verification. For instance, currently our contracts also include code for creating valid transactions (this is often called ``wallet code" in Bitcoin).
 
 A Bitcoin script can only be given a fixed set of byte arrays as the input. This means there's no way for a contract to examine the structure of the entire transaction, which severely limits what contracts can do. Our contracts are Turing-complete and can be written in any ordinary programming language that targets the JVM.	
-Corda allows arbitrarily-precise time-bounds to be specified in transactions (which must be attested to by a trusted timestamper) rather than relying on the time at which a block happens to be mined.  This is important given that many contract types we envisage supporting require precision in timing and because our primary consensus implementations use block-free conflict resolution algorithms.
+Corda allows arbitrarily-precise time-bounds to be specified in transactions (which must be attested to by a trusted timestamper) rather than relying on the time at which a block happens to be mined.  This is important given that many contract types we envisage supporting require precision in timing and because our primary consensus implementations use block-free conflict resolution algorithms. It should be noted that Corda does not utilise Proof of Work or have a concept of ``mining".
 
 \subsection{Comparisons to Ethereum}
 Like Ethereum, code runs inside a relatively powerful virtual machine and can contain complex logic. Non-assembly based programming languages can be used for contract programming.  They are both intended for the modelling of many different kinds of financial contracts.
@@ -250,4 +250,4 @@ In contrast to most existing distributed ledger platforms today, Corda was built
 \bibliographystyle{unsrt}
 \bibliography{Ref}
 
-\end{document}
+\end{document}