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
234
235
236
237
238
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rick.wesson@iidf.org>) id 1QwGvV-0004lD-EF
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 17:07:41 +0000
X-ACL-Warn:
Received: from mail-gy0-f175.google.com ([209.85.160.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QwGvT-0001uB-5d
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 17:07:41 +0000
Received: by gyg4 with SMTP id 4so1284950gyg.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Aug 2011 10:07:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.154.3 with SMTP id o3mr2076215icw.221.1314205653362; Wed,
24 Aug 2011 10:07:33 -0700 (PDT)
Received: by 10.42.244.130 with HTTP; Wed, 24 Aug 2011 10:07:33 -0700 (PDT)
In-Reply-To: <CAAS2fgQspsXy1Vw=fNr1FvsDRkEbP6dEcFLgUpK9DrBKXyiWNg@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
<201108241215.36847.luke@dashjr.org>
<CAAS2fgQspsXy1Vw=fNr1FvsDRkEbP6dEcFLgUpK9DrBKXyiWNg@mail.gmail.com>
Date: Wed, 24 Aug 2011 10:07:33 -0700
Message-ID: <CAJ1JLtsxPG9v-Hwdb-pfgY6GU0Z4it+frFzw_tObVbNC6Xgdjw@mail.gmail.com>
From: Rick Wesson <rick@support-intelligence.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=90e6ba6e83f021694c04ab435960
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
0.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QwGvT-0001uB-5d
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 17:07:41 -0000
--90e6ba6e83f021694c04ab435960
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke@dashjr.org> wrote:
>
> > - Replace hard limits (like 1 MB maximum block size) with something that
> can
> > dynamically adapt with the times. Maybe based on difficulty so it can't
> be
> > gamed?
>
> Too early for that.
>
>
Could you provide a reference to why in your estimation it is "to early."
Simpy stating this as fact isn't enough to sway demand.
> - Adjust difficulty every block, without limits, based on a N-block
> sliding
> > window. I think this would solve the issue when the hashrate drops
> > overnight, but maybe also add a block time limit, or perhaps include the
> > "current block" in the difficulty calculation?
>
> The quantized scheme limits the amount of difficulty skew miners can
> create by lying about timestamps to about a half a percent. A rolling
> window with the same time constant would allow much more skew.
>
> > Replacing the "Satoshi" 64-bit integers with
> > "Satoshi" variable-size fractions (ie, infinite numerator + denominator)
>
> Increasing precision I would agree with but, sadly, causing people to
> need more than 64 bit would create a lot of bugs.
>
>
how about we agree that increasing precision is a goal and worry about how
to encode that once its on the road map.
> infinite numerator + denominator is absolutely completely and totally
> batshit insane. For one, it has weird consequences that the same value
> can have redundant encodings.
>
> Most importantly, it suffers factor inflation: If you spend inputs
> 1/977 1/983 1/991 1/997 the smallest denominator you can use for the
> output 948892238557.
>
> Not to mention that the idiots writing financial software can only
> barely manage to not use radix-2 floating point on everything. Asking
> them to use arbitrary rational numbers with mixed radix will never
> fly.
>
> > - Remove the 100 confirmation requirement for spending generated coins.
> If
> > they are respent before 100 confirmations, clients can/should flag the
> new
> > outputs as also "generated" or "recently generated" so recipients are
> aware
> > of the risk.
>
> Please lets not make bitcoin _less_ trustworthy.
>
> The 100 block maturity on generated coins is good. The generation from
> an orphaning is lost forever like the losing side of a double spend,
> but far far worse... because orphaning happens all the time on its own
> without any malice.
>
> I agree it's obnoxious that you can't pad your generation payouts
> without creating more transactions, but I don't see a solution for
> that. Repeat the addresses... make up for it by increasing your payout
> threshold.
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--90e6ba6e83f021694c04ab435960
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Wed, Aug 24, 2011 at 9:46 AM, Gregory=
Maxwell <span dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com">gmaxwe=
ll@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <<a href=3D"=
mailto:luke@dashjr.org">luke@dashjr.org</a>> wrote:<br>
<br>
> - Replace hard limits (like 1 MB maximum block size) with something th=
at can<br>
> dynamically adapt with the times. Maybe based on difficulty so it can&=
#39;t be<br>
> gamed?<br>
<br>
</div>Too early for that.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>Could you prov=
ide a=A0reference=A0to why in your estimation it is "to early." =
=A0Simpy stating this as fact isn't enough to sway demand.</div><div><b=
r></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">
> - Adjust difficulty every block, without limits, based on a N-block sl=
iding<br>
> =A0window. I think this would solve the issue when the hashrate drops<=
br>
> =A0overnight, but maybe also add a block time limit, or perhaps includ=
e the<br>
> =A0"current block" in the difficulty calculation?<br>
<br>
</div>The quantized scheme limits the amount of difficulty skew miners can<=
br>
create by lying about timestamps to about a half a percent. A rolling<br>
window with the same time constant would allow much more skew.<br>
<div class=3D"im"><br>
> Replacing the "Satoshi" 64-bit integers with<br>
> "Satoshi" variable-size fractions (ie, infinite numerator + =
denominator)<br>
<br>
</div>Increasing precision I would agree with but, sadly, causing people to=
<br>
need more than 64 bit would create a lot of bugs.<br>
<br></blockquote><div><br></div><div>how about we agree that=A0increasing=
=A0precision is a goal and worry about how to encode that once its on the r=
oad map.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
infinite numerator + denominator is absolutely completely and totally<br>
batshit insane. For one, it has weird consequences that the same value<br>
can have redundant encodings.<br>
<br>
Most importantly, it suffers factor inflation: If you spend inputs<br>
1/977 1/983 1/991 1/997 the smallest denominator you can use for the<br>
output 948892238557.<br>
<br>
Not to mention that the idiots writing financial software can only<br>
barely manage to not use radix-2 floating point on everything. Asking<br>
them to use arbitrary rational numbers with mixed radix will never<br>
fly.<br>
<div class=3D"im"><br>
> - Remove the 100 confirmation requirement for spending generated coins=
. If<br>
> =A0they are respent before 100 confirmations, clients can/should flag =
the new<br>
> =A0outputs as also "generated" or "recently generated&q=
uot; so recipients are aware<br>
> of the risk.<br>
<br>
</div>Please lets not make bitcoin _less_ trustworthy.<br>
<br>
The 100 block maturity on generated coins is good. The generation from<br>
an orphaning is lost forever like the losing side of a double spend,<br>
but far far worse... because orphaning happens all the time on its own<br>
without any malice.<br>
<br>
I agree it's obnoxious that you can't pad your generation payouts<b=
r>
without creating more transactions, but I don't see a solution for<br>
that. Repeat the addresses... make up for it by increasing your payout<br>
threshold.<br>
<div><div></div><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
EMC VNX: the world's simplest storage, starting under $10K<br>
The only unified storage solution that offers unified management<br>
Up to 160% more powerful than alternatives and 25% more efficient.<br>
Guaranteed. <a href=3D"http://p.sf.net/sfu/emc-vnx-dev2dev" target=3D"_blan=
k">http://p.sf.net/sfu/emc-vnx-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br>
--90e6ba6e83f021694c04ab435960--
|
