Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 15BAF486 for ; Sun, 5 Feb 2017 16:22:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.161.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B60E3185 for ; Sun, 5 Feb 2017 16:22:13 +0000 (UTC) Received: by mail-yw0-f177.google.com with SMTP id u68so37598054ywg.0 for ; Sun, 05 Feb 2017 08:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mizrn+G9efcl7cKC74MT7nIHbBEDrGfeTV4KfSrLQNk=; b=qgtMDTbM0up2QPszjf4AvG4xgULSDvVkdhLq1C8M/wuRyp1fAOzdIojRwLqAQFk/ci whSvEZqeVjcTi+lkFs/9dmi9/u6yC3gqOg5Y2n/PDPCA4EimviEnqBfJYMQq1I64ZN9u 7LlVSx1vuX+UHQFb0FaNW9ui06wp+QMVVQC9iAWbtoi2NtDUFZ7lDT2H4TBBesJW1qfz W7zGmq1fs4pjg9V2dyeYijVyHiM7jRkqo3kYdNDW3Z+mVxNyKhLzqRq86LtguvSmRvQE 48TUSL+Q9Dn7Ajdt5Q91u2fKBJQBmlJgJa6abR5I4YTp9USHyb9XGHPInww20TQOycIz iqBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mizrn+G9efcl7cKC74MT7nIHbBEDrGfeTV4KfSrLQNk=; b=IQUZAYwlPIyQPQ2OUCyNt+uX5O6d3Zs4stNKJ9AP3TWTxyHirkFRAXaCJTskYus3wn lkpBiavFROTA+16EvxiXGC/TnGA6Yb+BiBvvNn6VQ7sVV2jKE+va9+BbblDQetmUTktt gokc4rtuAU3ZVS/6bmxOQalECqHbK+1z5aWnI5JpBkLdS8ULStx+yZHezLxSaIVGM+X5 YhB33nOT1S/Fo6mnsI5utWwp2jziDmnptIYTBRHAvNPPyYBzl4NLVRUaiUL63safMku4 c6Zcj90WAClZl0yiOTxag070qnwr/xfbhO5SbBO0jsbzEhWWCuPyz5EYEAsYvZP/VMmt oZkg== X-Gm-Message-State: AMke39njUPbRr/8u9qwm1CHc3r0EUVCFduHKndi6ByxDD36pMKILFMBFEiJVxWuyqnObuFRtj87zzjRfxkansA== X-Received: by 10.13.232.83 with SMTP id r80mr4956819ywe.101.1486311732827; Sun, 05 Feb 2017 08:22:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.75.67 with HTTP; Sun, 5 Feb 2017 08:22:11 -0800 (PST) Received: by 10.37.75.67 with HTTP; Sun, 5 Feb 2017 08:22:11 -0800 (PST) In-Reply-To: References: From: Natanael Date: Sun, 5 Feb 2017 17:22:11 +0100 Message-ID: To: Bitcoin Dev , John Hardy Content-Type: multipart/alternative; boundary=94eb2c084140dc78bc0547caeabf X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 Subject: Re: [bitcoin-dev] Transaction signalling through output address hashing 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: Sun, 05 Feb 2017 16:22:14 -0000 --94eb2c084140dc78bc0547caeabf Content-Type: text/plain; charset=UTF-8 Den 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Currently in order to signal support for changes to Bitcoin, only miners are able to do so on the blockchain through BIP9. One criticism is that the rest of the community is not able to participate in consensus, and other methods of assessing community support are fuzzy and easily manipulated through Sybil. I was trying to think if there was a way community support could be signaled through transactions without requiring a hard fork, and without increasing the size of transactions at all. My solution is basically inspired by hashcash and vanity addresses Censorship by miners isn't the only problem. Existing and normal transactions will probabilistically collide with these schemes, and most wallets have no straightforward way of supporting it. --94eb2c084140dc78bc0547caeabf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
De= n 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" <bitcoin-dev@lists.linuxf= oundation.org>:

Currently in order to signal support for changes to Bitcoin, only miners= are able to do so on the blockchain through BIP9.

One criticism is that the rest of the community is not able to participa= te in consensus, and other methods of assessing community support are fuzzy= and easily manipulated through Sybil.

I was trying to think if there was a way community support could be sign= aled through transactions without requiring a hard fork, and without increa= sing the size of transactions at all.

My solution is basically inspired by hashcash and vanity addresses


Censorship by miners isn't the only problem. Existing and normal = transactions will probabilistically collide with these schemes, and most wa= llets have no straightforward way of supporting it.=C2=A0
--94eb2c084140dc78bc0547caeabf--