Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 90C26BC2 for ; Tue, 30 Jun 2015 00:42:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C8A732 for ; Tue, 30 Jun 2015 00:42:34 +0000 (UTC) Received: by paceq1 with SMTP id eq1so112580939pac.3 for ; Mon, 29 Jun 2015 17:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M0Ri4yOsq5Y/zRwKbbSnKKYVFqGnrAbFVYrPzx5FhiA=; b=bCehj3XiZrR07gx1PqGx4UNJiYNgKIkISpbA0VXJ9lsXp7K/DL0wE+WpYuti56h1lf nNvH7VnFfbPYvpua7SWfu9OOhZMIEUSjcc4Nt5DbwtCWBjHui89LNhW1AIu4fDwXwq3b Vt+a3mKd8Fm/esKAlluWPIvbSSzkWAEgsHGWK4jrDTPWlyn8Fz0goFGunDOLPCmo3heY cw2qMZPULcYRxjgfmYA65J1CJQx1yqnF9kDhy3cEvPEkw7bTc14rKF6tV0O95OxiH+yE y5z9ZGzJJ9EitLooWAiY5QvDYxbaOB3sX+/viD2ooP/W6j2V3Z/g3lUh7JpXkllKqB+1 ZuOg== X-Gm-Message-State: ALoCoQk08jsUiqDOhYWrNu3cyugDziT9VjOB8c9OzEjsErpAdITT3NWMa4Qy6pmyXclSxMRAq5L0 X-Received: by 10.66.231.42 with SMTP id td10mr37033899pac.98.1435624953999; Mon, 29 Jun 2015 17:42:33 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by mx.google.com with ESMTPSA id jd4sm43429204pbd.46.2015.06.29.17.42.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2015 17:42:32 -0700 (PDT) Message-ID: <5591E5FC.4040003@thinlink.com> Date: Mon, 29 Jun 2015 17:42:36 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adam Back References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 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] A Proposed Compromise to the Block Size Limit 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: Tue, 30 Jun 2015 00:42:34 -0000 On 6/28/2015 3:07 PM, Adam Back wrote: > We dont know what that limit is but people have been imagining 1,000 > or 10,000 transactions per anchor transaction. Basically users would > park Bitcoins a on a hub channel instead of the blockchain. This re-introduces a solved problem (solved by bitcoin better than anything else) - worrying whether your "payment hub" actually connects to whom you wish to pay. There will be enormous network effects and centralization pressure in the payment-hub space. A few entities, maybe single entity, should be expected to quickly corner the market and own the whole thing. This concept is far too untested to justify amateur economic meddling in the bitcoin fee market by setting a restrictive hard cap below technical feasibility. I can guess exactly who would want to keep bitcoin from improving:=20 *those who hope to be the future payment hub oligarchs*.