1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2CFCF72A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 17:27:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C339181
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 17:27:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101])
by mx-out02.mykolab.com (Postfix) with ESMTPS id 7959E6353D;
Mon, 27 Mar 2017 19:27:27 +0200 (CEST)
From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org, Btc Ideas <btcideas@protonmail.com>
Date: Mon, 27 Mar 2017 19:29:57 +0200
Message-ID: <7350662.8AQMRkRU5C@cherry>
In-Reply-To: <uQBxE-Qbd-osime4uulMZZHdF_D7usA2EKsPjkTyXCHM0OakN2Wdoeriyrc73yWp5c5ULQNkIsRXAM64cCom7ecPvdwmatOyc9Kh1sTDpl4=@protonmail.com>
References: <uQBxE-Qbd-osime4uulMZZHdF_D7usA2EKsPjkTyXCHM0OakN2Wdoeriyrc73yWp5c5ULQNkIsRXAM64cCom7ecPvdwmatOyc9Kh1sTDpl4=@protonmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 27 Mar 2017 17:29:23 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 17:27:32 -0000
For some time now the relation between block size and propagation speed has
been decoupled. Using xthin/compact blocks miners only send a tiny version
of a block which then causes the receiving node to re-create it using the
memory pool. Immediately getting double benefits by including pre-verified
transactions from the memory pool you avoid the old problem of having to
validate them again when a block was mined.
As such there is no downside to a miner creating a bigger block, as long as
all the transactions they include are actually in the mempool.
As such I'm personally convinced that the problem you are trying to solve
has already been solved.
Cheers!
On Monday, 27 March 2017 18:12:19 CEST 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.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
|
