path: root/b2/79b9f0fd20c482f74169f1475804be47b23670

Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A25311BD7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  5 Jun 2018 01:08:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
	[209.85.220.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10E39136
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  5 Jun 2018 01:08:14 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id g14-v6so461449qkm.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 04 Jun 2018 18:08:14 -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=2MG9oTgFfR9kNIwYzj/ZpGdzEO3OgttM+y0i1O4W0rw=;
	b=aADd1088R8D/GyAGAwEG0X+4pnSwxsWKXHhe1x3Irnwpa/tiaRFSqXKjecDq4tYlAs
	sX88MwYBUBIIV9I9Uf0qTwBA0wA8ahuHPuN3Hmh3w364l11CBS4Eaw85zRuO1mFyehTL
	5mJ733W+VjpYU0ig4uHKy5hpcWvJ4j/AwpfzixN0i2pPQlqv5ucJlV2Vg5NuINNDdYJG
	tai9PNVTO1oLBUvdKqtTqrL3kv/LXGcXP+JwkDvSbXugAf7CXLVkBC2mTkDA3bvjEhjq
	Ph2RiwoKklFyD4niPJ+n42v0aB/q5zYZgEa2/BxRAzuVNznPyZT+grMvSPEOGlTnqfIz
	TJyw==
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=2MG9oTgFfR9kNIwYzj/ZpGdzEO3OgttM+y0i1O4W0rw=;
	b=YDOsNreS9CNZvmHuCd2bCWWC23Qz86VEQy3x9at2WnQAfWt9o0PgtrZC21nNYLMDie
	uq7LbaHyiQaayzi0d2RJReMn870aQlZgnCoZDfAFjzpgxjotSlnGjBvHuFt/DI2ylrK6
	zJsGiK9ad+0znnfdJZvy4QTHh2kcZFMvOME0ZYCkqVRz/ouhxy4+ttWRiYG/nAWIE2cB
	peHIMJBKbP2YfsQ27nFp4Nl8lkxlLYIHZM+ojl5LKsZmRzPGca8g0Yxcr9U634Droulu
	IOdptnYC6fYb3ZNVQsbsDoMpFFIZw6TjPLYNLWAdZrcqegGdbX8UUbeZ8cYORFP1jtwW
	rslw==
X-Gm-Message-State: APt69E29Rd4a+6ZiqkswXqXZrbprIih+Pxmxv9U0yX5lqgkcnq/Mt8Ad
	ZdOjLTigG7eCDclgdD5em+ykGrpV315vhCACa08=
X-Google-Smtp-Source: ADUXVKKtWpnCxba0MGqshcQzAprSijyHD8nRiBGQo0Dti8qLKDIcgeRoTSS4Fz/O0dtTcjTSZnKSSe1Q6krGT/FNqek=
X-Received: by 2002:a37:a80d:: with SMTP id
	r13-v6mr12087466qke.41.1528160893985; 
	Mon, 04 Jun 2018 18:08:13 -0700 (PDT)
MIME-Version: 1.0
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
	<CALJw2w7+VUYtMtdTexW6iE3mc0DsS9DME_ynP8skg_+-bv_tPA@mail.gmail.com>
	<CADabwBDG2_2syU0AnjbEfqTL=5ERRQkL6NOyVN7gAyJTAaf7UA@mail.gmail.com>
In-Reply-To: <CADabwBDG2_2syU0AnjbEfqTL=5ERRQkL6NOyVN7gAyJTAaf7UA@mail.gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Mon, 4 Jun 2018 18:08:01 -0700
Message-ID: <CADZtCSjsZ=_C+cFUXbAim=56QG4p0UdE4HEo9ZKJtNgEH_DqhQ@mail.gmail.com>
To: Riccardo Casatta <riccardo.casatta@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003ee8c5056ddaaf0c"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 05 Jun 2018 01:13:42 +0000
Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 05 Jun 2018 01:08:15 -0000

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

>
> I was wondering why this multi-layer multi-block filter proposal isn't
> getting any comment,
> is it because not asking all filters is leaking information?
>

It's an interesting idea, but it adds more complexity to the client and
could be added later on if clients adopt BIP 157 and complain about
bandwidth. It also derives all bandwidth gains from address reuse. So I'm
hesitant to make the complexity tradeoff for bandwidth savings due to a
behavior that is actively discouraged.

On another note, I've been thinking that block TXO commitments could
resolve the issue we are facing now with deciding between the prev script
approach and outpoint. The whole argument for outpoints is that there are
compact-ish (<1 MiB) proofs of filter validity, which is not currently
possible if the filters included prev output data. Such proofs would be
feasible if blocks headers (well, actually coinbase txs) had a commitment
to the Merkle root of all newly created outputs in the block.

This idea has been tossed around before in the context of fraud proofs and
TXO bitfields, and seems to unlock a whole bunch of other P2P commitments.
For example, if we wanted to do P2P commitments (BIP 157-style) to the
distribution of tx fees in a block, one could use block TXO commitments to
prove correctness of fees for non-segwit txs. It also enables block
validity proofs (assuming parent blocks are valid), which are not as
powerful as invalidity/fraud proofs, but interesting nonetheless.

This would require a new getdata type BLOCK_WITH_PREVOUTS or something. I
assume for most coinbase-tx-committed proposals, we'll also need a new
getcoinbases/coinbases that requests the coinbase tx and Merkle branch for
a range of headers as well. But with these additions, we could start
serving more block-derived data to light clients under the BIP 157
at-least-one-honest-peer assumption.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div style=3D"font-size:small">I was wondering why this mu=
lti-layer multi-block filter proposal isn&#39;t getting any comment,</div><=
div style=3D"font-size:small">is it because not asking all filters is leaki=
ng information?</div></div></blockquote><div><br></div><div><span style=3D"=
color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal=
;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-dec=
oration-style:initial;text-decoration-color:initial;float:none;display:inli=
ne">It&#39;s an interesting idea, but it adds more complexity to the client=
 and could be added later on if clients adopt BIP 157 and complain about ba=
ndwidth. It also derives all bandwidth gains from address reuse. So I&#39;m=
 hesitant to make the complexity tradeoff for bandwidth savings due to a be=
havior that is actively discouraged.</span></div><div><span style=3D"color:=
rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-=
variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-sp=
acing:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoratio=
n-style:initial;text-decoration-color:initial;float:none;display:inline"><b=
r></span></div><div><span style=3D"color:rgb(34,34,34);font-family:sans-ser=
if;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-vari=
ant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text=
-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgro=
und-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-co=
lor:initial;float:none;display:inline">On another note, I&#39;ve been think=
ing that block TXO commitments could resolve the issue we are facing now wi=
th deciding between the prev script approach and outpoint. The whole argume=
nt for outpoints is that there are compact-ish (&lt;1 MiB) proofs of filter=
 validity, which is not currently possible if the filters included prev out=
put data. Such proofs would be feasible if blocks headers (well, actually c=
oinbase txs) had a commitment to the Merkle root of all newly created outpu=
ts in the block.</span></div><div><span style=3D"color:rgb(34,34,34);font-f=
amily:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:no=
rmal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text=
-decoration-color:initial;float:none;display:inline"><br></span></div><div>=
<span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;fo=
nt-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font=
-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,25=
5,255);text-decoration-style:initial;text-decoration-color:initial;float:no=
ne;display:inline">This idea has been tossed around before in the context o=
f fraud proofs and TXO bitfields, and seems to unlock a whole bunch of othe=
r P2P commitments. For example, if we wanted to do P2P commitments (BIP 157=
-style) to the distribution of tx fees in a block, one could use block TXO =
commitments to prove correctness of fees for non-segwit txs. It also enable=
s block validity proofs (assuming parent blocks are valid), which are not a=
s powerful as invalidity/fraud proofs, but interesting nonetheless.</span><=
/div><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-si=
ze:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:n=
ormal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px;background-color:=
rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initia=
l;float:none;display:inline"><br></span></div><div><span style=3D"color:rgb=
(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-var=
iant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spaci=
ng:normal;text-align:start;text-indent:0px;text-transform:none;white-space:=
normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-s=
tyle:initial;text-decoration-color:initial;float:none;display:inline">This =
would require a new getdata type BLOCK_WITH_PREVOUTS or something. I assume=
 for most coinbase-tx-committed proposals, we&#39;ll also need a new getcoi=
nbases/coinbases that requests the coinbase tx and Merkle branch for a rang=
e of headers as well. But with these additions, we could start serving more=
 block-derived data to light clients under the BIP 157 at-least-one-honest-=
peer assumption.</span></div></div></div>

--0000000000003ee8c5056ddaaf0c--