From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4vpd-0005RY-21 for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 18:43:33 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.182 as permitted sender) client-ip=209.85.213.182; envelope-from=akaramaoun@gmail.com; helo=mail-ig0-f182.google.com; Received: from mail-ig0-f182.google.com ([209.85.213.182]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4vpb-0006aJ-3v for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 18:43:33 +0000 Received: by igbos3 with SMTP id os3so50907582igb.0 for ; Tue, 16 Jun 2015 11:43:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.43.196 with SMTP id y4mr5340882igl.14.1434480205785; Tue, 16 Jun 2015 11:43:25 -0700 (PDT) Sender: akaramaoun@gmail.com Received: by 10.64.20.229 with HTTP; Tue, 16 Jun 2015 11:43:25 -0700 (PDT) In-Reply-To: <20150616181724.GA4055@muck> References: <557D2571.601@gmail.com> <20150616181724.GA4055@muck> Date: Tue, 16 Jun 2015 18:43:25 +0000 X-Google-Sender-Auth: XdAeBn9N299waQym-OrFvYQ2778 Message-ID: From: Andrew To: Peter Todd Content-Type: multipart/alternative; boundary=089e011604121a71fd0518a6f3a5 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (akaramaoun[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z4vpb-0006aJ-3v Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 18:43:33 -0000 --089e011604121a71fd0518a6f3a5 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd wrote: > Merge-mined sidechains are not a scaling solution any more than SPV is a > scaling solution because they don't solve the scaling problem for > miners. > > Some kind of treechain like sidechain / subchains where what part of the > tree miners can mine is constrained to preserve fairness could be both a > scaling solution, and decentralized, but no-one has come up with a solid > design yet that's ready for production. (my treechains don't qualify for > transactions yet; maybe for other proof-of-publication uses) > > Well doesn't my proposal solve the miner decentralization problem. Only the direct parent and children chains are merge mined. To be more clear, let the top chain to have level 1. Each chain that is a child of a chain of level n has level n+1. For any chain C, a block is accepted if the hash of its header has an appropriate number of trailing zeros (as usual). It can also be accepted with special transactions as I will explain. Let C be a chain of level n. Let C0,C1,....,C9 be its children (each of level n+1). For any i in {0,1,...,9}, any solution to the mining problem of C can be inserted as a special transaction inside Ci and this enables the block to be accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in {0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of C cannot be inserted as a special transaction inside of child Cij of Ci. So that means all of the chains are not merge mined, only localised parts, right? By the way, we can eventually get rid of the block size 1 MB limit by requiring more than just the header to be hashed, but that can be done in the future as soft fork with sidechains, and is a side topic. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 --089e011604121a71fd0518a6f3a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd <pete@petertodd.org&g= t; wrote:
Merge-mined sidechains a= re not a scaling solution any more than SPV is a
scaling solution because they don't solve the scaling problem for
miners.

Some kind of treechain like sidechain / subchains where what part of the tree miners can mine is constrained to preserve fairness could be both a scaling solution, and decentralized, but no-one has come up with a solid design yet that's ready for production. (my treechains don't qualif= y for
transactions yet; maybe for other proof-of-publication uses)


Well doesn't my proposal solve the= miner decentralization problem. Only the direct parent and children chains= are merge mined. To be more clear, let the top chain to have level 1. Each= chain that is a child of a chain of level n has level n+1. For any chain C= , a block is accepted if the hash of its header has an appropriate number o= f trailing zeros (as usual). It can also be accepted with special transacti= ons as I will explain. Let C be a chain of level n. Let C0,C1,....,C9 be it= s children (each of level n+1). For any i in {0,1,...,9}, any solution to t= he mining problem of C can be inserted as a special transaction inside Ci a= nd this enables the block to be accepted in Ci (so C and C0,C1,...,C9 are m= erge mined. But, for any i in {0,1,...,9} and any j in {0,1,...,9}, any sol= ution to the mining problem of C cannot be inserted as a special transactio= n inside of child Cij of Ci. So that means all of the chains are not merge = mined, only localised parts, right?

By the way, we can eventually get rid of the block size 1 MB l= imit by requiring more than just the header to be hashed, but that can be d= one in the future as soft fork with sidechains, and is a side topic.


--
PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647=
--089e011604121a71fd0518a6f3a5--