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 0E6ED83D for ; Wed, 5 Aug 2015 23:45:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C43B14C for ; Wed, 5 Aug 2015 23:45:55 +0000 (UTC) Received: by pawu10 with SMTP id u10so47339001paw.1 for ; Wed, 05 Aug 2015 16:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XlILZrKhqjXyFyz69Yxl22+TtdKvA7RSWTrz41AlgKM=; b=SwXqJpBGOD53D4TaRPWCb5+VbRS8CebOvPFtrfg9ovmQj/5p5PN2KH6CRHSANBUrdt ZylC0caP6VYwhY2/7jpjcy3IYbggFCOltA2+wchzErtAeEBocQqDaoFRHNTPs3ypbXbE ioIE7VPSXoVn68nWVI+OPIg9UCuZpQ1nWIcoAE8Hl3Dd0qek+SwIeEDq+F+aLFZlGbBf g90Sfff2M83BuZ4uL2DYvcNsWYPNOF2zsoeAHp1DjsNdIUX/7Z36DKIXe/8hVyla4Z27 OR5lV4OokT5l80OOgJIVFEmAYJwHVqPOg2idNVu+VGKBnJTs+mhx47d/kcMoNIxi+3Am I7YQ== X-Gm-Message-State: ALoCoQnmyoA4nrBwh86zXPdSl8KUM5LVFLpgk9Db6SK1tRnvoNo0IfczW1V/dTY/Q+Q1S6UFC93H X-Received: by 10.68.173.97 with SMTP id bj1mr24543510pbc.122.1438818355215; Wed, 05 Aug 2015 16:45:55 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id p1sm4179817pdb.3.2015.08.05.16.45.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 16:45:53 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <1438640036.2828.0.camel@auspira.com> <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com> <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com> From: Tom Harding Message-ID: <55C2A012.7080908@thinlink.com> Date: Wed, 5 Aug 2015 16:45:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB 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] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 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: Wed, 05 Aug 2015 23:45:56 -0000 On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote: > I do suspect that if we were to model this more accurately we might be > able to infer the "typical" propagation characteristics by measuring > the deviation from the expected distribution. The paper models propagation using a single time value that is a function of block size. Modeling the propagation distribution (which is totally separate from the poisson model of block production) would add a lot of complexity and my guess is the outcome would be little changed. >> On 5 Aug 2015, at 15:15, Peter R wrote: >> Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row. At some point, his solution or solutions must be communicated to his peers. Why complicate the analysis by assuming that a miner who finds two blocks sequentially does not publish the first, or that other miners would orphan miner's first block unless both were very quick? In general you don't consider anything beyond 1 block in the future, which seems fine. >>> I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. >> It will be interesting to see. I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously). Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways). Correcting for non-orphaning of one's own blocks could be as simple as adding a factor (1 - h/H) to equation 4, which it appears would leave hashpower as an independent variable in the results. But at worst, the discussion can be considered to apply directly only to low-hashpower miners right now. Overall, the paper does not predict big changes to per/kb fees or spam costs for the kinds of block sizes being discussed for the immediate future (8MB). But it does conclude that these fees will rise, not fall, with bigger blocks. Also it is welcome that this paper actually mentions the bitcoin exchange rate as a factor in relation to block size (it points out that a spam attack is much more expensive in fiat terms today than it was years ago).