diff options
author | Michael Naber <mickeybob@gmail.com> | 2015-08-11 16:35:52 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-11 21:35:55 +0000 |
commit | 216442dc843cbd6ec173e1f08794d3fc8cf9f010 (patch) | |
tree | 104658ffd61e98c50b5b5e658a8f040ae8f97290 | |
parent | 820541481ab4482d51e60f67cfdaa67aeb4f9620 (diff) | |
download | pi-bitcoindev-216442dc843cbd6ec173e1f08794d3fc8cf9f010.tar.gz pi-bitcoindev-216442dc843cbd6ec173e1f08794d3fc8cf9f010.zip |
Re: [bitcoin-dev] Fees and the block-finding process
-rw-r--r-- | b8/50b54e857c1bf09fd2f63850fff299ec542eca | 337 |
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'= +t increase capacity then it won'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"><<a href=3D"mailto:adam@cypherspace.org" ta= +rget=3D"_blank">adam@cypherspace.org</a>></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"><<a href=3D"mailto:bitcoin-dev@l= +ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wro= +te:<br> +> The only reason why Bitcoin has grown the way it has, and in fact the = +only<br> +> reason why we're all even here on this mailing list talking about = +this, is<br> +> because Bitcoin is growing, since it's "better money than oth= +er money". One<br> +> of the key characteristics toward that is Bitcoin being inexpensive to= +<br> +> transact. If that characteristic is no longer true, then Bitcoin isn&#= +39;t going<br> +> to grow, and in fact Bitcoin itself will be replaced by better money t= +hat is<br> +> less expensive to transfer.<br> +><br> +> So the importance of this issue cannot be overstated -- it's compe= +te or die<br> +> for Bitcoin -- because people want to transact with global consensus a= +t high<br> +> volume, and because technology exists to service that want, then it= +9;s going<br> +> to be met. This is basic rules of demand and supply. I don't neces= +sarily<br> +> disagree with your position on only wanting to support uncontroversial= +<br> +> commits, but I think it's important to get consensus on the critic= +ality of<br> +> the block size issue: do you agree, disagree, or not take a side, and = +why?<br> +><br> +><br> +> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <<a href=3D"mailto:p= +ieter.wuille@gmail.com">pieter.wuille@gmail.com</a>><br> +> wrote:<br> +>><br> +>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev<br> +>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= +in-dev@lists.linuxfoundation.org</a>> wrote:<br> +>>><br> +>>> Hitting the limit in and of itself is not necessarily a bad th= +ing. The<br> +>>> question at hand is whether we should constrain that limit bel= +ow what<br> +>>> technology is capable of delivering. I'm arguing that not = +only we should<br> +>>> not, but that we could not even if we wanted to, since competi= +tion will<br> +>>> deliver capacity for global consensus whether it's in Bitc= +oin or in some<br> +>>> other product / fork.<br> +>><br> +>><br> +>> The question is not what the technology can deliver. The question = +is what<br> +>> price we're willing to pay for that. It is not a boolean "= +;at this size,<br> +>> things break, and below it, they work". A small constant fact= +or increase<br> +>> will unlikely break anything in the short term, but it will come w= +ith higher<br> +>> centralization pressure of various forms. There is discussion abou= +t whether<br> +>> these centralization pressures are significant, but citing that it= +'s<br> +>> artificially constrained under the limit is IMHO a misrepresentati= +on. It is<br> +>> constrained to aim for a certain balance between utility and risk,= + and<br> +>> neither extreme is interesting, while possibly still "working= +".<br> +>><br> +>> Consensus rules are what keeps the system together. You can't = +simply<br> +>> switch to new rules on your own, because the rest of the system wi= +ll end up<br> +>> ignoring you. These rules are there for a reason. You and I may ag= +ree about<br> +>> whether the 21M limit is necessary, and disagree about whether we = +need a<br> +>> block size limit, but we should be extremely careful with change. = +My<br> +>> position as Bitcoin Core developer is that we should merge consens= +us changes<br> +>> only when they are uncontroversial. Even when you believe a more i= +nvasive<br> +>> change is worth it, others may disagree, and the risk from disagre= +ement is<br> +>> likely larger than the effect of a small block size increase by it= +self: the<br> +>> risk that suddenly every transaction can be spent twice (once on e= +ach side<br> +>> of the fork), the very thing that the block chain was designed to = +prevent.<br> +>><br> +>> My personal opinion is that we should aim to do a block size incre= +ase for<br> +>> the right reasons. I don't think fear of rising fees or unreli= +ability should<br> +>> be an issue: if fees are being paid, it means someone is willing t= +o pay<br> +>> them. If people are doing transactions despite being unreliable, t= +here must<br> +>> be a use for them. That may mean that some use cases don't fit= + anymore, but<br> +>> that is already the case.<br> +>><br> +>> --<br> +>> Pieter<br> +>><br> +><br> +><br> +</div></div><div class=3D"HOEnZb"><div class=3D"h5">> __________________= +_____________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.linuxfoundation.org</a><br> +> <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> +><br> +</div></div></blockquote></div><br></div> + +--001a1135fbc6f6cdd1051d0fe230-- + |