path: root/ce/6552d25dbb3b1791bc6767c5332f3fe1fa498d

Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EE0A4B5F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 16:19:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com
	[209.85.215.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A7A3A15C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 16:19:16 +0000 (UTC)
Received: by mail-lf0-f43.google.com with SMTP id m18so34118824lfj.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 09:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=MVikv70RvuSrsyeyYTSLtw5yhfmOHORioBh+yJnFVOM=;
	b=MHNlAZOzyjDb0Q7Lc36lyiaQci9FT4f6UjlZY9L9VOjnp4XMDzEKDeTHmvx92+TQa4
	vPfc+Osx2p0vkbpaEBOYlYRamsyIUTxI4bMawscKBCv1kcmHqbzImEpTdgSu0gxSme/O
	zDUZykK0YGOOrzANO2dmPQEGv8KzFl7RetL89Pto1B8CqYQifst7HLnmbzkK5AkfKqgq
	nRqPtNdF4AjxzdQbkCFZwqYxkE6FOo04dEnARHuMTSLjRhX3S+nS5O0t0Xeb7pllfYh/
	uHRn6+0pqt8P1Wx2qoHfBp1Z/JNwPMAMwDfzpeX8bcqGHZrjgypBgtqmuynhbjM9TQqD
	OIOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=MVikv70RvuSrsyeyYTSLtw5yhfmOHORioBh+yJnFVOM=;
	b=aVtz/5OPECAFK3wzXVKcpQQkK4f3LJ5cPiq5X6CfalJcLbK21ixklLn7JKK8KP4k19
	BB167BR/536mY56VcT8+p95DtVVwYER4pA5az1B3a+PQF9G3pz5M7clBk3nqksSSW0PW
	Qbzm48ttp/EsuNsj3RHRXtfyt10tlkWdmr1LELlEeAkH+RksFLiiJht+q/EuYQW8KB4u
	77jzU2mqiiF0QvWQWNrRDgKo5SXkgbKuEngVN9kFAysFTS80Xnt0QYvHDWMtDVHCOmyV
	hp69o31FEiQgIgpBJODjiDjqj4YNZM5yij6inG8HU/Ll6wj48SYgZT0LtZa6TLVvjGyy
	Jz2g==
X-Gm-Message-State: AODbwcCKzio82GUJLx/+AirXUHf1Sz62SWuZJzf0XwBcunqRQxj9+89H
	tB35h7novApAojWvMyo91PqWKJwTlQ==
X-Received: by 10.46.82.151 with SMTP id n23mr6294195lje.2.1495469955015; Mon,
	22 May 2017 09:19:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.17.222 with HTTP; Mon, 22 May 2017 09:19:14 -0700 (PDT)
Received: by 10.25.17.222 with HTTP; Mon, 22 May 2017 09:19:14 -0700 (PDT)
In-Reply-To: <dhstGQudLBiwjDlaRrmMfy-ixwvXcwMr1CzCkPKh285RLICGZixkbdwpTDc2Sgz8eYIqSem8lwxW6QeJCD7aFfwQjLDnZ2NmOw0Zzd-KgSs=@protonmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<dhstGQudLBiwjDlaRrmMfy-ixwvXcwMr1CzCkPKh285RLICGZixkbdwpTDc2Sgz8eYIqSem8lwxW6QeJCD7aFfwQjLDnZ2NmOw0Zzd-KgSs=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Date: Mon, 22 May 2017 18:19:14 +0200
Message-ID: <CA+XQW1jZpJ9wnEg47fouyywL09=_vU8dMP3owkkuNqRvzTZUDg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="001a113c22be70e90705501f3b2b"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 22 May 2017 16:19:19 -0000

--001a113c22be70e90705501f3b2b
Content-Type: text/plain; charset="UTF-8"

On May 22, 2017 10:39 AM, "ZmnSCPxj" <ZmnSCPxj@protonmail.com> wrote:

Good morning Paul,

I read only http://www.truthcoin.info/blog/blind-merged-mining/

From just this document, I can't see a good justification for believing
that a main->side locking transaction can be safely spent into a side->main
unlocking transaction.  Do you have a better explanation?


Yes, a better explanation is in the drivechain spec, at:
http://www.truthcoin.info/blog/drivechain/

What you read is only an introduction of BMM. You may also consult the
notes (at the bottom of the BMM post) or the code, although this is time
consuming of course.


If I attempt to spend a main->side locking transaction on the basis of a
"mistaken" side block #49, what prevents me from this sequence:


The literal answer to your question is that mainchain Bitcoin will notice
that, for the second withdrawal, the sum of the inputs is less than the sum
of the outputs and they the transaction is therefore invalid.


1.  Put a side:side->main transaction into a block together with TheDAO's
hacked money.

So far, the only good side->main transfer I know of is in Blockstream's
original sidechains paper, with the main:side->main transaction ... Is your
proposal at the technical level actually similar, or does it truly seem to
be riskier?


I feel that my proposal is more secure, as it can operate healthily and
quickly while using spv proofs which are much slower and much much easier
to audit.


seems to me that your OP_is_h_in_coinbase should scan a series of sidechain
block headers backed by mainchain (meaning at the minimum that sidechains
should have some common header format prefix), rather than just mainchain
depth as your article seems to imply.


How would security be improved as a result? In either case, 51% of hashrate
can cause a reorg. The sidechain software itself does scan block headers,
of course.


Blind merged mining seems strictly inferior ... a rich attacker can simply
reorg the sidechain outright without playing such games.


In the future, when there is no block subsidy, a rich attacker can also do
that in mainchain Bitcoin.


Or is your proposal strictly for centralized sidechains, where only one
entity creates side blocks?


Not at all.

How does your proposal handle multiple side block creators on the same
sidechain, with the possibility that chain splits occur?


The side block is only "mined" if it is committed to in a mainchain Bitcoin
blog, and each mainchain block can only contain one block per sidechain. In
this way, drivechain sidechains are different from classical Namecoin
merged mining (where one _could_ run the entire system, mining included,
without interfacing with Bitcoin at all).


Regarding your dig about people who dislike data centers, the main issue
with miners blindly accepting sidechain commitments is that it violates
"Don't trust, verify", not that allows datacenters to be slightly smaller
by not including side:nodes.


As I explain early on, in earlier rounds of peer review, the focus was on
harms the sidechain technology might do to mainchain Bitcoin, and the
"datacenter point" was specifically the chief objection raised. So I am
afraid you are entirely incorrect.

In point of fact, the transactions *are* validated...by sidechain full
nodes, same as Bitcoin proper.

Paul


Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: [bitcoin-dev] Drivechain -- Request for Discussion
Local Time: May 22, 2017 6:17 AM
UTC Time: May 22, 2017 6:17 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.


Scaling Implications
---------------------

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.


Total Transaction Fees in the Far Future
-----------------------------------------

Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.


Juxtaposition with a recent "Scaling Compromise"
-------------------------------------------------

Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).

In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.


Other Thoughts
---------------

Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.

I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)

Cheers,
Paul

[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-
6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--001a113c22be70e90705501f3b2b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On May 22, 2017 10:39 AM, &quot;ZmnSCPxj&quot; &lt;<a href=3D"mai=
lto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div>Good morning Paul,<br></div>=
<div><br></div><div>I read only <a href=3D"http://www.truthcoin.info/blog/b=
lind-merged-mining/" target=3D"_blank">http://www.truthcoin.info/<wbr>blog/=
blind-merged-mining/</a><br></div><div><br></div><div>From just this docume=
nt, I can&#39;t see a good justification for believing that a main-&gt;side=
 locking transaction can be safely spent into a side-&gt;main unlocking tra=
nsaction.=C2=A0 Do you have a better explanation?<br></div></blockquote></d=
iv></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes, a better =
explanation is in the drivechain spec, at: <a href=3D"http://www.truthcoin.=
info/blog/drivechain/">http://www.truthcoin.info/blog/drivechain/</a></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">What you read is only an intr=
oduction of BMM. You may also consult the notes (at the bottom of the BMM p=
ost) or the code, although this is time consuming of course.</div><div dir=
=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
 class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div></div><div></div></blockquote></div></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div>If I attempt to spend a main=
-&gt;side locking transaction on the basis of a &quot;mistaken&quot; side b=
lock #49, what prevents me from this sequence:<br></div></blockquote></div>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">The literal answe=
r to your question is that mainchain Bitcoin will notice that, for the seco=
nd withdrawal, the sum of the inputs is less than the sum of the outputs an=
d they the transaction is therefore invalid.</div><div dir=3D"auto"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v></div><div><br></div><div>1.=C2=A0 Put a side:side-&gt;main transaction i=
nto a block together with TheDAO&#39;s hacked money.<br></div><div><br></di=
v><div>So far, the only good side-&gt;main transfer I know of is in Blockst=
ream&#39;s original sidechains paper, with the main:side-&gt;main transacti=
on ... Is your proposal at the technical level actually similar, or does it=
 truly seem to be riskier?</div></blockquote></div></div></div><div dir=3D"=
auto"><br></div><div dir=3D"auto"></div><div dir=3D"auto">I feel that my pr=
oposal is more secure, as it can operate healthily and quickly while using =
spv proofs which are much slower and much much easier to audit.</div><div d=
ir=3D"auto"></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div> seems to me that your OP_is_h_in_coinbase should=
 scan a series of sidechain block headers backed by mainchain (meaning at t=
he minimum that sidechains should have some common header format prefix), r=
ather than just mainchain depth as your article seems to imply.<br></div></=
blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
How would security be improved as a result? In either case, 51% of hashrate=
 can cause a reorg. The sidechain software itself does scan block headers, =
of course.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div></div><div><br></div><div>=
Blind merged mining seems strictly inferior ... a rich attacker can simply =
reorg the sidechain outright without playing such games.<br></div></blockqu=
ote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">In the =
future, when there is no block subsidy, a rich attacker can also do that in=
 mainchain Bitcoin.</div><div dir=3D"auto"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div></div><div><br></div><d=
iv>Or is your proposal strictly for centralized sidechains, where only one =
entity creates side blocks?</div></blockquote></div></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Not at all.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>How does your proposal handle multiple side=
 block creators on the same sidechain, with the possibility that chain spli=
ts occur?<br></div></blockquote></div></div></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">The side block is only &quot;mined&quot; if it is comm=
itted to in a mainchain Bitcoin blog, and each mainchain block can only con=
tain one block per sidechain. In this way, drivechain sidechains are differ=
ent from classical Namecoin merged mining (where one _could_ run the entire=
 system, mining included, without interfacing with Bitcoin at all).</div><d=
iv dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div></div><div><br></div><div>Regarding your dig about=
 people who dislike data centers, the main issue with miners blindly accept=
ing sidechain commitments is that it violates &quot;Don&#39;t trust, verify=
&quot;, not that allows datacenters to be slightly smaller by not including=
 side:nodes.<br></div></blockquote></div></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">As I explain early on, in earlier rounds of peer re=
view, the focus was on harms the sidechain technology might do to mainchain=
 Bitcoin, and the &quot;datacenter point&quot; was specifically the chief o=
bjection raised. So I am afraid you are entirely incorrect.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">In point of fact, the transactions *a=
re* validated...by sidechain full nodes, same as Bitcoin proper.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Paul</div><div dir=3D"auto"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div>=
<br></div><div><br></div><div>Sent with ProtonMail Secure Email.<br></div><=
div class=3D"elided-text"><div><br></div><div>-------- Original Message ---=
-----<br></div><div>Subject: [bitcoin-dev] Drivechain -- Request for Discus=
sion<br></div><div>Local Time: May 22, 2017 6:17 AM<br></div><div>UTC Time:=
 May 22, 2017 6:17 AM<br></div><div>From: <a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfound=
ation.org</a><br></div><div>To: Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linu=
xfoundation.org</a>&gt;<br></div><div><br></div><div>Dear list,<br></div><d=
iv> <br></div><div> I&#39;ve been working on &quot;drivechain&quot;, a side=
chain enabling technology, for<br></div><div> some time.<br></div><div> <br=
></div><div> * The technical info site is here: <a href=3D"http://www.drive=
chain.info" target=3D"_blank">www.drivechain.info</a><br></div><div> * The =
changes to Bitcoin are here:<br></div><div> <a href=3D"https://github.com/d=
rivechain-project/bitcoin/tree/mainchainBMM" target=3D"_blank">https://gith=
ub.com/drivechain-<wbr>project/bitcoin/tree/<wbr>mainchainBMM</a><br></div>=
<div> * A Blank sidechain template is here:<br></div><div> <a href=3D"https=
://github.com/drivechain-project/bitcoin/tree/sidechainBMM" target=3D"_blan=
k">https://github.com/drivechain-<wbr>project/bitcoin/tree/<wbr>sidechainBM=
M</a><br></div><div> <br></div><div> As many of you know, I&#39;ve been see=
king feedback in person, at various<br></div><div> conferences and meetups =
over the past year, most prominently Scaling<br></div><div> Milan. And I in=
tend to continue to seek feedback at Consensus2017 this<br></div><div> week=
, so if you are in NYC please just walk up and start talking to me!<br></di=
v><div> <br></div><div> But I also wanted to ask the list for feedback. Ini=
tially, I was<br></div><div> hesitant because I try not to consume reviewer=
s&#39; scarce time until the<br></div><div> author has put in a serious eff=
ort. However, I may have waiting too<br></div><div> long, as today it is ac=
tually quite close to a working release.<br></div><div> <br></div><div> <br=
></div><div> Scaling Implications<br></div><div> ---------------------<br><=
/div><div> <br></div><div> This upgrade would have significant scaling impl=
ications. Since it is<br></div><div> the case that sidechains can be added =
by soft fork, and since each of<br></div><div> these chains will have its o=
wn blockspace, this theoretically removes<br></div><div> the blocksize limi=
t from &quot;the Bitcoin system&quot; (if one includes<br></div><div> sidec=
hains as part of such a system). People who want a LargeBlock<br></div><div=
> bitcoin can just move their BTC over to such a network [1], and their<br>=
</div><div> txns will have no longer have an impact on &quot;Bitcoin Core&q=
uot;. Thus, even<br></div><div> though this upgrade does not actually incre=
ase &quot;scalability&quot; per se, it<br></div><div> may in fact put an en=
d to the scalability debate...forever.<br></div><div> <br></div><div> This =
work includes the relatively new concept of &quot;Blind Merged Mining&quot;=
<br></div><div> [2] which I developed in January to allow SHA256^2 miners t=
o merge-mine<br></div><div> these &quot;drivechains&quot;, even if these mi=
ners aren&#39;t running the actual<br></div><div> sidechain software. The g=
oal is to prevent sidechains from affecting the<br></div><div> levelness of=
 the mining &quot;playing field&quot;. BMM is conceptually similar to<br></=
div><div> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not=
<br></div><div> required for drivechain, but it would address some of the l=
ast remaining<br></div><div> concerns.<br></div><div> <br></div><div> <br><=
/div><div> Total Transaction Fees in the Far Future<br></div><div> --------=
----------------------<wbr>-----------<br></div><div> <br></div><div> Some =
people feel that a maximum blocksize limit is needed to ensure that<br></di=
v><div> future total equilibrium transaction fees are non-negligible. I<br>=
</div><div> presented [4] on why I don&#39;t agree, 8 months ago. The revie=
wers I spoke<br></div><div> to over the last year have stopped bringing thi=
s complaint up, but I am<br></div><div> not sure everyone feels that way.<b=
r></div><div> <br></div><div> <br></div><div> Juxtaposition with a recent &=
quot;Scaling Compromise&quot;<br></div><div> ------------------------------=
<wbr>-------------------<br></div><div> <br></div><div> Recently, a scalabi=
lity proposal began to circulate on social media. As<br></div><div> far as =
I could tell, it goes something like &quot;immediately activate<br></div><d=
iv> SegWit, and then HF to double the nonwitness blockspace to 2MB within 1=
2<br></div><div> months&quot;. But such a proposal is quite meager, compare=
d to a &quot;LargeBlock<br></div><div> Drivechain&quot;. The drivechain is =
better on both fronts, as it would not<br></div><div> require a hardfork, a=
nd could *almost immediately* add _any_ amount of<br></div><div> extra bloc=
kspace (specifically, I might expect a BIP101-like LargeBlock<br></div><div=
> chain that has an 8 MB maxblocksize, which doubles every two years).<br><=
/div><div> <br></div><div> In other words, I don&#39;t know why anyone woul=
d support that proposal over<br></div><div> mine. The only reasons would be=
 either ignorance (ie, unfamiliarity with<br></div><div> drivechain) or bec=
ause there are still nagging unspoken complaints about<br></div><div> drive=
chain which I apparently need to hear and address.<br></div><div> <br></div=
><div> <br></div><div> Other Thoughts<br></div><div> ---------------<br></d=
iv><div> <br></div><div> Unfortunately, anyone who worked on the &quot;firs=
t generation&quot; of sidechain<br></div><div> technology (the skiplist) or=
 the &quot;second generation&quot; (federated /<br></div><div> Liquid), wil=
l find that this is very different.<br></div><div> <br></div><div> I will a=
dmit that I am very pessimistic about any conversation that<br></div><div> =
involves scalability. It is often said that &quot;talking politics lowers<b=
r></div><div> your IQ by 25 points&quot;. Bitcoin scalability conversations=
 seem to drain<br></div><div> 50 points. (Instead of conversing, I think pe=
ople should quietly work on<br></div><div> whatever they are passionate abo=
ut until their problem either is solved,<br></div><div> or it goes away for=
 some other reason, or until we all agree to just<br></div><div> stop talki=
ng about it.)<br></div><div> <br></div><div> Cheers,<br></div><div> Paul<br=
></div><div> <br></div><div> [1] <a href=3D"http://www.drivechain.info/faq/=
#can-sidechains-really-help-with-scaling" target=3D"_blank">http://www.driv=
echain.info/<wbr>faq/#can-sidechains-really-<wbr>help-with-scaling</a><br><=
/div><div> [2] <a href=3D"http://www.truthcoin.info/blog/blind-merged-minin=
g/" target=3D"_blank">http://www.truthcoin.info/<wbr>blog/blind-merged-mini=
ng/</a><br></div><div> [3] <a href=3D"https://s3.amazonaws.com/peter.todd/b=
itcoin-wizards-13-10-17.log" target=3D"_blank">https://s3.amazonaws.com/<wb=
r>peter.todd/bitcoin-wizards-13-<wbr>10-17.log</a><br></div><div> [4]<br></=
div><div> <a href=3D"https://www.youtube.com/watch?v=3DYErLEuOi3xU&amp;list=
=3DPLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&amp;index=3D4" target=3D"_blank">http=
s://www.youtube.com/watch?<wbr>v=3DYErLEuOi3xU&amp;list=3DPLw8-<wbr>6ARlyVc=
iNjgS_NFhAu-qt7HPf_dtg&amp;<wbr>index=3D4</a><br></div><div> <br></div></di=
v><div class=3D"elided-text"><div> ______________________________<wbr>_____=
____________<br></div><div> bitcoin-dev mailing list<br></div><div> <a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.<wbr>linuxfoundation.org</a><br></div><div> <a href=3D"https://l=
ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">ht=
tps://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><=
br></div></div></blockquote></div><br></div></div></div>

--001a113c22be70e90705501f3b2b--