Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UeISP-0001LI-Ov for bitcoin-development@lists.sourceforge.net; Mon, 20 May 2013 05:16:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of quinnharris.me designates 67.223.164.214 as permitted sender) client-ip=67.223.164.214; envelope-from=btcdev@quinnharris.me; helo=fza.durangomail.com; Received: from fza.durangomail.com ([67.223.164.214]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UeISN-0006kN-Fc for bitcoin-development@lists.sourceforge.net; Mon, 20 May 2013 05:16:25 +0000 Received: from localhost (localhost [127.0.0.1]) by fza.durangomail.com (Postfix) with ESMTP id 665CE1EAE33 for ; Sun, 19 May 2013 23:16:17 -0600 (MDT) X-Virus-Scanned: amavisd-new at fza.durangomail.com Received: from fza.durangomail.com ([127.0.0.1]) by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKiV5036_Q4a for ; Sun, 19 May 2013 23:16:15 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by fza.durangomail.com (Postfix) with ESMTP id ACA051EAFA3 for ; Sun, 19 May 2013 23:16:15 -0600 (MDT) X-Virus-Scanned: amavisd-new at fza.durangomail.com Received: from fza.durangomail.com ([127.0.0.1]) by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NS0bgq7OJ4zs for ; Sun, 19 May 2013 23:16:15 -0600 (MDT) Received: from [192.168.1.74] (172-3-184-238.lightspeed.sntcca.sbcglobal.net [172.3.184.238]) by fza.durangomail.com (Postfix) with ESMTPSA id 2B4C61EAE33 for ; Sun, 19 May 2013 23:16:15 -0600 (MDT) Message-ID: <5199B19C.9020800@quinnharris.me> Date: Sun, 19 May 2013 23:16:12 -0600 From: Quinn Harris User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20130516100206.82680@gmx.com> In-Reply-To: <20130516100206.82680@gmx.com> Content-Type: multipart/alternative; boundary="------------040303000109080609010007" X-Spam-Score: -0.5 (/) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1UeISN-0006kN-Fc 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: Mon, 20 May 2013 05:16:26 -0000 This is a multi-part message in MIME format. --------------040303000109080609010007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Could this modularization effort lead to a special compiled bitcoind simulator that runs many virtual instances of a node on the same system (possibly same process)? The simulator would cache crypto computation results (ECDSA, SSH-256) to significantly speed up processing transactions and blocks between the virtual nodes. The virtual nodes would also need to share the same block data in memory when possible. This would also require significant additional work to simulate the network and possibly computational limits. The transactions on the existing block chain could be replayed into randomly chosen virtual nodes to help ensure any code changes would not have caused problems with historic transactions. You could even record all the messages for some time on many real nodes and use that as test data for the simulator. Many other test programs could be devised to quickly simulate other network activity. This wouldn't completely replace the test network but could provide greater and quicker confidence that code changes are safe. - Quinn On 05/16/2013 04:02 AM, bitcoingrant@gmx.com wrote: > One of the primary upcoming priorities for bitcoin's infrastructure, > beyond the bloom filter, will be the continued modularization of the > system. > > Here at the Bitcoin Grant, we would like to jump start this > development with a financial incentive and initiate an ongoing > conversation on how we can work together towards developing a smarter, > more efficient system of tomorrow, today. > > Up for grabs: 500 bitcoins or $500,000; whichever is greater. > > Taking on a project of this scope is a highly intensive, technical > undertaking and we believe excellent developers should be compensated > as such, especially when it comes to open source projects. > > One 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 directly to a relay node, based on the bloom filter. > Meanwhile, the block node will maintain the block chain and validate > and relay new blocks. > > Such developments would significantly strengthen the system. > Modularization would make cancer attacks less likely and increase the > node count, which, currently, is fairly low. > > This is by no means is a feature request, merely ideas 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 > submiting a grant proposal. > > http://bitcoingrant.org > > > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------040303000109080609010007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Could this modularization effort lead to a special compiled bitcoind simulator that runs many virtual instances of a node on the same system (possibly same process)?  The simulator would cache crypto computation results (ECDSA, SSH-256) to significantly speed up processing transactions and blocks between the virtual nodes.  The virtual nodes would also need to share the same block data in memory when possible.  This would also require significant additional work to simulate the network and possibly computational limits.

The transactions on the existing block chain could be replayed into randomly chosen virtual nodes to help ensure any code changes would not have caused problems with historic transactions.  You could even record all the messages for some time on many real nodes and use that as test data for the simulator.  Many other test programs could be devised to quickly simulate other network activity.

This wouldn't completely replace the test network but could provide greater and quicker confidence that code changes are safe.

- Quinn


On 05/16/2013 04:02 AM, bitcoingrant@gmx.com wrote:
One of the primary upcoming priorities for bitcoin’s infrastructure, beyond the bloom filter, will be the continued modularization of the system.

Here at the Bitcoin Grant, we would like to jump start this development with a financial incentive and initiate an ongoing conversation on how we can work together towards developing a smarter, more efficient system of tomorrow, today.

Up for grabs: 500 bitcoins or $500,000; whichever is greater.

Taking on a project of this scope is a highly intensive, technical undertaking and we believe excellent developers should be compensated as such, especially when it comes to open source projects.

One 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 directly to a relay node, based on the bloom filter. Meanwhile, the block node will maintain the block chain and validate and relay new blocks.

Such developments would significantly strengthen the system. Modularization would make cancer attacks less likely and increase the node count, which, currently, is fairly low.

This is by no means is a feature request, merely ideas 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 submiting a grant proposal.

http://bitcoingrant.org

 


  

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------040303000109080609010007--