Return-Path: 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: In-Reply-To: From: Billy Tetrud Date: Mon, 9 Aug 2021 22:44:04 -0700 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="0000000000003b91ac05c92dfe17" X-Mailman-Approved-At: Tue, 10 Aug 2021 10:13:00 +0000 Cc: Bitcoin Protocol Discussion , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 . > 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 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
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= only computational soundness.

=
>=C2=A0old things that never move more or less naturally "fall le= ftward"

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'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.

On Mon, Aug 9, 2021 at 10:04 PM Jeremy <jlrubin@mit.edu> wrote:
You might be interested in=C2=A0https://epr= int.iacr.org/2017/1066.pdf which claims that you can make CT computatio= nally hiding and binding, see section 4.6.

with respect to utreexo, you might review https://github.com/mit-dci/utreexo/discussions/249?sort=3Dnew which = discusses tradeoffs between different accumulator designs. With a swap tree= , old things that never move more or less naturally "fall leftward&quo= t;, although there are reasons to prefer alternative designs.


--0000000000003b91ac05c92dfe17--