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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <dgomez1092@gmail.com>) id 1YqpRR-0008VJ-Et
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 21:04:17 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.48 as permitted sender)
client-ip=74.125.82.48; envelope-from=dgomez1092@gmail.com;
helo=mail-wg0-f48.google.com;
Received: from mail-wg0-f48.google.com ([74.125.82.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqpRQ-0005lE-Gp
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 21:04:17 +0000
Received: by wgin8 with SMTP id n8so83006195wgi.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 14:04:10 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.186.5 with SMTP id fg5mr132356wic.60.1431119050527; Fri,
08 May 2015 14:04:10 -0700 (PDT)
Received: by 10.28.144.68 with HTTP; Fri, 8 May 2015 14:04:10 -0700 (PDT)
Date: Fri, 8 May 2015 14:04:10 -0700
Message-ID: <CAH+jCTxVe-2wKy8p5tvc8mMApzA_gg3_n-ZRcqiQrZzv+OOx4g@mail.gmail.com>
From: Damian Gomez <dgomez1092@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=001a11c334e6a35a7b0515985edc
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(dgomez1092[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (dgomez1092[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqpRQ-0005lE-Gp
Subject: Re: [Bitcoin-development] Block Size Increase (Raystonn)
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: Fri, 08 May 2015 21:04:17 -0000
--001a11c334e6a35a7b0515985edc
Content-Type: text/plain; charset=UTF-8
Hello,
I was reading some of the thread but can't say I read the entire thing.
I think that it is realistic to cinsider a nlock sixe of 20MB for any block
txn to occur. THis is an enormous amount of data (relatively for a netwkrk)
in which the avergage rate of 10tps over 10 miniutes would allow for
fewasible transformation of data at this curent point in time.
Though I do not see what extra hash information would be stored in the
overall ecosystem as we begin to describe what the scripts that are
atacrhed tp the blockchain would carry,
I'd therefore think that for the remainder of this year that it is possible
to have a block chain within 200 - 300 bytes that is more charatereistic of
some feasible attempts at attaching nuanced data in order to keep propliifc
the blockchain but have these identifiers be integral OPSIg of the the
entiore block. THe reasoning behind this has to do with encryption
standards that can be added toe a chain such as th DH algoritnm keys that
would allow for a higher integrity level withinin the system as it is.
Cutrent;y tyh prootocl oomnly controls for the amount of transactions
through if TxnOut script and the publin key coming form teh lcoation of the
proof-of-work. Form this then I think that a rate of higher than then
current standard of 92bytes allows for GPUS ie CUDA to perfirm its standard
operations of 1216 flops in rde rto mechanize a new personal identity
within the chain that also attaches an encrypted instance of a further
categorical variable that we can prsribved to it.
I think with the current BIP7 prootclol for transactions there is an area
of vulnerability for man-in-the-middle attacks upon request of bitcin to
any merchant as is. It would contraidct the security of the bitcoin if it
was intereceptefd iand not allowed to reach tthe payment network or if the
hash was reveresed in orfr to change the value it had. Therefore the
current best fit block size today is between 200 - 300 bytws (depending on
how exciteed we get)
Thanks for letting me join the conversation
I welcomes any vhalleneged and will reply with more research as i figure
out what problems are revealed in my current formation of thoughts (sorry
for the errors but i am just trying to move forward ---> THE DELRERT KEY
LITERALLY PREVENTS IT )
_Damian
--001a11c334e6a35a7b0515985edc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,=C2=A0<div><br></div><div>I was reading some of the =
thread but can't say I read the entire thing.=C2=A0</div><div><br></div=
><div>I think that it is realistic to cinsider a nlock sixe of 20MB for any=
block txn to occur. THis is an enormous amount of data (relatively for a n=
etwkrk) in which the avergage rate of 10tps over 10 miniutes would allow fo=
r fewasible transformation of data at this curent point in time.</div><div>=
<br></div><div>Though I do not see what extra hash information would be sto=
red in the overall ecosystem as we begin to describe what the scripts that =
are atacrhed tp the blockchain would carry,=C2=A0</div><div><br></div><div>=
I'd therefore think that for the remainder of this year that it is poss=
ible to have a block chain within 200 - 300 bytes that is more charatereist=
ic of some feasible attempts at attaching nuanced data in order to keep pro=
pliifc the blockchain but have these identifiers be integral OPSIg of the t=
he entiore block. THe reasoning behind this has to do with encryption stand=
ards that can be added toe a chain such as th DH algoritnm keys that would =
allow for a higher integrity level withinin the system as it is. Cutrent;y =
tyh prootocl oomnly controls for the amount of transactions through if TxnO=
ut script and the publin key coming form teh lcoation of the proof-of-work.=
Form this then I think that a rate of higher than then current standard of=
92bytes allows for GPUS ie CUDA to perfirm its standard operations of =C2=
=A01216 flops =C2=A0 in rde rto mechanize a new personal identity within th=
e chain that also attaches an encrypted instance of a further categorical v=
ariable that we can prsribved to it.=C2=A0</div><div><br></div><div>I think=
with the current BIP7 prootclol for transactions there is an area of vulne=
rability for man-in-the-middle attacks upon request of =C2=A0bitcin to any =
merchant as is. It would contraidct the security of the bitcoin if it was i=
ntereceptefd iand not allowed to reach tthe payment network or if the hash =
was reveresed in orfr to change the value it had. Therefore the current bes=
t fit block size today is between 200 - 300 bytws (depending on how excitee=
d we get)</div><div><br></div><div><br></div><div><br></div><div>Thanks for=
letting me join the conversation</div><div>I welcomes any vhalleneged and =
will reply with more research as i figure out what problems are revealed in=
my current formation of thoughts (sorry for the errors but i am just tryin=
g to move forward ---> THE DELRERT KEY LITERALLY PREVENTS IT )</div><div=
><br></div><div><br></div><div>_Damian</div></div>
--001a11c334e6a35a7b0515985edc--
|
