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 DFE7E1A1D for ; Wed, 23 Sep 2015 16:28:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 293D6160 for ; Wed, 23 Sep 2015 16:28:29 +0000 (UTC) Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MW8PN-1aC16P14ED-00XP2p; Wed, 23 Sep 2015 18:28:24 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Peter R In-Reply-To: Date: Wed, 23 Sep 2015 09:28:20 -0700 Message-Id: <64D181DA-05F6-4636-8F44-0FA63B758947@gmx.com> References: To: Gavin Andresen X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:B7he1h9R3dFgc16YKhWh5X8gRqINS+V7JtmAjR137rWg+rcLAso JRdQfFNwCIhunYoiI5nXV9aiSuqaLD/wkltzyLMU2g8JsU5cnusYBX0bV87LuCwmB8O1oNC 9ni8DtRq/gJF+QqSoJqO8qYrlbPBWJ26cbGx9IKZjrUnkHSB3m1OGTS6B1affzA5aHhSm2j DTUiLUTIKiGKtW/UMm1sg== X-UI-Out-Filterresults: notjunk:1;V01:K0:WGtMyIBV1QY=:qJ+BSADEIh8OQlF2YvbcSb uCQaGSMAYJTnqX6lkhQcpJk/XGZf853bhhJVmd0nTunR21tYTyFK5+jcpSFBF/6NpoKUIg8UJ 0se0r7uVIzp3VqwhTWupdUz5JzxywVMHZkZ7utj/UMpe0MRyh78PIA8WWrMG50ScX6yUslQOe 8rAfF3KAa6Lf7f5CS7eN98EFBhwUtFEwkIAVRjS23e/Vey40egz9Z7N02xhj388EM8pJ2X2aw XWFZ6gExSlwZ7B9qM3WEsNsnmbxm7qdM64kScjNpUoWxOPsc82euY/w+49SbnIqaDwrQijEhB 59PFBB9HBdPsziNzqRGY9C8XGS2ZRazDgAUhVD6sawofIDTWN1qZdN8qcIaDZfRuVfN7mEPgu qWrRy/ProyuRCKKO2zcrNRgKUE9HnbXZoBNzunW4NUuWZDvR39RQ6F8GtqGcWGhNyPTbgZCfj sOkrR3IREzSfYjfZBzD26GRUC7OjBTB6QnqdZfllYEI8aI6QHiwY4ymnoteIfCsGtlvVjTF6Z fx7ovg+6Lx68Y7rAogDZaRAIPPv/AP7sCU5ACqagDMCM6b4cbQey/lowcTZ+d5iU8BbGSkZob OmhH7TMFSZmItpWeXRtF2Fg6H5JqqfT8UMxPzyyXHP0uoVQ/qFJrZYYXGKGFuj1Gu3RnP9tUd hBiL7Vu0RFOz0ErmJmK4McC8LjWdhrLxKCtyrMJ+yxN+1O6/OpvvePB1tUQi9CBR9mwfgeZxq eNsjFqPW0S/WSN6DrK6CoLYRvlUhemBW4WMbAQ== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,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 Subject: Re: [bitcoin-dev] Weak block thoughts... 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, 23 Sep 2015 16:28:31 -0000 --Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Gavin, One thing that's not clear to me is whether it is even necessary--from = the perspective of the block size limit--to consider block propagation. = Bitcoin has been successfully operating unconstrained by the block size = limit over its entire history (except for in the past few months)--block = propagation never entered into the equation. =20 Imagine that the limit were raised to significantly above the free = market equilibrium block size Q*. Mining pools and other miners would = then have an incentive to work out schemes like "weak blocks," relay = networks, IBLTs, etc., in order to reduce the risk of orphaning larger = blocks (blocks with more fees that they'd like to produce if it were = profitable). =20 Shouldn't mining pools and miners be paying you guys for coding = solutions that improve their profitability? =20 Best regards, Peter On 2015-09-23, at 8:43 AM, Gavin Andresen via bitcoin-dev = wrote: > I've been thinking about 'weak blocks' and SPV mining, and it seems to = me weak blocks will make things better, not worse, if we improve the = mining code a little bit. >=20 > First: the idea of 'weak blocks' (hat tip to Rusty for the term) is = for miners to pre-announce blocks that they're working on, before = they've solved the proof-of-work puzzle. To prevent DoS attacks, assume = that some amount of proof-of-work is done (hence the term 'weak block') = to rate-limit how many 'weak block' messages are relayed across the = network. >=20 >=20 > Today, miners are incentivized to start mining an empty block as soon = as they see a block with valid proof-of-work, because they want to spend = as little time as possible mining a not-best chain. >=20 > Imagine miners always pre-announce the blocks they're working on to = their peers, and peers validate those 'weak blocks' as quickly as they = are able. >=20 > Because weak blocks are pre-validated, when a full-difficulty block = based on a previously announced weak block is found, block propagation = should be insanely fast-- basically, as fast as a single packet can be = relayed across the network the whole network could be mining on the new = block. >=20 > I don't see any barrier to making accepting the full-difficulty block = and CreateNewBlock() insanely fast, and if those operations take just a = microsecond or three, miners will have an incentive to create blocks = with fee-paying transactions that weren't in the last block, rather than = mining empty blocks. >=20 > ................. >=20 > A miner could try to avoid validation work by just taking a weak block = announced by somebody else, replacing the coinbase and re-computing the = merkle root, and then mining. They will be at a slight disadvantage to = fully validating miners, though, because they WOULD have to mine empty = blocks between the time a full block is found and a fully-validating = miner announced their next weak block. >=20 > ................. >=20 > Weak block announcements are great for the network; they give = transaction creators a pretty good idea of whether or not their = transactions are likely to be confirmed in the next block. And if we're = smart about implementing them, they shouldn't increase bandwidth or CPU = usage significantly, because all the weak blocks at a given point in = time are likely to contain the same transactions. >=20 > --=20 > -- > Gavin Andresen >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Gavin,

One thing that's not clear to me is whether it = is even necessary--from the perspective of the block size limit--to = consider block propagation.  Bitcoin has been successfully = operating unconstrained by the block size limit over its entire history = (except for in the past few months)--block propagation never entered = into the equation.  

Imagine that the = limit were raised to significantly above the free market equilibrium = block size Q*.  Mining pools and other miners would then have an = incentive to work out schemes like "weak blocks," relay networks, IBLTs, = etc., in order to reduce the risk of orphaning larger blocks (blocks = with more fees that they'd like to produce if it were profitable). =  

Shouldn't mining pools and miners be = paying you guys for coding solutions that improve their = profitability?   

Best = regards,
Peter


On = 2015-09-23, at 8:43 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:

I've been thinking about 'weak blocks' and SPV mining, and = it seems to me weak blocks will make things better, not worse, if we = improve the mining code a little bit.

First: =  the idea of 'weak blocks' (hat tip to Rusty for the term) is for = miners to pre-announce blocks that they're working on, before they've = solved the proof-of-work puzzle. To prevent DoS attacks, assume that = some amount of proof-of-work is done (hence the term 'weak block') to = rate-limit how many 'weak block' messages are relayed across the = network.


Today, miners are = incentivized to start mining an empty block as soon as they see a block = with valid proof-of-work, because they want to spend as little time as = possible mining a not-best chain.

Imagine = miners always pre-announce the blocks they're working on to their peers, = and peers validate those 'weak blocks' as quickly as they are = able.

Because weak blocks are pre-validated, = when a full-difficulty block based on a previously announced weak block = is found, block propagation should be insanely fast-- basically, as fast = as a single packet can be relayed across the network the whole network = could be mining on the new block.

I don't see = any barrier to making accepting the full-difficulty block and = CreateNewBlock() insanely fast, and if those operations take just a = microsecond or three, miners will have an incentive to create blocks = with fee-paying transactions that weren't in the last block, rather than = mining empty = blocks.

.................

A miner could try to avoid validation work by just taking a weak block = announced by somebody else, replacing the coinbase and re-computing the = merkle root, and then mining. They will be at a slight disadvantage to = fully validating miners, though, because they WOULD have to mine empty = blocks between the time a full block is found and a fully-validating = miner announced their next weak = block.

.................

Weak block announcements are great for the network; they give = transaction creators a pretty good idea of whether or not their = transactions are likely to be confirmed in the next block. And if we're = smart about implementing them, they shouldn't increase bandwidth or CPU = usage significantly, because all the weak blocks at a given point in = time are likely to contain the same = transactions.

--
--
Gavin Andresen

_______________________________________________
bitcoin-dev mailing = list
bitcoin-dev@lists.li= nuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinf= o/bitcoin-dev

= --Apple-Mail=_10FA6FBE-C1D2-4081-B884-5AF085C04FFF--