bitmessage/Jabit
bitmessage/Jabit
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated documentation

Browse Source
This commit is contained in:
Christian Basler 2015-05-15 10:59:56 +02:00
parent b996774ffb
commit bc630f82e2
4 changed files with 5965 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
Bitmessage.uml Normal file
View File

@ -0,0 +1,92 @@
<?xml version="1.0" encoding="UTF-8"?>
<Diagram>
<ID>JAVA</ID>
<OriginalElement />
<nodes>
<node x="299.75" y="401.0">ch.dissem.bitmessage.entity.VerAck</node>
<node x="284.5625" y="0.0">ch.dissem.bitmessage.entity.Streamable</node>
<node x="0.0" y="608.0">ch.dissem.bitmessage.ports.Inventory</node>
<node x="548.75" y="313.0">ch.dissem.bitmessage.entity.Version</node>
<node x="428.9236111111111" y="156.5">ch.dissem.bitmessage.entity.MessagePayload</node>
<node x="0.0" y="771.0">ch.dissem.bitmessage.ports.NetworkMessageReceiver</node>
<node x="108.75" y="378.5">ch.dissem.bitmessage.entity.NetworkMessage</node>
<node x="957.75" y="389.5">ch.dissem.bitmessage.entity.Addr</node>
<node x="418.0" y="608.0">ch.dissem.bitmessage.ports.NetworkMessageSender</node>
<node x="0.0" y="145.0">ch.dissem.bitmessage.entity.valueobject.InventoryVector</node>
<node x="338.0" y="771.0">ch.dissem.bitmessage.entity.ObjectPayload</node>
<node x="884.1736111111111" y="101.0">ch.dissem.bitmessage.entity.valueobject.NetworkAddress</node>
</nodes>
<notes />
<edges>
<edge source="ch.dissem.bitmessage.entity.NetworkMessage" target="ch.dissem.bitmessage.entity.Streamable">
<point x="-42.75" y="-59.5" />
<point x="151.5" y="81.0" />
<point x="362.9375" y="81.0" />
<point x="-26.125" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.valueobject.InventoryVector" target="ch.dissem.bitmessage.entity.Streamable">
<point x="0.0" y="-37.0" />
<point x="70.5" y="71.0" />
<point x="310.6875" y="71.0" />
<point x="-78.375" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.Version" target="ch.dissem.bitmessage.entity.valueobject.NetworkAddress">
<point x="97.25" y="-125.0" />
<point x="840.5" y="293.0" />
<point x="937.1736111111111" y="293.0" />
<point x="-53.0" y="81.0" />
</edge>
<edge source="ch.dissem.bitmessage.entity.valueobject.NetworkAddress" target="ch.dissem.bitmessage.entity.Streamable">
<point x="0.0" y="-81.0" />
<point x="990.1736111111111" y="71.0" />
<point x="467.4375" y="71.0" />
<point x="78.375" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.Version" target="ch.dissem.bitmessage.entity.MessagePayload">
<point x="-97.25" y="-125.0" />
<point x="646.0" y="293.0" />
<point x="525.7986111111111" y="293.0" />
<point x="19.375" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.NetworkMessage" target="ch.dissem.bitmessage.entity.MessagePayload">
<point x="42.75" y="-59.5" />
<point x="237.0" y="283.0" />
<point x="448.2986111111111" y="283.0" />
<point x="-58.125" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.VerAck" target="ch.dissem.bitmessage.entity.MessagePayload">
<point x="0.0" y="-37.0" />
<point x="414.25" y="293.0" />
<point x="487.0486111111111" y="293.0" />
<point x="-19.375" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.MessagePayload" target="ch.dissem.bitmessage.entity.Streamable">
<point x="0.0" y="-25.5" />
<point x="506.4236111111111" y="81.0" />
<point x="415.1875" y="81.0" />
<point x="26.125" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.Addr" target="ch.dissem.bitmessage.entity.MessagePayload">
<point x="-76.5" y="-48.5" />
<point x="1034.25" y="283.0" />
<point x="564.5486111111111" y="283.0" />
<point x="58.125" y="25.5" />
</edge>
<edge source="ch.dissem.bitmessage.entity.Addr" target="ch.dissem.bitmessage.entity.valueobject.NetworkAddress">
<point x="76.5" y="-48.5" />
<point x="1187.25" y="293.0" />
<point x="1043.173611111111" y="293.0" />
<point x="53.0" y="81.0" />
</edge>
</edges>
<settings layout="Hierarchic Group" zoom="0.7909738717339667" x="632.0" y="411.0" />
<SelectedNodes />
<Categories>
<Category>Fields</Category>
<Category>Methods</Category>
<Category>Properties</Category>
</Categories>
<SCOPE>All</SCOPE>
<VISIBILITY>private</VISIBILITY>
</Diagram>

5844
docs/diagram.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 477 KiB

BIN
docs/seminar.pdf
View File

Binary file not shown.

32
docs/seminar.tex
View File

@ -11,6 +11,7 @@
\newcommand{\msg}[1]{\textit{#1}} \newcommand{\msg}[1]{\textit{#1}}
\newcommand{\obj}[1]{\textbf{#1}} \newcommand{\obj}[1]{\textbf{#1}}
\newcommand{\node}[1]{\textbf{#1}} \newcommand{\node}[1]{\textbf{#1}}
\newcommand{\key}[1]{\textbf{#1}}
\begin{document} \begin{document}
\maketitle \maketitle
@ -76,7 +77,7 @@
\subsection{Addresses} \subsection{Addresses}
\label{subsec:addr} \label{subsec:addr}
\textit{BM-2cXxfcSetKnbHJX2Y85rSkaVpsdNUZ5q9h}: Addresses start with "BM-" and are, like Bitcoin addresses, Base58 encoded\footnote{Which avoids the easily confused characters I, l, 0 and O.}. \textit{BM-2cXxfcSetKnbHJX2Y85rSkaVpsdNUZ5q9h}: Addresses start with "BM-" and are, like Bitcoin addresses, Base58 encoded\footnote{Which uses characters 1-9, A-Z and a-z without the easily confused characters I, l, 0 and O.}.
\listinginfo{}{version}{Address version.}{} \listinginfo{}{version}{Address version.}{}
\listinginfo{}{stream}{Stream number.}{} \listinginfo{}{stream}{Stream number.}{}
@ -84,7 +85,32 @@
\listinginfo{}{checksum}{First four bytes of a double SHA-512 hash of the above.}{sha512(sha512(version + stream + ripe))} \listinginfo{}{checksum}{First four bytes of a double SHA-512 hash of the above.}{sha512(sha512(version + stream + ripe))}
\subsection{Encryption} \subsection{Encryption}
TODO
Bitcoin uses Elliptic Curve Cryptography for both signing and encryption. While the mathematics behind elliptic curves is even harder to understand than the usual prime-and-modulo-until-your-brain-explodes approach, it's based on the same principle that factorizing large numbers is very hard to do. Instead of two very large primes, we multiply a point on the elliptic curve by a very large number\footnote{Please don't ask me how to do it. If your're crazy enough, start at \url{http://en.wikipedia.org/wiki/Elliptic_curve_cryptography}. If you're not that crazy, use a library like Bouncy Casle.}.
The user, let's call her Alice, needs a key pair, consisting of a private key
$$k$$
which represents a huge random number, and a public key
$$K = G k$$
which represents a point on the agreed on curve\footnote{Bitmessage uses a curve called \textit{secp256k1}.}. Please note that this is not a simple multiplication, but the multiplication of a point along an elliptic curve. $G$ is the starting point for all operations on a specific curve.
Another user, Bob, knows the public key. To encrypt a message, Bob creates a temporary key pair
$$r$$
and
$$R = G r$$
He then calculates
$$K r$$
uses the resulting Point to encrypt the message\footnote{A double SHA-512 hash over the x-coordinate is used to create the actual key.} and sends $K$ along with the message.
When Alice receives the message, she uses the fact that
$$K r = G k r = G r k = R k$$
so she just uses $R k$ to decrypt the message.
The exact method used in Bitmessage is called Elliptic Curve Integrated Encryption Scheme or ECIES\footnote{See \url{http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme}}.
\subsection{Signature}
ECDSA
\section{Issues} \section{Issues}
@ -93,7 +119,7 @@
Bitmessage doen't really scale. If there are very few users, anonymity isn't given anymore, and with many users traffic and storage use grows quadratically. Bitmessage doen't really scale. If there are very few users, anonymity isn't given anymore, and with many users traffic and storage use grows quadratically.
\subsubsection{Streams} \subsubsection{Streams}
The intended solution for this problem is splitting traffic\footnote{Addresses, actualy} into streams. When all active streams are full, a new one is created which should be used for new addresses. All users can send messages to any stream, but only listen to the streams belonging to their addresses. The unsolved problem is to determine when a stream is full. The other issue is the fact that, as the overall network grows, traffic on full streams still grows, as there are more users who might wanto to write someone on the full stream. The intended solution for this problem is splitting traffic\footnote{Addresses, actualy.} into streams. When all active streams are full, a new one is created which should be used for new addresses. All users can send messages to any stream, but only listen to the streams belonging to their addresses. The unsolved problem is to determine when a stream is full. The other issue is the fact that, as the overall network grows, traffic on full streams still grows, as there are more users who might wanto to write someone on the full stream.
\subsubsection{Prefix Filtering} \subsubsection{Prefix Filtering}
TODO TODO