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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
Return-Path: <dweber.consulting@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 38D9F9E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Jun 2018 21:01:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com
[209.85.218.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83E45761
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Jun 2018 21:01:43 +0000 (UTC)
Received: by mail-oi0-f44.google.com with SMTP id e8-v6so6592166oii.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 06 Jun 2018 14:01:43 -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
:cc; bh=UO9ZagBo/U2Ek5jbYNf+E9OULBH16S1wsKcQ/oEEX/g=;
b=ZGfBAajdH2QSTNI7UNnjrEAP/Uj8hBZ6oW2M+Yg+uPbF6yROJ7ceQtp+SYnOCGADu3
Gkylja4p4HAaTjiuqdBILcY5T1qDOpBkYEJXy1E4QY7nV5OtBwvPKMJYvNicUEMtkyFh
ddGi9D34bBjLGR0EEwUFANY2cOfoZEszJxHuaN3aubn15BIFGfQDeaQgLV8W3ont2wx2
bkeK6OD+ecjkQwt3Ck0SiniHJ3adHegZkCZ5hS7+dwPpYYnBuQG7NAUntBvXKgKFl30P
OiRZGhcScdtKrFTrCndJtF5LYlWeoWIfF5DaAtjI1DrejCL9ruDNBlbt+rpfQfpHzjvu
yoeQ==
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:cc;
bh=UO9ZagBo/U2Ek5jbYNf+E9OULBH16S1wsKcQ/oEEX/g=;
b=G+ljKbQJHtpU15cD+/c5xW/+XSPFAiODBREwgWWbhT3Q1hJbeExwWkAzGzlxuRt482
voD1Tmylo3CaLsWVJYMCGf4HBSgSPNg9jRxkmWqJV11ZEqmupiEHL3/LTeCvj3qiLhxJ
tn0FXZK5ysVc3MnZtFbSUwkGxOmFep5mi1ntAu8wfO2s1HDYz+nF/3L8VQ5uma4vj69X
m8fjrJFrqHqO6o3DLqV1wwRrkW8jW5xy0oD30Pe7mk4J45PiGlcDl0SuqCygdLwHT65x
OKO2CSao5BmOJTdMTatnzgPQ7qjQ3podYBfCXzCDKNnJW2W2TqziXaOSh6MYPNZDP/dk
tV5w==
X-Gm-Message-State: APt69E2eeAAk2bwefkfd7bpliamq0VjMk+qGit0/WIZLUvVodIrLKFKQ
DP/VkSmb/jYPM12DtpK3xjV401GUkPh4YtD6qko=
X-Google-Smtp-Source: ADUXVKIcGitFxqG8DRcZIp8FxuXLJrA1VXALsuF0dOLpqxm476Y8DSi9eB+1h6rT258kLMmFttoP2iA1zHFbkoE2QY0=
X-Received: by 2002:aca:3ad6:: with SMTP id
h205-v6mr2385144oia.185.1528318902825;
Wed, 06 Jun 2018 14:01:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:4a85:0:0:0:0:0 with HTTP;
Wed, 6 Jun 2018 14:01:22 -0700 (PDT)
In-Reply-To: <3bf1d66e-8ebb-d475-04c4-a6b2c0a06794@aei.ca>
References: <CAJfMfCoK5=KVr6NB-dxddbjB+ufZxgaUBqwxN+_O3f9JWuut0w@mail.gmail.com>
<3bf1d66e-8ebb-d475-04c4-a6b2c0a06794@aei.ca>
From: Darren Weber <dweber.consulting@gmail.com>
Date: Wed, 6 Jun 2018 14:01:22 -0700
Message-ID: <CAJfMfCpzAPA7HXdUYzxxVrrcgck1cJAAo3cdv2tAT3EnSpj_BA@mail.gmail.com>
To: Thomas Guyot-Sionnest <dermoth@aei.ca>
Content-Type: multipart/alternative; boundary="0000000000004e7734056dff7988"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Thu, 07 Jun 2018 14:01:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 06 Jun 2018 21:01:44 -0000
--0000000000004e7734056dff7988
Content-Type: text/plain; charset="UTF-8"
Hi Thomas,
Thanks for considering this suggestion. You've raised some interesting
points (and concluded that it could be very difficult to implement). I'm
not yet at a point where I could answer any questions about implementation
details with any authority. With that caveat, your points are worth
considering further and I will dwell on it for a bit.
Best regards,
Darren
On Tue, Jun 5, 2018 at 3:50 AM, Thomas Guyot-Sionnest <dermoth@aei.ca>
wrote:
> 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: 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). The motivation is to make it more
> > difficult for malicious attacks to hash-power their way through a few
> > large transactions. Obviously, there are costs in greater transaction
> > 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,
>
> --
> Thomas
>
>
>
--
Darren L. Weber, Ph.D.
http://psdlw.users.sourceforge.net/
http://psdlw.users.sourceforge.net/wordpress/
--0000000000004e7734056dff7988
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>Hi=C2=A0<span name=3D"Thomas Guyot-Sio=
nnest" class=3D"gmail-gD">Thomas</span>,</div><div><br></div><div>Thanks fo=
r considering this suggestion.=C2=A0 You've raised some interesting poi=
nts (and concluded that it could be very difficult to implement).=C2=A0 I&#=
39;m not yet at a point where I could answer any questions about implementa=
tion details with any authority.=C2=A0 With that caveat, your points are wo=
rth considering further and I will dwell on it for a bit.</div><div><br></d=
iv><div>Best regards,</div><div>Darren</div><div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 5, 2018 at 3:50=
AM, Thomas Guyot-Sionnest <span dir=3D"ltr"><<a href=3D"mailto:dermoth@=
aei.ca" target=3D"_blank">dermoth@aei.ca</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span class=3D"">On 30/05/18 12:17 PM, Darren Weber v=
ia bitcoin-dev wrote:<br>
><br>
> Apologies for brevity, noob here and just throwing out an idea in case=
<br>
> it's useful (probably already covered somewhere, but I haven't=
got<br>
> time to do all the necessary background research).<br>
><br>
> From <a href=3D"https://github.com/bitcoin/">https://github.com/bitcoi=
n/</a><wbr>bitcoin/issues/13342<br>
><br>
> Suggestion:=C2=A0 To make it more difficult for a malicious attacker t=
o<br>
> reap quick rewards by double-spending large amounts with a relatively<=
br>
> brief majority of the network hashing power, introduce a hash workload=
<br>
> that is proportional to the sum of transactions in a block (probably<b=
r>
> the sum of the absolute values, and a "proportionality function&q=
uot; could<br>
> be linear or exponential).=C2=A0 The motivation is to make it more<br>
> difficult for malicious attacks to hash-power their way through a few<=
br>
> large transactions.=C2=A0 Obviously, there are costs in greater transa=
ction<br>
> delays (and fees?) for larger amounts (absolute value).<br>
><br>
> If there is original value in the idea, I can try to make time to<br>
> follow-up with a better BIP proposal.<br>
><br>
</span>Hi Darren,<br>
<br>
I'm wondering how do you think this can be implemented... The problem<b=
r>
being that you cannot just decide to exclude transactions because you<br>
found a lesser difficulty hash since that hash includes all transactions<br=
>
already... Miners will either include or not these transactions based on<br=
>
economical value, and since most of the rewards still comes from block<br>
rewards there would be very little right now except with very high fees.<br=
>
<br>
Even worse, it may have detrimental side-effects: since there is no<br>
distinctions between destination and change addresses, one can only<br>
assume the transaction amount is the full input amount. Therefore users<br>
would be inclined to keep large amount in lots of smaller addresses to<br>
avoid being penalized on small transactions, increasing the UTXO size<br>
for everybody.<br>
<br>
And besides, this is a huge change to swallow, requiring very good<br>
consensus and a hard fork. IMHO I wouldn't even waste time on this.<br>
<br>
Regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- <br>
Thomas<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature">Darren L. Weber, P=
h.D.<br><a href=3D"http://psdlw.users.sourceforge.net/" target=3D"_blank">h=
ttp://psdlw.users.sourceforge.net/</a><br><a href=3D"http://psdlw.users.sou=
rceforge.net/wordpress/" target=3D"_blank">http://psdlw.users.sourceforge.n=
et/wordpress/</a><br></div>
</div>
--0000000000004e7734056dff7988--
|
