From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B5BDBC000B for ; Fri, 23 Apr 2021 18:17:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A548D400E9 for ; Fri, 23 Apr 2021 18:17:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsAsD0rL3Cua for ; Fri, 23 Apr 2021 18:17:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from newmail.dtrt.org (newmail.dtrt.org [IPv6:2600:3c03::f03c:91ff:fe7b:78d1]) by smtp2.osuosl.org (Postfix) with ESMTPS id AAD3B400B5 for ; Fri, 23 Apr 2021 18:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org; s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nkyMjWBZR67GRm2dZSi+IqnZk4APlU1Du1hsMiCHWlw=; b=ao3G5ty/jPfjEODbNaBd+t7PrO +3OWREaDo0dGAlQNKqlV020Z5Q2zk/WgEFYKZvb7hSOtQYZ2dTAg7iWzzdtIV+V4P4jlk49SADVAE 0gkA96LnXYk7Wr/3lsbz81lGTG0irLLJIFTj1zayj4DMc+/rK6yqNyBYMiII7oeiYYr4=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1la0Mt-000382-NB; Fri, 23 Apr 2021 08:17:31 -1000 Date: Fri, 23 Apr 2021 08:15:50 -1000 From: "David A. Harding" To: Jeremy , Bitcoin Protocol Discussion Message-ID: <20210423181550.xri2ravlwfe3vpc6@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yaxs7lrk47x4mwnh" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:17:34 -0000 --yaxs7lrk47x4mwnh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote: > Script is technically "too wide" a type as what I really want is to > only return coins with known output types. I don't understand this concern. If script is too wide a type, then OP_RETURN being a scriptPubKey of arbitrary length up to almost a million bytes is also going to be too wide, right? > 1) Should it be human readable & checksummed or encoded? It should absolutely not be human readable in the sense of being meaningful to humans. We've seen in the past that tools and sites that display OP_RETURN data as ASCII encourage people to put text in the block chain that is offensive and illegal. This puts people running nodes at risk of social and legal intervention. Bitcoin's premissionless nature means we can't stop people from creating such problems, but we can lower the risk by having our tools default to meaningless representations of OP_RETURN data. The best advice I've seen is to display OP_RETURN data in hex. It's still possible to say things like "dead beef" with that, but significant abuse is hard. This will, of course, make even 80 byte OP_RETURN "addresses" very long. > 2) Should it have a fixed length of max 40-80 bytes or should we support > arbitrary length strings? If it doesn't support the fell range, somebody's just going to complain later and there will have to be a v2 address. > 3) Should it be possible (i.e., from core) to pay into such an OP_RETURN or > should we categorize OP_RETURNS as a non-payable address type (and just use > it for parsing blockdata) I don't think including arbitrary data in the block chain is something that's currently useful for typical end users, and applications that want to use OP_RETURN with Bitcoin Core can already call create(psbt|rawtransaction) with the `data` field, so I'd be mildly opposed in including such a feature in Bitcoin Core's wallet. If at least a few other wallets add the feature to pay OP_RETURN "addresses" and it seems popular, then I'm wrong and so I would probably then change my position. Regarding "parsing block data", I don't think there's any need to change Bitcoin Core's current representation of OP_RETURN outputs (which is just showing the hex-encoded script in RPC output). For any program needing OP_RETURN output, hex format is going to be a the next best thing to getting it in raw binary. Any other address format is going to be equal or more work. Additionally, as mentioned in the other thread about OP_RETURN this week, increasing transaction fees should increasingly push uses of OP_RETURN off the network or into more efficient constructions, so it doesn't seem warranted to me to spend a lot of time trying to optimize how we use it when we'll be using it less and less over time. -Dave --yaxs7lrk47x4mwnh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmCDDtUACgkQ2dtBqWwi adMlNg/+Pad5O4QtNYq2+vL236XzgPIUUKs7xU65APhO2ziEvqVKG3w4wG8XmYwh IsletdCsKzrHVLcEPPsd+7jL1bNKfdTCzb4AsZRSWlj04k0FX1Gk23LT9ZV7d8re bWZOOrC/C/nKWppyKxtUXTd+MOtVF4he9g6+/0vgxbNQY1z9VKFAz4adXQdtwkXe u07EKsUWbZGSTI7v46Kd38JM8+j53IEzHMZ+fBh9XMLhTiOggWduhPzzuGWM1wNC 3+JPdr382jU1w8CAHDcR5UhFAhfLr9obVoFIHcBeZ1qQxxe7OK5IDuvPpoHx/iUn fYvq7vdT/XuF+bGLokIPJ2FLXp3VEqkRiVbx2qvocEZui8unsOXeWIbrWG0YmZ49 tvMPhtfXgEmVuIqbC578BNZRNOzTpfzKCi6qBeYZX9srrA3UtocoxMrRswhvfxyJ jFOMF5qjotMp2Ba1raBjaElDTwbn1tc88mhmPrdS+v/ZrYXvR9q14rSyJ6+gFlKJ SvTFA7gn8Gp9m+borrYuxCuW4TlyGwcXMnRq8FiBprnnNiXS9mghXBv/0WdQbqqx HTwPnrEffvBdk7rA5IyuqhBYcwJUu2l6Oo5j0iz4vCVP5JV5jRus80tDVJTmVEA4 AL80zb9GPihSfcG9yaeLQF8LSU3yimZ8GddoFECVnvt1zLLQXY0= =EU8a -----END PGP SIGNATURE----- --yaxs7lrk47x4mwnh--