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 1QrGQe-0001hd-14 for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 21:35:08 +0000 X-ACL-Warn: Received: from mail-iy0-f171.google.com ([209.85.210.171]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrGQd-00084t-6K for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 21:35:07 +0000 Received: by iyf13 with SMTP id 13so2091793iyf.30 for ; Wed, 10 Aug 2011 14:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.244.3 with SMTP id lo3mr7979721icb.335.1313012101439; Wed, 10 Aug 2011 14:35:01 -0700 (PDT) Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 14:35:01 -0700 (PDT) X-Originating-IP: [99.173.148.118] In-Reply-To: <201108102213.09632.andyparkins@gmail.com> References: <201108102032.00373.andyparkins@gmail.com> <201108102213.09632.andyparkins@gmail.com> Date: Wed, 10 Aug 2011 17:35:01 -0400 Message-ID: From: Jeff Garzik To: Andy Parkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1QrGQd-00084t-6K Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Change to multiple executables? 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: Wed, 10 Aug 2011 21:35:08 -0000 On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins wrote= : > Don't believe me? =A0Here's a list of ideas I've had "no, no, no"d so far= ; not > one of which would have any financial implication at all. =A0Only some of > which would break backward compatibility. Breaking backwards compatibility means breaking people's access to their own money. If you remove an "unnecessary" step that existing nodes expect, then the cost of disrupting monetary access seems higher than the value of that breaking change. > =A0- Extra bits in the service field of the version message to allow node= s > =A0 to indicate if they are mining; if they are willing to be seed nodes; > =A0 if they relay transactions; if they want relayed transactions. My own 'supernode' proposal also includes using the nServices bits. There's nothing fundamentally incompatible or wrong about that. > =A0- Remove verack, as it's completely unnecessary. Compatibility issues? > =A0- Query miners for pending transactions I could see value in querying a bitcoind node over JSON-RPC for pending transactions... and by extension, supporting that as an RPC on various miners' pool servers. Having a local dump of pending TX's would be useful. As an optional bitcoin P2P protocol command, available to anyone, seems to negatively impact privacy. > =A0- Application version separate from client version Consensus has already approved this one, AFAIK. > =A0- A way of requesting block bodies without headers (saving a lot of tr= affic > =A0 for a thin client upgrading) Do you mean headers without bodies? Gavin wants to work on headers-only, from what I've read, but others are welcome to contribute patches. > =A0- Double SHA-256 for a packet checksum? =A0Seriously? Compatibility issues? > =A0- Sequence number as part of TxIn instead of part of the whole transac= tion Compatibility issues? > =A0- Script parameters should be stored outside the script, and reference= by > =A0 the script. =A0All that ridiculous filtering of the scripts in OP_CHE= CKSIG > =A0 would then go away. Compatibility issues? > =A0- MSG_DOUBLESPEND... nope Does consensus want this? > =A0- getblocks to accept MSG_TX and do something sensible Link to elaboration of use case and need? > You can imagine then that when I read moans about there not being enough = new > developers fixing bugs, that I am unsurprised and unsympathetic. =A0I lik= e > bitcoin enough to hover on this list; and offer a view of your world from= a > potential developer who was chased away. Well, one unfortunate current aspect of bitcoin is... there seem to be problems aplenty right now :) However demotivating it may be, keeping the current system running must take priority over new features. I also heartily encourage others to do something I always want to do, but for lack of time: work on the design for bitcoin v2 ("theme: any breaking change is acceptable, it is a new block chain") There you may improve the protocol, get rid of the patent-cloudy ECDSA, use google's protocol buffers for encoding, make the proof-of-work algorithm memory-intensive, and other excellent, thoughtful breaking-change suggestions that have been made. Securing the integrity of money means that a lot of implementation decisions have been cemented into stone, however much we may personally dislike them. Backwards compatibility is paramount. --=20 Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com