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\))
From: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
In-Reply-To: <CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
Date: Wed, 23 Sep 2015 15:16:14 -0700
Message-Id: <03FF5567-DF6E-4242-B63F-D71D1E7E393F@toom.im>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
	<CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
	<CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
	<CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Weak block thoughts...
Precedence: list


--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 =
<bitcoin-dev@lists.linuxfoundation.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.
>=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><br></div><div><div>On Sep 23, 2015, at 2:37 =
PM, Gavin Andresen 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"><blockquote =
class=3D"gmail_quote" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; 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;">Take care, here-- if a scheme is used where e.g. =
the full solution had<br>to be exactly identical to a prior weak block =
then the result would be<br>making mining not progress free because =
bigger miners would have<br>disproportionately more access to the =
weak/strong one/two punch. I<br>think what you're thinking here is okay, =
but it wasn't clear to me if<br>you'd caught that particular potential =
issue.<br></blockquote><div style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><br></div><div style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I'm =
assuming the optimized protocol would be forward-error-coded (e.g. using =
IBLTs) &nbsp;and NOT require the full solution (or follow-on weak =
blocks) to be exactly the same.</div><br =
class=3D"Apple-interchange-newline"></blockquote></div><br><div>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.</div><div><br></div><div>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.</div></body></html>=

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