path: root/86/c4b7bde4e58eff18af883866ca40f450cfe45a

Return-Path: <jannes.faber@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C634ACED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Dec 2015 00:43:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com
	[209.85.217.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 97AE713C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Dec 2015 00:43:34 +0000 (UTC)
Received: by lbbcs9 with SMTP id cs9so79374180lbb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Dec 2015 16:43:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=kQYfBmd+v2laQohFQPfyWp8hJwu00lBDedc02tW9xZo=;
	b=cQjA+L91UbOK5EtxsD3+h6hSLCLr6hOUSsPoEXgkm6hdn2a1zHMsyEC8NBy9LktarG
	Lt4pHsXkWMBVR/Bi9XOzZIM9LuVoInp0ZKOfIgxeXydhB04YTPYxdQEmm5hqxfc9VfY4
	MWfjglgnhHneXVmiCXhYwMEksEzTX0/DCCiG/0i95PSr2qk4BGBDZynJcu29L0vvW39F
	vpkf4m7+uoYtGJcpGrB6qm1PPF+kdEx4cKfbFuRP+hrIdbbCO+yXKQW+36YTdr7nTsiZ
	MxdGYU8g2c8QeMFmlwy0s5dQ1Go5X7LNbvGJSd62FoWyqha+tPr2CzyXMkKYfakti5sh
	cFDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type;
	bh=kQYfBmd+v2laQohFQPfyWp8hJwu00lBDedc02tW9xZo=;
	b=e0NZv9AXiT7paBK8FfKe7gSMoJkpBd4w4DhpYeOv6e6d7XcmbNDmJM1iXwgBs+RRdG
	8oJHlpMzDNv8xhcJN+LCfzMlNhVcvPUGbAIPJvrLzOrzQBjKeP6cIu3Sk8KutfEo0INw
	ObeHFQ4S1Q4RUmqnM4ukZupvpH+SLIH3VpqmDdQKhxogvciHKQhPeGQsoLbIInYf5Vr+
	FGWNkA447F28b5K40Zlg512lk8dFlmIFmLciieN0OcWiCN8LfV92DciQwDtq1k1Zr51M
	vP6CKT/HhhQ25jv9ScrI8jaL9rVyUtzWgSX1mlYQxySK1oHZ0RQpAkJTDHEVGaTeM+lN
	8w1w==
X-Received: by 10.112.158.66 with SMTP id ws2mr9435400lbb.126.1449881012743;
	Fri, 11 Dec 2015 16:43:32 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com.
	[209.85.217.173])
	by smtp.gmail.com with ESMTPSA id i13sm3628197lfe.9.2015.12.11.16.43.31
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 11 Dec 2015 16:43:31 -0800 (PST)
Received: by lbblt2 with SMTP id lt2so79911012lbb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Dec 2015 16:43:31 -0800 (PST)
X-Gm-Message-State: ALoCoQlwEstwB7lzAYilyEIv0wMupxBpgcVVX3YN+7L6GUYfHo9dJmHE0GI6uUaz1FWcaJaSlGGUA424RiCa60oXRn6eGA2OKw==
X-Received: by 10.112.184.165 with SMTP id ev5mr9249219lbc.111.1449881011442; 
	Fri, 11 Dec 2015 16:43:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.157.199 with HTTP; Fri, 11 Dec 2015 16:43:11 -0800 (PST)
In-Reply-To: <7D7416E3-0038-484D-BBA9-35FA4C2AE3DC@bitsofproof.com>
References: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
	<7D7416E3-0038-484D-BBA9-35FA4C2AE3DC@bitsofproof.com>
From: Jannes Faber <jannes.faber@gmail.com>
Date: Sat, 12 Dec 2015 01:43:11 +0100
X-Gmail-Original-Message-ID: <CABeL=0hzQeOPcVgRcdM6Q_hqTNevHBOs7d2HMd6yh0o5Du9yAw@mail.gmail.com>
Message-ID: <CABeL=0hzQeOPcVgRcdM6Q_hqTNevHBOs7d2HMd6yh0o5Du9yAw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c3c1aea7730f0526a8bad6
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	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: Sat, 12 Dec 2015 02:05:50 +0000
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 12 Dec 2015 00:43:35 -0000

--001a11c3c1aea7730f0526a8bad6
Content-Type: text/plain; charset=UTF-8

Segregated IBLT

I was just wondering if it would make sense when we have SW to also make
Segregated IBLT? Segregating transactions from signatures and then tune the
parameters such that transactions have a slightly higher guarantee and save
a bit of space on the signatures side.

IBLT should of course, most of the time, convey all transactions _and_ all
signatures. However, in suboptimal situations, at least the receiving miner
will be more likely to have all the transactions, just possibly not all the
signatures.

Assuming the miner was already planning on SPV mining anyway, at least now
she knows which transactions to remove from her mempool, taking away an
excuse to mine an empty block. And she can still verify most of the
signatures too (whatever % could be recovered from the IBLT).

I guess this does not improve the worst adversarial case for IBLT block
propagation, but it should improve the effectiveness in cases where the
"normal" IBLT would fail to deliver all transactions. Transactions without
signatures is better than no transactions at all, for a miner that's eager
to start on the next block, right? In "optimal" cases it would reduce the
size of the IBLT.

Sorry if this was already suggested.


--
Jannes

On 10 December 2015 at 13:54, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Note that the unused space in coin base input script allows us to
> soft-fork an additional SW Merkle tree root into the design,
> therefore please make sure the new SW data structure also has a new slot
> for future extension.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a11c3c1aea7730f0526a8bad6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Segregated IBLT<br><br>I was just wondering if i=
t would make sense when we have SW to also make Segregated IBLT? Segregatin=
g transactions from signatures and then tune the parameters such that trans=
actions have a slightly higher guarantee and save a bit of space on the sig=
natures side.<br><br></div>IBLT should of course, most of the time, convey =
all transactions _and_ all signatures. However, in suboptimal situations, a=
t least the receiving miner will be more likely to have all the transaction=
s, just possibly not all the signatures.<br><br></div>Assuming the miner wa=
s already planning on SPV mining anyway, at least now she knows which trans=
actions to remove from her mempool, taking away an excuse to mine an empty =
block. And she can still verify most of the signatures too (whatever % coul=
d be recovered from the IBLT).<br><div><br></div><div>I guess this does not=
 improve the worst adversarial case for IBLT block propagation, but it shou=
ld improve the effectiveness in cases where the &quot;normal&quot; IBLT wou=
ld fail to deliver all transactions. Transactions without signatures is bet=
ter than no transactions at all, for a miner that&#39;s eager to start on t=
he next block, right? In &quot;optimal&quot; cases it would reduce the size=
 of the IBLT.<br></div><div><br></div><div>Sorry if this was already sugges=
ted.<br></div><div><br></div></div><div class=3D"gmail_extra"><br clear=3D"=
all"><div><div class=3D"gmail_signature">--<br>Jannes</div></div>
<br><div class=3D"gmail_quote">On 10 December 2015 at 13:54, Tamas Blummer =
via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note that the unus=
ed space in coin base input script allows us to soft-fork an additional SW =
Merkle tree root into the design,<br>
therefore please make sure the new SW data structure also has a new slot fo=
r future extension.<br>
<br>
Tamas Blummer<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--001a11c3c1aea7730f0526a8bad6--