From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DB8ACD79 for ; 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 ; 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 ; 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 In-Reply-To: Date: Mon, 14 Dec 2015 19:21:43 +0800 Message-Id: <3292B7BA-13A8-4BD9-AB08-4F5EBE534771@toom.im> References: <1449897228198.c655b3ae@Nodemailer> To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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
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.li= nuxfoundation.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.

Non segwit = servers and wallets would continue operations as if nothing had = occurred.

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. 


=97 Regards,

= --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--