From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WJFPY-0007ma-Ms for bitcoin-development@lists.sourceforge.net; Fri, 28 Feb 2014 04:51:00 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WJFPW-0005HZ-P5 for bitcoin-development@lists.sourceforge.net; Fri, 28 Feb 2014 04:51:00 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Thu, 27 Feb 2014 22:50:51 -0600 id 000000000006A340.00000000531015AB.000057EB Date: Thu, 27 Feb 2014 22:50:51 -0600 From: Troy Benjegerdes To: Peter Todd Message-ID: <20140228045051.GM3180@nl.grid.coop> References: <20140225044116.GA28050@savin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20140225044116.GA28050@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WJFPW-0005HZ-P5 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Fee drop 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: Fri, 28 Feb 2014 04:51:00 -0000 On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote: > So, just to be clear, we're adding, say, a memory limited mempool or > something prior to release so this fee drop doesn't open up an obvious > low-risk DDoS exploit.... right? As we all know, the network bandwidth > DoS attack mitigation strategy relies on transactions we accept to > mempools getting mined, and the clearance rate of the new low-fee > transactions is going to be pretty small; we've already had problems in > the past with mempool growth in periods of high demand. Equally it > should be obvious to people how you can create large groups of low-fee > transactions, and then cheaply double-spend them with higher fee > transactions to suck up network bandwidth - just like I raised for the > equally foolish double-spend propagation pull-req. > > Of course, there's also the problem that we're basically lying to people > about whether or not Bitcoin is a good medium for microtransactions. > It's not. Saying otherwise by releasing software that has known and > obvious DoS attack vulnerabilities that didn't exist in the previous > version is irresponsible on multiple levels. Well, if your investors take money with market manipulating news stories, this is absolutely the responsible thing to do to increase shareholder value with a future opportunity to cause a crash-on-demand. Besides, if you really want microtransactions, you should be using an altcoin with faster block times, smaller market cap, and larger 'human' readable currency supply. That being said, I'd say include the change, we all know about it. What would be nice would be some exploits and attack signatures for what the DOS will look like when it hits so that those of us paying attention can make some money trading in anticipation of the market crash instead of just the guys paying for the attack. The real killer feature of Bitcoin is that we can learn from it's mistakes (and bitcoin can learn from the copycatcoins), instead of one-size-fits all fiat. -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash