path: root/d5/01883e6d18b26a6656b56fd3c5ec0174d0c28f

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 68D0293D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Oct 2016 18:17:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
	[209.85.213.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4850D1FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Oct 2016 18:17:33 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id y190so112371651vkd.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 02 Oct 2016 11:17:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream-io.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=jqKGUo2+ZENPFDMW6vL+flHjefKztKXP17ebKSI4E9o=;
	b=jC4jEKdgom+z0Z04FQCunQjgSc7H4aww6kvhkHqju/NGklUXyEld/JHdEHXX0LTt5r
	y2TuaMb5WWW7xhJnfxMLr2cPt9VLSOtvG91233pn+4Ra3vkhNdI2hTzHmWRihsNRiuA9
	2GXrwpzWA04z36f18DJrxBObRbUh3MG51uzTwDLOcbYXywMbDW7LYcM6qGpT1R5Eo7gR
	D1deY6rlDMdFm9utgWPXOU26i4vo00Uy8vzin8Dip0+q6c3NmMyJRDHFR81fHfdlTGao
	5OOiGA1H9R1dXnyz+zxuEQUF23WH8jT3UTRzUirtr8FvAn8YYxxQ5gFNChDvnWC+Fy16
	qSbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=jqKGUo2+ZENPFDMW6vL+flHjefKztKXP17ebKSI4E9o=;
	b=hBXghkw7AyzB/llHekKhYyGcNVWllNa2uuNrZA/ylSmugqzu0P3gSbfawI53a1m5Sf
	q2YIF9TEwv7DDzp2sa5lqxKfpDFOx2kBa5qqvC2224Pn+LuUeSNF1iviMW/mLBvdSUrx
	5EdlZnPTAXEfcvsLwXP9ux/stwY7O68/a44cwzjb63ZhbP76i/MwKoTVa1yWEvBbMeSU
	akCrxBHPO4HtYodypc8hovUNH5LfLN2Ah9MBaE/bZhVflMpVDZ8LVlrvWGPj8JeiwA6a
	5lkdQWLGsIgTXuaUHLkZ+AyNaYY0nSJ4c8dfA7Rf1xtUd9M6VofbGWP3SWd/NBgRH6EF
	zBEA==
X-Gm-Message-State: AA6/9RkyC4MyYrS6tqctGqnrlxRwFHN942QgN1IYyB6WkzXbOIU6I5M1Puhdel19+YSCcrSrq10GuJM2fQbval0O
X-Received: by 10.31.194.206 with SMTP id s197mr11427878vkf.101.1475432252473; 
	Sun, 02 Oct 2016 11:17:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.3.102 with HTTP; Sun, 2 Oct 2016 11:17:12 -0700 (PDT)
In-Reply-To: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com>
References: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 2 Oct 2016 14:17:12 -0400
Message-ID: <CAMZUoKmMT7=QMWNEQ+AerUi3yT7z5n3Onm26fH3631U2kSpHtw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11437b544c9ca1053de5d733
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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
X-Mailman-Approved-At: Sun, 02 Oct 2016 18:18:14 +0000
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
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: Sun, 02 Oct 2016 18:17:34 -0000

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

If I understand this BIP correctly, the values pushed onto the stack by the
OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
block that this happens to be included in.

This isn't going to be acceptable.  The validity of a transaction should
always be monotone in the sense that if a transaction was acceptable in a
given block, it must always be acceptable in any subsequent block, with the
only exception being if one of the transaction's inputs get double spent.

The added check lock time and check sequence number operations were
carefully constructed to ensure this property.

On Sun, Oct 2, 2016 at 11:49 AM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Since ScalingBitcoin is close, I think this is a good moment to publish
> our proposal on drivechains. This BIP proposed the drivechain we'd like to
> use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented in Bitcoin. Until that happens, we're using a federated
> approach.
> I'm sure that adding risk-less Bitcoin extensibility through
> sidechains/drivechains is what we all want, but it's of maximum importance
> to decide which technology will leads us there.
> We hope this work can also be the base of all other new 2-way-pegged
> blockchains that can take Bitcoin the currency to new niches and test new
> use cases, but cannot yet be realized because of current
> limitations/protections.
>
> The full BIP plus a reference implementation can be found here:
>
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
>
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> (Note: Code is still unaudited)
>
> As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode
> that counts acks and nacks tags in coinbase fields, and push the resulting
> totals in the script stack.
>
> The system was designed with the following properties in mind:
>
> 1. Interoperability with scripting system
> 2. Zero risk of invalidating a block
> 3. No additional computation during blockchain management and
> re-organization
> 4. No change in Bitcoin security model
> 5. Bounded computation of poll results
> 6. Strong protection from DoS attacks
> 7. Minimum block space consumption
> 8. Zero risk of cross-secondary chain invalidation
>
> Please see the BIP draft for a more-detailed explanation on how we achieve
> these goals.
>
> I'll be in ScalingBitcoin in less than a week and I'll be available to
> discuss the design rationale, improvements, changes and ideas any of you
> may have.
>
> Truly yours,
> Sergio Demian Lerner
> Bitcoiner and RSK co-founder
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div>If I understand this BIP correctly, the values pushed=
 onto the stack by the OP_COUNT_ACKS operation depends on the ack and nack =
counts relative to the block that this happens to be included in.<br><br></=
div>This isn&#39;t going to be acceptable.=C2=A0 The validity of a transact=
ion should always be monotone in the sense that if a transaction was accept=
able in a given block, it must always be acceptable in any subsequent block=
, with the only exception being if one of the transaction&#39;s inputs get =
double spent.<br><br>The added check lock time and check sequence number op=
erations were carefully constructed to ensure this property.<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Oct 2, 2016 at=
 11:49 AM, Sergio Demian Lerner via bitcoin-dev <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Since ScalingBitcoi=
n is close, I think this is a good moment to publish our proposal on drivec=
hains. This BIP proposed the drivechain we&#39;d like to use in RSK (a.k.a.=
 Rootstock) two-way pegged blockchain and see it implemented in Bitcoin. Un=
til that happens, we&#39;re using a federated approach. <br>I&#39;m sure th=
at adding risk-less Bitcoin extensibility through sidechains/drivechains is=
 what we all want, but it&#39;s of maximum importance to decide which techn=
ology will leads us there.<br>We hope this work can also be the base of all=
 other new 2-way-pegged blockchains that can take Bitcoin the currency to n=
ew niches and test new use cases, but cannot yet be realized because of cur=
rent limitations/protections.<br><br>The full BIP plus a reference implemen=
tation can be found here:<br></div><br>BIP (draft):<br><a href=3D"https://g=
ithub.com/rootstock/bips/blob/master/BIP-R10.md" target=3D"_blank">https://=
github.com/rootstock/<wbr>bips/blob/master/BIP-R10.md</a><br><br></div>Code=
 &amp; Test cases:<br><a href=3D"https://github.com/rootstock/bitcoin/tree/=
op-count-acks_devel" target=3D"_blank">https://github.com/rootstock/<wbr>bi=
tcoin/tree/op-count-acks_<wbr>devel</a><br></div><div>(Note: Code is still =
unaudited)<br><br></div><div>As a summary, OP_COUNT_ACKS is a new segwit-ba=
sed and soft-forked opcode that counts acks and nacks tags in coinbase fiel=
ds, and push the resulting totals in the script stack.<br><br>The system wa=
s designed with the following properties in mind:<br><br>1. Interoperabilit=
y with scripting system <br>2. Zero risk of invalidating a block<br>3. No a=
dditional computation during blockchain management and re-organization<br>4=
. No change in Bitcoin security model<br>5. Bounded computation of poll res=
ults<br>6. Strong protection from DoS attacks<br>7. Minimum block space con=
sumption<br>8. Zero risk of cross-secondary chain invalidation<br><br></div=
><div>Please see the BIP draft for a more-detailed explanation on how we ac=
hieve these goals.<br></div><div></div><div><br></div>I&#39;ll be in Scalin=
gBitcoin in less than a week and I&#39;ll be available to discuss the desig=
n rationale, improvements, changes and ideas any of you may have.<br><br></=
div><div>Truly yours, <br></div>Sergio Demian Lerner<br></div>Bitcoiner and=
 RSK co-founder<br><div><div><div><div><div> <div><div><br></div></div></di=
v></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a11437b544c9ca1053de5d733--