-
Notifications
You must be signed in to change notification settings - Fork 14
/
readme
81 lines (58 loc) · 3.44 KB
/
readme
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
Shufflepuff implementation of the CoinShuffle protocol in java. This is a work
in progress. If you wish to support this project, please contact me
(daniel.krawisz@thingobjectentity.net) for tasks that you might try completing.
CoinShuffle description:
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf
-- Functionality
Shufflepuff can run on its own or it can be used as a library and encorporated
into a java program.
If it is run on its own, it takes a private key, an amount to be shuffled, and a
set of IP addresses or websocket addresses denoting the other players.
Shufflepuff can also be used as a library in another application. The other
application would instantiate player.Player and it works from there.
Stufflpuff comes with a bitcoinj implementation, but the user could provide an
implementation in another library too.
Shufflepuff needs to look up address balances in order to run the protocol.
For lite applications there is an option for querying blockchain.info. For
players with full nodes, an option is provided to look up balances using btcd.
The user could also provide other options by extending the Bitcoin class.
-- Overall Organization of the Project
Package protocol implements Coin Shuffle according to the same concepts as in
the original paper. It abstracts away a lot. In order to implement this version
of the protocol, a user would have to implement the following interfaces:
* Coin - provides cryptocurrency functions and objects.
* Crypto - provides cryptographic functions and objects.
* Messages - provides for a implementation of the messages in Coin Shuffle
* Network - provides a connection to the other players in the protocol.
The purpose of this design is that a set of test cases can be developed for
the protocol as a whole before any work has been put into its details. This
means that there can already be a huge set of test cases very early
in the development of a working version of the protocol, which will greatly
reduce the risk of introducing errors as the rest of the development work
proceeds. Furthermore, this protocol can be adapted to any java implementation
of Bitcoin, or any other cryptocurrency.
status: Works!
Package mock includes mock implementations of all these interfaces for testing
purposes.
status: functional
Package sim allows for the protocol to be run with any number of simulated
players. There is a Simulator class which can be used to simulate runs of the
protocol with any implementation. It allows for malicious players. All test
cases work.
status: very slick
Package bitcoin will provide an implementation of Coin and Crypto which is
specific to the Bitcoin network and which provides the cryptography as described
in the paper. It relies on bitcoinj and Spongey Castle.
status: coming along.
Package p2p includes classes for constructing various internet channels, by
which instances of this program will communicate.
status: Partly tested, some classes still needed.
Package player provides for some peripheral issues about running the protocol,
such as collecting the initial data and re-running the protocol if some players
have to be eliminated. Player is also quite abstract and could be implemented in
various ways.
status: lots to do.
Package moderator will have a server which will eventually help people to find
one another to create joins. It will also provide for a client that can schedule
and commit to joins.
status: barely started