path: root/80/5e96657822fd07e8855bb78624dda7ce80771b

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 365C2891
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  9 Sep 2017 15:33:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f171.google.com (mail-io0-f171.google.com
	[209.85.223.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85FE6A1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  9 Sep 2017 15:33:16 +0000 (UTC)
Received: by mail-io0-f171.google.com with SMTP id y123so10780422iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 09 Sep 2017 08:33:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:references:from:to:message-id:date:user-agent:mime-version
	:in-reply-to:content-language:content-transfer-encoding;
	bh=L0upFmVhoZ+IfpnBwIPRBTFLhwpTA8Vmpfys521W1jE=;
	b=kJFJldz1jxYP2hfvYpcMZrsEsDAq/aDMhlaAGRN1QaaoJmTchMSEYl6Kkn4IAATSQ/
	A0MfQenJxBUwazJMcD+u+5+LVCsMhfsl+yZKzSqYJMpLroKSP6ZCiJukTgBB7R8ZQoRY
	077QysOGcdMrdpUGDQsJLo6nK62oTEGj+yl0d6j7exyobxp72lwAxFjqk7OPVF5AQ6Yz
	kQlCZGHGvudQCKtDFZrxaUDlKXY5xRWQ0leGSU8ZPMdXtW5+rKfGkVuWGwcXKjGDCFHm
	7N8gIy6qHsJasvgkTqCV0DOExM0zbGb/jqUmX9Oo77HVRW8pC6M2yLHpPH3BTIBYSO8y
	/Vpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:references:from:to:message-id:date
	:user-agent:mime-version:in-reply-to:content-language
	:content-transfer-encoding;
	bh=L0upFmVhoZ+IfpnBwIPRBTFLhwpTA8Vmpfys521W1jE=;
	b=W+wDDKD0xLcoaGMQYEn5v+WlNLMguJsue68pe0NaYlgkF88bCVxvY7gpBi+KJVcABC
	FS6JyvUk67SmFRn7liVIgm4BGEcefFHfldekxBa3f8B+zsCXAXFe8AsCYyhuTA9JZooG
	f7WR1qQYuaLQuVvU7WqFzL+umLa6XMpGQVXvlb9pp77dVLz5Qmt9fxlhZkMeK+UmfgWR
	phgw3F04c9sxaE4JG3Tddx1po0465AXfvi/xuzHRKVTVlgfE1i2bsXxoPKwyQu47hQzm
	VoeOnd8ig1n0tU7SHF2xW5+ObeixpBhNV3v1VAzP1GkSniMrpgJ3Xj82WIPH2rk59ntr
	fw2g==
X-Gm-Message-State: AHPjjUj2jd2TaxquBe45ePPlF8HlJCD/TRwg6ESXkCh5SVREd7SnGUv1
	zH0VuLDPDeNoxA==
X-Google-Smtp-Source: AOwi7QDiHf0ZDh9lKZqTVcMl+nCBzX+vlVReNsN9tD4h0yxv7/VK3gT/SXls5HkeDtiFABT46l3fGg==
X-Received: by 10.107.138.77 with SMTP id m74mr8438495iod.218.1504971195629;
	Sat, 09 Sep 2017 08:33:15 -0700 (PDT)
Received: from [192.168.43.210] ([172.58.142.199])
	by smtp.googlemail.com with ESMTPSA id
	12sm2308553itm.1.2017.09.09.08.33.13
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 09 Sep 2017 08:33:14 -0700 (PDT)
References: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
	<CAGL6+mG-jD6L5b0LepyotDd2+POjkrgV98c2fLFGM0ZokD4afA@mail.gmail.com>
	<wkUkYK_kYwSQx7JKzvgrfUiZYPLPrORMT_zBL5Tg-Spnr8tOyC_o4nZT4yFOD-FE86FvshRhWTfPblYqVmaZHi-VnMbKwpDDkAOjI8b9ap8=@protonmail.com>
	<CAGL6+mGy7nTK1yA8YZcG59r9GZmVb+XWgQ1HjuPD4_pD7ZWThw@mail.gmail.com>
	<6S1lfiXnljmQiZLorMOenBXGeve0K_LHKiCIZ75Gfc8LZieB7sq_bV_UWV-kJ197FYWywzDaQE7kOEqguYxlDFWZnLdzONhFZ7OAaWFgn64=@protonmail.com>
	<CAGL6+mHqKXbm5nAHq+ghaTihCQQe0Rs1sd82ff2NiFKSq6Be+A@mail.gmail.com>
	<yDICafWAbOJEbNvT9o8fltfCuJry5ZOLGwjQ-Ji6xfLjTP3XI_DXb8UbFJ6tA8jclqIEudFABAVEbXuLN9HLnN2nv-WTDE7q9vyjcALtufc=@protonmail.com>
	<CAGL6+mGrN1m_zWs0KM4sfPHCdYUjuJ+E6hjVCFOtz2RoBDZyoQ@mail.gmail.com>
	<E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1e3f1e8d-c5c9-9ee5-7069-6db47bec5879@gmail.com>
Date: Sat, 9 Sep 2017 11:33:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
	autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification
 of drivechains and spv proofs)
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: Sat, 09 Sep 2017 15:33:17 -0000


Hi everyone,

I have some agreements and disagreements.

I agree with Zmn:

1. That the sidechain's header is fully defined by the bits of data
included in mainchain headers. These bits include "h*" (some hash that
is either of the header itself or side:hashMerkleRoot), something that
forces these hashes into a DAG-like structure (in Zmn's case, it is a
full hashPrevBlock, whereas for us it is just a tiny integer).
2. That "miner-voting" (for lack of better phrase) accomplishes the same
task as any SPV Proof of any kind.
3. That sidechains basically need to be merged-mined; to do otherwise,
there are marginal costs but really no marginal benefits.

However:

On 9/8/2017 12:19 AM, ZmnSCPxj wrote:
> Good morning.
>
> The obvious reply to all this is: what does
> sidechain-headers-on-mainchain do that drivechain cannot do cheaper?
>
> 1.  Unifies merge mining (h* commitment) and WT^ validity voting.
> Merge-mined headers increase the vote on a WT^, by increasing the depth
> of the WT^.



1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain")
to "unify merged-mining and the WT^ validity voting". This causes the
SHOM to regress to mere extension blocks, and they therefore take on
many of the negative properties of extension blocks.

See: http://www.drivechain.info/faq/index.html#usefulness


> 2.  Through OP_BRIBEVERIFY, the power to decide the validity of a
> sidechain lies in the economic majority rather than in the miners.


I don't think that this is true. 51% miner-group can pay bribes to
themselves, and orphan any block or txn that disagrees with them.

I also don't think that there is any meaningful difference between "what
the economic majority wants" and "what the miners do". To me it is a
blindingly obvious fact: miners are paid more, only if they increase the
value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if
Bitcoin is expected to be more objectively useful, and if its users
treasure its use sufficiently to warrant the payment of high tx fees.

When miners disagree with, for example, the bitcoin-dev mailing list,
this is because miners are attempting to guess what the economic
majority wants, and, in making this earnest attempt, miners believe that
the bitcoin-dev interest is different from the economic majority interest.

Obviously, I don't expect to change any minds on this list. After all,
(since no one dares oppose the economic majority), it is a smart
strategy to pretend that the economic majority always agrees with you.
And it is extra smart to avoid examining that belief too carefully.


  2.2.1.  This seems to imply that sidechains where unified merge-mining
> and WT^ voting are paid for by economic majority, effectively work as
> proof-of-stake.  The difference here is that the proof does not have to
> cover itself (i.e. the stake being used to prove is outside the system
> which the proof is proving) and it is really more of a
> proof-of-sacrifice-of-stake, since the economic majority needs to pay
> (and thus lose) the stake for continued operation of the sidechain.  One
> can argue that proof-of-work is just an instance of
> proof-of-sacrifice-of-stake anyway.

I agree with most of this, but I think in proof of work and proof of
stake the security guarantee is more reasonable.. In SHOM, there is no
reason to believe that the the quantity "total amount of money available
for withdrawal in a given time" will always be smaller than "sum of 288
bribes".

> 2.2.2.  Miner behavior on Bcash and Bitcoin suggests to me that a good
> portion of the miners are interested more in short-term profits than
> long-term.

As long as some critical mass of investors exist, there is no difference
between short and long term profits. It is impossible for an investor to
act in a way that affects the long term, but does not immediately also
affect the short term.


> I have not seen a good explanation of how drivechain WT^ validity voting
> works in detail; my understanding is that a WT^ is presented on the
> mainchain, then a voting period is established during which miners
> somehow vote for whether the WT^ is valid or not, then the voting ends
> and a UTXO is somehow created.  If it is in some Sztorc video, I
> apologize, I am unable to usefully view them.
Some documentation is here:
https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md


> --
>
> I think lockboxes should have fixed value.  The value should be big
> enough that the cost of OP_WITHDRAWPROOFVERIFY is low.  Particularly for
> privacy-oriented sidechains, all lockboxes having the same value will
> help tremendously in continuing obscurity after side-to-main transfers.
> However, I am uncertain whether sidechain or mainchain should enforce
> this fixed value.  This parameter is something to be endlessly debated.
> Perhaps it should be sidechain that enforces this, but then mistakes
> could occur on the mainchain where some lockbox on the mainchain is
> deemed invalid on the sidechain, and cannot be unlocked validly except
> by destroying the sidechain.
I don't think this makes any sense, because it implies that the value of
288 block's worth of mainchain BTC transaction fees should always be
worth more than the entire market capitalization of Bitcoin.

Specifically, in this case, the error it introduces is that someone
could get around the fixed value by just using multiple sidechains. Then
the miners would just attack all the sidechains simultaneously. (And
these smaller sidechains would themselves have much smaller fees.)


>
> Sidechains may first be deployed as federated peg, then at some
> sidechain height the federation may announce a move to
> drivechain/sidechain-headers-on-mainchain.  The move from federated to
> economic-majority-controlled would involve the federation moving its
> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes.
Sergio likes this idea, but I think that this attitude represents a lack
of faith in the design. Either the design works or it does not. Either
the federation works or it does not.
>
> Sidechain hardforks would be very contentious, with only one clear
> winner that can unlock lockboxes.  I think, part of sidechain design
> must be the understanding that sidechains must never be hardforked, and
> only softforked.  Indeed, I am very much convinced that it is impossible
> to safely hardfork mainchain at all, and any block size increase must by
> necessity be softforked in.
This is already the case in what we have done...the only way to
guarantee that all clients report the same WT^ is if they are all
running softforks of the first version.


> The mechanism that supports sidechains supports any financial system,
> including centralized, non blockchain ones.  The h* commitments can be
> made into commitments to the financial system's state.  Basically, it is
> an implementation of CoinWitness, without using zk-SNARKs and instead
> using some mainchain-voted proof, where validity is judged by how much
> maincoin was sacrified to advance that proof.  The supported financial
> system might even allow arbitrary execution of Turing-complete code for
> more vulnerabilities.
This is why I do not want ultra-easy, completely-permissionless creation
of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED
behavior of the sidechain.
> Is there some spec for WT^ layout?
Yes, see above.

Thanks,
Paul