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 950CC48B for ; Thu, 23 Jul 2015 17:51:13 +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 E7937E9 for ; Thu, 23 Jul 2015 17:51:12 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so4365781wib.1 for ; Thu, 23 Jul 2015 10:51:11 -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=Jx7qooPuQFUcVoxzsse+AuPjvP1DRP4XEXtyZ6ofKI4=; b=gqfqrRZrLsECht1T5TagQGO+mOFjCP0MSaSjTvf+2enNcE9BJ3fh81wJ5upXqtesPv 9XNSy5q1fMNVM5OL6K5SgTqoz+uUDZ05DC1dDQkBSs5Ga4tarSyYQmBdsj0R4gtAsVDx uUbKw/vzBvPBZabGrQaJfhPd2+joLrI8A71iHRWzK5Ay/hX8G5cTCUi6X/GY6Kw/HnsQ iD+2hZnbjV7EGCp4jBSLCHBWajq9IrVamptDg8lKy4VYPNuWt0RCJ6cPSW4SIPBp4Z4I RVDYNbtlSs6x51+UXxSVr5msxgoIyxX83r8iBMjOny+bmH4rOXq3eMUCuyX7HdUlTP0y JIVA== X-Gm-Message-State: ALoCoQnhZqgfBdeMCtjJlwCqY2WSlwgACqVCHPnNMTkXcYO7JhoXXg4qn8O73QX04uRBPaqtKydP MIME-Version: 1.0 X-Received: by 10.180.109.6 with SMTP id ho6mr55504271wib.58.1437673871591; Thu, 23 Jul 2015 10:51:11 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 10:51:11 -0700 (PDT) In-Reply-To: <55B113AF.40500@thinlink.com> References: <55B113AF.40500@thinlink.com> Date: Thu, 23 Jul 2015 19:51:11 +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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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: Thu, 23 Jul 2015 17:51:13 -0000 On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev wrote: > On 7/23/2015 5:17 AM, Jorge Tim=C3=B3n via bitcoin-dev wrote: > >> If the user expectation is that a price would never arise because >> supply is going to be increased ad infinitum and they will always be >> able to send fast in-chain bitcoin transactions for free, just like >> breath air (an abundant resource) for free, then we should change that >> expectation as soon as possible. > > No. We should accept that reality may change, and we should promote > understanding of that fact. > > We should not artificially manipulate the market "as soon as possible," > since we ourselves don't know much at all about how the market will > unfold in the future. We know perfectly well that the system will need to eventually be sustained by fees. We should stop misinforming new users talking them about how bitcoin transactions "are free", because they're clearly not. >> the criteria for the consensus block size should be purely based on >> technological capacity (propagation benchmarking, etc) and >> centralization concerns > > Right, purely these. There is no place for artificially manipulating > expectations. Am I "artificially manipulating expectations" ? >> they will simply advance the front and start another battle, because >> their true hidden faction is the "not ever side". Please, Jeff, Gavin, >> Mike, show me that I'm wrong on this point. Please, answer my question >> this time. If "not now", then when? > > Bitcoin has all the hash power. The merkle root has effectively > infinite capacity. We should be asking HOW to scale the supporting > information propagation system appropriately, not WHEN to limit the > capacity of the primary time-stamping machine. Timestamping data using the blockchain is not the same as including that the data in the blockchain itself because the later is a scarce resource. The "timestamping space" is already unlimited today with no changes. You can use a bitcoin transaction to timestamp an unbounded amount of external data using exactly 0 extra bytes in your transaction! Here's the code: https://github.com/Blockstream/contracthashtool And I'm very interested in scaling Bitcoin, I just disagree that changing a constant is a "scaling solution". On Thu, Jul 23, 2015 at 6:28 PM, Gavin Andresen via bitcoin-dev wrote: > On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev >> We haven't tried yet. I can't answer for the people you asked, but >> personally I haven't thought much about when we should declare failure. > > > Yes! Lets plan for success! I extremely disagree that having a block limit is failure. It's a design decision to protect the system against centralization (which we will be able to rise as we solve technical and centralization problems we have today). But thank you for being more clear about it now, Gavin. You won't stop on a 8GB or 32GB limit because you think having ANY limit would be a failure. Is that correct? If not, can you please answer clearly when and why you think the blocksize should be lower than demand (when you will be ok with bitcoin users having to pay fees for the service they're enjoying)? If your answer is "never", I would prefer to hear it from you than just concluding it by the lack of an answer.