public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: AJ West <ajwest@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
Date: Mon, 27 Mar 2017 12:29:20 -0400	[thread overview]
Message-ID: <CABXVU6ZRBBcPVjEcCRjhSNsgPmWrHWnmcWLOYVDjRdQYN2QTiQ@mail.gmail.com> (raw)

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

Hi I'm AJ West, I made a service http://preferredminer.com which is a
proof-of-concept project designed to spur discussion on exactly this issue
of "miners as service providers."

The current status is that Bitcoin end users are looking to support
specific miners, whether that's because they agree with a miner/pool's
political positions, their consensus ideology, physical location (yes some
people would like only miners in particular countries to mine their
transactions) and the list of reasons goes on. The main attitude right now
is that people would like to 'support' miners who signal for the features
they care about.

I strongly believe, whether the Bitcoin developer community facilitates it
or not, certain miners will become preferred by users. In summary, there
are realistically two proposed ways of providing this service in the
present-day situation: 1) By creating 'segregated mempools' where an
authenticated third-party like my web service Preferred Miner manages the
access to pending transactions destined for a specific set of miners, and
2) by creating transactions where the mining fee is in one way or another,
an output to an address owned by the preferred miner(s).

There are some terrible pitfalls with both of these methods. The first
being that you have to trust a lot of people, including the 3rd party (me)
and the pools to work in your users' interest ("don't give my transactions
to other miners or broadcast to mempool please"). Then there are the extra
fees users will have to pay to offset the risk of a miner losing out for
having to send the network a not-yet-broadcasted transaction. And finally,
the other method requires that they be larger transactions, and a directory
of mining pools' receiving addresses for outputs must be maintained. Then
you have to hope the miner will be setup to scoop in your transaction
knowing it's got a fee for them. Plus, how many nodes going forward are
going to hold what seem to be 0-fee transactions in mempool (because the
fee is in the outputs)?

I am not necessarily looking for answers or solutions to these issues, but
simply to show a case and to express that this idea of having specific
miners/pools process their transactions, is important to some people.

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

             reply	other threads:[~2017-03-27 16:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 16:29 AJ West [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-03-28 12:58 [bitcoin-dev] Inquiry: Transaction Tiering Martin Stolze
2017-03-28 14:57 ` Andrew Baine
2017-03-29 12:51   ` Martin Stolze
2017-03-22 17:48 Martin Stolze
2017-03-25  4:42 ` praxeology_guy
2017-03-25 17:15   ` Martin Stolze
2017-03-26 11:12     ` praxeology_guy
2017-03-26 12:11     ` greg misiorek
2017-03-27 17:18       ` Martin Stolze
     [not found]     ` <fFz3k0NstFYpKctCaSKDrhPnkInjW3GgQ-3FIyokzdl_SScKjXptQsn8jnW71ax_oknq9hI8gUBllYaKo_9hMiBASSJtkL6xXN_NX8tcmXw=@protonmail.com>
2017-03-27 21:11       ` Martin Stolze
2017-03-28  7:02         ` praxeology_guy
2017-03-28 19:51           ` Martin Stolze
2017-03-20 20:12 Martin Stolze
2017-03-21 15:18 ` Tim Ruffing
2017-03-29  9:04 ` Tom Zander
2017-03-29 12:48   ` Martin Stolze
2017-03-29 13:10     ` Tom Zander

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=CABXVU6ZRBBcPVjEcCRjhSNsgPmWrHWnmcWLOYVDjRdQYN2QTiQ@mail.gmail.com \
    --to=ajwest@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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