From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <andrew.baine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 12520941
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 14:57:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com
[209.85.214.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F29ED24E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 14:57:20 +0000 (UTC)
Received: by mail-it0-f51.google.com with SMTP id 76so13409742itj.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 07:57:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=QxJKF4KsHtvzUteEiiDmmbLBpEQBOuAxQKY64mRYDTw=;
b=sLjnYNVRyS9wuDsFhZIIPP/G82CsOIj8hreBXHa99Qvx+qtxLYw2/5mhuevZVCKdzq
/PqjYLeOX5yvmI6YhkTrr00CuvDzGCFqWwOb5g1yS6PgQ2sGL0Vndcl1r3//An9dsJR6
mQGk6fYupr2eoSxfOnLvW4QTeSKgs6baWmpzkUnZ8Xm+qBnhVzupqkcx59GJ3FZ8j9w5
VuLvXmFWrHpKBeWMP2MrvaTmPnijXVYik/VJ85UvTfssaUMBE+AV7+uoGW01F7CHSM5E
1QZATFs8hIxHBwi6swxdiBROtRV01B60POulxP0/UVsarmDSAqa5DSbAFshNAVXYeTSa
RHjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=QxJKF4KsHtvzUteEiiDmmbLBpEQBOuAxQKY64mRYDTw=;
b=NmFb5zAFzxnbjUSqWhpzcPvDU2XSGFlZq0joQfEbW/TDqv7PELxFKfy3+Twh9hLzhO
B5MXWAulr3EVU4mbAWRqObFDMHnTErzGywbbEGHmlbP8+lSe6EfNQQ9thhCAQy9AwIl+
o2bkLrHObKF4f2PEj8NQ3DlTO6Rck+f12z9D34iDwTp1934i2fKz4xjeR1EC/K7w2wU3
f2HfixfFBN+0lVmM8B2Blc657Iy8Z1mUtmdsoG8lAZ+KR6gKFzZbhnllNMFv/qQFFrxO
UUasQKMs5InfnQzi2kxNXwn8wd93yTG3ZW6uuvMS7jOASmxPM0Z9sP0J4BRLVD8dGVAv
zCSw==
X-Gm-Message-State: AFeK/H1yj8CA4tdYmC+K+1BlaltFeLSum7y/R11xErjetI/PzucwKMsbSfvCuOp37qZY7v5ZqDoKGZrD/qQSDQ==
X-Received: by 10.36.130.133 with SMTP id t127mr15010670itd.36.1490713040278;
Tue, 28 Mar 2017 07:57:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAOyfL0pN8Z8XSvHAXkG2=ic=J6m-8B5K2d=_eL=84Dnox3ovMQ@mail.gmail.com>
In-Reply-To: <CAOyfL0pN8Z8XSvHAXkG2=ic=J6m-8B5K2d=_eL=84Dnox3ovMQ@mail.gmail.com>
From: Andrew Baine <andrew.baine@gmail.com>
Date: Tue, 28 Mar 2017 14:57:09 +0000
Message-ID: <CAJxsMusFEDmT4YLhMJT0a6S=Mm0rfNGp6U5QRKApK6KJXU0cLg@mail.gmail.com>
To: Martin Stolze <martin@stolze.cc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0891483a9332054bcbad07
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Wed, 29 Mar 2017 13:48:57 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 14:57:22 -0000
--94eb2c0891483a9332054bcbad07
Content-Type: text/plain; charset=UTF-8
The bitcoin ecosystem is better off the more transactions are propogated
peer-to-peer than directly to miners. We want miners listening to the
network, not soliciting transactions directly from users. You whispering
your transactions to your miner-of-choice while I whisper to mine
contravenes a critical value-add of the peer-to-peer network in my opinion.
On Tue, Mar 28, 2017 at 10:35 AM Martin Stolze via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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)?
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c0891483a9332054bcbad07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The bitcoin ecosystem is better off the more transactions =
are propogated peer-to-peer than directly to miners. We want miners listeni=
ng to the network, not soliciting transactions directly from users. You whi=
spering your transactions to your miner-of-choice while I whisper to mine c=
ontravenes a critical value-add of the peer-to-peer network in my opinion.<=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Mar 28, 2017 a=
t 10:35 AM Martin Stolze via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Hi AJ,<br class=3D"gmail_msg">
That's outstanding. I am glad to see that there is actually somebody<br=
class=3D"gmail_msg">
who has made some progress.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> "miners as service providers."<br class=3D"gmail_msg">
Great idea! Block space as a resource is under-analyzed.<br class=3D"gmail_=
msg">
<br class=3D"gmail_msg">
> miner/pool's political positions, their consensus ideology, physic=
al location (yes some people would like only miners in particular countries=
to mine their transactions)<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I am not joking when I say that in 3 to 8 years, I want to be able to<br cl=
ass=3D"gmail_msg">
verify my transaction through green blocks that are generated locally<br cl=
ass=3D"gmail_msg">
by my neighbor through the excess capacity of his solar panels or by<br cla=
ss=3D"gmail_msg">
an NGO pool that promotes solar deployment around the equator.<br class=3D"=
gmail_msg">
<br class=3D"gmail_msg">
> The main attitude right now is that people would like to 'support&=
#39; miners who signal for the features they care about.<br class=3D"gmail_=
msg">
<br class=3D"gmail_msg">
Yes, just selecting all SegWit signaling hash power instead of picking<br c=
lass=3D"gmail_msg">
individual Authorities would be helpful on <a href=3D"http://preferredminer=
.com" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">preferredmin=
er.com</a><br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> I strongly believe, whether the Bitcoin developer community facilitate=
s it or not, certain miners will become preferred by users.<br class=3D"gma=
il_msg">
<br class=3D"gmail_msg">
Absolutely, considering the recent language used in opinions by the<br clas=
s=3D"gmail_msg">
ECB and drafts by the EU I see them assembling the artillery. I<br class=3D=
"gmail_msg">
wouldn't be surprised if they start target practice next year. That<br =
class=3D"gmail_msg">
will mean that commercial interest must have a way to transact on<br class=
=3D"gmail_msg">
somewhat regulated space.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> 1) By creating 'segregated mempools' where an authenticated th=
ird-party like my web service Preferred Miner manages the access to pending=
transactions destined for a specific set of miners<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I would call it regulated block space or regulated consensus space. I<br cl=
ass=3D"gmail_msg">
hope that we can do that on a deeper level, as part of the p2p<br class=3D"=
gmail_msg">
protocol layer.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> 2) by creating transactions where the mining fee is in one way or anot=
her, an output to an address owned by the preferred miner(s).<br class=3D"g=
mail_msg">
<br class=3D"gmail_msg">
That's a distinct function, e.g. at least some communities charge a tax=
. [1]<br class=3D"gmail_msg">
I fear it is more likely that a business, say Coinbase, will approach<br cl=
ass=3D"gmail_msg">
a "miner" and just say "we pay 100 USD for a KB to your bank=
account,<br class=3D"gmail_msg">
here are our transactions with no fee". It will literally be an<br cla=
ss=3D"gmail_msg">
off-chain fee. That's what I mean by "secondary market". This=
would be<br class=3D"gmail_msg">
one of the least appealing scenarios.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> There are some terrible pitfalls with both of these methods. [...]<br =
class=3D"gmail_msg">
<br class=3D"gmail_msg">
Spot on, that's why this should receive some attention before it<br cla=
ss=3D"gmail_msg">
becomes urgent. I think there is much more to it that we are missing<br cla=
ss=3D"gmail_msg">
at the moment, e.g. Tom: "Using xthin/compact blocks miners only send<=
br class=3D"gmail_msg">
a tiny version of a block which then causes the receiving node to<br class=
=3D"gmail_msg">
re-create it using the memory pool."<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
[1] <a href=3D"http://thebitcoin.foundation/declaration.txt" rel=3D"norefer=
rer" class=3D"gmail_msg" target=3D"_blank">http://thebitcoin.foundation/dec=
laration.txt</a><br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> From: AJ West <<a href=3D"mailto:ajwest@gmail.com" class=3D"gmail_m=
sg" target=3D"_blank">ajwest@gmail.com</a>><br class=3D"gmail_msg">
> To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"=
gmail_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br c=
lass=3D"gmail_msg">
> Cc:<br class=3D"gmail_msg">
> Bcc:<br class=3D"gmail_msg">
> Date: Mon, 27 Mar 2017 12:29:20 -0400<br class=3D"gmail_msg">
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering<br class=3D"gm=
ail_msg">
> Hi I'm AJ West, I made a service <a href=3D"http://preferredminer.=
com" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">http://prefer=
redminer.com</a> which is a proof-of-concept project designed to spur discu=
ssion on exactly this issue of "miners as service providers."<br =
class=3D"gmail_msg">
><br class=3D"gmail_msg">
> The current status is that Bitcoin end users are looking to support sp=
ecific miners, whether that's because they agree with a miner/pool'=
s political positions, their consensus ideology, physical location (yes som=
e people would like only miners in particular countries to mine their trans=
actions) and the list of reasons goes on. The main attitude right now is th=
at people would like to 'support' miners who signal for the feature=
s they care about.<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> I strongly believe, whether the Bitcoin developer community facilitate=
s it or not, certain miners will become preferred by users. In summary, the=
re are realistically two proposed ways of providing this service in the pre=
sent-day situation: 1) By creating 'segregated mempools' where an a=
uthenticated third-party like my web service Preferred Miner manages the ac=
cess 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).<br class=3D"gmail_msg=
">
><br class=3D"gmail_msg">
> 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 t=
here are the extra fees users will have to pay to offset the risk of a mine=
r losing out for having to send the network a not-yet-broadcasted transacti=
on. 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 y=
our transaction knowing it's got a fee for them. Plus, how many nodes g=
oing forward are going to hold what seem to be 0-fee transactions in mempoo=
l (because the fee is in the outputs)?<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div>
--94eb2c0891483a9332054bcbad07--