diff options
author | Andrew C <achow101@gmail.com> | 2017-02-05 11:26:30 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-02-05 16:26:26 +0000 |
commit | 449e5c5c67f139640bd49ba0ec305072bdeb751c (patch) | |
tree | 616f978cec65a8a9e9ff2b54c7895bcc040bf020 | |
parent | e4cf478bb78ba3f1a3f17c746fe67cfec5be8a27 (diff) | |
download | pi-bitcoindev-449e5c5c67f139640bd49ba0ec305072bdeb751c.tar.gz pi-bitcoindev-449e5c5c67f139640bd49ba0ec305072bdeb751c.zip |
Re: [bitcoin-dev] Transaction signalling through output address hashing
-rw-r--r-- | 9c/ec6a88b8e3f66d003c0f4cf71a4e91a7097ab5 | 302 |
1 files changed, 302 insertions, 0 deletions
diff --git a/9c/ec6a88b8e3f66d003c0f4cf71a4e91a7097ab5 b/9c/ec6a88b8e3f66d003c0f4cf71a4e91a7097ab5 new file mode 100644 index 000000000..9afe7ddbe --- /dev/null +++ b/9c/ec6a88b8e3f66d003c0f4cf71a4e91a7097ab5 @@ -0,0 +1,302 @@ +Return-Path: <achow101@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 8100B9FA + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 5 Feb 2017 16:26:25 +0000 (UTC) +Received: by mail-qk0-f182.google.com with SMTP id u25so34906618qki.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <john@seebitcoin.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +References: <BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0@BL2PR03MB435.namprd03.prod.outlook.com> +From: Andrew C <achow101@gmail.com> +Message-ID: <b5648b1d-b18d-c82c-8bb7-6ed9139c0a9f@gmail.com> +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: <BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0@BL2PR03MB435.namprd03.prod.outlook.com> +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 <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, 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 + +<html> + <head> + <meta content="text/html; charset=windows-1252" + http-equiv="Content-Type"> + </head> + <body bgcolor="#FFFFFF" text="#000000"> + <p>Instead of using vanity addresses, the transactions could just + use an OP_RETURN output and express the signalling there.</p> + <p><br> + </p> + <p>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.<br> + </p> + <br> + <div class="moz-cite-prefix">On 2/2/2017 7:13 PM, John Hardy via + bitcoin-dev wrote:<br> + </div> + <blockquote +cite="mid:BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0@BL2PR03MB435.namprd03.prod.outlook.com" + type="cite"> + <meta http-equiv="Content-Type" content="text/html; + charset=windows-1252"> + <style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style> + <div id="divtagdefaultwrapper" +style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" + dir="ltr"> + <p>Currently in order to signal support for changes to Bitcoin, + only miners are able to do so on the blockchain through BIP9.</p> + <p><br> + </p> + <p>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.</p> + <p><br> + </p> + <p>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.</p> + <p><br> + </p> + <p>My solution is basically inspired by hashcash and vanity + addresses.</p> + <p><br> + </p> + <p>The output address of a transaction could basically have the + last 4 characters used<span style="font-size: 12pt;">�to + signal support for a particular proposal.<br> + <br> + 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.<br> + <br> + An example bitcoin address that wanted to support the core + roadmap might be:</span></p> + <p><span style="font-size: 12pt;"><span><span + style="font-family: monospace; font-size: 14.625px;">1CLNgjuu8s51umTA76Zi8v6EdvDp8q<b>CorE</b></span></span><br> + </span></p> + <p><br> + </p> + <p>or to signal support for a big block proposal might be:</p> + <p><span style="font-family: monospace; font-size: 14.625px;">1N62SRhBioRFrigS5eJ8kR1WYcfcYr<b>16mB</b></span></p> + <p><br> + </p> + <div><span style="font-family: Calibri, Arial, Helvetica, + sans-serif, "Apple Color Emoji", "Segoe UI + Emoji", NotoColorEmoji, "Segoe UI Symbol", + "Android Emoji", EmojiSymbols; font-size: 16px;">Popularity + could be measured weighted by�</span>fee<span + style="font-family: Calibri, Arial, Helvetica, sans-serif, + "Apple Color Emoji", "Segoe UI Emoji", + NotoColorEmoji, "Segoe UI Symbol", "Android + Emoji", EmojiSymbols; font-size: 16px;">�paid per + voting kb.</span></div> + <p><br> + </p> + <p>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.</p> + <p><br> + </p> + <p>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.</p> + <p><br> + </p> + <p>For its weaknesses, surely it is better than the existing + methods we use to assess support from the wider economic + community?</p> + <p><br> + </p> + <p>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.</p> + <p><br> + </p> + <p>Any thoughts welcome.</p> + <p><br> + </p> + <p>Thanks,</p> + <p><br> + </p> + <p>John Hardy</p> + <p><a class="moz-txt-link-abbreviated" href="mailto:john@seebitcoin.com">john@seebitcoin.com</a></p> + </div> + <br> + <fieldset class="mimeAttachmentHeader"></fieldset> + <br> + <pre wrap="">_______________________________________________ +bitcoin-dev mailing list +<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> +<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> +</pre> + </blockquote> + <br> + </body> +</html> + +--------------37867346B73C275CB709CC80-- + |