summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichael Naber <mickeybob@gmail.com>2015-08-11 16:35:52 -0500
committerbitcoindev <bitcoindev@gnusha.org>2015-08-11 21:35:55 +0000
commit216442dc843cbd6ec173e1f08794d3fc8cf9f010 (patch)
tree104658ffd61e98c50b5b5e658a8f040ae8f97290
parent820541481ab4482d51e60f67cfdaa67aeb4f9620 (diff)
downloadpi-bitcoindev-216442dc843cbd6ec173e1f08794d3fc8cf9f010.tar.gz
pi-bitcoindev-216442dc843cbd6ec173e1f08794d3fc8cf9f010.zip
Re: [bitcoin-dev] Fees and the block-finding process
-rw-r--r--b8/50b54e857c1bf09fd2f63850fff299ec542eca337
1 files changed, 337 insertions, 0 deletions
diff --git a/b8/50b54e857c1bf09fd2f63850fff299ec542eca b/b8/50b54e857c1bf09fd2f63850fff299ec542eca
new file mode 100644
index 000000000..fac55bdab
--- /dev/null
+++ b/b8/50b54e857c1bf09fd2f63850fff299ec542eca
@@ -0,0 +1,337 @@
+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--
+