path: root/a6/9d6fbc307657a209828ee1839d5fb7c0442b61

Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DB8ACD79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 14 Dec 2015 11:21:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 39FA52F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 14 Dec 2015 11:21:47 +0000 (UTC)
Received: from [IPv6:::1] ([58.96.168.240]) (authenticated bits=0)
	by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBEBLgHw025506
	(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 14 Dec 2015 03:21:44 -0800
Content-Type: multipart/signed;
	boundary="Apple-Mail=_30D9D353-CB1B-43E4-9283-5BD0F7EE212B";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <CAOG=w-t=+0Zdoy+d4Y2t9nbRkyO30N_Az9kbRarGo69yHCpSwA@mail.gmail.com>
Date: Mon, 14 Dec 2015 19:21:43 +0800
Message-Id: <3292B7BA-13A8-4BD9-AB08-4F5EBE534771@toom.im>
References: <CABsx9T0nxcqAkEt7+pVm9oZEZH_HCJ9D3J00v0bKJYeUcDv1hQ@mail.gmail.com>
	<1449897228198.c655b3ae@Nodemailer>
	<CAOG=w-t=+0Zdoy+d4Y2t9nbRkyO30N_Az9kbRarGo69yHCpSwA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVbeh0qArFBSxqZ16jpyALV8jydvHJXAiFyq+CCBLJ1pYmlIXuGdLXFAySSTHP4Lszlx9mc7NLT++DXwOaqK8m1M
X-Sonic-ID: C;ElLZ2VSi5RG1CMgxU3XIUw== M;uBju2lSi5RG1CMgxU3XIUw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
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: Mon, 14 Dec 2015 11:21:48 -0000


--Apple-Mail=_30D9D353-CB1B-43E4-9283-5BD0F7EE212B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9EEF5B05-B9A8-458E-A0F5-846C2E9F1429"


--Apple-Mail=_9EEF5B05-B9A8-458E-A0F5-846C2E9F1429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

This means that a server supporting SW might only hear of the tx data =
and not get the signature data for some transactions, depending on how =
the relay rules worked (e.g. if the SW peers had higher minrelaytxfee =
settings than the legacy peers). This would complicate fast block relay =
code like IBLTs, since we now have to check to see that the recipient =
has both the tx data and the witness/sig data.

The same issue might happen with block relay if we do SW as a soft fork. =
A SW node might see a block inv from a legacy node first, and might =
start downloading the block from that node. This block would then be =
marked as in-flight, and the witness data might not get downloaded. This =
shouldn't be too hard to fix by creating an inv for the witness data as =
a separate object, so that a node could download the block from e.g. =
Peer 1 and the segwit data from Peer 2.

Of course, the code would be simpler if we did this as a hard fork and =
we could rely on everyone on the segwit fork supporting the segwit data. =
Although maybe we want to write the interfaces in a way that supports =
some nodes not downloading the segwit data anyway, just because not =
every node will want that data.

I haven't had time to read sipa's code yet. I apologize for talking out =
of a position of ignorance. For anyone who has, do you feel like sharing =
how it deals with these network relay issues?

By the way, since this thread is really about SegWit and not about any =
other mechanism for increasing Bitcoin capacity, perhaps we should =
rename it accordingly?


On Dec 12, 2015, at 11:18 PM, Mark Friedenbach via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> A segwit supporting server would be required to support relaying =
segwit transactions, although a non-segwit server could at least inform =
a wallet of segwit txns observed, even if it doesn't relay all =
information necessary to validate.
>=20
> Non segwit servers and wallets would continue operations as if nothing =
had occurred.
>=20
> If this means essentially that a soft fork deployment of SegWit will =
require SPV wallet servers to change their logic (or risk not being able =
to send payments) then it does seem to me that a hard fork to deploy =
this non controversial change is not only cleaner (on the data structure =
side) but safer in terms of the potential to affect the user experience.
>=20
>=20
> =97 Regards,


--Apple-Mail=_9EEF5B05-B9A8-458E-A0F5-846C2E9F1429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>This means that a server supporting SW might =
only hear of the tx data and not get the signature data for some =
transactions, depending on how the relay rules worked (e.g. if the SW =
peers had higher minrelaytxfee settings than the legacy peers). This =
would complicate fast block relay code like IBLTs, since we now have to =
check to see that the recipient has both the tx data and the witness/sig =
data.</div><div><br></div><div>The same issue might happen with block =
relay if we do SW as a soft fork. A SW node might see a block inv from a =
legacy node first, and might start downloading the block from that node. =
This block would then be marked as in-flight, and the witness data might =
not get downloaded. This shouldn't be too hard to fix by creating an inv =
for the witness data as a separate object, so that a node could download =
the block from e.g. Peer 1 and the segwit data from Peer =
2.&nbsp;</div><div><br></div><div>Of course, the code would be simpler =
if we did this as a hard fork and we could rely on everyone on the =
segwit fork supporting the segwit data. Although maybe we want to write =
the interfaces in a way that supports some nodes not downloading the =
segwit data anyway, just because not every node will want that =
data.</div><div><br></div><div>I haven't had time to read sipa's code =
yet. I apologize for talking out of a position of ignorance. For anyone =
who has, do you feel like sharing how it deals with these network relay =
issues?</div><div><br></div><div>By the way, since this thread is really =
about SegWit and not about any other mechanism for increasing Bitcoin =
capacity, perhaps we should rename it =
accordingly?</div><div><br></div><div><br></div><div><div>On Dec 12, =
2015, at 11:18 PM, Mark Friedenbach via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><p =
dir=3D"ltr">A segwit supporting server would be required to support =
relaying segwit transactions, although a non-segwit server could at =
least inform a wallet of segwit txns observed, even if it doesn't relay =
all information necessary to validate.</p><p dir=3D"ltr">Non segwit =
servers and wallets would continue operations as if nothing had =
occurred.</p>
<div class=3D"gmail_quot&lt;blockquote class=3D" style=3D"margin: 0px =
0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex; position: static; =
z-index: auto;">
<div>If this means essentially that a soft fork deployment of SegWit =
will require SPV wallet servers to change their logic (or risk not being =
able to send payments) then it does seem to me that a hard fork to =
deploy this non controversial change is not only cleaner (on the data =
structure side) but safer in terms of the potential to affect the user =
experience.&nbsp;</div>
<div><br></div>
<div>
<br>=97
Regards, </div>
</div></blockquote></div><br></body></html>=

--Apple-Mail=_9EEF5B05-B9A8-458E-A0F5-846C2E9F1429--

--Apple-Mail=_30D9D353-CB1B-43E4-9283-5BD0F7EE212B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWbqZIAAoJEIEuMk4MG0P1GEIIAJnZfzFSCpJ0s2OO3LwMMYcN
CfLjD9KyN1GzJoRGcZVkpxhkhBHeAKSU25SdXsUZBALRIjdE8OLbiWnCgjCMx76J
Fp3nWsKlAxCHBi5bIRjanADQpjk9mYCmK65lguL4hYAIkUs2uYwfYGta9KHVN1jX
+MKYCSO6hCyL5EBU0AsERgOlaIKJc3qZEKMyLBQz4Bchd2MwTHKeYQTR3fgiAD1x
m8aajUA5ru/TLbjtjSL2ZzpmuFT32CVhaW2AJ9cPXV0cVowu6z+Zy565dEUZm19x
Hn1+kz1VsOkersGNOEOQk3VV5RDyJDKOTIRqmlzm1Fw/nAPBYgfswwD+tuqP9cw=
=Konk
-----END PGP SIGNATURE-----

--Apple-Mail=_30D9D353-CB1B-43E4-9283-5BD0F7EE212B--