From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
Date: Tue, 26 Jul 2016 22:45:14 +0100 [thread overview]
Message-ID: <CAE-z3OUkRbKVEB17dRzgtm_Ojdy9Bf6tqwz=nopJEOO2-7+3qw@mail.gmail.com> (raw)
In-Reply-To: <CAODYVYfciFGoVMKtOWs9PNkEJEt768KFZNO6s-qFhzQFchUTXw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1639 bytes --]
next prev parent reply other threads:[~2016-07-26 21:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 20:58 [bitcoin-dev] Reasons to add sync flags to Bitcoin Martijn Meijering
2016-07-26 21:45 ` Tier Nolan [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-07-26 12:47 Moral Agent
2016-07-26 13:51 ` Tom
2016-07-26 17:27 ` Erik Aronesty
2016-07-26 22:03 ` Nick ODell
2016-07-27 14:42 ` Moral Agent
2016-07-28 16:41 ` Moral Agent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE-z3OUkRbKVEB17dRzgtm_Ojdy9Bf6tqwz=nopJEOO2-7+3qw@mail.gmail.com' \
--to=tier.nolan@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox