public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Inquiry: Transaction Tiering
@ 2017-03-20 20:12 Martin Stolze
  2017-03-21 15:18 ` Tim Ruffing
  2017-03-29  9:04 ` Tom Zander
  0 siblings, 2 replies; 18+ messages in thread
From: Martin Stolze @ 2017-03-20 20:12 UTC (permalink / raw)
  To: bitcoin-dev

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


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Inquiry: Transaction Tiering
@ 2017-03-22 17:48 Martin Stolze
  2017-03-25  4:42 ` praxeology_guy
  0 siblings, 1 reply; 18+ messages in thread
From: Martin Stolze @ 2017-03-22 17:48 UTC (permalink / raw)
  To: bitcoin-dev

Hi Tim,
After writing this I figured that it was probably not evident at first
sight as the concept may be quite novel. The physical location of the
"miner" is indeed irrelevant, I am referring to the digital location.
Bitcoins blockchain is a digital location or better digital "space".
As far as I am concerned the authority lies with whoever governs this
particular block space. A "miner" can, or can not, include my
transaction.

To make this more understandable:

Abu Bakr al-Baghdadi can extend his caliphate into Bitcoins block
space and rule sovereign(!) over a given block. If he processes my
transaction my fee goes directly into the coffers of his organization.
The same goes for the Queen of England or the Emperor of China. My
interest is not necessarily aligned with each specific authority, yet
as you point out, I can only not use Bitcoin.
Alternatively, however, I can very well sign my transaction and send
it to an authority of my choosing to be included into the ledger, say
BitFurry. - This is what I describe in option 1.

In order to protect my interest I do need to choose, maybe not today,
but eventually.

I also think that people do care who processes transactions and a lot
of bickering could be spared if we could choose.

If we assume a perfectly competitive market with 3 authorities that
govern the block space equally, the marginal cost of 1/3 of the block
space is the same for each, however, the marginal revenue absent of
block rewards is dependent on fees.
If people are willing to pay only a zero fee to a specific authority
while a fee greater than zero to the others it's clear that one would
be less competitive.

Let us assume the fees are 10% of the revenue and the cost is 95 we
have currently the following situation:

A: Cost=95; Revenue=100; Profit=5
B: Cost=95; Revenue=100; Profit=5
C: Cost=95; Revenue=100; Profit=5

With transaction tiering, the outcome could be different!

A: Cost=95; Revenue=90; Loss=5 // BSA that does not respect user interest.
B: Cost=95; Revenue=105; Profit=10
C: Cost=95; Revenue=105; Profit=10

This could motivate transaction processors to behave in accordance
with user interest, or am I missing something?

Best Regards,
Martin

> From: Tim Ruffing <tim.ruffing@mmci•uni-saarland.de>
> To: bitcoin-dev@lists•linuxfoundation.org
> Cc:
> Bcc:
> Date: Tue, 21 Mar 2017 16:18:26 +0100
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> (I'm not a lawyer...)
>
> I'm not sure if I can make sense of your email.
>
> On Mon, 2017-03-20 at 20:12 +0000, Martin Stolze via bitcoin-dev wrote:
>> 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]
>
> Ignoring the rest, I don't think that the physical location /
> jurisdiction of the miner has any legal implications for law applicable
> to the relationship between sender and receiver of a payment.
>
> This is not particular to Bitcoin. We're both in Germany (I guess).
> Assume we have a contract without specific agreements and I pay you in
> Icelandic kronur via PayPal (in Luxembourg) and my HTTPS requests to
> PayPal went via Australia and the US. Then German law applies to our
> contract, nothing in the middle can change that.
>
> Also ignoring possible security implications, there is just no need for
> a mechanism that enables users to select miners. I claim that almost
> nobody cares who will mine a transaction, because it makes no technical
> difference. If you don't want a specific miner to mine your
> transaction, then don't use Bitcoin.
>
> Tim


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Inquiry: Transaction Tiering
@ 2017-03-27 16:29 AJ West
  0 siblings, 0 replies; 18+ messages in thread
From: AJ West @ 2017-03-27 16:29 UTC (permalink / raw)
  To: bitcoin-dev

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [bitcoin-dev] Inquiry: Transaction Tiering
@ 2017-03-28 12:58 Martin Stolze
  2017-03-28 14:57 ` Andrew Baine
  0 siblings, 1 reply; 18+ messages in thread
From: Martin Stolze @ 2017-03-28 12:58 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

Hi AJ,
That's outstanding. I am glad to see that there is actually somebody
who has made some progress.

> "miners as service providers."
Great idea! Block space as a resource is under-analyzed.

> miner/pool's political positions, their consensus ideology, physical location (yes some people would like only miners in particular countries to mine their transactions)

I am not joking when I say that in 3 to 8 years, I want to be able to
verify my transaction through green blocks that are generated locally
by my neighbor through the excess capacity of his solar panels or by
an NGO pool that promotes solar deployment around the equator.

> The main attitude right now is that people would like to 'support' miners who signal for the features they care about.

Yes, just selecting all SegWit signaling hash power instead of picking
individual Authorities would be helpful on preferredminer.com

> I strongly believe, whether the Bitcoin developer community facilitates it or not, certain miners will become preferred by users.

Absolutely, considering the recent language used in opinions by the
ECB and drafts by the EU I see them assembling the artillery. I
wouldn't be surprised if they start target practice next year. That
will mean that commercial interest must have a way to transact on
somewhat regulated space.

> 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

I would call it regulated block space or regulated consensus space. I
hope that we can do that on a deeper level, as part of the p2p
protocol layer.

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

That's a distinct function, e.g. at least some communities charge a tax. [1]
I fear it is more likely that a business, say Coinbase, will approach
a "miner" and just say "we pay 100 USD for a KB to your bank account,
here are our transactions with no fee". It will literally be an
off-chain fee. That's what I mean by "secondary market". This would be
one of the least appealing scenarios.

> There are some terrible pitfalls with both of these methods. [...]

Spot on, that's why this should receive some attention before it
becomes urgent. I think there is much more to it that we are missing
at the moment, e.g. Tom: "Using xthin/compact blocks miners only send
a tiny version of a block which then causes the receiving node to
re-create it using the memory pool."


[1] http://thebitcoin.foundation/declaration.txt



> From: AJ West <ajwest@gmail•com>
> To: bitcoin-dev@lists•linuxfoundation.org
> Cc:
> Bcc:
> Date: Mon, 27 Mar 2017 12:29:20 -0400
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> 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)?
>


^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-03-29 13:07 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-20 20:12 [bitcoin-dev] Inquiry: Transaction Tiering 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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox