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 20192360 for ; Mon, 27 Mar 2017 21:24:08 +0000 (UTC) X-Greylist: delayed 00:23:04 by SQLgrey-1.7.6 Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BB85728A for ; Mon, 27 Mar 2017 21:24:06 +0000 (UTC) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 4D54447E1EF for ; Mon, 27 Mar 2017 22:56:57 +0200 (CEST) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 830DDC5A44 for ; Mon, 27 Mar 2017 22:56:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id NLEOOamrhM5u for ; Mon, 27 Mar 2017 22:56:50 +0200 (CEST) X-Originating-IP: 2.216.198.114 Received: from [192.168.0.20] (unknown [2.216.198.114]) (Authenticated sender: antoine@alc.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E08C5C5A60 for ; Mon, 27 Mar 2017 22:56:49 +0200 (CEST) To: bitcoin-dev@lists.linuxfoundation.org References: From: Antoine Le Calvez Message-ID: <3cf94d94-f5c9-602e-a8f5-1fe8686468b1@alc.io> Date: Mon, 27 Mar 2017 21:56:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4A398C2AF83CF7587A297238" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 X-Mailman-Approved-At: Mon, 27 Mar 2017 21:31:05 +0000 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 21:24:08 -0000 This is a multi-part message in MIME format. --------------4A398C2AF83CF7587A297238 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I don't think encouraging mining more transactions is a good idea since it would promote inefficient transaction patterns. It's more efficient to send transactions with a high number of outputs/inputs instead of creating long transaction chains as some services do. You might consider incentivizing miners to mine blocks that reduce the UTXO set size the most, or some other metric that promotes efficient uses of the blockchain. On 27/03/17 17:12, Btc Ideas via bitcoin-dev 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 --------------4A398C2AF83CF7587A297238 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

I don't think encouraging mining more transactions is a good idea since it would promote inefficient transaction patterns. It's more efficient to send transactions with a high number of outputs/inputs instead of creating long transaction chains as some services do.

You might consider incentivizing miners to mine blocks that reduce the UTXO set size the most, or some other metric that promotes efficient uses of the blockchain.

On 27/03/17 17:12, Btc Ideas via bitcoin-dev 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

--------------4A398C2AF83CF7587A297238--