Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ugim1-0001t6-54 for bitcoin-development@lists.sourceforge.net; Sun, 26 May 2013 21:46:41 +0000 X-ACL-Warn: Received: from nm40-vm8.bullet.mail.ne1.yahoo.com ([98.138.229.184]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Ugily-0007FA-6A for bitcoin-development@lists.sourceforge.net; Sun, 26 May 2013 21:46:41 +0000 Received: from [98.138.226.176] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2013 21:46:32 -0000 Received: from [98.138.226.168] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2013 21:46:32 -0000 Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 26 May 2013 21:46:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 736393.99485.bm@omp1069.mail.ne1.yahoo.com Received: (qmail 77555 invoked by uid 60001); 26 May 2013 21:46:32 -0000 X-YMail-OSG: n0ODKKkVM1kdzWaaJ1nor5BhZfTwi8YsXpFKHeKYjhX.4Q1 By91OP95P1wPiW.SEZcmsuMnz0cb_i1f_gC96j9d0AkXffD2n8E3PCc53N3y o6DwxZgawXv_zxK18MNbgQJ4sZKcWMqrnF.XDCOxcCcWYEuvziPjLWHB.Ez_ fJR1aEn8UZjeNVKAncm6rtrjMj3E2dgHrMYVNB3tkJa1PBPzKWlN70i7ziWC v77MZKyGCqSFbEZc6S_pDT.Wpqp5iATvVinAhhLMKV0.GjbiruJnHR5v2gnC z3t08T0sbV5kr_kkGexuWW0a5ZM1C2qaUzUPi4SUljcxZoDfFtFm58p4w1k6 WFZ.1Wlkkae11HUHWwI2x7ZsmqYOAuQIn_l5kdXhms96CqKzXanzLyeG5.OU 13RMBi6mbIqy6RscMY.aUfqXV5spTqFL2ZJSuQTWpfLpt4_RBPpdnzz0RSs8 ZcxLyBTYmdnEx5ftbk7RPw4._Uh5rhC1ff9sEuATl.NASuPZiFPRSuy3k8uK WfnGk7HxeRw5aSf6vEG1r2Gf9fiNqa_1lEjERysbEqakWmmhD84U0z8SSAbN vXpakg.SHYhjNgg-- Received: from [68.193.144.167] by web124503.mail.ne1.yahoo.com via HTTP; Sun, 26 May 2013 14:46:32 PDT X-Rocket-MIMEInfo: 002.001, RnJvbTogPGJpdGNvaW5ncmFudEBnbS4uLj4gLSAyMDEzLTA1LTE2IDEwOjAyCgkgIAkKCgogICAgICAgICAgICAKICAgICAgICAgICAgCiAgICAgICAgICAgIE9uZSBvZiB0aGUgcHJpbWFyeSB1cGNvbWluZyBwcmlvcml0aWVzIGZvciBiaXRjb2lu4oCZcyBpbmZyYXN0cnVjdHVyZSwgYmV5b25kIHRoZSBibG9vbSBmaWx0ZXIsIHdpbGwgYmUgdGhlIGNvbnRpbnVlZCBtb2R1bGFyaXphdGlvbiBvZiB0aGUgc3lzdGVtLgpIZXJlIGF0IHRoZSBCaXRjb2luIEdyYW50LCB3ZSB3b3VsZCBsaWtlIHRvIGp1bXAgc3QBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.144.546 Message-ID: <1369604792.77530.YahooMailClassic@web124503.mail.ne1.yahoo.com> Date: Sun, 26 May 2013 14:46:32 -0700 (PDT) From: Ron To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1103591728-1141625165-1369604792=:77530" X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.229.184 listed in list.dnswl.org] 0.6 HK_RANDOM_ENVFROM Envelope sender username looks random 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rdwnj[at]yahoo.com) -1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 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 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1Ugily-0007FA-6A Subject: Re: [Bitcoin-development] Modularizing Bitcoin 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: Sun, 26 May 2013 21:46:41 -0000 ---1103591728-1141625165-1369604792=:77530 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: - 2013-05-16 10:02=0A=09 =09=0A=0A=0A = =0A =0A One of the primary upcoming priorities for = bitcoin=E2=80=99s infrastructure, beyond the bloom filter, will be the cont= inued modularization of the system.=0AHere at the Bitcoin Grant, we would l= ike to jump start this development with a financial incentive and initiate = an ongoing conversation on how we can work together towards developing a sm= arter, more efficient system of tomorrow, today.=0AUp for grabs: 500 bitcoi= ns or $500,000; whichever is greater.=0ATaking on a project of this scope i= s a highly intensive, technical undertaking and we believe excellent develo= pers should be compensated as such, especially when it comes to open source= projects.=0AOne of the main goals will be to separate the wallet from the = node, as we have already done with mining. This way, the wallet, which will= only hold private keys and create transactions, would pass transactions di= rectly to a relay node, based on the bloom filter. Meanwhile, the block nod= e will maintain the block chain and validate and relay new blocks.=0ASuch d= evelopments would significantly strengthen the system. Modularization would= make cancer attacks less likely and increase the node count, which, curren= tly, is fairly low.=0AThis is by no means is a feature request, merely idea= s as to initiate a discussion. We welcome any feedback or suggestions. And = of course, let us know if you would like to contribute to this project by s= ubmiting a grant proposal.=0Ahttp://bitcoingrant.org http://bitcoingrant.or= g/&lang=3Den=0A=0A Hello I don't know if this is the proper method of replying or even if=20 I am allowed to reply! Modularization can have many meanings, depending upon one's past!=20 The code is somewhat compartmentalized/modularized now. But if one=20 forces complete separation of the parts, with a 'loose coupling',=20 etc., I find that the performance tends to suffer and the size=20 increases.=20 In the Java world there is the notion of refactoring one's code.=20 This would be too much, I think, in this case. When I developed=20 with a team and alone, I would make what used to be called=20 'step-wise refinements' on existing working code. To me, one of=20 things this meant was doing a one to one transformation of the=20 source code, in such a way as to have the identical, byte for=20 byte, executable file, but a 'better' set of source files. A=20 similar process would seem appropriate here. Especially since=20 there is much in the code that I don't understand :)=20 As to 'separating the wallet from the node', do you mean allowing=20 the wallet.dat file to be anywhere, and not restricted to the 'OS default'= =20 or 'datadir' directory? If so, I have done that with no change to the=20 current behavior, and also the wallet.dat now can have any legal=20 filename too! I haven't tested it yet on bitcoin-qt, but it runs=20 on bitcoind. I am still 'ramping up' on github to get the code into=20 view. After testing on bitcoin-qt of course. What may I ask, is a cancer attack? If any of this inappropriate, forgive me. Ron ---1103591728-1141625165-1369604792=:77530 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=
<= tbody>
From: <bitcoingrant@gm...> - 2013-05-16 10:02=0A=09 =09=0A=0A=0A =0A =0A 
One of the primary upcoming priorities for bitcoin=E2=80=99s infr=
astructure, beyond the bloom filter, will be the continued modularization o=
f the system.=0AHere at the Bitcoin Grant, we would like to jump start this=
 development with a financial incentive and initiate an ongoing conversatio=
n on how we can work together towards developing a smarter, more efficient =
system of tomorrow, today.=0AUp for grabs: 500 bitcoins or $500,000; whiche=
ver is greater.=0ATaking on a project of this scope is a highly intensive, =
technical undertaking and we believe excellent developers should be compens=
ated as such, especially when it comes to open source projects.=0AOne of th=
e main goals will be to separate the wallet from the node, as we have alrea=
dy done with mining. This way, the wallet, which will only hold private key=
s and create transactions, would pass transactions directly to a relay node=
, based on the bloom filter. Meanwhile, the block node will maintain the bl=
ock chain and validate and relay new blocks.=0ASuch developments would sign=
ificantly strengthen the system. Modularization would make cancer attacks l=
ess likely and increase the node count, which, currently, is fairly low.=0A=
This is by no means is a feature request, merely ideas as to initiate a dis=
cussion. We welcome any feedback or suggestions. And of course, let us know=
 if you would like to contribute to this project by submiting a grant propo=
sal.=0Ahttp://bitcoingrant.org http://bitcoingrant.org/&la=
ng=3Den=0A=0A
Hello

I don't know if this is the proper method=
 of replying or even if 
I am allowed to reply!

Modularization ca=
n have many meanings, depending upon one's past! 
The code is somewhat c=
ompartmentalized/modularized now. But if one 
forces complete separation=
 of the parts, with a 'loose coupling', 
etc., I find that the performan=
ce tends to suffer and the size 
increases. 

In the Java world th=
ere is the notion of refactoring one's code. 
This would be too much, I =
think, in this case. When I developed 
with a team and alone, I would ma=
ke what used to be called 
'step-wise refinements' on existing working c=
ode. To me, one of 
things this meant was doing a one to one transformat=
ion of the 
source code, in such a way as to have the identical, byte fo=
r 
byte, executable file, but a 'better' set of source files. A 
simi=
lar process would seem appropriate here. Especially since 
there is much=
 in the
 code that I don't understand :) 

As to 'separating the wallet from =
the node', do you mean allowing 
the wallet.dat file to be anywhere, and=
 not restricted to the 'OS default' 
or 'datadir' directory? If so, I ha=
ve done that with no change to the 
current behavior, and also the walle=
t.dat now can have any legal 
filename too! I haven't tested it yet on b=
itcoin-qt, but it runs 
on bitcoind. I am still 'ramping up' on github t=
o get the code into 
view. After testing on bitcoin-qt of course.
What may I ask, is a cancer attack?

If any of this inappropriate, f=
orgive me.

Ron
---1103591728-1141625165-1369604792=:77530--