Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMO<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=286.msg2745#msg2745">Quote from: gavinandresen on July 14, 2010, 04:22:49 AM</a></div><div class="quote">Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.<br/></div><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=286.msg2745#msg2745">Quote from: gavinandresen on July 14, 2010, 04:22:49 AM</a></div><div class="quote">Don't worry much about it until just before it becomes a problem.&nbsp; Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.<br/></div><br/>I agree with both points but they also seem to be somewhat mutually contradictory to me (this may be because of ignorance more than anything). Perhaps you can illuminate what steps you think need to be taken to "make it easier for merchants to accept bitcoins and users to pay using them". In my view, having a lightweight client, build on fairly open standards would facilitate making transactions easier. Ideally this lightweight client would/could be implemented in a number of languages/platforms.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=286.msg2745#msg2745">Quote from: gavinandresen on July 14, 2010, 04:22:49 AM</a></div><div class="quote">Don't worry much about it until just before it becomes a problem.&nbsp; Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.<br/></div><br/>This is certainly good advice: "beware of premature optimization". I would like to point out though that optimization and system architecture are different beasts. Planning for scalability is a system architecture task. The whole "Don't overengineer" paradigm is more of an implementation &amp; design principle and suggests that we should be agile in that we only implement what we need today. An agile perspective does not preclude thinking about and planning out the system architecture, at least testing assumptions mentally and ensuring that "it could scale" when the time comes for that ability to be added. I have been involved in a number of projects that failed not because the underlying technology was bad, but because scalability was never considered or tested up front. Everything worked perfectly until the system was put "to the (scalability) test". A lack of planning and foresight up-front was usually the cause.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=286.msg2745#msg2745">Quote from: gavinandresen on July 14, 2010, 04:22:49 AM</a></div><div class="quote">This quote seems appropriate:<br/>"We reject: kings, presidents and voting.<br/>We believe in: rough consensus and running code."&nbsp; -- David D. Clark<br/></div><br/>I like this quote. There is certainly something to be said for having something that works. I tend to struggle with being a bit of a purist; I have to work at pragmatism. Having said this, you can say: "we have great software. It has very few bugs and it hardly ever crashes" and that all sounds well and good until the day it becomes untrue. Scalability issues can hit you quickly and silently, especially in this day-in-age.<br/><br/>My preference would be, for a project like this, would be to continue to have "working software" but also establish a well defined road-map of where we hope the software is going. This road map needs to discuss scalability and how we envision a system with a million transactions a day would work and looks, not just today but 20 years from now. A currency needs to be resilient. For people to assign value to Bitcoin they need to perceive that it has value and that it is safe. This means they need to be able to trust that the infrastructure &amp; design is (and will be) perpetually reliable. Unfortunately I don't Bitcoin, if it is to be successful, as the luxury of being just another hacked together open source project (I'm not implying that it is hacky...I'm implying that the prevailing mindset and practice in open source tends to be a "hack it together" mind set).</div> text/html