[bitcoin-dev] Transaction signalling through output address hashing

[bitcoin-dev] Transaction signalling through output address hashing

[John Hardy]

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

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:

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 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

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

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

[Natanael]

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

Den 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:

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


Censorship by miners isn't the only problem. Existing and normal
transactions will probabilistically collide with these schemes, and most
wallets have no straightforward way of supporting it.

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

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

[John Hardy]

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

Probabilistic collisions, while present, would be statistically insignificant at 4 chars length.


Implementation by wallets would just require a loop of their existing address generation until a match is found, trivial to implement. Wallets could provide a dropdown which shows the most commonly used signals as seen on the block chain, or a write-in.

Signalling within OP_RETURN increases the tx size and cost. This address hashing method keeps the very small economic cost of voting off the chain, rather than passing it cumulatively to everyone with the insertion of additional data.


Since I wrote this I have come across a similar idea called CryptoVoter which I think deserves more attention than it has had.

________________________________
From: Natanael <natanael.l@gmail.com>
Sent: Sunday, February 5, 2017 4:22 PM
To: Bitcoin Dev; John Hardy
Subject: Re: [bitcoin-dev] Transaction signalling through output address hashing

Censorship by miners isn't the only problem. Existing and normal transactions will probabilistically collide with these schemes, and most wallets have no straightforward way of supporting it.

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

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

[Andrew C]

[-- 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 --]