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 6C630AB9 for ; Mon, 27 Mar 2017 16:29:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62AA9181 for ; Mon, 27 Mar 2017 16:29:06 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id g83so18755976oia.0 for ; Mon, 27 Mar 2017 09:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vtogwiIOAia7xEMyx6xGQWEEKK6nWZhNOmWFQOzWJfY=; b=IO8jx+3pysRB4aq9wzrSw52BhNHBmSHqIyZZk0/lZFOhEgHrOuA9DDkrd3o+eN+tC4 MOWyTgziQe2AqNjip70Yho0o7LFa9CNqUsiyYTx501ygfTZOl9hI7/AmKnuDq2lvaplT HMx3i1WzRfhy61h4TDQ/omdXwshUmuhrHioG8NCdrPHdQ4mvZlOf55pDjsrg1yN660Re 44Sd64m80nd+3aC9Q3kK/q1KwIx5v1LOz4MwO+TSMk+jl2qUQVLT9b+iW3UMvXCHYv9Z Gr++loVwEb/7ZH1HU+mIrlUiyUUzoPL+YA+nTa0kRUq1gOeFCPLxJ2WR1A+r38grBIKf 1+JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vtogwiIOAia7xEMyx6xGQWEEKK6nWZhNOmWFQOzWJfY=; b=LqvMtP5jGvwiDu+xhrdVNBJei870IPQQzN/yyRnvk5/aGS+mlCx43ykAcbfBET+l+a nHXc/7tCnpZWRgdcqmUX0g8ylg4GI/3oqPWGgL4nhZZkT/pbwmUvuEANXjSZK1zdmVti k3kXwcy6Qh3dl75pt3LF2SI3wReSWbxk7MbNXZKRCHh64XnhlwkkPT3/e1QAcgMzBjoF YahNVHbCwzl79isx9UbCX8ofdGQzqPDM5YYTUEWRVoQa5/NVOhuBDRjb8+FNPIstHe+W et8HJeOSa2jsCzAiWDCH/5b5Hz2evc4tO73A4IWfQ+rIgaqtMA2Y/5goQJ/szBEHJ33F 3qDA== X-Gm-Message-State: AFeK/H3GTmLttOJkwCYgYj9ouc9ex2zQE4cXd+eGYKrQ3GOrDr/coHixyX4dunu71JAyeNcnVUeWhcaANYaoRg== X-Received: by 10.202.177.70 with SMTP id a67mr12291854oif.137.1490632145767; Mon, 27 Mar 2017 09:29:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.3 with HTTP; Mon, 27 Mar 2017 09:29:05 -0700 (PDT) In-Reply-To: References: From: Jameson Lopp Date: Mon, 27 Mar 2017 12:29:05 -0400 Message-ID: To: Btc Ideas , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113ce0e88a148b054bb8d70e X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Encouraging good miners 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: Mon, 27 Mar 2017 16:29:07 -0000 --001a113ce0e88a148b054bb8d70e Content-Type: text/plain; charset=UTF-8 Bitcoin chooses the "best chain" based upon the one that has the most cumulative proof of work behind it. Are you proposing that the cumulative proof of work be ignored if two blocks are within a certain threshold of each others' work and if so, the number of transactions in the block / the size of the block should be used as a "tie breaker?" I think this idea needs more fleshing out of exactly how it would work, with careful consideration that adding complexity to the best chain logic could introduce exploitable flaws. On Mon, Mar 27, 2017 at 12:12 PM, Btc Ideas via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Add a preference for mined blocks to be the one with more transactions. > This comes into play when 2 blocks of the same height are found. The first > good block mined would be orphaned if it had less transactions than > another. Optionally, have this rule apply to the current block and the > previous one. > > This increases incentive for full blocks because a miner thinking the > faster propagation of a smaller block will win him the reward, but that > would no longer be a good assumption. > > I read some miners could attack a chain by mining small or empty blocks. > This makes that a little more difficult, but they can still attack the > chain many ways. > > > Sent with ProtonMail Secure Email. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113ce0e88a148b054bb8d70e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bitcoin chooses the "best chain" based upon the = one that has the most cumulative proof of work behind it. Are you proposing= that the cumulative proof of work be ignored if two blocks are within a ce= rtain threshold of each others' work and if so, the number of transacti= ons in the block / the size of the block should be used as a "tie brea= ker?"

I think this idea needs more fleshing out of = exactly how it would work, with careful consideration that adding complexit= y to the best chain logic could introduce exploitable flaws.

On Mon, Mar 27, 2017= at 12:12 PM, Btc Ideas via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
Add a preference for mined blocks to be the one with more transa= ctions. This comes into play when 2 blocks of the same height are found. Th= e first good block mined would be orphaned if it had less transactions than= another. Optionally, have this rule apply to the current block and the pre= vious one.

This increases incentive for full b= locks because a miner thinking the faster propagation of a smaller block wi= ll win him the reward, but that would no longer be a good assumption.

I read some miners could attack a chain by mining s= mall or empty blocks. This makes that a little more difficult, but they can= still attack the chain many ways.


<= div class=3D"m_8850343332467748790protonmail_signature_block">
Sent with ProtonMail Secure Email.<= br>


____________________________________= ___________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a113ce0e88a148b054bb8d70e--