path: root/63/25b46b742c4f11d83d49da821677d1e7e693cc

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 2A8B2B6E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Apr 2017 16:14:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
	[209.85.216.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E647B10E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Apr 2017 16:14:19 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id m36so49274978qtb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Apr 2017 09:14:19 -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=wnurzJ7A2LKsO8Sd1fQMmUEmHfkC2CwESMUsWcTL1wQ=;
	b=MImVyseiDgDcr1xQT7xdUrX22h/NmIA5+hy3Sos2EL330xE8lV+he6ybpuMt+7201A
	fxwOsWg9V0dPiqBU6uplcTt9AzlbKs6I1Y/AWBeMwVKebtuS6RyXe16FDG1v5K8DQCew
	Quq2DGKWQpd/c2f/tJ++IU1fCRcOwcynSFDagfczRGR8/7tabBbIOs6TeQOAw9moW2BW
	TsYeGwqKowfiq8ESkvGcY/GBoUVjMhfS3FLLd99BPaHsd9ymhkifmtiBBZe/G165Opve
	jqLtqfAzrPlhHQKm8H6/+4e3WJ6XWTeJ1SkFjwENZC5Ys6vcofadHKnpRodLtq1jnTOO
	axxw==
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=wnurzJ7A2LKsO8Sd1fQMmUEmHfkC2CwESMUsWcTL1wQ=;
	b=S2nQE0BKLCErzuTy8WkR4ACCESd8iOWR8PsISgaAeQPKt8U2QYi+g57IzufE6l5VJ/
	FqfT8Z4cXUDud5NrDZoXI5elDoj16lEVRql2+Y2SnLLhMw2Aq3z2RalCFYzsPX3SaBEG
	R0C8yyvVd22ubQ24Xsby06V1fYMtNFJOAMDyen1DRDnmHunzYC/vDl21fTk5XEkBGiTG
	3mSVaEknay7BFuihLWRlkTu8Hzg8tEBLDmmPK1DOj9dDtjk3QYZMcyMu/Sgmhbz9yh8V
	oquIJAzLJUWU7LGbc9YSccO+Djn1z2hWwnNJfMoAx4scHHhVVRj55ZdqBMdQ5oQEfXf2
	dhoQ==
X-Gm-Message-State: AN3rC/6jXv5fzo39EyvNerfyUrj/JML8TcgcViNTd1NmKqu5jg60kBA0
	t8F560JCApRfIoOHdCRxWZBNUEwA8g==
X-Received: by 10.200.43.17 with SMTP id 17mr8223068qtu.199.1492704859044;
	Thu, 20 Apr 2017 09:14:19 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.0.146 with HTTP; Thu, 20 Apr 2017 09:14:18 -0700 (PDT)
In-Reply-To: <1492554557.1625.4.camel@mmci.uni-saarland.de>
References: <CAJowKgJ38kA_vPGF6KpKEnrRzStrk-Mj87bttaOw-dvLW675Jw@mail.gmail.com>
	<CAJowKgK4j=sL2vh1bxWh2WWw0vw1PuxfJ39JW7bQS-UDzKh6CQ@mail.gmail.com>
	<CAJowKgKAnrMKiLdONrXJtGQYhYgRSXq7JNWrY=zUEMvw4WSX9w@mail.gmail.com>
	<CAJowKgL-NB0zF-Ud52Jr6n0Fo-uV=bXzVAFMOKmhAVA0RdRVuQ@mail.gmail.com>
	<CAJowKgJGZJMondTmsdOLdqqY1mf9S+TaB8UmdCtsLF6PA2RSJw@mail.gmail.com>
	<CAJowKg+gZcNO+-sdmt55KOt+zuN+8m7Hiqh77s9=gYpyszDwmA@mail.gmail.com>
	<CAJowKgKC4+6vv0QUH_DRASVqU4jui-iXG6TDgEpGUHRkVwJFqg@mail.gmail.com>
	<CAJowKgKH2h1QwpEvZ30OuEUsTCg1OoD6JcuXdmS+d_pKpygFcQ@mail.gmail.com>
	<CAJowKg+EJGXA5=LjJhCo1YevQtBubEftSNPfnzE4b5ESCwrUMg@mail.gmail.com>
	<CAJowKgLQCqL37oCzkJc8gPnUCkPYtF6G8_7Ug4AP5FpTOonBWQ@mail.gmail.com>
	<CAJowKgJ-eoF6ZCKrWbJQDcMK8-jTZxD+J_6tGAyfXz+HYrqmXg@mail.gmail.com>
	<CAJowKgKEVxS9OCg=Lioc1gRAy1Ftc27bp3nr2R9MQX-VQ9PrhQ@mail.gmail.com>
	<CALxbBHVY6_Xuq4Si9yQ0+dL_9DTCdwiWLDFStzFO2xRvHzTyBQ@mail.gmail.com>
	<1492554557.1625.4.camel@mmci.uni-saarland.de>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 20 Apr 2017 12:14:18 -0400
X-Google-Sender-Auth: 9p3kMJkyp98LHh67m_mw5vdh69c
Message-ID: <CAJowKgK=B2=fSwz5cqPLzMtyo-uDiNCOy9q+C39DJkaQ5h8U_Q@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Content-Type: multipart/alternative; boundary=001a11c0342ae0c058054d9b6ef8
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM 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: Thu, 20 Apr 2017 16:16:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction signalling
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: Thu, 20 Apr 2017 16:14:21 -0000

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

I agree, addresses create vulnerability, an OP_RETURN signal seems the
safest way to go for UA signalling.   I can model a BIP after BIP9, with
some discussion of how to properly collect statistics, and the ability for
nodes to activate features based on an "economic majority" defined in this
way.

On Tue, Apr 18, 2017 at 6:29 PM, Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't have an opinion on whether signaling is a good idea in general.
>
> However I don't think that using addresses is a good idea, because this
> has privacy implications. For example, it makes it much easier to link
> the addresses, e.g., inputs with change address. (The change address
> votes for the same proposal as the input address.)
>
> Tim
>
> On Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev
> wrote:
> > I really like the idea of extending signalling capabilities to the
> > end-users. It gives stakeholders a voice in the decisions we take in
> > the network, and are a clear signal to all other involved parties. It
> > reminds me of a student thesis I supervised some time ago [1], in
> > which we explored various signalling ideas.
> >
> > I think we have a number of fields that may be used for such a
> > signalling, e.g., OP_RETURN, locktime, and output scripts. I think
> > OP_RETURN is probably not the field you'd want to use though since it
> > adds data that needs to be transferred, stored for bootstrap, and
> > outputs in the UTXO would need to be tagged with additional
> > information. Locktime has the advantage of being mostly a freeform
> > field for values in the past, but it clashes with other uses that may
> > rely on it. Furthermore, it is the transaction creator that specifies
> > the locktime, hence the signal trails one hop behind the current
> > owner, i.e., the actual stakeholder.
> >
> > I think probably the best field to signal would be the output
> > script. It is specified by the recipient of the funds, i.e., the
> > current owner, and is already stored in the UTXO, so a single pass
> > can
> > tally up the votes. We could for example use the last 4 bits of the
> > pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1
> > depending on the stakeholders desired signal). We'd need to define
> > similar semantics for other script types, but getting the standard
> > scripts to be recognized should be simple.
> >
> > In the spirit of full disclosure I'd like to also mention some of the
> > downsides of voting this way. Unlike the OP_RETURN proposal, users
> > that do not intend to signal will also be included in the tally. I'd
> > expect the signals of these users to be random with a 50% chance of
> > either outcome, so they should not influence the final result, but
> > may
> > muddy the water depending on what part of the population is
> > signalling. The opt-in should make sure that the majority of votes
> > are
> > actually voluntary votes, and not just users that randomly select a
> > pubkey/pubkeyhash, and can be adjusted as desired, though higher
> > values require more grinding on behalf of the users.
> >
> > The grinding may also exacerbate some problems we already have with
> > the HD Wallet lookahead, since we now skip a number of addresses, so
> > we should not require too many opt-in bits.
> >
> > So there are some problems we'd need to tackle, but I'm really
> > excited
> > about this, as it could provide data to make informed decisions, and
> > should put an end to the endless speculation about the will of the
> > economic majority.
> >
> > Cheers,
> > Christian
> >
> > [1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>I agree, addresses create vulnerability, an OP_RETURN=
 signal seems the safest way to go for UA signalling.=C2=A0=C2=A0 I can mod=
el a BIP after BIP9, with some discussion of how to properly collect statis=
tics, and the ability for nodes to activate features based on an &quot;econ=
omic majority&quot; defined in this way.<br></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Tue, Apr 18, 2017 at 6:29 PM, Tim=
 Ruffing via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don&#3=
9;t have an opinion on whether signaling is a good idea in general.<br>
<br>
However I don&#39;t think that using addresses is a good idea, because this=
<br>
has privacy implications. For example, it makes it much easier to link<br>
the addresses, e.g., inputs with change address. (The change address<br>
votes for the same proposal as the input address.)<br>
<br>
Tim<br>
<br>
On Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev<br>
wrote:<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt; I really like the idea of exte=
nding signalling capabilities to the<br>
&gt; end-users. It gives stakeholders a voice in the decisions we take in<b=
r>
&gt; the network, and are a clear signal to all other involved parties. It<=
br>
&gt; reminds me of a student thesis I supervised some time ago [1], in<br>
&gt; which we explored various signalling ideas.<br>
&gt;<br>
&gt; I think we have a number of fields that may be used for such a<br>
&gt; signalling, e.g., OP_RETURN, locktime, and output scripts. I think<br>
&gt; OP_RETURN is probably not the field you&#39;d want to use though since=
 it<br>
&gt; adds data that needs to be transferred, stored for bootstrap, and<br>
&gt; outputs in the UTXO would need to be tagged with additional<br>
&gt; information. Locktime has the advantage of being mostly a freeform<br>
&gt; field for values in the past, but it clashes with other uses that may<=
br>
&gt; rely on it. Furthermore, it is the transaction creator that specifies<=
br>
&gt; the locktime, hence the signal trails one hop behind the current<br>
&gt; owner, i.e., the actual stakeholder.<br>
&gt;<br>
&gt; I think probably the best field to signal would be the output<br>
&gt; script. It is specified by the recipient of the funds, i.e., the<br>
&gt; current owner, and is already stored in the UTXO, so a single pass<br>
&gt; can<br>
&gt; tally up the votes. We could for example use the last 4 bits of the<br=
>
&gt; pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1<br>
&gt; depending on the stakeholders desired signal). We&#39;d need to define=
<br>
&gt; similar semantics for other script types, but getting the standard<br>
&gt; scripts to be recognized should be simple.<br>
&gt;<br>
&gt; In the spirit of full disclosure I&#39;d like to also mention some of =
the<br>
&gt; downsides of voting this way. Unlike the OP_RETURN proposal, users<br>
&gt; that do not intend to signal will also be included in the tally. I&#39=
;d<br>
&gt; expect the signals of these users to be random with a 50% chance of<br=
>
&gt; either outcome, so they should not influence the final result, but<br>
&gt; may<br>
&gt; muddy the water depending on what part of the population is<br>
&gt; signalling. The opt-in should make sure that the majority of votes<br>
&gt; are<br>
&gt; actually voluntary votes, and not just users that randomly select a<br=
>
&gt; pubkey/pubkeyhash, and can be adjusted as desired, though higher<br>
&gt; values require more grinding on behalf of the users.<br>
&gt;<br>
&gt; The grinding may also exacerbate some problems we already have with<br=
>
&gt; the HD Wallet lookahead, since we now skip a number of addresses, so<b=
r>
&gt; we should not require too many opt-in bits.<br>
&gt;<br>
&gt; So there are some problems we&#39;d need to tackle, but I&#39;m really=
<br>
&gt; excited<br>
&gt; about this, as it could provide data to make informed decisions, and<b=
r>
&gt; should put an end to the endless speculation about the will of the<br>
&gt; economic majority.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Christian<br>
&gt;<br>
&gt; [1] <a href=3D"http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.p=
df" rel=3D"noreferrer" target=3D"_blank">http://pub.tik.ee.ethz.ch/<wbr>stu=
dents/2015-HS/SA-2015-30.<wbr>pdf</a><br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">&gt; __________________=
____________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><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>
</div></div></blockquote></div><br></div>

--001a11c0342ae0c058054d9b6ef8--