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 2B16194D for ; Tue, 26 Jul 2016 21:45:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 129DF153 for ; Tue, 26 Jul 2016 21:45:16 +0000 (UTC) Received: by mail-qk0-f182.google.com with SMTP id x1so18582877qkb.3 for ; Tue, 26 Jul 2016 14:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iEjEomNgfEbYhiWLteyaOf1Et/M1mtk691I+UwvbjGw=; b=ub3tuDBxcwj8A9fnaa8dgZu0PD8zBOQCBKny4qXVWywFSWvgZKb1GUNhcUQZahQect ptjRJdDj1fk7r+/0MMZOX3sGNCk3lHmnZ8vdJmTekolLiwUNSkhz2I/sNduMPTCpMpme xl3wERQs9MF2ecG9G+S5EO7wVqtsjlDQPd4X55EZHe+9KEgJYCebvK3I8LxB6rtOds9z iwei1Pdgl2/HMbPVcxuR8QecNdLW44BxYj6+9dCsadRZkAlrhW7nk6tfbmMRu8113eeR dV2GNKLKHucURBNRh6gQrjFHlMEsZxjfmjbeq6p60ZuBL88xlYu6zybUx/w7Bnp82Pr6 gGRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iEjEomNgfEbYhiWLteyaOf1Et/M1mtk691I+UwvbjGw=; b=UqnoXUlqebThhNP2xvqeQ46UF4CweVsgS5KO7UBHS2oj8PLq9nwAMvnxIiLfA6X1Ck rjKAJHPafb9ZWnO+ZCmktsP63h4HYe84r0peG2eyt5oD+3qRIuPnmtcMKuugSf5x5rq/ 2GERRnOwVD3buFCaUX7S5/gj6nDERDyObwIOGye2nJjYI0ohhmPFcmIA9RF8GZl4ixmb K27P8dHQycszk8emBui/c3HYFA7g06F8IK9SZ9rz6iY+FhjzjXpACYkUpGeJZQ5J8fcF H3I45+ZRZpzXwhwgH+VBWQCc0rh53se5MgFruDAFjVKxTy6N2ee1hnVsuRYd3fu5/mfl nFgA== X-Gm-Message-State: AEkoouszGh6qT5R3nlsWHSeJErD9jfMhX85D4vWI8nzUlnehug6R+oTuZVv5kD8SyO3JdKenFY5gyMi/5iHGpQ== X-Received: by 10.55.21.160 with SMTP id 32mr32806924qkv.210.1469569515189; Tue, 26 Jul 2016 14:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.193 with HTTP; Tue, 26 Jul 2016 14:45:14 -0700 (PDT) In-Reply-To: References: From: Tier Nolan Date: Tue, 26 Jul 2016 22:45:14 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11473cf6ecfb60053890d0ad X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 21:45:17 -0000 --001a11473cf6ecfb60053890d0ad Content-Type: text/plain; charset=UTF-8 On Tue, Jul 26, 2016 at 9:58 PM, Martijn Meijering via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Is there a reason miners would be more likely to engage in selfish > mining of sync flags than they are now with ordinary blocks? > This proposal has the same effect as adding mandatory empty blocks. POW targeted at 2 minutes means that the POW for the flag is 25% of the block POW. That gives a flag every 2 minutes and a block every 8 minutes. It has the feature that the conversion rate from hashing power to reward is the same for the flags and the blocks. A flag get 25% of the reward for 25% of the effort. A soft fork to add this rule would have a disadvantage relative to a competing chain. It would divert 20% of its hashing power to the flag blocks, which would be ignored by legacy nodes. The soft fork would need 55% of the hashing power to win the race. This isn't that big a deal if a 75% activation threshold is used. It might be worth bumping it up to 80% in that case. This rule would mean that headers first clients would have to download more information to verify the longest chain. If they only download the headers, they are missing 20% of the POW. --001a11473cf6ecfb60053890d0ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 26, 2016 at 9:58 PM, Martijn Meijering via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Is there a reason miners would be more likely to engage in selfish
mining of sync flags than they are now with ordinary blocks?


This proposal has the same effect as a= dding mandatory empty blocks.

POW targeted at 2 minutes m= eans that the POW for the flag is 25% of the block POW.=C2=A0 That gives a = flag every 2 minutes and a block every 8 minutes.

It has the feature= that the conversion rate from hashing power to reward is the same for the = flags and the blocks.=C2=A0 A flag get 25% of the reward for 25% of the eff= ort.

A soft fork to add this rule would have a= disadvantage relative to a competing chain.=C2=A0 It would divert 20% of i= ts hashing power to the flag blocks, which would be ignored by legacy nodes= .=C2=A0 The soft fork would need 55% of the hashing power to win the race.<= br>
This isn't that big a deal if a 75% activation thresh= old is used.=C2=A0 It might be worth bumping it up to 80% in that case.
=
This rule would mean that headers first clients would have t= o download more information to verify the longest chain.=C2=A0 If they only= download the headers, they are missing 20% of the POW.
--001a11473cf6ecfb60053890d0ad--