public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: Damian Gomez <dgomez1092@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Block Size Increase (Raystonn)
Date: Fri, 8 May 2015 14:04:10 -0700	[thread overview]
Message-ID: <CAH+jCTxVe-2wKy8p5tvc8mMApzA_gg3_n-ZRcqiQrZzv+OOx4g@mail.gmail.com> (raw)

[-- 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 --]

                 reply	other threads:[~2015-05-08 21:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH+jCTxVe-2wKy8p5tvc8mMApzA_gg3_n-ZRcqiQrZzv+OOx4g@mail.gmail.com \
    --to=dgomez1092@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox