path: root/b8/50b54e857c1bf09fd2f63850fff299ec542eca

Return-Path: <mickeybob@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8407488B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 21:35:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
	[209.85.212.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F97D109
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 21:35:54 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so1904880wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 14:35:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Vc9tGY6R9aTtJQxOHaJa+s99TRk5KvMTaIHtCRfaCyQ=;
	b=IrzqF41z5iVscBvAHjqSSNRQfl8rhuSlYVQt2zPrVH0nwIN32aN2wm6HPx13WIWEN4
	9aErdsaKm/D+q2dweAf9xGaQMM0UEELf43ycEItwH5jqjnGjPFnCtXc2aJaSX+SFcK7R
	S+LEXPdbXjnKIjPpKbNeKacz+X1Tn1iOHZglC+QpDoo6Vze6YSgAnXfpqwiqrecv/t7q
	9/2814pTXGFisSSmF1pUxT+F6DWU5djS9CZx1kol+cv4e+CG75O2aA4snh7m/N4psqW9
	ovASFJ7DQLppdkqnhtq3Pf3mm1EW/bTkHRd1J9ISpedPoY4MYAjmGagIKGB8SMwjILEG
	cQ7A==
MIME-Version: 1.0
X-Received: by 10.180.219.41 with SMTP id pl9mr40496439wic.30.1439328953091;
	Tue, 11 Aug 2015 14:35:53 -0700 (PDT)
Received: by 10.27.78.207 with HTTP; Tue, 11 Aug 2015 14:35:52 -0700 (PDT)
In-Reply-To: <CALqxMTFfUdMuNsNnx-B+SPq7HvQyA+NkvFHGVYPiFHn-ZipVJw@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
	<CABm2gDoz4NMEQuQj6UHCYYCwihZrEC4Az8xDvTBwiZDf9eQ7-w@mail.gmail.com>
	<8181630.GdAj0CPZYc@coldstorage>
	<CABm2gDp2svO2G5bHs5AcjjN8dmP6P5nv0xriWez-pvzs2oBL5w@mail.gmail.com>
	<CALgxB7sQM5ObxyxDiN_BOyJrgsgfQ6PAtJi52dJENfWCRKywWg@mail.gmail.com>
	<CABm2gDq+2mXEN2hZY6_JYXAJX=Wxrxr6jm86P6g2YD4zzy-=Nw@mail.gmail.com>
	<CALgxB7sLsod9Kb-pwxGwCtPpWXsUusDE1nJ7p4nbFMG8mDWFtg@mail.gmail.com>
	<CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
	<CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com>
	<CALqxMTFfUdMuNsNnx-B+SPq7HvQyA+NkvFHGVYPiFHn-ZipVJw@mail.gmail.com>
Date: Tue, 11 Aug 2015 16:35:52 -0500
Message-ID: <CALgxB7vcQpPFcFYX72hkYuE8Da9saKKvSNWdh1m1dCvCCcwA=Q@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a1135fbc6f6cdd1051d0fe230
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 11 Aug 2015 21:35:55 -0000

--001a1135fbc6f6cdd1051d0fe230
Content-Type: text/plain; charset=UTF-8

Bitcoin would be better money than current money even if it were a bit more
expensive to transact, simply because of its other great characteristics
(trustlessness, limited supply, etc). However... it is not better than
something else sharing all those same characteristics but which is also
less expensive. The best money will win, and if Bitcoin doesn't increase
capacity then it won't remain the best.

On Tue, Aug 11, 2015 at 4:23 PM, Adam Back <adam@cypherspace.org> wrote:

> I dont think Bitcoin being cheaper is the main characteristic of
> Bitcoin.  I think the interesting thing is trustlessness - being able
> to transact without relying on third parties.
>
> Adam
>
>
> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The only reason why Bitcoin has grown the way it has, and in fact the
> only
> > reason why we're all even here on this mailing list talking about this,
> is
> > because Bitcoin is growing, since it's "better money than other money".
> One
> > of the key characteristics toward that is Bitcoin being inexpensive to
> > transact. If that characteristic is no longer true, then Bitcoin isn't
> going
> > to grow, and in fact Bitcoin itself will be replaced by better money
> that is
> > less expensive to transfer.
> >
> > So the importance of this issue cannot be overstated -- it's compete or
> die
> > for Bitcoin -- because people want to transact with global consensus at
> high
> > volume, and because technology exists to service that want, then it's
> going
> > to be met. This is basic rules of demand and supply. I don't necessarily
> > disagree with your position on only wanting to support uncontroversial
> > commits, but I think it's important to get consensus on the criticality
> of
> > the block size issue: do you agree, disagree, or not take a side, and
> why?
> >
> >
> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille@gmail.com>
> > wrote:
> >>
> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>
> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
> >>> question at hand is whether we should constrain that limit below what
> >>> technology is capable of delivering. I'm arguing that not only we
> should
> >>> not, but that we could not even if we wanted to, since competition will
> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> some
> >>> other product / fork.
> >>
> >>
> >> The question is not what the technology can deliver. The question is
> what
> >> price we're willing to pay for that. It is not a boolean "at this size,
> >> things break, and below it, they work". A small constant factor increase
> >> will unlikely break anything in the short term, but it will come with
> higher
> >> centralization pressure of various forms. There is discussion about
> whether
> >> these centralization pressures are significant, but citing that it's
> >> artificially constrained under the limit is IMHO a misrepresentation.
> It is
> >> constrained to aim for a certain balance between utility and risk, and
> >> neither extreme is interesting, while possibly still "working".
> >>
> >> Consensus rules are what keeps the system together. You can't simply
> >> switch to new rules on your own, because the rest of the system will
> end up
> >> ignoring you. These rules are there for a reason. You and I may agree
> about
> >> whether the 21M limit is necessary, and disagree about whether we need a
> >> block size limit, but we should be extremely careful with change. My
> >> position as Bitcoin Core developer is that we should merge consensus
> changes
> >> only when they are uncontroversial. Even when you believe a more
> invasive
> >> change is worth it, others may disagree, and the risk from disagreement
> is
> >> likely larger than the effect of a small block size increase by itself:
> the
> >> risk that suddenly every transaction can be spent twice (once on each
> side
> >> of the fork), the very thing that the block chain was designed to
> prevent.
> >>
> >> My personal opinion is that we should aim to do a block size increase
> for
> >> the right reasons. I don't think fear of rising fees or unreliability
> should
> >> be an issue: if fees are being paid, it means someone is willing to pay
> >> them. If people are doing transactions despite being unreliable, there
> must
> >> be a use for them. That may mean that some use cases don't fit anymore,
> but
> >> that is already the case.
> >>
> >> --
> >> Pieter
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

--001a1135fbc6f6cdd1051d0fe230
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Bitcoin would be better money than current money even if i=
t were a bit more expensive to transact, simply because of its other great =
characteristics (trustlessness, limited supply, etc). However... it is not =
better than something else sharing all those same characteristics but which=
 is also less expensive. The best money will win, and if Bitcoin doesn&#39;=
t increase capacity then it won&#39;t remain the best.</div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 11, 2015 at 4:23 PM,=
 Adam Back <span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" ta=
rget=3D"_blank">adam@cypherspace.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">I dont think Bitcoin being cheaper is the main characteri=
stic of<br>
Bitcoin.=C2=A0 I think the interesting thing is trustlessness - being able<=
br>
to transact without relying on third parties.<br>
<br>
Adam<br>
<br>
<br>
On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev<br>
<div class=3D"HOEnZb"><div class=3D"h5">&lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<br>
&gt; The only reason why Bitcoin has grown the way it has, and in fact the =
only<br>
&gt; reason why we&#39;re all even here on this mailing list talking about =
this, is<br>
&gt; because Bitcoin is growing, since it&#39;s &quot;better money than oth=
er money&quot;. One<br>
&gt; of the key characteristics toward that is Bitcoin being inexpensive to=
<br>
&gt; transact. If that characteristic is no longer true, then Bitcoin isn&#=
39;t going<br>
&gt; to grow, and in fact Bitcoin itself will be replaced by better money t=
hat is<br>
&gt; less expensive to transfer.<br>
&gt;<br>
&gt; So the importance of this issue cannot be overstated -- it&#39;s compe=
te or die<br>
&gt; for Bitcoin -- because people want to transact with global consensus a=
t high<br>
&gt; volume, and because technology exists to service that want, then it&#3=
9;s going<br>
&gt; to be met. This is basic rules of demand and supply. I don&#39;t neces=
sarily<br>
&gt; disagree with your position on only wanting to support uncontroversial=
<br>
&gt; commits, but I think it&#39;s important to get consensus on the critic=
ality of<br>
&gt; the block size issue: do you agree, disagree, or not take a side, and =
why?<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille &lt;<a href=3D"mailto:p=
ieter.wuille@gmail.com">pieter.wuille@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hitting the limit in and of itself is not necessarily a bad th=
ing. The<br>
&gt;&gt;&gt; question at hand is whether we should constrain that limit bel=
ow what<br>
&gt;&gt;&gt; technology is capable of delivering. I&#39;m arguing that not =
only we should<br>
&gt;&gt;&gt; not, but that we could not even if we wanted to, since competi=
tion will<br>
&gt;&gt;&gt; deliver capacity for global consensus whether it&#39;s in Bitc=
oin or in some<br>
&gt;&gt;&gt; other product / fork.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The question is not what the technology can deliver. The question =
is what<br>
&gt;&gt; price we&#39;re willing to pay for that. It is not a boolean &quot=
;at this size,<br>
&gt;&gt; things break, and below it, they work&quot;. A small constant fact=
or increase<br>
&gt;&gt; will unlikely break anything in the short term, but it will come w=
ith higher<br>
&gt;&gt; centralization pressure of various forms. There is discussion abou=
t whether<br>
&gt;&gt; these centralization pressures are significant, but citing that it=
&#39;s<br>
&gt;&gt; artificially constrained under the limit is IMHO a misrepresentati=
on. It is<br>
&gt;&gt; constrained to aim for a certain balance between utility and risk,=
 and<br>
&gt;&gt; neither extreme is interesting, while possibly still &quot;working=
&quot;.<br>
&gt;&gt;<br>
&gt;&gt; Consensus rules are what keeps the system together. You can&#39;t =
simply<br>
&gt;&gt; switch to new rules on your own, because the rest of the system wi=
ll end up<br>
&gt;&gt; ignoring you. These rules are there for a reason. You and I may ag=
ree about<br>
&gt;&gt; whether the 21M limit is necessary, and disagree about whether we =
need a<br>
&gt;&gt; block size limit, but we should be extremely careful with change. =
My<br>
&gt;&gt; position as Bitcoin Core developer is that we should merge consens=
us changes<br>
&gt;&gt; only when they are uncontroversial. Even when you believe a more i=
nvasive<br>
&gt;&gt; change is worth it, others may disagree, and the risk from disagre=
ement is<br>
&gt;&gt; likely larger than the effect of a small block size increase by it=
self: the<br>
&gt;&gt; risk that suddenly every transaction can be spent twice (once on e=
ach side<br>
&gt;&gt; of the fork), the very thing that the block chain was designed to =
prevent.<br>
&gt;&gt;<br>
&gt;&gt; My personal opinion is that we should aim to do a block size incre=
ase for<br>
&gt;&gt; the right reasons. I don&#39;t think fear of rising fees or unreli=
ability should<br>
&gt;&gt; be an issue: if fees are being paid, it means someone is willing t=
o pay<br>
&gt;&gt; them. If people are doing transactions despite being unreliable, t=
here must<br>
&gt;&gt; be a use for them. That may mean that some use cases don&#39;t fit=
 anymore, but<br>
&gt;&gt; that is already the case.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Pieter<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">&gt; __________________=
_____________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>

--001a1135fbc6f6cdd1051d0fe230--