public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Martin Stolze <martin@stolze.cc>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Inquiry: Transaction Tiering
Date: Mon, 20 Mar 2017 20:12:36 +0000	[thread overview]
Message-ID: <CAOyfL0oQrHzDmHBnWo0pTdbVU7acnsLmikTh9NU_u6HnhT4VCw@mail.gmail.com> (raw)

Hi Team,
I would like to find out what the current consensus on transaction tiering is.

Background: The current protocol enables two parties to transact
freely, however, transaction processors (block generators) have the
authority to discriminate participants arbitrarily. This is well known
and it is widely accepted that transaction processors may take
advantage of this with little recourse. It is the current consensus
that the economic incentives in form of transaction fees are
sufficient because the transaction processing authorities are assumed
to be guided by the growth of Bitcoin and the pursuit of profit.

We can establish that a transaction processing authority does not need
to actually process transactions and reigns sovereign over the block
space they govern. [1] For further discussion I will refer to a
transaction processor more aptly as "Block Space Authority" (BSA).

Currently, a user can only signal to all BSA’s (via the mempool) its
desire to include her transaction into the ledger. A user can not
signal to specific BSA’s, and thus, can not easily carry out business
in jurisdictions that conform to the users understanding of best
practice.

As a participant in the economy in general and of Bitcoin in
particular, I desire an ability to decide where I transact. The
current state of Bitcoin does not allow me to choose my place of
business. As a consequence, I try to learn what would be the best way
to conduct my business in good faith. [2]

I have certain minimum requirements towards the constitution of the
block space like transparency, forward guidance and risk management.
More poignantly, it could also include due diligence to ensure that
child labor is not involved in the maintenance of a specific block
space, or that the specific block space does not utilize nuclear
energy or sources at least 80% of the expended energy from solar
power. Obviously, preferences can vary widely.

I don’t think there is any way to discard the desire of users to
choose their place of business, especially under the consideration
that BSA’s have the discretion to choose users transactions already.
I have identified the following options along the lines of Lawrence
Lessig's concept of Cyberspace: [3]

1. Law: Bilateral Agreement

Users engage directly with BSA’s to process their transaction.
Transactions are routed around the mempool. A likely outcome of this
solution is the emergence of brokers that sell off block space in a
sort of secondary market. Wallets may negotiate on behalf of their
users. This model has obvious downsides as it involves new middlemen,
increases transaction cost beyond the current market price
(speculation) and potentially reduces performance.

2. Architecture: Remove transaction fees

If only the block reward functions to incentivise transaction
processing, no differentiation is useful. However, spam/empty blocks
could not be prevented and Bitcoin would have to be entirely
redesigned, potentially losing its censorship resistance.

3. Market: Direct Communication

Through the core client, BSA’s can offer individual mempools that
users can choose to advertise their transactions to. Different BSA’s
could receive different transaction fees for the same transaction in
their respective mempool to reflect the preference of the user.

In Conclusion: In the long term, it is likely that a clearer
differentiation of BSA’s will become important. Today, BSA’s
communicate rarely and it appears that their raison d'etre is not
necessarily motivated by good faith towards Bitcoin as a whole. [4] As
we move forward it is not just important to attract opportunistic
players that win an individual game but good players that are invited
to play again in order to win a set of all possible games.

BSA’s establish their authority on cheap access to capital in the form
of electricity and hardware and the consent and trust of users who
expect BSA's to respect and maintain the ledgers integrity.

In 3 to 8 years, when Bitcoin leaves it’s bootstrapping phase, the
incentives will squarely fall on the later. [5] Subsequently it seems
prudent to allow BSA’s to compete for business on other factors than
price.

Hence my question: What is the current stance of core developers
regarding the facilitation of direct communication between users and
BSA’s, possibly through a transaction tiering model?

Sincerely,
Martin Stolze

[1] BSA rules sovereign: (https://twitter.com/JihanWu/status/704476839566135298)
[2] No direct attribution but solid foundation for business logic
since 1899: §242 ff BGB
(https://www.gesetze-im-internet.de/englisch_bgb/englisch_bgb.html#p0726)
[3] Lessig, Code. "And Other Laws of Cyberspace, Version 2.0." (2006).
[4] The pursuit of profit can come at the expense of Bitcoin:
(https://twitter.com/ToneVays/status/835233366203072513)
[5] Satoshi Nakamoto: "Once a predetermined number of coins have
entered circulation, the incentive can transition entirely to
transaction fees [...]"


             reply	other threads:[~2017-03-20 20:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20 20:12 Martin Stolze [this message]
2017-03-21 15:18 ` [bitcoin-dev] Inquiry: Transaction Tiering Tim Ruffing
2017-03-29  9:04 ` Tom Zander
2017-03-29 12:48   ` Martin Stolze
2017-03-29 13:10     ` Tom Zander
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-27 16:29 AJ West
2017-03-28 12:58 Martin Stolze
2017-03-28 14:57 ` Andrew Baine
2017-03-29 12:51   ` Martin Stolze

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=CAOyfL0oQrHzDmHBnWo0pTdbVU7acnsLmikTh9NU_u6HnhT4VCw@mail.gmail.com \
    --to=martin@stolze.cc \
    --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