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 ) 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 ; 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: From: Damian Gomez 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hello,=C2=A0

I was reading some of the = thread but can't say I read the entire thing.=C2=A0

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.
=
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

= 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

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)



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 tryin= g to move forward ---> THE DELRERT KEY LITERALLY PREVENTS IT )


_Damian
--001a11c334e6a35a7b0515985edc--