<div dir="ltr"><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><div class="gmail_default" style="font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> I have one question about these sorts of schemes...</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">></span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> There's a naive approach where you don't attempt to model multisignature</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> trust in terms of a single signature, but rather have a whitelisted set of</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> keys, and have k / n potential signers produce an individual signature.</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"></div><div class="gmail_default" style="font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px"><br></span></div><div class="gmail_default" style="font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">Indeed, Bitcoin's built in mutlsig feature takes exactly this approach and allows for addresses that have multiple associated keys. However, these addresses are distinguishable from single-key addresses, and also the information about the access structure being used is published on the block chain. This has negative implications for privacy and anonymity. </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">See section 4.3.2 of our paper for a full discussion on this point: </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px"><a href="http://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf" target="_blank">http://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf</a>.</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 12:22 AM, Steven Goldfeder <span dir="ltr"><<a href="mailto:sgoldfed@gmail.com" target="_blank">sgoldfed@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> I have one question about these sorts of schemes...</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">></span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> There's a naive approach where you don't attempt to model multisignature</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> trust in terms of a single signature, but rather have a whitelisted set of</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> keys, and have k / n potential signers produce an individual signature.</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"></div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px"><br></span></div></span><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">Indeed, Bitcoin's built in mutlsig feature takes exactly this approach and allows for addresses that have multiple associated keys. However, these addresses are distinguishable from single-key addresses, and also the information about the access structure being used is published on the block chain. This has negative implications for privacy and anonymity. </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">See section 4.3.2 of our paper for a full discussion on this point: </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px"><a href="http://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf" target="_blank">http://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf</a>.</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 15, 2015 at 11:29 PM, Tom Ritter <span dir="ltr"><<a href="mailto:tom@ritter.vg" target="_blank">tom@ritter.vg</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On the topic of threshold ECC, I'll point to an implementation I ran<br>
across recently:<br>
<a href="https://github.com/cwgit/ximix/tree/master/common/src/main/java/org/cryptoworkshop/ximix/common/crypto/threshold" target="_blank">https://github.com/cwgit/ximix/tree/master/common/src/main/java/org/cryptoworkshop/ximix/common/crypto/threshold</a><br>
<br>
The entire repo seems particularly interesting, but I haven't had time<br>
to dig into it closely.  RPC-based mixnet?<br>
<span><font color="#888888"><br>
-tom<br>
</font></span><div><div>_______________________________________________<br>
Curves mailing list<br>
<a href="mailto:Curves@moderncrypto.org" target="_blank">Curves@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/curves" target="_blank">https://moderncrypto.org/mailman/listinfo/curves</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>