From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WRPQh-0001Ob-6G for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 17:09:55 +0000 Received: from mail-pa0-f45.google.com ([209.85.220.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WRPQg-0000CQ-8F for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 17:09:55 +0000 Received: by mail-pa0-f45.google.com with SMTP id kl14so3693983pab.4 for ; Sat, 22 Mar 2014 10:09:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oheBgBNoDTypdh/ZLSQztnGbbEsbbgMyNe+6UUa9KLQ=; b=l8NhSPrXUlT8Mhq1KdaMzTik82G+v8fVVnA1gInzwH5Fz58sUkwVpw03WtPiHhbW4X wSmst4j/DiNwvJ0B602ryLC33ES36+o5kYSSObpGMYTt+Kpwc9IGOfNKQ4e6fxTjYX5x xQGfa800g/bBVf6JLkTS2X1IYPwlfwwQDGVcrUIRgNjBar/YCnXyTUmxK8o0OYWqUBME YfzX7wDEq44dM5XPGq0+BUpDKKITWGwI+WFO5ugs8o8T58ZGd8fX9m6lU3q7Q9dOvlg9 uPwXAfB9oeH4VhIFZATmx/4aGoz0S9c9CSwAoOAd3AbTWcD57av3h4tLQ0eCSdK3ey9x NV/w== X-Gm-Message-State: ALoCoQldTuEUNyuWBJFvp/Ik8Y2M11VUBelUoU3x0+/7RPS4VYa0evsosqLV7jIBuFfRoV2LCTPJ X-Received: by 10.67.4.169 with SMTP id cf9mr61338687pad.45.1395507870888; Sat, 22 Mar 2014 10:04:30 -0700 (PDT) Received: from [192.168.127.179] (50-0-36-93.dsl.dynamic.sonic.net. [50.0.36.93]) by mx.google.com with ESMTPSA id nx12sm44795009pab.6.2014.03.22.10.04.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Mar 2014 10:04:30 -0700 (PDT) Message-ID: <532DC29E.4080304@monetize.io> Date: Sat, 22 Mar 2014 10:04:30 -0700 From: Mark Friedenbach Organization: Monetize.io Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop> In-Reply-To: <20140322150836.GG3180@nl.grid.coop> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 1WRPQg-0000CQ-8F 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 17:09:55 -0000 Please, by all means: ignore our well-reasoned arguments about externalized storage and validation cost and alternative solutions. Please re-discover how proof of publication doesn't require burdening the network with silly extra data that must be transmitted, kept, and validated from now until the heat death of the universe. Your failure will make my meager bitcoin holdings all the more valuable! As despite persistent assertions to the contrary, making quality software freely available at zero cost does not pay well, even in finance. You will not find core developers in the Bitcoin 1%. Please feel free to flame me back, but off-list. This is for *bitcoin* development. On 03/22/2014 08:08 AM, Troy Benjegerdes wrote: > 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. >