Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C8ADBE19 for ; Wed, 23 Sep 2015 22:27:16 +0000 (UTC) X-Greylist: delayed 00:10:56 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 4962822D for ; Wed, 23 Sep 2015 22:27:16 +0000 (UTC) Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t8NMGGmu027616 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 23 Sep 2015 15:16:16 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90"; 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.1 From: "Jonathan Toomim (Toomim Bros)" In-Reply-To: Date: Wed, 23 Sep 2015 15:16:14 -0700 Message-Id: <03FF5567-DF6E-4242-B63F-D71D1E7E393F@toom.im> References: To: Bitcoin Dev X-Mailer: Apple Mail (2.1878.6) X-Sonic-CAuth: UmFuZG9tSVZ0lR1oumHexThjCg19hXE0gCsZeQZ/6WFlqI57mmx6OImkRXg+AAP5HneNLaf/afT75flxh9fFExMkelZkHViW X-Sonic-ID: C;GpAqtUBi5RGrleK7sH9FTg== M;GH+XtUBi5RGrleK7sH9FTg== 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] Weak block thoughts... 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: Wed, 23 Sep 2015 22:27:16 -0000 --Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90 Content-Type: multipart/alternative; boundary="Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C" --Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 23, 2015, at 2:37 PM, Gavin Andresen via bitcoin-dev = wrote: > Take care, here-- if a scheme is used where e.g. the full solution had > to be exactly identical to a prior weak block then the result would be > making mining not progress free because bigger miners would have > disproportionately more access to the weak/strong one/two punch. I > think what you're thinking here is okay, but it wasn't clear to me if > you'd caught that particular potential issue. >=20 > I'm assuming the optimized protocol would be forward-error-coded (e.g. = using IBLTs) and NOT require the full solution (or follow-on weak = blocks) to be exactly the same. >=20 One possible improvement on this is to cache Merkle nodes/subtrees. When = a weak block is created, nodes could cache the hashes for the Merkle = nodes along with each node's children. A miner could then describe their = block in terms of Merkle nodes (describing groups of 2^n transactions), = which would give them the ability to copy e.g. 87.5% or 96.875% or = whatever of their new block from someone else's weak block but with a = few modifications (e.g. new transactions) in the remaining = non-prespecified portion. This gives small miners the ability to trade = off versatility (do I specify all of the transactions with my own Merkle = structure?) versus propagation speed (do I copy all of my Merkle tree = from another miner's weak block?) with all steps in between. I've got a proposal for a block propagation protocol inspired by = bittorrent applied to the Merkle tree instead of chunks of a file. Weak = blocks would fit in with this blocktorrent protocol quite nicely by = caching and pre-transmitting Merkle nodes. I don't want to hijack this = thread, so I'll post it under a separate subject in an hour or so. --Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 23, 2015, at 2:37 = PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:

Take care, here-- if a scheme is used where e.g. = the full solution had
to be exactly identical to a prior weak block = then the result would be
making mining not progress free because = bigger miners would have
disproportionately more access to the = weak/strong one/two punch. I
think what you're thinking here is okay, = but it wasn't clear to me if
you'd caught that particular potential = issue.

I'm = assuming the optimized protocol would be forward-error-coded (e.g. using = IBLTs)  and NOT require the full solution (or follow-on weak = blocks) to be exactly the same.


One = possible improvement on this is to cache Merkle nodes/subtrees. When a = weak block is created, nodes could cache the hashes for the Merkle nodes = along with each node's children. A miner could then describe their block = in terms of Merkle nodes (describing groups of 2^n transactions), which = would give them the ability to copy e.g. 87.5% or 96.875% or whatever of = their new block from someone else's weak block but with a few = modifications (e.g. new transactions) in the remaining non-prespecified = portion. This gives small miners the ability to trade off versatility = (do I specify all of the transactions with my own Merkle structure?) = versus propagation speed (do I copy all of my Merkle tree from another = miner's weak block?) with all steps in = between.

I've got a proposal for a block = propagation protocol inspired by bittorrent applied to the Merkle tree = instead of chunks of a file. Weak blocks would fit in with this = blocktorrent protocol quite nicely by caching and pre-transmitting = Merkle nodes. I don't want to hijack this thread, so I'll post it under = a separate subject in an hour or so.
= --Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C-- --Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90 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 iQEcBAEBCgAGBQJWAySvAAoJEIEuMk4MG0P1i+oH/0+AFg6wc3vDcWz9DM1s8KOD yUWb7YKd7taNe8jDB8Va4MXrrfRUk9ZDqnlAaeP94wd/nfETBVn2ZoMDS9NAXtPD qjYwy3YTVoUfPK5yes4hztzk8i+mVPuuQ4jOjyhs+VMaoGws7nDscUQOkyogXdYr FZZbfQM/AzTE7bCsk4dsGHxlifMbUYSzedThtzn1vZcoiqK0riV9w1UkHSN9Vw5f Ix1kLE9iYHKuoe/XkpOFBZCpurE0raFjxmeoFQbODHMDlQ7W44+MBzoMDc8f3xz+ 4UxSSb6zAgg3BMf2y0tK9Wwky74pLd+zgTLfnGkVi9bIS5N+eqGMbb98LCScXdI= =ZVHr -----END PGP SIGNATURE----- --Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90--