Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AD33F94F for ; Tue, 18 Apr 2017 18:01:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 00F2924F for ; Tue, 18 Apr 2017 18:01:53 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id f133so531209qke.2 for ; Tue, 18 Apr 2017 11:01:53 -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=9cDE2yRdeXOLJgZT3K0kDP2yaOiC3Z8kbCoIBV5+65Y=; b=TbY7iVx3LCGKv9PP+Z53TLRsuwQkSYswuSNz7gkUIde2kkeLdd3Q+8pt2SIRCjoazM 4id4b0nOLVRfEYGNLWZnruloaJ/5jN7srefazoI29HMn44CsppXt+pjZZSM60p8Yw7ky NOgiRpgt72sIKoHLi6Yh0498cdQWN/4ihutR+fAUDVWIwsU18HVLkOfZf+jO9O5ZiT14 0dN3nr5iNXMJR1E7xPKjL9aloXycdos9d+bj42I6iI3W9T5LHAjKQ1NBoynG/Sgs4E3G 4WUYTHSd+G6dVYn+sYQmlLIBzUlLeCsKNHJovc/242zH4X0O3lzPD7WQDT03eYwbX6Gs Ewuw== 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=9cDE2yRdeXOLJgZT3K0kDP2yaOiC3Z8kbCoIBV5+65Y=; b=P9yqb+8w3wD+sHI9UHCcIGVZEyL1kZxXnRWcmJjwXoFYlotJDAbcckAlwpQjhTyco5 O6kLaa69J1iCIJobhSFVJyrtPiCA6WV1iVeEIlAMLoAzntj7i+7tKDCpgQx2Jat71vBg f/p3s2xmb95shQyYVmuRks4tYXB+bRaRAVBZPtIri2V4S2n63x49Gy/SbuqKa1zFISzZ /70MAuYWIdwyutfzuYx7Akcabm8V9bpHDfpoB4HB7Z3sqmHbbZWn2+o7QqRIo1yYPOf/ X3wDKw2HY/loRLE5tB2z/ck5h2aZ6Us3EbeM4/r7ecxcEvdnMroFuzhpFV6z+r4/srl4 chug== X-Gm-Message-State: AN3rC/5UXsWb2as44ufzRTj60QppkMoMxbfi3DkqmzvL7eVt3OYLxF2B KQvS4/h//hEDIzAJ5OKIKeEbXmF++ZJk X-Received: by 10.55.168.198 with SMTP id r189mr16410814qke.228.1492538513091; Tue, 18 Apr 2017 11:01:53 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.200.0.146 with HTTP; Tue, 18 Apr 2017 11:01:52 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Tue, 18 Apr 2017 14:01:52 -0400 X-Google-Sender-Auth: uTPCgT9qsP0usozdDKHamhEpduM Message-ID: To: Marcel Jamin Content-Type: multipart/alternative; boundary=001a114fe8f6e2f3f2054d74b39b X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 X-Mailman-Approved-At: Tue, 18 Apr 2017 18:02:24 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:01:54 -0000 --001a114fe8f6e2f3f2054d74b39b Content-Type: text/plain; charset=UTF-8 Just to be clear, the tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. Major exchanges will regularly tag massive amounts of Bitcoins with their capabilities. Just adding a nice bit-field and a tagging standard, and then charting it might be enough to "think about how to use it later". The only problem would be that this would interfere with "other uses of op_return" ... colored coins, etc. Personally, I think that's OK, since the purpose is to tag economically meaningful nodes to the Bitcoin ecosystem and colored coins, by definition, only have value to "other ecosystems". (Counterargument: Suppose in some future where this is used as an alternative to BIP9 for a user-coordinated code release - especially in situations where miners have rejected activation of a widely-regarded proposal. Suppose also, in that future, colored coin ICO's that use op-return are regularly used to float the shares of major corporation. It might be irresponsible to exclude them from coordinating protocol changes.) On Tue, Apr 18, 2017 at 10:52 AM, Marcel Jamin wrote: > Probably a bad idea for various reasons, but tagging (fee paying) > transactions with info about the capabilities of the node that created > it might be interesting? Might be useful to gauge economic support for > certain upgrades, especially if excluding long transaction chains, > etc. In the very least it would be a far better indicator than simply > counting reachable nodes. > > On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev > wrote: > > If users added a signal to OP_RETURN, might it be possible to tag all > > validated input addresses with that signal. > > > > Then a node can activate a new feature after the percentage of tagged > input > > addresses reaches a certain level within a certain period of time? > > > > This could be used in addition to a flag day to trigger activation of a > > feature with some reassurance of user uptake. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --001a114fe8f6e2f3f2054d74b39b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to be clear, the tagging would occur on the= addresses, and the weighting would be by value, so it's a measure of e= conomic significance.=C2=A0=C2=A0 Major exchanges will regularly tag massiv= e amounts of Bitcoins with their capabilities.

Just adding a n= ice bit-field and a tagging standard, and then charting it might be enough = to "think about how to use it later".=C2=A0=C2=A0 The only proble= m would be that this would interfere with "other uses of op_return&quo= t; ... colored coins, etc.=C2=A0=C2=A0

Personally, I think that'= ;s OK, since the purpose is to tag economically meaningful nodes to the Bit= coin ecosystem and colored coins, by definition, only have value to "o= ther ecosystems".

(Counterargument: Suppose in some futur= e where this is used as an alternative to BIP9 for a user-coordinated code = release - especially in situations where miners have rejected activation of= a widely-regarded proposal.=C2=A0 Suppose also, in that future, colored co= in ICO's that use op-return are regularly used to float the shares of m= ajor corporation.=C2=A0 It might be irresponsible to exclude them from coor= dinating protocol changes.)





On Tue, Apr 18, 2017 at 10:= 52 AM, Marcel Jamin <marcel@jamin.net> wrote:
Probably a bad idea for variou= s reasons, but tagging (fee paying)
transactions with info about the capabilities of the node that created
it might be interesting? Might be useful to gauge economic support for
certain upgrades, especially if excluding long transaction chains,
etc. In the very least it would be a far better indicator than simply
counting reachable nodes.

On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> If users added a signal= to OP_RETURN, might it be possible to tag all
> validated input addresses with that signal.
>
> Then a node can activate a new feature after the percentage of tagged = input
> addresses reaches a certain level within a certain period of time?
>
> This could be used in addition to a flag day to trigger activation of = a
> feature with some reassurance of user uptake.
>
>
>
>
>
>
>
>
>
> __________________= _____________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a114fe8f6e2f3f2054d74b39b--