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; 
MIME-Version: 1.0
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
Subject: Re: [Bitcoin-development] Block Size Increase (Raystonn)
Precedence: list

--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&#39;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&#39;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 ---&gt; THE DELRERT KEY LITERALLY PREVENTS IT )</div><div=
><br></div><div><br></div><div>_Damian</div></div>

--001a11c334e6a35a7b0515985edc--