Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E94893E for ; Mon, 27 Mar 2017 17:18:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com [209.85.216.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 81670140 for ; Mon, 27 Mar 2017 17:18:43 +0000 (UTC) Received: by mail-qt0-f173.google.com with SMTP id r45so43397189qte.3 for ; Mon, 27 Mar 2017 10:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stolze-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LQpBIMM98ohNtMeAbY2EAaWKw3ePJmnQAslt3u6RAR0=; b=P5kbpI4OeVjgP4K+KApTfFRHLy/DAFV7HSLrmOhk/+KXauHHtnd6B2Nc2Cf3AOvxjH gF3qedMzVGhybh/ZzbDZvD5upn6lE6RvSBiYDusj82HNmxd+JXtHztaFdhEOMmquIwVo CSI+EFwO0seAboMDIZojbF5H6j/s1RBT9yakPHGei+8LYAkBpXcFKQ+863AeBKlCn6zl rciWTNwPdt5mHG7QHS098VwP+ZPcsqKPPgGUxHIejdohp4ax7b+AWRbDPsE879fW8Wwu vGOt7YKIlkgyIXQdZivr3pnWZ/wKzdnFXVdlzliEONYRmxUucui7ufc1HeGW9oxSk0j7 VxyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LQpBIMM98ohNtMeAbY2EAaWKw3ePJmnQAslt3u6RAR0=; b=AV0WguV2fyq2BkY7T3gK0SJFLaqGjW4hxdbDtalJgeVWKoM6uWup6bPGH+oS5zEO6w GOOSD8lsFwlO1kadP3HoW6qyEE3MaVbY23b0b5J0ainAF1fKpZRkdIQLT6a9NNdJQZN8 kwum2A9IpmZbaU/V+y7CmWmOGwar81s5XqvzZHTn/ku9U1wqYXt1veqgCbl/QShQzL9z nF5TTqKO96Yq1NvI6JlAo6eqA5cQTvrW2v8vIvJOLof+r9d59Xb2cHE9dh8yd7udKgph 6oBM6RpEv0s5ecVJT6FmS1YmuAX5sZroK/9yI313XwaOif5RqCL+NYXzReRfhzrk+dvw xy6Q== X-Gm-Message-State: AFeK/H1KgOz6hJwiJRmDMsHHyTYksqrgbEzHQKTsRt2TC+NB9peMegRq1dWOApVuDEb0yuk75ZHXw7C+Gy6HeQ== X-Received: by 10.200.34.37 with SMTP id o34mr21897161qto.213.1490635122405; Mon, 27 Mar 2017 10:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.78 with HTTP; Mon, 27 Mar 2017 10:18:22 -0700 (PDT) X-Originating-IP: [193.138.219.231] In-Reply-To: References: From: Martin Stolze Date: Mon, 27 Mar 2017 18:18:22 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11403b8ef714cc054bb98896 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 27 Mar 2017 17:25:05 +0000 Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:18:45 -0000 --001a11403b8ef714cc054bb98896 Content-Type: text/plain; charset=UTF-8 Yes, the terminology is creating a lot of confusion. I would be happy to contribute to a discourse that helps to clear up the ambiguities and cringeworthiness of current "standardized terminology". Robert Keagen developed a perspective on psychological development [1] and it appears to me that Stage 2 and 3 (miner, cash, network upgrade, ...) is discussing with Stage 4 (hash power, settlement, fork, ...). "Miner" is not wrong, just not helpful if you try to gauge the deeper complexities of Bitcoin. Likewise, "money" is not wrong if you explain it to a child, while credit and debt is much more useful if you want to gauge the deeper complexities of economics. still, any form forking has dilutive effect on existing BTC holders. Not at all, I sleep sound and anticipate any such event as an ugly scrip dividend. Regards Martin [1] https://en.wikipedia.org/wiki/Robert_Kegan#In_Over_Our_Heads On Sun, Mar 26, 2017 at 1:11 PM, greg misiorek wrote: > agreed, the 'miner' term has run its course and plays a different role > than it was originally set out to do, esp its original distributed nature. > the 'mining business' has become concentrated too much and resembles > today's financial institutions or simply banks, imho. > > > still, any form forking has dilutive effect on existing BTC holders. > > > thx, gm > ------------------------------ > *From:* bitcoin-dev-bounces@lists.linuxfoundation.org < > bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Martin Stolze > via bitcoin-dev > *Sent:* Saturday, March 25, 2017 1:15 PM > *To:* praxeology_guy > *Cc:* bitcoin-dev@lists.linuxfoundation.org > > *Subject:* Re: [bitcoin-dev] Inquiry: Transaction Tiering > > Thanks, those are valid concerns. > > > Potentially miners could create their own private communication > channel/listening port for submitting transactions that they would not > relay to other miners/the public node relay network. > That is the idea. Transaction Processors could source transactions > from the public mempool as well their proprietary mempool(s). > > > Miners would be incentivized to not relay higher fee transactions, > because they would want to keep them to themselves for higher profits. > Not so, a user may want to incentivise a specific Transaction > Processor or many. A user can detect this behavior and withdraw his > future business if he notices that his transaction is not included in > a block despite there being transactions with lower fees included. > Remember, the transaction can be advertised to different mempools and > a Transaction Processor could lose this business to a competitor who > processes the next block if he holds it back. > > Best Regards > Martin > > PS: It seems not too late to get rid of misleading terms like "miner". > Block rewards (infrastructure subsidies) will be neglectable for > future generations and the analogy is exceedingly poor. > > On Sat, Mar 25, 2017 at 4:42 AM, praxeology_guy > wrote: > > Potentially miners could create their own private communication > > channel/listening port for submitting transactions that they would not > relay > > to other miners/the public node relay network. Users could then chose > who > > they want to relay to. Miners would be incentivized to not relay higher > fee > > transactions, because they would want to keep them to themselves for > higher > > profits. > > > > Cheers, > > Praxeology Guy > > > > > > -------- Original Message -------- > > Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering > > Local Time: March 22, 2017 12:48 PM > > UTC Time: March 22, 2017 5:48 PM > > From: bitcoin-dev@lists.linuxfoundation.org > > To: bitcoin-dev@lists.linuxfoundation.org > > > > 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 > >> 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 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > bitcoin-dev -- Bitcoin Protocol Discussion - Linux Foundation > > lists.linuxfoundation.org > Bitcoin development and protocol discussion. This list is lightly > moderated. - No offensive posts, no personal attacks. - Posts must concern > development of bitcoin ... > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > bitcoin-dev -- Bitcoin Protocol Discussion - Linux Foundation > > lists.linuxfoundation.org > Bitcoin development and protocol discussion. This list is lightly > moderated. - No offensive posts, no personal attacks. - Posts must concern > development of bitcoin ... > > > --001a11403b8ef714cc054bb98896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, the terminology is creating a lot of confusion. I wou= ld be happy to contribute to a discourse that helps to clear up the ambigui= ties and cringeworthiness of current "standardized terminology".<= br>Robert Keagen developed a perspective on psychological development [1] a= nd it appears to me that Stage 2 and 3 (miner, cash, network upgrade, ...) = is discussing with Stage 4 (hash power, settlement, fork, ...).

&qu= ot;Miner" is not wrong, just not helpful if you try to gauge the deepe= r complexities of Bitcoin. Likewise, "money" is not wrong if you = explain it to a child, while credit and debt is much more useful if you wan= t to gauge the deeper complexities of economics.

still, any form forking has dilutive effec= t on existing BTC holders.

Not at all, I sleep sound and an= ticipate any such event as an ugly scrip dividend.=C2=A0

RegardsMartin

[1]=C2=A0https://en.wikipedia.org/wiki/Robert_Kegan#In_Ov= er_Our_Heads

On Sun, Mar 26, 2017 at 1:11 PM, greg misiorek <g= reg_not_so@hotmail.com> wrote:

agreed, the 'miner' term has run its course and plays a differen= t role than it was originally set out to do, esp its original=C2=A0distribu= ted nature. the 'mining business' has become concentrated too much = and resembles today's financial institutions or simply banks, imho.=C2=A0


still, any form=C2=A0forking has dilutive effect on existing BTC holders= .


thx, gm

From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of= Martin Stolze via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Saturday, March 25, 2017 1:15 PM
To: praxeology_guy
Cc: bitcoin-dev@lists.linuxfoundation.org

Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
<= /font>
=C2=A0
Thank= s, those are valid concerns.

> Potentially miners could create their own private communication channe= l/listening port for submitting transactions that they would not relay to o= ther miners/the public node relay network.
That is the idea. Transaction Processors could source transactions
from the public mempool as well their proprietary mempool(s).

> Miners would be incentivized to not relay higher fee transactions, bec= ause they would want to keep them to themselves for higher profits.
Not so, a user may want to incentivise a specific Transaction
Processor or many. A user can detect this behavior and withdraw his
future business if he notices that his transaction is not included in
a block despite there being transactions with lower fees included.
Remember, the transaction can be advertised to different mempools and
a Transaction Processor could lose this business to a competitor who
processes the next block if he holds it back.

Best Regards
Martin

PS: It seems not too late to get rid of misleading terms like "miner&q= uot;.
Block rewards (infrastructure subsidies) will be neglectable for
future generations and the analogy is exceedingly poor.

On Sat, Mar 25, 2017 at 4:42 AM, praxeology_guy
<prax= eology_guy@protonmail.com> wrote:
> Potentially miners could create their own private communication
> channel/listening port for submitting transactions that they would not= relay
> to other miners/the public node relay network.=C2=A0 Users could then = chose who
> they want to relay to.=C2=A0 Miners would be incentivized to not relay= higher fee
> transactions, because they would want to keep them to themselves for h= igher
> profits.
>
> Cheers,
> Praxeology Guy
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> Local Time: March 22, 2017 12:48 PM
> UTC Time: March 22, 2017 5:48 PM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
>
> 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<= br> > "miner" is indeed irrelevant, I am referring to the digital = location.
> Bitcoins blockchain is a digital location or better digital "spac= e".
> As far as I am concerned the authority lies with whoever governs this<= br> > particular block space. A "miner" can, or can not, include m= y
> 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<= br> > 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<= br> > BitFurry. - This is what I describe in option 1.
>
> In order to protect my interest I do need to choose, maybe not today,<= br> > but eventually.
>
> I also think that people do care who processes transactions and a lot<= br> > 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<= br> > 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 wo= uld
> 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=3D95; Revenue=3D100; Profit=3D5
> B: Cost=3D95; Revenue=3D100; Profit=3D5
> C: Cost=3D95; Revenue=3D100; Profit=3D5
>
> With transaction tiering, the outcome could be different!
>
> A: Cost=3D95; Revenue=3D90; Loss=3D5 // BSA that does not respect user= interest.
> B: Cost=3D95; Revenue=3D105; Profit=3D10
> C: Cost=3D95; Revenue=3D105; Profit=3D10
>
> 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 w= rote:
>>> As a participant in the economy in general and of Bitcoin in >>> particular, I desire an ability to decide where I transact. Th= e
>>> 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 b= est way
>>> to conduct my business in good faith. [2]
>>
>> Ignoring the rest, I don't think that the physical location /<= br> >> jurisdiction of the miner has any legal implications for law appli= cable
>> to the relationship between sender and receiver of a payment.
>>
>> This is not particular to Bitcoin. We're both in Germany (I gu= ess).
>> Assume we have a contract without specific agreements and I pay yo= u in
>> Icelandic kronur via PayPal (in Luxembourg) and my HTTPS requests = to
>> PayPal went via Australia and the US. Then German law applies to o= ur
>> contract, nothing in the middle can change that.
>>
>> Also ignoring possible security implications, there is just no nee= d for
>> a mechanism that enables users to select miners. I claim that almo= st
>> nobody cares who will mine a transaction, because it makes no tech= nical
>> difference. If you don't want a specific miner to mine your >> transaction, then don't use Bitcoin.
>>
>> Tim
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bitcoin-dev -- Bitcoin Proto= col Discussion - Linux Foundation
lists.linuxf= oundation.org
Bitcoin development and protocol discussion. This list is lightly moderated= . - No offensive posts, no personal attacks. - Posts must concern developme= nt of bitcoin ...


>
>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev
bitcoin-dev -- Bitcoin Prot= ocol Discussion - Linux Foundation
lists.linuxf= oundation.org
Bitcoin development and protocol discussion. This list is lightly moderated= . - No offensive posts, no personal attacks. - Posts must concern developme= nt of bitcoin ...



--001a11403b8ef714cc054bb98896--