Updated documentation
This commit is contained in:
parent
b996774ffb
commit
bc630f82e2
92
Bitmessage.uml
Normal file
92
Bitmessage.uml
Normal 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
5844
docs/diagram.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 477 KiB |
BIN
docs/seminar.pdf
BIN
docs/seminar.pdf
Binary file not shown.
@ -11,6 +11,7 @@
|
||||
\newcommand{\msg}[1]{\textit{#1}}
|
||||
\newcommand{\obj}[1]{\textbf{#1}}
|
||||
\newcommand{\node}[1]{\textbf{#1}}
|
||||
\newcommand{\key}[1]{\textbf{#1}}
|
||||
|
||||
\begin{document}
|
||||
\maketitle
|
||||
@ -76,7 +77,7 @@
|
||||
\subsection{Addresses}
|
||||
\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{}{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))}
|
||||
|
||||
\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}
|
||||
|
||||
@ -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.
|
||||
|
||||
\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}
|
||||
TODO
|
||||
|
||||
Loading…
Reference in New Issue
Block a user