path: root/58/e6bddc7ef864e40cbd828ebfd1cd77aae0d602

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 19B6CC000E;
 Tue, 10 Aug 2021 05:44:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0213F81AD1;
 Tue, 10 Aug 2021 05:44:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DDBUEt3MGuog; Tue, 10 Aug 2021 05:44:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 700308194C;
 Tue, 10 Aug 2021 05:44:21 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id g21so28465426edb.4;
 Mon, 09 Aug 2021 22:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=YblONAdCIgDCigiFo6eWQauaSprItxpZpjmccB+WELg=;
 b=PadyiJtkavzBgtlMHuYjtmzyini4NgZUVSoVIWnCNQ5qKe5eV+vxBHw9SnAcQFrwer
 cwejDWh9deLgr/MYal5igGhce8C9CZLb0Zgmzy9lOgGekUYOekmrNKzJoPNSGz6DELFg
 K6I/947wpLUB+sOSWuYAZVEQ6yW6UhOeqI5cLG7D4Kj3QZJRw/6dF0S4CNDkI7UxreCx
 p1XLf01yxy2QPjN8HfzUnKJNj/SCx9+wXQmdNiXw1jH+A1d0sjONQnzpiIduH2lhF+oQ
 5Uclv1khnHCMgcRJB7ScGSNCmcK1+BRRMv3l8tWuE6379DivSfpPBDK8je0+ixVF1o3+
 RgxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=YblONAdCIgDCigiFo6eWQauaSprItxpZpjmccB+WELg=;
 b=oOAzTZOGkwd6n7nBVl3vOzhnHdTLaExn6ZjlX9Kn20zahK/aapEDCIwR6rqmGeODIF
 mdtMG5suLY3qtYxlBRyrMClUo7lPiqYWXlCTHeSRw1FCDKNW8hPXoUscQ7WWK3LO9J+7
 urCsal1ga2ZTp/ENvu0JaIk+ojvhLA8lhyw6mhZSjCEaXSKhWbDuhOmc/cMdYHduIwzw
 ylujZqC361bryLHGoPURzgMHCQTHUgjvaPItAJ/wIngNvgFgHg9TEF4H6VyEtPez/yIR
 l+a2TxhenMKtTX1jXcBxhhjzKVy66fg7NeT5Jb8oJWoVvy9Q+On67c0fj9wONc6Q0htS
 F+qQ==
X-Gm-Message-State: AOAM5318c7vP5bCNL8dQ1kE+3tEORa1zEHcbKow4lYNH+HI3etnky7/O
 jImOgIfgbO40k6EjA+wZ70SXJze+8y+mNlNx8P8=
X-Google-Smtp-Source: ABdhPJxwzIYVtscwWtkVH/vXcn9YZxS6ht0wpCMx1Txm/m9inWyJZXngvS5jB4lzb+hGHQPt2HuuO5UmTOxCgVvDzqw=
X-Received: by 2002:a50:cc06:: with SMTP id m6mr2741170edi.97.1628574259580;
 Mon, 09 Aug 2021 22:44:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
 <CAGpPWDZn6dcuEJXRjUP4VYvJbL9u4mmVoS9xTVzBrGWOM5CeZw@mail.gmail.com>
 <CAD5xwhi_Sf1NRPBSAcWWFiAjyFsnmWbtowBF96j=EM4NXxfOKw@mail.gmail.com>
In-Reply-To: <CAD5xwhi_Sf1NRPBSAcWWFiAjyFsnmWbtowBF96j=EM4NXxfOKw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 9 Aug 2021 22:44:04 -0700
Message-ID: <CAGpPWDYsRSv0Teiq5JD1iHJnAbRdCmr+e6UGvV5JDpoXL-7M0w@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000003b91ac05c92dfe17"
X-Mailman-Approved-At: Tue, 10 Aug 2021 10:13:00 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Aug 2021 05:44:26 -0000

--0000000000003b91ac05c92dfe17
Content-Type: text/plain; charset="UTF-8"

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 only
computational soundness
<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>
.

> old things that never move more or less naturally "fall leftward"

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.

On Mon, Aug 9, 2021 at 10:04 PM Jeremy <jlrubin@mit.edu> wrote:

> You might be interested in https://eprint.iacr.org/2017/1066.pdf which
> claims that you can make CT computationally hiding and binding, see section
> 4.6.
>
> with respect to utreexo, you might review
> https://github.com/mit-dci/utreexo/discussions/249?sort=new 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.
>
>
>>>

--0000000000003b91ac05c92dfe17
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">For sure, CT can be done with computational soundness. The=
 advantage of unhidden amounts (as with current bitcoin) is that you get un=
conditional soundness. My understanding is that there is a fundamental trad=
eoff between unconditional soundness and unconditional privacy. I believe M=
onero has taken this alternate tradeoff path with unconditional privacy but=
 <a href=3D"https://www.reddit.com/r/Monero/comments/8erg8e/what_should_mon=
ero_do_about_the_soundness_problem/dxy59ad?utm_source=3Dshare&amp;utm_mediu=
m=3Dweb2x&amp;context=3D3">only computational soundness</a>.<div><br></div>=
<div>&gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,=
sans-serif">old things that never move more or less naturally &quot;fall le=
ftward&quot;</span></div><div><span style=3D"color:rgb(0,0,0);font-family:a=
rial,helvetica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0=
,0,0);font-family:arial,helvetica,sans-serif">Ah yes, something like that w=
ould definitely be interesting to basically make dust a moot point. Sounds =
like the tradeoff mentioned is that proofs would be twice as big? Except ne=
wer UTXOs would have substantially shorter proofs. It sounds like the kind =
of thing where there&#39;s some point where there would be so many old UTXO=
s that proofs would be smaller on average in the swap tree version vs the d=
ead-leaf version. Maybe someone smarter=C2=A0than me could estimate where t=
hat point is.</span></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Mon, Aug 9, 2021 at 10:04 PM Jeremy &lt;<a hre=
f=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt=
r"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">You might be interested in=C2=A0<a h=
ref=3D"https://eprint.iacr.org/2017/1066.pdf" target=3D"_blank">https://epr=
int.iacr.org/2017/1066.pdf</a> which claims that you can make CT computatio=
nally hiding and binding, see section 4.6.</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)"><br></div><div><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">with respect to utreexo, you might review <a href=3D"htt=
ps://github.com/mit-dci/utreexo/discussions/249?sort=3Dnew" target=3D"_blan=
k">https://github.com/mit-dci/utreexo/discussions/249?sort=3Dnew</a> which =
discusses tradeoffs between different accumulator designs. With a swap tree=
, old things that never move more or less naturally &quot;fall leftward&quo=
t;, although there are reasons to prefer alternative designs.</div><br></di=
v></div></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"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>

--0000000000003b91ac05c92dfe17--