From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WRNXQ-0001TL-T4 for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 15:08:44 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WRNXP-0002XR-Re for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 15:08:44 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Sat, 22 Mar 2014 10:08:36 -0500 id 000000000006A341.00000000532DA774.000006AE Date: Sat, 22 Mar 2014 10:08:36 -0500 From: Troy Benjegerdes To: Peter Todd Message-ID: <20140322150836.GG3180@nl.grid.coop> References: <20140322084702.GA13436@savin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20140322084702.GA13436@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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WRNXP-0002XR-Re Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee 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: Sat, 22 Mar 2014 15:08:45 -0000 On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: > There's been a lot of recent hoopla over proof-of-publication, with the > OP_RETURN length getting reduced to a rather useless 40 bytes at > the last minute prior to the 0.9 release. Secondly I noticed a > overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken > into account, making it possible to broadcast unminable transactions and > bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG > outputs given that the sigops limit and the way they use up a fixed 20 > sigops per op makes them hard to do fee calculations for. They also make > it easy to bloat the UTXO set, potentially a bad thing. This would of > course require things using them to change. Currently that's just > Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. -- ---------------------------------------------------------------------------- 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