gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] r33019 - gnunet-java


From: gnunet
Subject: [GNUnet-SVN] r33019 - gnunet-java
Date: Thu, 10 Apr 2014 11:42:18 +0200

Author: dold
Date: 2014-04-10 11:42:18 +0200 (Thu, 10 Apr 2014)
New Revision: 33019

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2014-04-10 09:19:06 UTC (rev 33018)
+++ gnunet-java/ISSUES  2014-04-10 09:42:18 UTC (rev 33019)
@@ -1,58 +1,48 @@
+mesh service regularly segfaults when running secretsharing
 
-While waiting for mesh fixes, I looked again at
-multi-way elections, and implemented them (suprisingly they even work ;)
- * zero knowledge proof turned out to be tricky but easier than I anticipated
-    Basic Idea:
-     * The chaum pedersen proof can prove equality of logs
-     * The Cramer-Damgard-Schoenmakers construction transforms any ZKP (with 
the required properties)
-       into disjunction (or more complicated access structures) proofs
- * currently there's no fancy algorithm for the dlog,
-   just very crude brute force
+how do the *_QUOTA_* options of ats work?
 
+thesis / voting:
+coercion-freeness (there is no way for me to prove you that I voted for party 
X)
+ * current implementation is not coercion-free (nonce for encryption is the 
proof)
+ * most of the literature published on coercion/receipt-freeness turned out
+   to be faulty
+ * basic problem: the r in (g^r,m*h^r) can be used as proof of what we voted 
(m)
+ * the sako+hirt construction posts one list of vote choices per voter (!!!) 
on the bulletin board,
+   voters only give number of choice
+ * there are some ideas based on re-encryption and designated verifier proofs 
of re-encryption
+  * I think the main reason they do not work for the approach we implement is 
that we need (in
+    contrast to mix-based voting) zero knowledge proofs of valitity
+ * I believe we could have a system that is resistant against vote-buying under
+   the assumption that none of the authorities cooperates with a vote-buyer.
+  * the voter would ask an authority to re-randomize the vote
+  * the voter again must re-randomize the vote so that the authority can't 
associate the vote
+    with the voter
+  * if the authority is compromized, the coercer could force the voter to 
leave out the 
+    re-randomization
 
- * signing in gnunet-java now works like in GNUnet (correct usage of purpose 
header)
-  * as discussed, implemented with construct message unions
+How extensive should the discussion be of completely different (mixnets / 
blind signatures) voting
+systems? 
 
- * voting crypto works
- * simple voting test case works
-  * suggestions for test cases?
-   * no double voting, edge cases etc.
- * Fixed the annoying java mesh api bug, that was actually a bug in the test 
case
+------------------------------------------------
 
-Main problem right now: mesh is really unstable, consensus or secretsharing 
crash it all the time
+regarding digital currencies:
+have you heard about ripple?
+They have:
+ * a public ledger
+ * a group of validators (peers)
+ * a set of transactions
+ * a consensus on transaction set to apply to the ledger
+   (done repeatedly)
+Does that sound vaguely familiar? ;-)
 
-Tutorial/Release:
- * gradle is now no explicit dependency, tutorial advises to use ./gradlew
- * The section "Installing GNUnet-Java" were previously just build 
instructions.
-   But this does not make sense anymore, as there's the ivy repository now.
- * Same goes for the dreaded izpack installer.  I don't see any use there, as 
projects will either
-  * Ship gnunet-java as dependency in the download
-    (Practically all java projects do this)
-  * Use the ivy repository for the development tree
- * What should the release contain? Common for java projects: 2-3 seperate 
downloads
-  * gnunet-java-0.2-src.zip, which contains a snapshot of the svn repo
-  * gnunet-java-0.2.zip, which contains the libs and bin, but not the source
-  * gnunet-java-0.2.jar, just the jar file
+However, they do nothing about byzantine consensus ... 
+how are they not susceptible to "transaction stuffing", fragmenting the ledger?
+Why does nobody mention this?
 
+Quote (wikipedia):
+"For its creation and development of the ripple protocol (RTXP) and the Ripple
+payment/exchange network, the Massachusetts Institute of Technology (MIT)
+recognized Ripple Labs as one of 2014’s 50 Smartest Companies in the February
+2014 edition of MIT Technology Review. "
 
-new locations for coverage / test reports:
-http://sam.net.in.tum.de:20021/reports/jacoco/test/html/
-http://sam.net.in.tum.de:20021/reports/tests/
-
-javadoc works again (https://gnunet.org/javadoc/)
-
-gnurl-7.34.0 builds on squeeze, 7.45 does not.
-
-Why does libmicrohttps need libtool>=2.4
address@hidden:~/repos/libmicrohttpd$ ./bootstrap 
-configure.ac:24: error: Libtool version 2.4.0 or higher is required
-/usr/share/aclocal/libtool.m4:46: LT_PREREQ is expanded from...
-configure.ac:24: the top level
-autom4te: /usr/bin/m4 failed with exit status: 63
-aclocal: autom4te failed with exit status: 63
-
-
-
-
-For the thesis: Is self-plagiarism plagiarism? (i.e. how much can I use
-from the seminar/proseminar)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]