From: John Hardy <john@seebitcoin.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: Transaction signalling through output address hashing
Thread-Index: AQHSfbGZvr4KI3DKIEKafV3UKQG/og==
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Fri, 3 Feb 2017 00:13:04 +0000
Message-ID: <BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0@BL2PR03MB435.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [/dpYCdl3D7pS1GinXFeQ8DqrCrhH5l1C]
x-incomingheadercount: 38
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; BY2NAM01HT067;
	5:sj/eGfDehG0kJHRmpsU722lwlgKONvDYTcEcw6w9I6qcrI8uj8lAkpBST7UU8H990gROVCEPQ2kbD20MBEHj9gl/3hYsxCA+ss0HNXy6iTFnIhBCyXWxlnbIYDhRuDvalW7HsdUjV2algJUi+kh9Fg==;
	24:KW8CfhLXnOeJizY0FAKw2llX5hYM6rQ+KGpQXRSG+1eGMr5ygjBPVndm4QMd02NdSGrHobB9nL2Hbx34aIQSx+KB2bf+94uCGv0cc1BP9ks=;
	7:79GEWiH9uiBggktJA8LTOgwdY0RqX9j2h27fIGS0gVSc/zTSfcfnHmxhz44YRFSlWDh2qrnzqVWUp1ZQeHdI8YZVi2MNiRSVogK9sNsDkpCZF4r9Yhv8uMGo71P+z6hORTHn8qbWFgjZbSAtKYzrFKagIk8NpFofwlUSFdUbpllkeq9PzfheDVdGQ3PsIYDHuNp4QIt3aOFUiVqBDmN2GLWT4BG8eEqrxjkeAGUtRAVDKfzodZvIXkC+A2sPDg4dZhKSuR/AXbE+1aqxIMhJWX1RW1qTnV81z/DRlBY0RBKX7jH4VYFOc8hnn0XR45g0Ynqy9etWFHLw62PZxZXcNRmxtyFEQ1Ow3sJeSIi71+fIZDAAhczCz7/HRysl0WL4HhColQdBaFUFvU974r+M4N3+dQmfY5z9S4yVeGtCEsTStJ5eDusOzYmirA0BRi0BrjvpeVoOQKD8SM9MUTR/KBlxsUnk4Oab6zjFQ/vIY9MmzDWtfFkSmfEkWkq2XrjCi2/xyRtSPOQ0rcLQpEroKg==
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900005);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY2NAM01HT067;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 8e81153c-b516-4c90-b730-08d44bc96cfd
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(1601124038)(5061506426)(5061507331)(1603103135)(1603101370)(1601125107)(1701031045);
	SRVR:BY2NAM01HT067; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(444111334)(432015062)(82015046); SRVR:BY2NAM01HT067;
	BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT067; 
x-forefront-prvs: 02070414A1
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 00:13:04.9164 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT067
X-OriginalArrivalTime: 03 Feb 2017 00:13:07.0788 (UTC)
	FILETIME=[4BE168C0:01D27DB2]
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW,TRACKER_ID 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: Sun, 05 Feb 2017 15:32:56 +0000
Subject: [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: Fri, 03 Feb 2017 00:13:09 -0000

--_000_BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0BL2PR03MB435namprd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Currently in order to signal support for changes to Bitcoin, only miners ar=
e 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 an=
d easily manipulated through Sybil.


I was trying to think if there was a way community support could be signale=
d through transactions without requiring a hard fork, and without increasin=
g 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 charact=
ers used to signal support for a particular proposal.

To generate an address with 4 consecutive case-insensitive characters shoul=
d be roughly 34^4 which is just over a million attempts. On typical hardwar=
e 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 cou=
ld be identified if a large number of voting transactions were not in the m=
empool.


Despite the limitations, I believe this offers a very accessible way to imm=
ediately 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 r=
elatively 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 chang=
es in the future.


Any thoughts welcome.


Thanks,


John Hardy

john@seebitcoin.com

--_000_BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0BL2PR03MB435namprd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"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 participa=
te 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 sign=
aled through transactions without requiring a hard fork, and without increa=
sing 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 char=
acters used<span style=3D"font-size: 12pt;">&nbsp;to signal support for a p=
articular proposal.<br>
<br>
To generate an address with 4 consecutive case-insensitive characters shoul=
d be roughly 34^4 which is just over a million attempts. On typical hardwar=
e 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=3D"font-size: 12pt;"><span><span style=3D"font-family: monos=
pace; 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=3D"font-family: monospace; font-size: 14.625px;">1N62SRhBioR=
FrigS5eJ8kR1WYcfcYr<b>16mB</b></span></p>
<p><br>
</p>
<p></p>
<div><span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif, &qu=
ot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, NotoColorEmoji, &qu=
ot;Segoe UI Symbol&quot;, &quot;Android Emoji&quot;, EmojiSymbols; font-siz=
e: 16px;">Popularity could be measured weighted by&nbsp;</span>fee<span sty=
le=3D"font-family: Calibri, Arial, Helvetica, sans-serif, &quot;Apple Color=
 Emoji&quot;, &quot;Segoe UI Emoji&quot;, NotoColorEmoji, &quot;Segoe UI Sy=
mbol&quot;, &quot;Android Emoji&quot;, EmojiSymbols; font-size: 16px;">&nbs=
p;paid
 per voting kb.</span></div>
<p></p>
<p><br>
</p>
<p>Issues are that this could lead to transactions been censored by particu=
lar miners for political reasons. Also miners might attempt to manipulate t=
he 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></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 wit=
hin transactions. The only cost is that of a tiny hashing PoW that should t=
ie up a CPU for a barely noticeable
 amount of time, and could be implemented relatively easily into wallet sof=
tware.</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 'vo=
ice' on chain, if considered effective it could also be used to activate ch=
anges 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>john@seebitcoin.com</p>
</div>
</body>
</html>

--_000_BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0BL2PR03MB435namprd_--