From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 503851BB for ; Fri, 31 Jul 2015 01:29:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33E50B0 for ; Fri, 31 Jul 2015 01:29:23 +0000 (UTC) Received: by wibud3 with SMTP id ud3so40442880wib.1 for ; Thu, 30 Jul 2015 18:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=De9Q7NOOKFariI1jOmiauF0MzXpFk3s6Vw6dm10fJmc=; b=XmxmqqBkp9Mm/FveyLWJ58Q8ps17/lZ9DVCLlrk95aMIJ/b+W5rRDzUSWx/bjC8yWa MhOmnhPER6GeIvCcMxQNncbE2rvEJlvYuq5owALmOpm/Elw6zcm3bfHefKwtVDPvcSdp //ijKCRDrDx/BNlUyupQT7L/DJ9TljvvAfb1gdzlsCoXrzTpUlsO+2t5C1m/FIWkOU0D XsMZXt1uR7lWO6BUW3L70f/NYFDROunOjOw5OxdGblRH8tvuG5+cL0/DqtRJ84PSaj45 Kdwo46VApf06boLeXK3jNHGrX9E8za5i2kasDkS09Xjs8798/dHZ2QaZZ4DH67XSyqHa bD9Q== X-Gm-Message-State: ALoCoQmJ+s3CajCoUdHmQJNFwX1y9KNQIG6Rf1SjP3o9wXk9LFjh3TF+ipOnPXG5naTELviI9cM+ MIME-Version: 1.0 X-Received: by 10.180.21.175 with SMTP id w15mr1173105wie.58.1438306161586; Thu, 30 Jul 2015 18:29:21 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 18:29:21 -0700 (PDT) In-Reply-To: References: <543015348.4948849.1438178962054.JavaMail.yahoo@mail.yahoo.com> <55B959A2.9020402@sky-ip.org> <55BA2329.1080700@thinlink.com> <55BA8ED0.4080600@thinlink.com> Date: Fri, 31 Jul 2015 03:29:21 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tom Harding Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] =?utf-8?q?R=C4=83spuns=3A_Personal_opinion_on_the_f?= =?utf-8?q?ee_market_from_a_worried_local_trader?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 01:29:24 -0000 I'm re-reading and I have many spelling errors, sorry. On Fri, Jul 31, 2015 at 3:21 AM, Jorge Tim=C3=B3n wrote: > On Thu, Jul 30, 2015 at 10:53 PM, Tom Harding wrote: >> On 7/30/2015 11:14 AM, Jorge Tim=C3=B3n wrote: >>> The blocksize limit (your "production quota") is necessary for >>> decentralization, not for having a functioning fee market. >> >>> If we can agree that hitting the limit will JUST cause higher fees and >>> not bitcoin to fail, puppies to die or the sky to turn purple I think >>> that's a great step forward in this debate. >> >> It's interesting how people see things differently. I think your first >> statement above represents a great step forward in the debate. Unlike >> Adam Back, you state that a block size limit is not necessary to create >> a functioning fee market. > > Yes, Adam Back and I some times see things differently, and that's fine. > Many times, we realize later that we're saying the same thing with > different words and we're just discussing about terminology. That's > not an exclusive problem we have, it's a universal communication > problem. That's why math (which is nothing but a language) was > invented: to never discuss about terminology, to force any used > concept to be defined beforehand. > Sorry for the distraction, but I think this is one of those times. > Whether "hitting the limit" is "necessary" (I bet he never said > "strictly necessary") or just "helpful" is not very relevant. I think > Adam and I agree that hitting the limit wouldn't be bad, but actually > good for an young and immature market like bitcoin fees. > Apart from the dubious time-preference premium (dubious because in > most cases is just wallet's defaults and not users in a hurry), > transactions are basically free if you are willing to wait (and > apparently not that much). > > If I was a miner and you want me to include your transaction for free, > you're asking me to give you money, which I would prefer to do > directly if you are a friend or a non-profit organization that I like > or whatever rather than giving you money through bitcoin fee > discounts. > By including your transaction, I'm increasing the probability of my > mined block being orphaned and you're not willing to give me even a > single satoshi in exchange. > Today, in practice, one satoshi fee and no fee at all are treated > exactly the same by most (maybe all?) miners, which if you ask me, I > find very ~~unfair~~ economically absurd. > > Are all miners just stupid? > Not necessarily, they just don't care about fees or transactions at all. > Who is to blame? Certainly not the value chosen for the block size > limit, it's clearly the subsidy's fault: subsidy is all miners care > about (by the way, that's also the illness behind the SPV-mining > symptom). I am very worried about excessive mining subsidies (if you > knew how worried the freicoin community was [and still is] about this > problem, even if freicoin probably has one of the lowest mining > subsidies out there [currently and perpetually annual 5% of the > monetary base]...). > And I think that "hitting the limit" is not a catastrophe at all, but > rather an opportunity to motivate miners to start caring more about > transactions and fees (in proportion to what they care about). > And if the limit is increased later and fees fall again, that's fine, > because miners' will already be more prepared for the next time we > "hit the limit". > Anyway, maybe that hope is irrelevant, but what I'm convinced about is > that rising non-fast-confirmation mining fees above zero is not a bad > thing. > >> As to your second statement, unfortunately for immediate harmonious >> relations, I was merely separating out the elevated fee market concern, >> not at all saying it is the only or even the biggest concern with >> limited capacity. Alan Reiner, Ryan X. Charles and others have >> eloquently explained how restrictive a 1MB limit is, even with "layer 2"= . > > To be honest, I've only followed those were assuming the worse case > for optimization: bitcoin global monetary monopoly. > If I remember correctly, they were aiming for something around 170 MB, > but in any case, any value for the constant is completely arbitrary to > me at this point, including 1 MB. I'm deeply offended when I feel > included in the "1MBers group" because I don't feel like that at all. > To be honest, I have no idea what the correct value should be, all I > know it's a trade-off in a monotonic function: > > f(blocksize) =3D decentralization > >> What's missing from the decentralization dialog is a quantitative >> measure of decentralization. > > You are completely right: there's no defined measurable unit for > "decentralization" ("p2pness", whatever bitcoin has that wasn't > possible before pow-based distributed consensus). > And I'm afraid we will never have such a measurable unit. Maybe the > best definition of the property we're trying to capture is just "the > opposite of centralization", assuming centralization is easier to > define. > The best we have now are pool percentages, number of nodes, > subsidy/fee ratio (as said, this influences things like SPV mining) > How all that gets to...? > > g(many unrelated matrics) =3D centralization > > I don't really think anybody knows, but no matter what your > interpretation of some Japanese-named dude on the internet's words > (aka bitcoin sacred history) are, if you think 3 validating nodes is > enough for a "p2p" monetary network. > It is very possible that decentralization(blocksize) =3D > decentralization(blocksize+1) for many values of blocksize, but I > think the burden of the proof that decentralization(current_blocksize) > ~=3D decentralization(current_blocksize+1) is on those who propose > ++current_blocksize. > But I think ANY metric for centralization would be welcomed right now. > In fact, it doesn't need to be a function of blocksize, it can be a > function of maxBlockSigops or maybe even maxBlockInputs or > maxBlockOuputs. > But if we don't want to have any consensus limit to centralization > bitcoin has already fail (and doesn't need expensive proof of work). > >> Why not slam users with higher fees now, if we accept that they may be >> necessary someday? For the same reasons you don't ask a child, age 5, to >> work in a factory. > > It is a certainty that fees will be necessary someday: bitcoin's > seigniorage is limited to 21 M to subsidize mining, and we know that > won't last forever. Expensive proof of work (that centralized systems > lack) must be paid for somehow. > Who's child am I asking to work in a factory? I feel I'm missing > something there.