diff options
| author | Dave Hudson <dave@hashingit.com> | 2015-08-05 15:44:18 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-05 22:44:24 +0000 |
| commit | 53a17cb5dbf328d050dfd4fffab3414c49f045c9 (patch) | |
| tree | f4e3e304aaa9b11dfe33a8c4d2c1f8f8b9dbe552 | |
| parent | c8753c4612d77a33a5608bc285932a59874cab08 (diff) | |
| download | pi-bitcoindev-53a17cb5dbf328d050dfd4fffab3414c49f045c9.tar.gz pi-bitcoindev-53a17cb5dbf328d050dfd4fffab3414c49f045c9.zip | |
Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests
| -rw-r--r-- | e7/f288e8cd416a4a8ad3323ae57ce26424b53107 | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/e7/f288e8cd416a4a8ad3323ae57ce26424b53107 b/e7/f288e8cd416a4a8ad3323ae57ce26424b53107 new file mode 100644 index 000000000..fcb66c5b8 --- /dev/null +++ b/e7/f288e8cd416a4a8ad3323ae57ce26424b53107 @@ -0,0 +1,130 @@ +Return-Path: <dave@hashingit.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 88EC57AE + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 5 Aug 2015 22:44:24 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from heron.directrouter.co.uk (heron.directrouter.co.uk + [89.145.69.228]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B721A1A9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 5 Aug 2015 22:44:23 +0000 (UTC) +Received: from [207.140.24.78] (port=43894 helo=[10.0.0.145]) + by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) + (Exim 4.85) (envelope-from <dave@hashingit.com>) + id 1ZN7Q5-001YL2-LE; Wed, 05 Aug 2015 22:44:21 +0000 +Content-Type: text/plain; charset=windows-1252 +Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) +From: Dave Hudson <dave@hashingit.com> +In-Reply-To: <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com> +Date: Wed, 5 Aug 2015 15:44:18 -0700 +Content-Transfer-Encoding: quoted-printable +Message-Id: <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com> +References: <CABsx9T1E1s=4h-SxLTOAXK4GniZrUekcEb6zDdTDFG+h7X98MA@mail.gmail.com> + <1438640036.2828.0.camel@auspira.com> + <CABsx9T2A-Mz9z=TTifbL2_sKCDvy8coRpNse+0vff6EbXbp8cg@mail.gmail.com> + <BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com> + <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> + <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com> +To: Peter R <peter_r@gmx.com> +X-Mailer: Apple Mail (2.2102) +X-AntiAbuse: This header was added to track abuse, + please include it with any abuse report +X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk +X-AntiAbuse: Original Domain - lists.linuxfoundation.org +X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] +X-AntiAbuse: Sender Address Domain - hashingit.com +X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id: + dave@hashingit.com +X-Source: +X-Source-Args: +X-Source-Dir: +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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 <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 05 Aug 2015 22:44:24 -0000 + +>=20 +> On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx.com> wrote: +>=20 +> Hi Dave, +>=20 +> Thank you for the feedback regarding my paper. =20 +>=20 +>> The paper is nicely done, but I'm concerned that there's a real = +problem with equation 4. The orphan rate is not just a function of time; = +it's also a function of the block maker's proportion of the network hash = +rate. Fundamentally a block maker (pool or aggregation of pools) does = +not orphan its own blocks. +>=20 +> With the benefit of hindsight, I think the paper would be stronger if = +it also analyzed how the model changes (or doesn't) if we assume zero = +propagation impedance for intra-miner communication, as you suggested = +(the "you don't orphan your own blocks" idea). Note that the paper did = +briefly discuss miner-dependent propagation times in the second = +paragraph of page 9 and in note 13. + +I think this would be really interesting. It's an area that seems to be = +lacking research. + +While I've not had time to model it I did have a quick discussion with = +the author of the Organ-of-Corti blog a few months ago and he seemed to = +think that the Poisson process model isn't quite accurate here. = +Intuitively this makes sense as until a block has fully propagated we're = +only seeing some fraction of the actual hashing network operating on the = +same problem, so we actually see slightly fewer very quick blocks than = +we might expect. + +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. + +>> Consider that a 1% miner must assume a greater risk from orphaning = +than, say, a pool with 25%, or worse 40% of the hash rate. +>=20 +> I'd like to explore this in more detail. 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. And if there's information about the = +transactions in his blocks to communicate, I think there's a cost = +associated with that. It's an interesting problem and I'd like to = +continue working on it. \ + +Agreed - I think this would be really interesting! + +>> 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. +>=20 +> 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). + +I really look forward to seeing the revised version. Seeing the = +differences will also help assess how much impact there is from = +simplified models. + + +Regards, +Dave + + + |