public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christian Decker <decker.christian@gmail.com>
To: Erik Aronesty <erik@q32.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction signalling
Date: Tue, 18 Apr 2017 18:07:25 +0000	[thread overview]
Message-ID: <CALxbBHVY6_Xuq4Si9yQ0+dL_9DTCdwiWLDFStzFO2xRvHzTyBQ@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgKEVxS9OCg=Lioc1gRAy1Ftc27bp3nr2R9MQX-VQ9PrhQ@mail.gmail.com>

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

I really like the idea of extending signalling capabilities to the
end-users. It gives stakeholders a voice in the decisions we take in
the network, and are a clear signal to all other involved parties. It
reminds me of a student thesis I supervised some time ago [1], in
which we explored various signalling ideas.

I think we have a number of fields that may be used for such a
signalling, e.g., OP_RETURN, locktime, and output scripts. I think
OP_RETURN is probably not the field you'd want to use though since it
adds data that needs to be transferred, stored for bootstrap, and
outputs in the UTXO would need to be tagged with additional
information. Locktime has the advantage of being mostly a freeform
field for values in the past, but it clashes with other uses that may
rely on it. Furthermore, it is the transaction creator that specifies
the locktime, hence the signal trails one hop behind the current
owner, i.e., the actual stakeholder.

I think probably the best field to signal would be the output
script. It is specified by the recipient of the funds, i.e., the
current owner, and is already stored in the UTXO, so a single pass can
tally up the votes. We could for example use the last 4 bits of the
pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1
depending on the stakeholders desired signal). We'd need to define
similar semantics for other script types, but getting the standard
scripts to be recognized should be simple.

In the spirit of full disclosure I'd like to also mention some of the
downsides of voting this way. Unlike the OP_RETURN proposal, users
that do not intend to signal will also be included in the tally. I'd
expect the signals of these users to be random with a 50% chance of
either outcome, so they should not influence the final result, but may
muddy the water depending on what part of the population is
signalling. The opt-in should make sure that the majority of votes are
actually voluntary votes, and not just users that randomly select a
pubkey/pubkeyhash, and can be adjusted as desired, though higher
values require more grinding on behalf of the users.

The grinding may also exacerbate some problems we already have with
the HD Wallet lookahead, since we now skip a number of addresses, so
we should not require too many opt-in bits.

So there are some problems we'd need to tackle, but I'm really excited
about this, as it could provide data to make informed decisions, and
should put an end to the endless speculation about the will of the
economic majority.

Cheers,
Christian

[1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf

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

  parent reply	other threads:[~2017-04-18 18:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJowKgJ38kA_vPGF6KpKEnrRzStrk-Mj87bttaOw-dvLW675Jw@mail.gmail.com>
     [not found] ` <CAJowKgK4j=sL2vh1bxWh2WWw0vw1PuxfJ39JW7bQS-UDzKh6CQ@mail.gmail.com>
     [not found]   ` <CAJowKgKAnrMKiLdONrXJtGQYhYgRSXq7JNWrY=zUEMvw4WSX9w@mail.gmail.com>
     [not found]     ` <CAJowKgL-NB0zF-Ud52Jr6n0Fo-uV=bXzVAFMOKmhAVA0RdRVuQ@mail.gmail.com>
     [not found]       ` <CAJowKgJGZJMondTmsdOLdqqY1mf9S+TaB8UmdCtsLF6PA2RSJw@mail.gmail.com>
     [not found]         ` <CAJowKg+gZcNO+-sdmt55KOt+zuN+8m7Hiqh77s9=gYpyszDwmA@mail.gmail.com>
     [not found]           ` <CAJowKgKC4+6vv0QUH_DRASVqU4jui-iXG6TDgEpGUHRkVwJFqg@mail.gmail.com>
     [not found]             ` <CAJowKgKH2h1QwpEvZ30OuEUsTCg1OoD6JcuXdmS+d_pKpygFcQ@mail.gmail.com>
     [not found]               ` <CAJowKg+EJGXA5=LjJhCo1YevQtBubEftSNPfnzE4b5ESCwrUMg@mail.gmail.com>
     [not found]                 ` <CAJowKgLQCqL37oCzkJc8gPnUCkPYtF6G8_7Ug4AP5FpTOonBWQ@mail.gmail.com>
     [not found]                   ` <CAJowKgJ-eoF6ZCKrWbJQDcMK8-jTZxD+J_6tGAyfXz+HYrqmXg@mail.gmail.com>
2017-04-17 15:50                     ` [bitcoin-dev] Transaction signalling Erik Aronesty
2017-04-18 14:52                       ` Marcel Jamin
2017-04-18 18:01                         ` Erik Aronesty
2017-04-18 18:07                       ` Christian Decker [this message]
2017-04-18 22:29                         ` Tim Ruffing
2017-04-20 16:14                           ` Erik Aronesty
2017-05-03 19:41                             ` Erik Aronesty

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=CALxbBHVY6_Xuq4Si9yQ0+dL_9DTCdwiWLDFStzFO2xRvHzTyBQ@mail.gmail.com \
    --to=decker.christian@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=erik@q32.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