diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2014-11-17 13:00:07 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-11-17 12:00:14 +0000 |
| commit | 43f2234887ec99b3654210634195f91016174345 (patch) | |
| tree | cd80a50e7fc46d5d08b86c1c5aa8d13cbd1baa1b | |
| parent | a22ec9e4aec0df5e82ddc027629698c3daaffd7b (diff) | |
| download | pi-bitcoindev-43f2234887ec99b3654210634195f91016174345.tar.gz pi-bitcoindev-43f2234887ec99b3654210634195f91016174345.zip | |
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
| -rw-r--r-- | 7c/5d4e5798ed7b8b0f689c8598245794e7e2c714 | 101 |
1 files changed, 101 insertions, 0 deletions
diff --git a/7c/5d4e5798ed7b8b0f689c8598245794e7e2c714 b/7c/5d4e5798ed7b8b0f689c8598245794e7e2c714 new file mode 100644 index 000000000..3d92bebfd --- /dev/null +++ b/7c/5d4e5798ed7b8b0f689c8598245794e7e2c714 @@ -0,0 +1,101 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pieter.wuille@gmail.com>) id 1XqKyc-0003z0-1S + for bitcoin-development@lists.sourceforge.net; + Mon, 17 Nov 2014 12:00:14 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.213.180 as permitted sender) + client-ip=209.85.213.180; envelope-from=pieter.wuille@gmail.com; + helo=mail-ig0-f180.google.com; +Received: from mail-ig0-f180.google.com ([209.85.213.180]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1XqKyb-0002ZR-7Z + for bitcoin-development@lists.sourceforge.net; + Mon, 17 Nov 2014 12:00:14 +0000 +Received: by mail-ig0-f180.google.com with SMTP id h15so4978214igd.13 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 17 Nov 2014 04:00:08 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.107.137.84 with SMTP id l81mr2014604iod.61.1416225607886; + Mon, 17 Nov 2014 04:00:07 -0800 (PST) +Received: by 10.50.248.5 with HTTP; Mon, 17 Nov 2014 04:00:07 -0800 (PST) +In-Reply-To: <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com> +References: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com> + <201411161724.19573.luke@dashjr.org> + <CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com> + <CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com> + <5469692F.9030702@gmail.com> + <CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com> + <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com> +Date: Mon, 17 Nov 2014 13:00:07 +0100 +Message-ID: <CAPg+sBjrgKtv+teEobckRLRuw_o0eTN=R5YQE8=Mv6LT5oTCDQ@mail.gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Flavien Charlon <flavien.charlon@coinprism.com> +Content-Type: text/plain; charset=ISO-8859-1 +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1XqKyb-0002ZR-7Z +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload + size +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, 17 Nov 2014 12:00:14 -0000 + +On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon +<flavien.charlon@coinprism.com> wrote: +>> My main concern with OP_RETURN is that it seems to encourage people to use +>> the blockchain as a convenient transport channel +> +> The number one user of the blockchain as a storage and transport mechanism +> is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from +> doing so. In fact they use multi-sig outputs which is worse than OP_RETURN +> since it's not always prunable, and yet let them store much more than 40 +> bytes. + +It wasn't limited to stop them from using it. It was limited to avoid +giving others the impression that OP_RETURN was intended for data +storage. For the intended purpose (making a transaction commit to some +external data) a 32-byte hash + 8 byte id is more than sufficient. + +> For Open Assets, we need to store a URL in the OP_RETURN output (with +> optionally a hash) plus some bytes of overhead. 40 bytes comes really short +> for that. The benefit of having a URL in there is that any storage mechanism +> can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, +> you have to hardcode the storing mechanism in the protocol (and even then, a +> hash is not enough to address a HTTP or FTP resource). Storing only a hash +> is fine for the most basic timestamping application, but it's hardly enough +> to build something interesting. + +Do you really need that data published to everyone? You're at the very +least exposing yourself to censorship, and (depending on the design) +potentially decreased privacy for your users. I would expect that for +most colored coin applications, just having the color transfer +information in external data sent directly to the receiver with +transactions committing to it should suffice. + +-- +Pieter + + |