summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew C <achow101@gmail.com>2017-02-05 11:26:30 -0500
committerbitcoindev <bitcoindev@gnusha.org>2017-02-05 16:26:26 +0000
commit449e5c5c67f139640bd49ba0ec305072bdeb751c (patch)
tree616f978cec65a8a9e9ff2b54c7895bcc040bf020
parente4cf478bb78ba3f1a3f17c746fe67cfec5be8a27 (diff)
downloadpi-bitcoindev-449e5c5c67f139640bd49ba0ec305072bdeb751c.tar.gz
pi-bitcoindev-449e5c5c67f139640bd49ba0ec305072bdeb751c.zip
Re: [bitcoin-dev] Transaction signalling through output address hashing
-rw-r--r--9c/ec6a88b8e3f66d003c0f4cf71a4e91a7097ab5302
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, &quot;Apple Color Emoji&quot;, &quot;Segoe UI
+ Emoji&quot;, NotoColorEmoji, &quot;Segoe UI Symbol&quot;,
+ &quot;Android Emoji&quot;, EmojiSymbols; font-size: 16px;">Popularity
+ could be measured weighted by�</span>fee<span
+ style="font-family: Calibri, Arial, Helvetica, sans-serif,
+ &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;,
+ NotoColorEmoji, &quot;Segoe UI Symbol&quot;, &quot;Android
+ Emoji&quot;, 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--
+