path: root/d6/e89e281cb4a2b4b2d4a52d0e923a1b75b91ab1

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E4F01B7A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 13:39:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
	[209.85.220.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7BDA1F0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 13:39:00 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id d14so57463368qkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 06:39:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=hSCc+JagjhmYElZFpzBddH64Vcq88ixdKNv4yyDyuHg=;
	b=jnisj7YI5M3cMQqp+Daq3CafJg1T73U/Kp2wxe/DIWINtB4gSIyPplSGApjVohku2A
	QGbseXsl6TVR/U3mw2STS2TUTCHBn+vEJRCAs/bz20pzvK1lqqAUBDUsMeJuz/bf4BZC
	lnU6oa7fjKFcGzm31MfxG0+kt+UPAmsyW7lgxRIMD2uvknukyFMmkurSHGLXQ3mnO8WD
	5otNifh+iEAw1DL8KXCvrHaf6JXrCbmrvsxKhifhrczskQ/CqibuCaMi1c98cSMOzVb4
	5h3j9DogopAYBAk/z7RLBnnA54bRnYuMTXLHhHMsm08ZR0GZvRjbfrTnu1Mdm8I9Vxa9
	p3uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=hSCc+JagjhmYElZFpzBddH64Vcq88ixdKNv4yyDyuHg=;
	b=A2DCKL+7TWMxzfgcjDMr+qjlHtztn/fl+PsR3PAB5tGZGRYiLC6fgVZPUQ8kezcxQ5
	NWuMLCkz6+2Fc61XelnfvsPfTeOoizpNfaaH5n0R00GM8edk6F2p2T5nLyek67F2aedj
	ZrQz2NOFXlpKTlWdQI1BJlENMEsTgJW/tOriiL3OKeZa0GrErr1XV4rpATsBvsvgbZIf
	7JlumZ6m53w5ad5ovf+hGmS5sns3PGu4Dmrm3Nmy1U6AKuP0uXFL4+xWhqfWnIoVY9r+
	JoUnCDrpQ0P+MpZ/+YrgiE8HChVJUUPTo8m9P3rKyT8WDAcqoM5aJvKcnveV4bdOAXaU
	7VjQ==
X-Gm-Message-State: AKS2vOwm2EPC3n/FrSTrJChnD+60P5TOz2iYzleNzQv+8XM4ZSDGjBvk
	3FQtSpxkTpIp+DI4mwe28//wF+CG7Q==
X-Received: by 10.233.223.199 with SMTP id t190mr33902880qkf.247.1497965939800;
	Tue, 20 Jun 2017 06:38:59 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.54.100 with HTTP; Tue, 20 Jun 2017 06:38:59 -0700 (PDT)
In-Reply-To: <33d98418-10f0-3854-a954-14985d53e04b@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
	<33d98418-10f0-3854-a954-14985d53e04b@gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 20 Jun 2017 09:38:59 -0400
X-Google-Sender-Auth: cjqb1n-Moh00nH6tCuvWjsKLbs8
Message-ID: <CAJowKgKT2rn3N3L+79JEY_uNfKDewcmgkiEB2mJYx1mg+YjGCQ@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c043278ba40f40552645f9e"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 20 Jun 2017 13:40:39 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
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: Tue, 20 Jun 2017 13:39:03 -0000

--94eb2c043278ba40f40552645f9e
Content-Type: text/plain; charset="UTF-8"

- a proof-of-burn sidechain is the ultimate two-way peg.   you have to burn
bitcoin *or* side-chain tokens to mine the side chain.   the size of the
burn is the degree of security.    i actually wrote code to do randomized
blind burns where you have a poisson distribution (non-deterministic
selected burn).    there is no way to game it... it's very similar to
algorand - but it uses burns instead of staking

- you can then have a secure sidechain that issues a mining reward in
sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
result of this is that any bitcoins held in the sidechain depreciate in
value at a rate of X% per year.   this deflation rate pays for increased
security

- logically this functions like an alt coin, with high inflation and cheap
transactions.   but the altcoin is pegged to bitcoin's price because of the
pool of unredeemed bitcoins held within the side chain.



On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com> wrote:

> Hi Erik,
>
> As you know:
>
> 1. If a sidechain is merged mined it basically grows out of the existing
> Bitcoin mining network. If it has a different PoW algorithm it is a new
> mining network.
> 2. The security (ie, hashrate) of any mining network would be determined
> by the total economic value of the block. In Bitcoin this is
> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
> would only be (tx_fees)*price.
>
> Unfortunately the two have a nasty correlation which can lead to a
> disastrous self-fulfilling prophecy: users will avoid a network that is too
> insecure; and if users avoid using a network, they will stop paying txn
> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
> network's security. So it is quite problematic and I recommend just biting
> the bullet and going with merged mining instead.
>
> And, the point may be moot. Bitcoin miners may decide that, given their
> expertise in seeking out cheap sources of power/cooling, they might as well
> mine both/all chains. So your suggestion may not achieve your desired
> result (and would, meanwhile, consume more of the economy's resources --
> some of these would not contribute even to a higher hashrate).
>
> Paul
>
>
>
>
> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>
> It would be nice to be able to enforce that a drivechain *not* have the
> same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already have
> too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Greg,
>>
>> Responses below:
>>
>> On 6/18/2017 5:30 PM, Tao Effect wrote:
>> > In Drivechain, 51% of miners have total control and ownership over all
>> > of the sidechain coins.
>>
>> It would not be accurate to say that miners have "total" control. Miners
>> do control the destination of withdrawals, but they do not control the
>> withdrawal-duration nor the withdrawal-frequency.
>>
>> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>> theft, but they can not change the fact that their malfeasance will be
>> [a] obvious, and [b] on display for a long period of time.
>>
>> We might draw a comparison between:
>>
>> 1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
>> chain to double-spend funds (or coordinate with someone who is
>> double-spending). This is prevented/discouraged by waiting for many
>> confirmations.
>> 2. Channel Theft -- A majority hashrate assists a Lightning-Network
>> thief, by censoring the punitive audit txn (possibly by exploiting some
>> excuse regarding fullness of blocks, or possibly induced to do so by the
>> thief provably splitting the proceeds with miners). This is
>> prevented/discouraged by using lengthy custodial periods, paying high
>> fees with your attacker's money, and using fungibility/non-communication
>> to interact with miners as little as possible (so as to frame LN-theft
>> as undermining the entire LN system, and not merely a single tragedy).
>> 3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
>> withdrawal from some sidechain. This is prevented/discouraged by only
>> using 'popular' sidechains (those that [a] increase the usefulness
>> ("market price") of bitcoin, and [b] generate tx fees for miners). It is
>> also discouraged by the fact that egregious theft would probably end the
>> sidechain experiment, meaning that all present and future sidechains
>> would be forever unavailable (and unable to buoy the price or the tx
>> revenues).
>>
>> I do not think that any of the three stands out as being categorically
>> worse than the others, especially when we consider the heterogeneity of
>> use-cases and preferences. As Luke-Jr has been pointing out on social
>> media recently, the very group which is more associated with miners (and
>> explicitly more willing to trust them, ie Bitcoin Unlimited et al),
>> happens to be the same group that would be expected to make use of a
>> LargeBlock drivechain. Some can argue that one type of security is more
>> "cryptographic" than others, but I think this is misguided (how many
>> 'bits' of security does each have?) -- imho, all three security models
>> are 'game theoretic' (neither computer scientific, nor cryptographic).
>>
>> More importantly, before a miner has any "control" over the sidechain
>> coins, users must voluntarily agree to subject themselves to these new
>> rules. This is similar to how an arbitrary piece of (open source)
>> software can have "total" control over your computer...if you choose to
>> install it.
>>
>> > Thus the effect of Drivechain appears to be the creation of a new kind
>> > of digital border imposed onto the network ...
>>
>> I'm not sure it would "create a border", given that sidechains are
>> currently not accessible at all. If anything drivechain cuts a door into
>> an existing impassible border.
>>
>> >  ... where everyone hands over ownership of their Bitcoins to a
>> > /single/ mining cartel when they wish to interact with /any/ sidechain.
>>
>> The qualifier "/any/ sidechain" would seem to imply that there is a way
>> to do sidechains that does not involve handing over some control to 51%
>> hashrate...I think this is false (even in the fabled case of ZK-SNARKS).
>> The first thing I do in the drivechain spec (
>> truthcoin.info/blog/drivechain ) is explain why.
>>
>> > Drivechain would be a reasonable idea if that weren't the case, but
>> > since it is, Drivechain now introduces a very real possible future
>> > where Bitcoins can be confiscated by the Chinese government in exactly
>> > the same manner that the Chinese government today confiscates
>> > financial assets in other financial networks within China.
>>
>> Yes, but money could also be confiscated from _any_ Bitcoin users
>> (Chinese or otherwise) using any of the three methods I mentioned above.
>> And confiscation could strike Chinese Bitcoin users if they decided to
>> sell their Bitcoin for Chinese Yuan, which they then deposited in a
>> Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by
>> the Chinese govt in some other way.
>>
>> It is not up to the members of this list to decide, USSR style, what
>> other people are allowed to do with their own money.
>>
>> The exceptions to this rule would be (ie, "bitcoin-dev should care about
>> what users are doing when..."):
>>
>> 1. [Unreasonable use of Reviewer Time]  The user's use-case is either
>> nonexistent (ie "no one wants that"), or totally unachievable ("we can't
>> do that") thus rendering the conversation a complete waste of time /
>> reviewer attention.
>> 2. [Harmful Interference] The user's use-case would impose harm on some
>> existing use-case(s).
>>
>> No reasonable person will claim the first, given today's scaling debate
>> (not to mention today's 'bitcoin dominance index'). Therefore, critics
>> must claim the second (as, for example, Peter Todd has been doing on
>> this list).
>>
>> Which is why I narrowly focus on inter-chain harms [1], leading
>> ultimately to a focus on the mining ecosystem [2,3] and the development
>> of Blind Merged Mining [4].
>>
>> [1]
>> https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyV
>> ciNjgS_NFhAu-qt7HPf_dtg&index=1
>> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>> [3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
>> [4] http://www.truthcoin.info/blog/blind-merged-mining/
>> [5] http://www.truthcoin.info/blog/measuring-decentralization/
>>
>> > 1. The Bitcoin network centralizes more, because more power (both
>> > financial power and power in terms of capability/control) is granted
>> > to miners.
>>
>> I think that one has some duty to very clearly define something (like
>> "mining centralization" [2] or "centralization" [5]) before complaining
>> about it. I feel that people will occasionally use selfless complaints
>> to accomplish a selfish goal...especially when the artificial selfless
>> part is hard to discuss by virtue of its being poorly defined
>> (especially vague or abstract items like "the company", "our country",
>> etc). For example, those who take it upon themselves to "defend" "the
>> Bitcoin community" may have exactly that in mind as their primary
>> goal...but they may also end up with more visibility (and with it: more
>> influence, more job offers, more conference invites, more friends, etc)
>> and they may also end up with a megaphone for which to broadcast their
>> other views, or just a defend-able excuse for bragging loudly about how
>> great cypherpunks are and/or how devoted they-in-particular are to the
>> cypherpunk tribe, et cetera. To avoid this problem in my own technical
>> discourse, I try to avoid abstractions like "centralization" until I
>> have defined them [2,5].
>>
>> You have defined centralization above, but the definition is itself
>> vague to the point where I do not think even you actually endorse it.
>> For example, you would need to say that Bitcoin centralizes whenever the
>> exchange rate increases (as this grants additional financial power to
>> miners) or when any new user joins Bitcoin, or when tx fee revenues
>> increase for any reason. You might also be forced to say that LN
>> centralizes Bitcoin (as LN grants new capability/control to miners), and
>> probably even that Bitcoin becomes more centralized when developers
>> release new software (as this grants new capability to miners,
>> specifically the ability to deny upgrades). This probably isn't what you
>> meant, but since you did not clearly explain what you meant we have no
>> way of knowing for sure.
>>
>> It seems to me that you reject the premise that BMM [4] addresses these
>> issues. This is probably because BMM only addresses miner's interactions
>> with each other, and it does not address miner abilities as a group in
>> relation to other groups (for example, vs. users, developers,
>> investors). But, as I consistently emphasize, these groups of people are
>> free to ignore any sidechains that they do not like. In law there is a
>> saying 'volenti non fit injuria' which I would translate as "he who
>> volunteers cannot claim later to have been injured". This is a legal
>> theory, because otherwise everyone would be arbitrarily liable for
>> choices beyond their control (ie, responsible for decisions of other
>> unrelated people), which would be nonsense.
>>
>> > 3. Drivechain limits user's existing choice when it comes to who is
>> > acting as custodian of their Bitcoins, from any trustworthy exchange,
>> > down to a single mining cartel under the control of a single set of
>> laws.
>>
>> Currently no (P2P) sidechains exist, and therefore the set of choices
>> today would seem to be more "limited" than in a post-sidechain future.
>> (The set of options may decrease later, for ecological reasons, if and
>> only if 'exchanges' are a strictly inferior option to 'sidechains' for
>> some reason...I don't see why this would be the case. I also don't
>> understand the emphasis on "exchanges" [SCs are much more like Altcoins,
>> than exchanges] in the first place, nor the dubious qualifier
>> "trustworthy".)
>>
>> --Paul
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>

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

<div dir=3D"ltr"><div>- a proof-of-burn sidechain is the ultimate two-way p=
eg. =C2=A0 you have to burn bitcoin *or* side-chain tokens to mine the side=
 chain. =C2=A0 the size of the burn is the degree of security. =C2=A0 =C2=
=A0i actually wrote code to do randomized blind burns where you have a pois=
son distribution (non-deterministic selected burn). =C2=A0 =C2=A0there is n=
o way to game it... it&#39;s very similar to algorand - but it uses burns i=
nstead of staking<br></div><div><br></div><div>- you can then have a secure=
 sidechain that issues a mining reward in sidechain tokens, which can be ag=
grregated and redeemed for bitcoins. =C2=A0 the result of this is that any =
bitcoins held in the sidechain depreciate in value at a rate of X% per year=
. =C2=A0 this deflation rate pays for increased security</div><div><br></di=
v><div>- logically this functions like an alt coin, with high inflation and=
 cheap transactions. =C2=A0 but the altcoin is pegged to bitcoin&#39;s pric=
e because of the pool of unredeemed bitcoins held within the side chain.</d=
iv><div><br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <span dir=3D"ltr">&=
lt;<a href=3D"mailto:truthcoin@gmail.com" target=3D"_blank">truthcoin@gmail=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"m_-7917178296017049299moz-cite-prefix">Hi Erik,<br>
      <br>
      As you know:<br>
      <br>
      1. If a sidechain is merged mined it basically grows out of the
      existing Bitcoin mining network. If it has a different PoW
      algorithm it is a new mining network.<br>
      2. The security (ie, hashrate) of any mining network would be
      determined by the total economic value of the block. In Bitcoin
      this is (subsidy+tx_fees)*price, but since a sidechain cannot
      issue new tokens it would only be (tx_fees)*price.<br>
      <br>
      Unfortunately the two have a nasty correlation which can lead to a
      disastrous self-fulfilling prophecy: users will avoid a network
      that is too insecure; and if users avoid using a network, they
      will stop paying txn fees and so the quantity (tx_fees)*price
      falls toward zero, erasing the network&#39;s security. So it is quite
      problematic and I recommend just biting the bullet and going with
      merged mining instead.<br>
      <br>
      And, the point may be moot. Bitcoin miners may decide that, given
      their expertise in seeking out cheap sources of power/cooling,
      they might as well mine both/all chains. So your suggestion may
      not achieve your desired result (and would, meanwhile, consume
      more of the economy&#39;s resources -- some of these would not
      contribute even to a higher hashrate).<span class=3D"HOEnZb"><font co=
lor=3D"#888888"><br>
      <br>
      Paul</font></span><div><div class=3D"h5"><br>
      <br>
      <br>
      <br>
      On 6/19/2017 1:11 PM, Erik Aronesty wrote:<br>
    </div></div></div><div><div class=3D"h5">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>It would be nice to be able to enforce that a drivechain
          *not* have the same POW as bitcoin. <br>
          <br>
        </div>
        <div>I suspect this is the only way to be sure that a drivechain
          doesn&#39;t destabilize the main chain and push more power to
          miners that already have too much power.<br>
        </div>
        <br>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">On Mon, Jun 19, 2017 at 12:04 PM, Paul
          Sztorc via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<w=
br>linuxfoundation.org</a>&gt;</span>
          wrote:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Hi Greg,<br>
            <br>
            Responses below:<br>
            <span><br>
              On 6/18/2017 5:30 PM, Tao Effect wrote:<br>
              &gt; In Drivechain, 51% of miners have total control and
              ownership over all<br>
              &gt; of the sidechain coins.<br>
              <br>
            </span>It would not be accurate to say that miners have
            &quot;total&quot; control. Miners<br>
            do control the destination of withdrawals, but they do not
            control the<br>
            withdrawal-duration nor the withdrawal-frequency.<br>
            <br>
            So, if miners wish to &#39;steal&#39; from a sidechain, they _c=
an_
            initiate a<br>
            theft, but they can not change the fact that their
            malfeasance will be<br>
            [a] obvious, and [b] on display for a long period of time.<br>
            <br>
            We might draw a comparison between:<br>
            <br>
            1. Classic Theft=C2=A0 =C2=A0-- A majority hashrate reorganizes=
 the
            main Bitcoin<br>
            chain to double-spend funds (or coordinate with someone who
            is<br>
            double-spending). This is prevented/discouraged by waiting
            for many<br>
            confirmations.<br>
            2. Channel Theft -- A majority hashrate assists a
            Lightning-Network<br>
            thief, by censoring the punitive audit txn (possibly by
            exploiting some<br>
            excuse regarding fullness of blocks, or possibly induced to
            do so by the<br>
            thief provably splitting the proceeds with miners). This is<br>
            prevented/discouraged by using lengthy custodial periods,
            paying high<br>
            fees with your attacker&#39;s money, and using
            fungibility/non-communication<br>
            to interact with miners as little as possible (so as to
            frame LN-theft<br>
            as undermining the entire LN system, and not merely a single
            tragedy).<br>
            3. Drivechain Theft -- A majority hashrate initiates an
            unrepresentative<br>
            withdrawal from some sidechain. This is
            prevented/discouraged by only<br>
            using &#39;popular&#39; sidechains (those that [a] increase the
            usefulness<br>
            (&quot;market price&quot;) of bitcoin, and [b] generate tx fees=
 for
            miners). It is<br>
            also discouraged by the fact that egregious theft would
            probably end the<br>
            sidechain experiment, meaning that all present and future
            sidechains<br>
            would be forever unavailable (and unable to buoy the price
            or the tx<br>
            revenues).<br>
            <br>
            I do not think that any of the three stands out as being
            categorically<br>
            worse than the others, especially when we consider the
            heterogeneity of<br>
            use-cases and preferences. As Luke-Jr has been pointing out
            on social<br>
            media recently, the very group which is more associated with
            miners (and<br>
            explicitly more willing to trust them, ie Bitcoin Unlimited
            et al),<br>
            happens to be the same group that would be expected to make
            use of a<br>
            LargeBlock drivechain. Some can argue that one type of
            security is more<br>
            &quot;cryptographic&quot; than others, but I think this is misg=
uided
            (how many<br>
            &#39;bits&#39; of security does each have?) -- imho, all three
            security models<br>
            are &#39;game theoretic&#39; (neither computer scientific, nor
            cryptographic).<br>
            <br>
            More importantly, before a miner has any &quot;control&quot; ov=
er the
            sidechain<br>
            coins, users must voluntarily agree to subject themselves to
            these new<br>
            rules. This is similar to how an arbitrary piece of (open
            source)<br>
            software can have &quot;total&quot; control over your computer.=
..if
            you choose to<br>
            install it.<br>
            <span><br>
              &gt; Thus the effect of Drivechain appears to be the
              creation of a new kind<br>
            </span>&gt; of digital border imposed onto the network ...<br>
            <br>
            I&#39;m not sure it would &quot;create a border&quot;, given th=
at
            sidechains are<br>
            currently not accessible at all. If anything drivechain cuts
            a door into<br>
            an existing impassible border.<br>
            <br>
            &gt;=C2=A0 ... where everyone hands over ownership of their
            Bitcoins to a<br>
            <span>&gt; /single/ mining cartel when they wish to
              interact with /any/ sidechain.<br>
              <br>
            </span>The qualifier &quot;/any/ sidechain&quot; would seem to =
imply
            that there is a way<br>
            to do sidechains that does not involve handing over some
            control to 51%<br>
            hashrate...I think this is false (even in the fabled case of
            ZK-SNARKS).<br>
            The first thing I do in the drivechain spec (<br>
            <a href=3D"http://truthcoin.info/blog/drivechain" rel=3D"norefe=
rrer" target=3D"_blank">truthcoin.info/blog/drivechain</a>
            ) is explain why.<br>
            <span><br>
              &gt; Drivechain would be a reasonable idea if that weren&#39;=
t
              the case, but<br>
              &gt; since it is, Drivechain now introduces a very real
              possible future<br>
              &gt; where Bitcoins can be confiscated by the Chinese
              government in exactly<br>
              &gt; the same manner that the Chinese government today
              confiscates<br>
              &gt; financial assets in other financial networks within
              China.<br>
              <br>
            </span>Yes, but money could also be confiscated from _any_
            Bitcoin users<br>
            (Chinese or otherwise) using any of the three methods I
            mentioned above.<br>
            And confiscation could strike Chinese Bitcoin users if they
            decided to<br>
            sell their Bitcoin for Chinese Yuan, which they then
            deposited in a<br>
            Chinese bank. Or if they sold their Bitcoin for an Altcoin
            controlled by<br>
            the Chinese govt in some other way.<br>
            <br>
            It is not up to the members of this list to decide, USSR
            style, what<br>
            other people are allowed to do with their own money.<br>
            <br>
            The exceptions to this rule would be (ie, &quot;bitcoin-dev
            should care about<br>
            what users are doing when...&quot;):<br>
            <br>
            1. [Unreasonable use of Reviewer Time]=C2=A0 The user&#39;s use=
-case
            is either<br>
            nonexistent (ie &quot;no one wants that&quot;), or totally
            unachievable (&quot;we can&#39;t<br>
            do that&quot;) thus rendering the conversation a complete waste
            of time /<br>
            reviewer attention.<br>
            2. [Harmful Interference] The user&#39;s use-case would impose
            harm on some<br>
            existing use-case(s).<br>
            <br>
            No reasonable person will claim the first, given today&#39;s
            scaling debate<br>
            (not to mention today&#39;s &#39;bitcoin dominance index&#39;).
            Therefore, critics<br>
            must claim the second (as, for example, Peter Todd has been
            doing on<br>
            this list).<br>
            <br>
            Which is why I narrowly focus on inter-chain harms [1],
            leading<br>
            ultimately to a focus on the mining ecosystem [2,3] and the
            development<br>
            of Blind Merged Mining [4].<br>
            <br>
            [1]<br>
            <a href=3D"https://www.youtube.com/watch?v=3D0goYH2sDw0w&amp;li=
st=3DPLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&amp;index=3D1" rel=3D"noreferrer" t=
arget=3D"_blank">https://www.youtube.com/watch?<wbr>v=3D0goYH2sDw0w&amp;lis=
t=3DPLw8-6ARlyV<wbr>ciNjgS_NFhAu-qt7HPf_dtg&amp;index=3D<wbr>1</a><br>
            [2] <a href=3D"http://www.truthcoin.info/blog/mirage-miner-cent=
ralization/" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info=
/blog<wbr>/mirage-miner-centralization/</a><br>
            [3] <a href=3D"http://www.truthcoin.info/blog/mining-threat-equ=
ilibrium/" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/b=
log<wbr>/mining-threat-equilibrium/</a><br>
            [4] <a href=3D"http://www.truthcoin.info/blog/blind-merged-mini=
ng/" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/blog<wb=
r>/blind-merged-mining/</a><br>
            [5] <a href=3D"http://www.truthcoin.info/blog/measuring-decentr=
alization/" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/=
blog<wbr>/measuring-decentralization/</a><br>
            <span><br>
              &gt; 1. The Bitcoin network centralizes more, because more
              power (both<br>
              &gt; financial power and power in terms of
              capability/control) is granted<br>
              &gt; to miners.<br>
              <br>
            </span>I think that one has some duty to very clearly define
            something (like<br>
            &quot;mining centralization&quot; [2] or &quot;centralization&q=
uot; [5]) before
            complaining<br>
            about it. I feel that people will occasionally use selfless
            complaints<br>
            to accomplish a selfish goal...especially when the
            artificial selfless<br>
            part is hard to discuss by virtue of its being poorly
            defined<br>
            (especially vague or abstract items like &quot;the company&quot=
;, &quot;our
            country&quot;,<br>
            etc). For example, those who take it upon themselves to
            &quot;defend&quot; &quot;the<br>
            Bitcoin community&quot; may have exactly that in mind as their
            primary<br>
            goal...but they may also end up with more visibility (and
            with it: more<br>
            influence, more job offers, more conference invites, more
            friends, etc)<br>
            and they may also end up with a megaphone for which to
            broadcast their<br>
            other views, or just a defend-able excuse for bragging
            loudly about how<br>
            great cypherpunks are and/or how devoted they-in-particular
            are to the<br>
            cypherpunk tribe, et cetera. To avoid this problem in my own
            technical<br>
            discourse, I try to avoid abstractions like &quot;centralizatio=
n&quot;
            until I<br>
            have defined them [2,5].<br>
            <br>
            You have defined centralization above, but the definition is
            itself<br>
            vague to the point where I do not think even you actually
            endorse it.<br>
            For example, you would need to say that Bitcoin centralizes
            whenever the<br>
            exchange rate increases (as this grants additional financial
            power to<br>
            miners) or when any new user joins Bitcoin, or when tx fee
            revenues<br>
            increase for any reason. You might also be forced to say
            that LN<br>
            centralizes Bitcoin (as LN grants new capability/control to
            miners), and<br>
            probably even that Bitcoin becomes more centralized when
            developers<br>
            release new software (as this grants new capability to
            miners,<br>
            specifically the ability to deny upgrades). This probably
            isn&#39;t what you<br>
            meant, but since you did not clearly explain what you meant
            we have no<br>
            way of knowing for sure.<br>
            <br>
            It seems to me that you reject the premise that BMM [4]
            addresses these<br>
            issues. This is probably because BMM only addresses miner&#39;s
            interactions<br>
            with each other, and it does not address miner abilities as
            a group in<br>
            relation to other groups (for example, vs. users,
            developers,<br>
            investors). But, as I consistently emphasize, these groups
            of people are<br>
            free to ignore any sidechains that they do not like. In law
            there is a<br>
            saying &#39;volenti non fit injuria&#39; which I would translat=
e as
            &quot;he who<br>
            volunteers cannot claim later to have been injured&quot;. This =
is
            a legal<br>
            theory, because otherwise everyone would be arbitrarily
            liable for<br>
            choices beyond their control (ie, responsible for decisions
            of other<br>
            unrelated people), which would be nonsense.<br>
            <span><br>
              &gt; 3. Drivechain limits user&#39;s existing choice when it
              comes to who is<br>
              &gt; acting as custodian of their Bitcoins, from any
              trustworthy exchange,<br>
              &gt; down to a single mining cartel under the control of a
              single set of laws.<br>
              <br>
            </span>Currently no (P2P) sidechains exist, and therefore
            the set of choices<br>
            today would seem to be more &quot;limited&quot; than in a
            post-sidechain future.<br>
            (The set of options may decrease later, for ecological
            reasons, if and<br>
            only if &#39;exchanges&#39; are a strictly inferior option to
            &#39;sidechains&#39; for<br>
            some reason...I don&#39;t see why this would be the case. I als=
o
            don&#39;t<br>
            understand the emphasis on &quot;exchanges&quot; [SCs are much =
more
            like Altcoins,<br>
            than exchanges] in the first place, nor the dubious
            qualifier<br>
            &quot;trustworthy&quot;.)<br>
            <span class=3D"m_-7917178296017049299HOEnZb"><font color=3D"#88=
8888"><br>
                --Paul<br>
              </font></span>
            <div class=3D"m_-7917178296017049299HOEnZb">
              <div class=3D"m_-7917178296017049299h5"><br>
                ______________________________<wbr>_________________<br>
                bitcoin-dev mailing list<br>
                <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
                <a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfou=
ndation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div></div></div>

</blockquote></div><br></div>

--94eb2c043278ba40f40552645f9e--