Re: [bitcoin-dev] Transaction signalling through output address hashing

From: Andrew C <achow101@gmail•com>
To: John Hardy <john@seebitcoin•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction signalling through output address hashing
Date: Sun, 5 Feb 2017 11:26:30 -0500	[thread overview]
Message-ID: <b5648b1d-b18d-c82c-8bb7-6ed9139c0a9f@gmail.com> (raw)
In-Reply-To: <BL2PR03MB4358286BE7F0D51F99B8EC6EE4C0@BL2PR03MB435.namprd03.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5675 bytes --]