diff options
author | Andreas Petersson <andreas@petersson.at> | 2014-02-25 00:06:30 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-02-24 23:06:56 +0000 |
commit | 65e63db130c52a49ad2e2d172f6424a52be0101a (patch) | |
tree | fddffd6e27277b39233c9ff36246790685b2280e | |
parent | 2bc24d7f978087ee80d5c74a8dba4ab9d88f3a08 (diff) | |
download | pi-bitcoindev-65e63db130c52a49ad2e2d172f6424a52be0101a.tar.gz pi-bitcoindev-65e63db130c52a49ad2e2d172f6424a52be0101a.zip |
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
-rw-r--r-- | c9/9961aaf8024cba04a81ab646c0f4fb01dc21d8 | 64 |
1 files changed, 64 insertions, 0 deletions
diff --git a/c9/9961aaf8024cba04a81ab646c0f4fb01dc21d8 b/c9/9961aaf8024cba04a81ab646c0f4fb01dc21d8 new file mode 100644 index 000000000..90023ffd6 --- /dev/null +++ b/c9/9961aaf8024cba04a81ab646c0f4fb01dc21d8 @@ -0,0 +1,64 @@ +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 <andreas@petersson.at>) 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 <bitcoin-development@lists.sourceforge.net>; + 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 <andreas@petersson.at> +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: <CAJHLa0PXHY1qisXhN98DMxgp11ouqkzYMBvrTTNOtwX09T1kZg@mail.gmail.com> <CA+s+GJC1FgCW9spkViMPvuWNS84Ys33pj=RP1ZpzBCa++e-iMQ@mail.gmail.com> + <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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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) + + |