From d229e128b8dc76d66acc7a76edac02b7c7806b15 Mon Sep 17 00:00:00 2001 From: James Ray Date: Fri, 17 Nov 2017 16:55:38 +1100 Subject: [PATCH 01/10] @misc{Leonardos_2017, --- papers/CasperTFG/ethereum.bib | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/papers/CasperTFG/ethereum.bib b/papers/CasperTFG/ethereum.bib index 6e5eb819..ba043231 100644 --- a/papers/CasperTFG/ethereum.bib +++ b/papers/CasperTFG/ethereum.bib @@ -1,3 +1,13 @@ +@misc{Leonardos_2017, + title = {{The Bitcoin Backbone Protocol: Analysis and Applications}}, + author = "Juan A. Garay and Aggelos Kiayias and Nikos Leonardos", + url = "https://123doc.org/document/4286628-the-bitcoin-backbone-protocol.htm", + journal = "Proc. Eurocrypt 2015", + note = {{An abridged version of this paper appears in Proc. Eurocrypt 2015.}}, + year = "2017", + month = "February", +} + @MISC{GHOST, TITLE = {Secure High-Rate Transaction Processing in Bitcoin}, author = {Yonatan Sompolinsky and Aviv Zohar}, From d8999f46913d4d4bd4920116bda2e98bc208bd1e Mon Sep 17 00:00:00 2001 From: James Ray Date: Fri, 17 Nov 2017 16:58:26 +1100 Subject: [PATCH 02/10] @misc{Garay_Kiayias_Leonardos_2017, --- papers/CasperTFG/ethereum.bib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/CasperTFG/ethereum.bib b/papers/CasperTFG/ethereum.bib index ba043231..27eab21c 100644 --- a/papers/CasperTFG/ethereum.bib +++ b/papers/CasperTFG/ethereum.bib @@ -1,4 +1,4 @@ -@misc{Leonardos_2017, +@misc{Garay_Kiayias_Leonardos_2017, title = {{The Bitcoin Backbone Protocol: Analysis and Applications}}, author = "Juan A. Garay and Aggelos Kiayias and Nikos Leonardos", url = "https://123doc.org/document/4286628-the-bitcoin-backbone-protocol.htm", From aba489d524a6765488fbcee2b237f7bdea974a1f Mon Sep 17 00:00:00 2001 From: James Ray Date: Fri, 17 Nov 2017 16:58:56 +1100 Subject: [PATCH 03/10] \cite{Garay_Kiayias_Leonardos_2017} --- papers/CasperTFG/CasperTFG.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/CasperTFG/CasperTFG.tex b/papers/CasperTFG/CasperTFG.tex index ab65dc7c..17211106 100644 --- a/papers/CasperTFG/CasperTFG.tex +++ b/papers/CasperTFG/CasperTFG.tex @@ -82,7 +82,7 @@ \subsection{Comparing Traditional Consensus to Blockchain Consensus} Blockchain consensus protocols like Bitcoin do not finalize/decide on one block at a time. In fact, the Bitcoin blockchain in particular does not make ``finalized decisions'' at all; blocks are ``orphaned'' if/when they are not in the highest total difficulty chain. However, if the miners are able to mine on the same blockchain, then the blocks that get deep enough into the blockchain won't be reverted (``orphaned''). A block's depth in the blockchain therefore serves as a proxy for finalization. In the average case for blockchain consensus protocols, each node only requires approximately one message, $\mathcal{O}(1)$, for every block. -Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network.'' +Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Garay_Kiayias_Leonardos_2017} Traditional Byzantine fault tolerant consensus protocols have precisely stated Byzantine fault tolerance numbers (often can tolerate less than a third Byzantine faults, or up to $t$ faults when there are $3t + 1$ nodes)[CITE]. On the other hand, it is less clear exactly how many faults (measured as a proportion of hashrate) the Bitcoin blockchain protocol can tolerate. From 8cacda29e66d336af7ee38786bfbf0e04b742a73 Mon Sep 17 00:00:00 2001 From: James Ray Date: Fri, 24 Nov 2017 12:38:25 +1100 Subject: [PATCH 04/10] Pass_Seeman_Shelat_2016 --- papers/CasperTFG/ethereum.bib | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/papers/CasperTFG/ethereum.bib b/papers/CasperTFG/ethereum.bib index 27eab21c..98be1d90 100644 --- a/papers/CasperTFG/ethereum.bib +++ b/papers/CasperTFG/ethereum.bib @@ -1,3 +1,11 @@ +@misc{Pass_Seeman_Shelat_2016, + title = {{Analysis of the Blockchain Protocol in Asynchronous Networks}}, + author = "Rafael Pass and Lior Seeman and Abhi Shelat", + url = "https://eprint.iacr.org/2016/454.pdf", + year = "2016", + month = "September", + } + @misc{Garay_Kiayias_Leonardos_2017, title = {{The Bitcoin Backbone Protocol: Analysis and Applications}}, author = "Juan A. Garay and Aggelos Kiayias and Nikos Leonardos", From 1c9f75a85062526585959ae87cf8586b11f6baa8 Mon Sep 17 00:00:00 2001 From: James Ray Date: Fri, 24 Nov 2017 13:23:59 +1100 Subject: [PATCH 05/10] \cite{Garay_Kiayias_Leonardos_2017} + elaboration --- papers/CasperTFG/CasperTFG.tex | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/papers/CasperTFG/CasperTFG.tex b/papers/CasperTFG/CasperTFG.tex index 17211106..60fb1137 100644 --- a/papers/CasperTFG/CasperTFG.tex +++ b/papers/CasperTFG/CasperTFG.tex @@ -82,7 +82,13 @@ \subsection{Comparing Traditional Consensus to Blockchain Consensus} Blockchain consensus protocols like Bitcoin do not finalize/decide on one block at a time. In fact, the Bitcoin blockchain in particular does not make ``finalized decisions'' at all; blocks are ``orphaned'' if/when they are not in the highest total difficulty chain. However, if the miners are able to mine on the same blockchain, then the blocks that get deep enough into the blockchain won't be reverted (``orphaned''). A block's depth in the blockchain therefore serves as a proxy for finalization. In the average case for blockchain consensus protocols, each node only requires approximately one message, $\mathcal{O}(1)$, for every block. -Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Garay_Kiayias_Leonardos_2017} +Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Garay_Kiayias_Leonardos_2017} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite{Garay_Kiayias_Leonardos_2017, pp.~4–5} +\begin{itemize} +\item \textit{consistency}: at any point, the chains of two honeste players can differ only in the last $T$ blocks; +\item \textit{future self-consistence}: at any two points, $r$ and $s$, the chains of any honest player at $r$ and $s$ differ only within the last $T$ blocks; +\item \textit{g-chain growth}: at any point in the execution, the chain of honest players grows by at least $T$ blocks in the last $T/g$ rounds; where $g$ is called the chain-growth of the protocol. +\item \textit{\mu-chain quality}: for any $T$ consecutive blocks in any chain held by some honest player, the fraction of blocks that were "contributed by honest players" is at least \mu. +\end{itemize} Traditional Byzantine fault tolerant consensus protocols have precisely stated Byzantine fault tolerance numbers (often can tolerate less than a third Byzantine faults, or up to $t$ faults when there are $3t + 1$ nodes)[CITE]. On the other hand, it is less clear exactly how many faults (measured as a proportion of hashrate) the Bitcoin blockchain protocol can tolerate. From 48d4b5ea6e5e1f3fbad6daaa67b624c9afd843e7 Mon Sep 17 00:00:00 2001 From: James Ray Date: Mon, 11 Dec 2017 19:18:52 +1100 Subject: [PATCH 06/10] \cite{Pass_Seeman_Shelat_2016} instead of Garay --- papers/CasperTFG/CasperTFG.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/CasperTFG/CasperTFG.tex b/papers/CasperTFG/CasperTFG.tex index 60fb1137..65d68b1b 100644 --- a/papers/CasperTFG/CasperTFG.tex +++ b/papers/CasperTFG/CasperTFG.tex @@ -82,7 +82,7 @@ \subsection{Comparing Traditional Consensus to Blockchain Consensus} Blockchain consensus protocols like Bitcoin do not finalize/decide on one block at a time. In fact, the Bitcoin blockchain in particular does not make ``finalized decisions'' at all; blocks are ``orphaned'' if/when they are not in the highest total difficulty chain. However, if the miners are able to mine on the same blockchain, then the blocks that get deep enough into the blockchain won't be reverted (``orphaned''). A block's depth in the blockchain therefore serves as a proxy for finalization. In the average case for blockchain consensus protocols, each node only requires approximately one message, $\mathcal{O}(1)$, for every block. -Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Garay_Kiayias_Leonardos_2017} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite{Garay_Kiayias_Leonardos_2017, pp.~4–5} +Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Pass_Seeman_Shelat_2016} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite{Pass_Seeman_Shelat_2016, pp.~4–5} \begin{itemize} \item \textit{consistency}: at any point, the chains of two honeste players can differ only in the last $T$ blocks; \item \textit{future self-consistence}: at any two points, $r$ and $s$, the chains of any honest player at $r$ and $s$ differ only within the last $T$ blocks; From 74fe41d7c08bb9e83937340995876e8b52a27fa6 Mon Sep 17 00:00:00 2001 From: James Ray Date: Mon, 11 Dec 2017 19:20:07 +1100 Subject: [PATCH 07/10] honeste > honest --- papers/CasperTFG/CasperTFG.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/CasperTFG/CasperTFG.tex b/papers/CasperTFG/CasperTFG.tex index 65d68b1b..bfaac192 100644 --- a/papers/CasperTFG/CasperTFG.tex +++ b/papers/CasperTFG/CasperTFG.tex @@ -84,7 +84,7 @@ \subsection{Comparing Traditional Consensus to Blockchain Consensus} Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Pass_Seeman_Shelat_2016} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite{Pass_Seeman_Shelat_2016, pp.~4–5} \begin{itemize} -\item \textit{consistency}: at any point, the chains of two honeste players can differ only in the last $T$ blocks; +\item \textit{consistency}: at any point, the chains of two honest players can differ only in the last $T$ blocks; \item \textit{future self-consistence}: at any two points, $r$ and $s$, the chains of any honest player at $r$ and $s$ differ only within the last $T$ blocks; \item \textit{g-chain growth}: at any point in the execution, the chain of honest players grows by at least $T$ blocks in the last $T/g$ rounds; where $g$ is called the chain-growth of the protocol. \item \textit{\mu-chain quality}: for any $T$ consecutive blocks in any chain held by some honest player, the fraction of blocks that were "contributed by honest players" is at least \mu. From d68844a59eadc5a8e70350f820c2ea217900f489 Mon Sep 17 00:00:00 2001 From: James Ray Date: Mon, 11 Dec 2017 19:24:37 +1100 Subject: [PATCH 08/10] missing } --- papers/CasperTFG/ethereum.bib | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/papers/CasperTFG/ethereum.bib b/papers/CasperTFG/ethereum.bib index 141e7b92..9c767b40 100644 --- a/papers/CasperTFG/ethereum.bib +++ b/papers/CasperTFG/ethereum.bib @@ -4,7 +4,7 @@ @misc{Pass_Seeman_Shelat_2016 url = "https://eprint.iacr.org/2016/454.pdf", year = "2016", month = "September", - } +} @misc{Garay_Kiayias_Leonardos_2017, title = {{The Bitcoin Backbone Protocol: Analysis and Applications}}, @@ -14,7 +14,8 @@ @misc{Garay_Kiayias_Leonardos_2017 note = {{An abridged version of this paper appears in Proc. Eurocrypt 2015.}}, year = "2017", month = "February", -\ +} + @misc{orphanBitcoin, title = {{Orphan Blocks}}, url = "https://bitcoin.org/en/developer-guide#orphan-blocks", From 2fb7fbac5c78b4a757d7c057ac207fe23221a5c9 Mon Sep 17 00:00:00 2001 From: James Ray Date: Mon, 11 Dec 2017 19:25:12 +1100 Subject: [PATCH 09/10] Another missing } --- papers/CasperTFG/ethereum.bib | 1 + 1 file changed, 1 insertion(+) diff --git a/papers/CasperTFG/ethereum.bib b/papers/CasperTFG/ethereum.bib index 9c767b40..193d31e4 100644 --- a/papers/CasperTFG/ethereum.bib +++ b/papers/CasperTFG/ethereum.bib @@ -43,6 +43,7 @@ @article{Fischer_Lynch_Paterson_FLP_Impossibility_1985 year = "1985", month = "April", pages = 374–382, +} @MISC{GHOST, TITLE = {Secure High-Rate Transaction Processing in Bitcoin}, From 546dc48eb8ad3aa1c533914f52ae1b4856e72b60 Mon Sep 17 00:00:00 2001 From: James Ray Date: Mon, 11 Dec 2017 19:30:50 +1100 Subject: [PATCH 10/10] =?UTF-8?q?\cite[pp.~4=E2=80=935]{Pass=5FSeeman=5FSh?= =?UTF-8?q?elat=5F2016,=20pp.~4=E2=80=935}?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- papers/CasperTFG/CasperTFG.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/papers/CasperTFG/CasperTFG.tex b/papers/CasperTFG/CasperTFG.tex index be31fe75..64b3c82e 100644 --- a/papers/CasperTFG/CasperTFG.tex +++ b/papers/CasperTFG/CasperTFG.tex @@ -83,7 +83,7 @@ \subsection{Comparing Traditional Consensus to Blockchain Consensus} Blockchain consensus protocols like Bitcoin do not finalize/decide on one block at a time.\cite{nakamoto} In fact, the Bitcoin blockchain in particular does not make ``finalized decisions'' at all; blocks are ``orphaned'' if/when they are not in the highest total difficulty chain. \cite{orphanBitcoin} However, if the miners are able to mine on the same blockchain, then the blocks that get deep enough into the blockchain won't be reverted (``orphaned''). A block's depth in the blockchain therefore serves as a proxy for finalization. In the average case for blockchain consensus protocols, each node only requires approximately one message, $\mathcal{O}(1)$, for every block. \footnote{For Bitcoin, refer to \cite{nakamoto}, section 5 on pp. 3–4.} -Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Pass_Seeman_Shelat_2016} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite{Pass_Seeman_Shelat_2016, pp.~4–5} +Traditional consensus protocol research has focused on producing protocols that are asynchronously safe (i.e.\ blocks won't be reverted due to arbitrary timing of future events) and live in asynchrony (or partial synchrony) (i.e.\ nodes eventually decide on new blocks). On the other hand, the Bitcoin blockchain is not safe in an asynchonous network but is safe and live (for unknown block-depth or ``confirmation count'') in a ``partially synchronous network''.\cite{Pass_Seeman_Shelat_2016} Specifically, the following properties are proven to be required for a blockchain to be safe (which Bitcoin is proven to satisfy), all with overwhelming probability (in $T$): \cite[pp.~4–5]{Pass_Seeman_Shelat_2016, pp.~4–5} \begin{itemize} \item \textit{consistency}: at any point, the chains of two honest players can differ only in the last $T$ blocks; \item \textit{future self-consistence}: at any two points, $r$ and $s$, the chains of any honest player at $r$ and $s$ differ only within the last $T$ blocks;