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 E9C3449B for ; Fri, 31 Jul 2015 08:07:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from pmx.vmail.no (pmx.vmail.no [193.75.16.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 53421EA for ; Fri, 31 Jul 2015 08:07:08 +0000 (UTC) Received: from pmx.vmail.no (localhost [127.0.0.1]) by localhost (pmx.isp.as2116.net) with SMTP id E787F440F0 for ; Fri, 31 Jul 2015 10:07:06 +0200 (CEST) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by pmx.vmail.no (pmx.isp.as2116.net) with ESMTP id A8EA7442B3 for ; Fri, 31 Jul 2015 10:06:38 +0200 (CEST) Received: from coldstorage.localnet (unknown [81.191.185.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTPS id 9300D1F54B for ; Fri, 31 Jul 2015 10:06:38 +0200 (CEST) From: Thomas Zander To: Bitcoin Dev Date: Fri, 31 Jul 2015 10:06:37 +0200 Message-ID: <1550277.3yUysHbRPT@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <4330019.CpFTjXpmfm@coldstorage> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary 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 08:07:09 -0000 On Thursday 30. July 2015 11.02.43 Mark Friedenbach wrote: > It is possible for a decentralized system like bitcoin to scale via > distribution in a way that introduces minimal trust, for example by > probabilistic validation and distribution of fraud proofs. However changes > to bitcoin consensus rules (mostly soft-forks) are required in order to > make this possible. Sounds overly complicated... What about a much simpler solution where the miner has a CPU in a well connected data center. Say, Amsterdam. He runs bitcoind on there and he, in China or such, connects to it over RPC (and ssl) to get a "block 000f00" accepted signal. Which would be 100 bytes or so. The miner continues to use his current setup, but with actual validation of the blocks to completely eliminate the risk of mining on orphaned blocks and at the same time remove most of the cost of larger-than-average bandwidth in his country. A slightly more complicated solution is needed to allow the miner to only send the headers to the bitcoind instance. So he only sends a couple of kb and his datacenter machine does the actual propagation. If the risk of duplication becomes an issue, setup multiple propagating nodes on different sides of the world. Bottom line for me is that most of the innovation for making stuff better for miners should be done in miners-specific software. Not in end-user software like bitcoin-core. -- Thomas Zander