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
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
Return-Path: <dermoth@aei.ca>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 73D4F49F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Jun 2018 10:57:22 +0000 (UTC)
X-Greylist: delayed 00:06:41 by SQLgrey-1.7.6
Received: from mail001.aei.ca (mail001.aei.ca [206.123.6.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD585721
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Jun 2018 10:57:21 +0000 (UTC)
Received: (qmail 10479 invoked by uid 89); 5 Jun 2018 10:50:39 -0000
Received: by simscan 1.2.0 ppid: 10472, pid: 10477, t: 0.0040s
scanners: regex: 1.2.0 attach: 1.2.0
Received: from mail002.aei.ca (HELO mta.aei.ca) (206.123.6.132)
by mail001.aei.ca with (DHE-RSA-AES256-SHA encrypted) SMTP;
5 Jun 2018 10:50:39 -0000
Received: (qmail 22249 invoked by uid 89); 5 Jun 2018 10:50:38 -0000
Received: by simscan 1.2.0 ppid: 22227, pid: 22229, t: 2.6666s
scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 dsl-216-221-32-146.mtl.aei.ca (HELO ?192.168.67.200?)
(dermoth@216.221.32.146)
by mail.aei.ca with ESMTPA; 5 Jun 2018 10:50:36 -0000
To: Darren Weber <dweber.consulting@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAJfMfCoK5=KVr6NB-dxddbjB+ufZxgaUBqwxN+_O3f9JWuut0w@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <3bf1d66e-8ebb-d475-04c4-a6b2c0a06794@aei.ca>
Date: Tue, 5 Jun 2018 06:50:35 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAJfMfCoK5=KVr6NB-dxddbjB+ufZxgaUBqwxN+_O3f9JWuut0w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Mailman-Approved-At: Tue, 05 Jun 2018 13:29:15 +0000
Subject: Re: [bitcoin-dev] BIP suggestion: PoW proportional to block
transaction sum
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: Tue, 05 Jun 2018 10:57:22 -0000
On 30/05/18 12:17 PM, Darren Weber via bitcoin-dev wrote:
>
> Apologies for brevity, noob here and just throwing out an idea in case
> it's useful (probably already covered somewhere, but I haven't got
> time to do all the necessary background research).
>
> From https://github.com/bitcoin/bitcoin/issues/13342
>
> Suggestion:=C2=A0 To make it more difficult for a malicious attacker to=
> reap quick rewards by double-spending large amounts with a relatively
> brief majority of the network hashing power, introduce a hash workload
> that is proportional to the sum of transactions in a block (probably
> the sum of the absolute values, and a "proportionality function" could
> be linear or exponential).=C2=A0 The motivation is to make it more
> difficult for malicious attacks to hash-power their way through a few
> large transactions.=C2=A0 Obviously, there are costs in greater transac=
tion
> delays (and fees?) for larger amounts (absolute value).
>
> If there is original value in the idea, I can try to make time to
> follow-up with a better BIP proposal.
>
Hi Darren,
I'm wondering how do you think this can be implemented... The problem
being that you cannot just decide to exclude transactions because you
found a lesser difficulty hash since that hash includes all transactions
already... Miners will either include or not these transactions based on
economical value, and since most of the rewards still comes from block
rewards there would be very little right now except with very high fees.
Even worse, it may have detrimental side-effects: since there is no
distinctions between destination and change addresses, one can only
assume the transaction amount is the full input amount. Therefore users
would be inclined to keep large amount in lots of smaller addresses to
avoid being penalized on small transactions, increasing the UTXO size
for everybody.
And besides, this is a huge change to swallow, requiring very good
consensus and a hard fork. IMHO I wouldn't even waste time on this.
Regards,
--=20
Thomas
|
