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 1WI4bw-0006dv-CK for bitcoin-development@lists.sourceforge.net; Mon, 24 Feb 2014 23:06:56 +0000 Received: from bi.petersson.at ([46.4.24.198] helo=petersson.at) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WI4bv-0003kZ-CN for bitcoin-development@lists.sourceforge.net; Mon, 24 Feb 2014 23:06:56 +0000 Received: from [192.168.0.199] (chello084114039092.14.vie.surfer.at [84.114.39.92]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: andreas) by petersson.at (Postfix) with ESMTPSA id 8B75E238081E for ; Tue, 25 Feb 2014 00:14:03 +0100 (CET) Message-ID: <530BD076.3020606@petersson.at> Date: Tue, 25 Feb 2014 00:06:30 +0100 From: Andreas Petersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <530B8000.1070801@monetize.io> In-Reply-To: <530B8000.1070801@monetize.io> 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. -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WI4bv-0003kZ-CN Subject: Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 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: Mon, 24 Feb 2014 23:06:56 -0000 Regarding 80 bytes vs smaller: The objectives should be that if you are determined to put some extra data in the blockchain, OP_RETURN should be the superior alternative. if a user can include more data with less fees using a multisig TX, then this will happen. eventually dust-limit rules will not be the deciding factor here, since i suspect block propagation times will have a stronger effect on effective fees. therefore a slightly larger payload than the biggest multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes. (this is my understanding of how large a 3-of-3 multisig tx can be, plus 1.5 bits encoded in the "n" parameter)