Re: [Bitcoin-development] Block Size Increase (Raystonn)

Re: [Bitcoin-development] Block Size Increase (Raystonn)

[Damian Gomez]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2571 bytes --]