From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8100B9FA for ; Sun, 5 Feb 2017 16:26:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0F0418F for ; Sun, 5 Feb 2017 16:26:25 +0000 (UTC) Received: by mail-qk0-f182.google.com with SMTP id u25so34906618qki.2 for ; Sun, 05 Feb 2017 08:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=f0WvALKzcm0YPZth9+QHxhUD2HT2a3uA31xrTdRs+ME=; b=GO485KWU9uIUqyZ6QGZPaM6EiYb8/vTBnHiB74H9C+MUvKNM5n63Ic8YHvOuE1Gt/n LI9Pcgcx4ePBE1T1V7n3jWN/1IULovQI3vmua7lE9/Y7R5W7oTuZY7wquSGfi8gcNIWO 3N/jjIcpLt8kjttOHlScBN7BDCnYImNF/IRMt+tNsf5P6yt44SOsaLCge1HQyY5YG1Bq Y4+YcqefP18hKcqNteixU+iYkcG/3Ln2q3gDUq1qM1VBFfJnF0PH6j96AHxJcnLuUSRa n2ekBK/GVrzRTi386yu4JAPFfpL0RoTcchiXHN9aE5IbK7TF4YAQcl7z9UaPPMy0hpBX 6zJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=f0WvALKzcm0YPZth9+QHxhUD2HT2a3uA31xrTdRs+ME=; b=hKHFFFslS8DTwIOpSUg169PJIPiziPcZFMTHKq1dRvCq/d6cUd8epLm9+kgrr2h2Db ngjJY7e2czOH4N64Bp7Y53eYgPXUPy+veKKYlddHMa0YwWSWKKU15AT49KNEQ7Ii87Lx uVosT8U4uKaiPwN+10CskrsDFTIFAEIn2/y+Kxm+Ya2PwDB4MrsnCUi9yAo/3esO/KP7 xmshjRLmIrDAgaHAxofgR4uxw68PcvF0vl+pEllyJEVw7K6VndOVQa1z8z2YAaHqFYYl +hKBkhqQsg53MDti29naZ9uHrZvcKaKjvb1enh4R6oG9nVc7cSw0w6PwSngQVdNHXeE4 +G8A== X-Gm-Message-State: AMke39n1UuQoqtDTdGTKo6nRVMYeTjfis/Z6IkgIC+wstplmIfkEh8WwCgrO6JtKz87AQw== X-Received: by 10.55.75.143 with SMTP id y137mr5647280qka.39.1486311984655; Sun, 05 Feb 2017 08:26:24 -0800 (PST) Received: from [192.168.1.6] ([129.2.206.150]) by smtp.gmail.com with ESMTPSA id w44sm30718967qta.4.2017.02.05.08.26.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 08:26:23 -0800 (PST) To: John Hardy , Bitcoin Protocol Discussion References: From: Andrew C Message-ID: Date: Sun, 5 Feb 2017 11:26:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------37867346B73C275CB709CC80" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,TRACKER_ID 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:26:26 -0000 This is a multi-part message in MIME format. --------------37867346B73C275CB709CC80 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Instead of using vanity addresses, the transactions could just use an OP_RETURN output and express the signalling there. However, such a system could be easily gamed by people who simply spam the network with transactions and by miners who choose what transactions to include in their blocks. On 2/2/2017 7:13 PM, John Hardy via bitcoin-dev wrote: > > 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. > > > The output address of a transaction could basically have the last 4 > characters used to signal support for a particular proposal. > > To generate an address with 4 consecutive case-insensitive characters > should be roughly 34^4 which is just over a million attempts. On > typical hardware this should take less than a second. > > An example bitcoin address that wanted to support the core roadmap > might be: > > 1CLNgjuu8s51umTA76Zi8v6EdvDp8q*CorE* > > > or to signal support for a big block proposal might be: > > 1N62SRhBioRFrigS5eJ8kR1WYcfcYr*16mB* > > > Popularity could be measured weighted by fee paid per voting kb. > > > Issues are that this could lead to transactions been censored by > particular miners for political reasons. Also miners might attempt to > manipulate the results by stuffing their block with 'fake' > transactions. Such attempts could be identified if a large number of > voting transactions were not in the mempool. > > > Despite the limitations, I believe this offers a very accessible way > to immediately allow the entire economic community to signal their > support within transactions. The only cost is that of a tiny hashing > PoW that should tie up a CPU for a barely noticeable amount of time, > and could be implemented relatively easily into wallet software. > > > For its weaknesses, surely it is better than the existing methods we > use to assess support from the wider economic community? > > > While it could just be used for signaling support and giving users a > 'voice' on chain, if considered effective it could also be used to > activate changes in the future. > > > Any thoughts welcome. > > > Thanks, > > > John Hardy > > john@seebitcoin.com > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------37867346B73C275CB709CC80 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Instead of using vanity addresses, the transactions could just use an OP_RETURN output and express the signalling there.


However, such a system could be easily gamed by people who simply spam the network with transactions and by miners who choose what transactions to include in their blocks.


On 2/2/2017 7:13 PM, John Hardy via bitcoin-dev wrote:

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.


The output address of a transaction could basically have the last 4 characters used to signal support for a particular proposal.

To generate an address with 4 consecutive case-insensitive characters should be roughly 34^4 which is just over a million attempts. On typical hardware this should take less than a second.

An example bitcoin address that wanted to support the core roadmap might be:

1CLNgjuu8s51umTA76Zi8v6EdvDp8qCorE


or to signal support for a big block proposal might be:

1N62SRhBioRFrigS5eJ8kR1WYcfcYr16mB


Popularity could be measured weighted by fee paid per voting kb.


Issues are that this could lead to transactions been censored by particular miners for political reasons. Also miners might attempt to manipulate the results by stuffing their block with 'fake' transactions. Such attempts could be identified if a large number of voting transactions were not in the mempool.


Despite the limitations, I believe this offers a very accessible way to immediately allow the entire economic community to signal their support within transactions. The only cost is that of a tiny hashing PoW that should tie up a CPU for a barely noticeable amount of time, and could be implemented relatively easily into wallet software.


For its weaknesses, surely it is better than the existing methods we use to assess support from the wider economic community?


While it could just be used for signaling support and giving users a 'voice' on chain, if considered effective it could also be used to activate changes in the future.


Any thoughts welcome.


Thanks,


John Hardy

john@seebitcoin.com



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------37867346B73C275CB709CC80--