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 DBC3B267 for ; Fri, 31 Jul 2015 01:21:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0FF214E for ; Fri, 31 Jul 2015 01:21:09 +0000 (UTC) Received: by wicgb10 with SMTP id gb10so13222364wic.1 for ; Thu, 30 Jul 2015 18:21:08 -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=99Sin8tJQEhS8WZJb4JlJqmjsmyprkmOB4uZMkFkKXQ=; b=ElkEYddum2BzBel3Jz8qCwBw/bt9RYArerpjBZjpxIsq+yV21ul2fT7pMWniTwHCdF 7BV+HuyOgDOu7iDkhQApg63MOaEw3o0fOQQTsG/Sim4/j7hUV2gDnggD70JCuq4EYHz4 wvO4lW4h16ZG8LlxliKpbeu2SrdRc49NMKIDGA4bXPGDRdlQcEG5+cuYTG1YXV+aKaky iFDHOLMFZIVYnQJJJJ47SkSjD7Caq4K18b5jcWG1KCqjjctGO4RWjJJtLfiPwu6qd9ic kFAA85llN5rwb9cXZQaXv3uqaBBa4gGvL9RGUe0QRdOqoJVWBirItZhX4/33CzeKku87 fbgA== X-Gm-Message-State: ALoCoQnfYxv963gFdhS87pUy4n6WL0UtoqShDGwaMpJl98ZxUKbBkSynh0TIp+gEiBBbpbQH9m8g MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr307459wjb.133.1438305667939; Thu, 30 Jul 2015 18:21:07 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 18:21:07 -0700 (PDT) In-Reply-To: <55BA8ED0.4080600@thinlink.com> 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:21:07 +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:21:11 -0000 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.