public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      parent reply	other threads:[~2017-02-05 16:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03  0:13 [bitcoin-dev] Transaction signalling through output address hashing John Hardy
2017-02-05 16:22 ` Natanael
     [not found]   ` <BL2PR03MB435D7E36434A342BBEBC735EE410@BL2PR03MB435.namprd03.prod.outlook.com>
2017-02-05 21:06     ` [bitcoin-dev] Fw: " John Hardy
2017-02-05 16:26 ` Andrew C [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5648b1d-b18d-c82c-8bb7-6ed9139c0a9f@gmail.com \
    --to=achow101@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=john@seebitcoin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox