<div dir="ltr">For sure, CT can be done with computational soundness. The advantage of unhidden amounts (as with current bitcoin) is that you get unconditional soundness. My understanding is that there is a fundamental tradeoff between unconditional soundness and unconditional privacy. I believe Monero has taken this alternate tradeoff path with unconditional privacy but <a href="https://www.reddit.com/r/Monero/comments/8erg8e/what_should_monero_do_about_the_soundness_problem/dxy59ad?utm_source=share&utm_medium=web2x&context=3">only computational soundness</a>.<div><br></div><div>> <span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">old things that never move more or less naturally "fall leftward"</span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Ah yes, something like that would definitely be interesting to basically make dust a moot point. Sounds like the tradeoff mentioned is that proofs would be twice as big? Except newer UTXOs would have substantially shorter proofs. It sounds like the kind of thing where there's some point where there would be so many old UTXOs that proofs would be smaller on average in the swap tree version vs the dead-leaf version. Maybe someone smarter than me could estimate where that point is.</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 9, 2021 at 10:04 PM Jeremy <<a href="mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">You might be interested in <a href="https://eprint.iacr.org/2017/1066.pdf" target="_blank">https://eprint.iacr.org/2017/1066.pdf</a> which claims that you can make CT computationally hiding and binding, see section 4.6.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">with respect to utreexo, you might review <a href="https://github.com/mit-dci/utreexo/discussions/249?sort=new" target="_blank">https://github.com/mit-dci/utreexo/discussions/249?sort=new</a> which discusses tradeoffs between different accumulator designs. With a swap tree, old things that never move more or less naturally "fall leftward", although there are reasons to prefer alternative designs.</div><br></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> </blockquote></div> </blockquote></div></div> </blockquote></div>