David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-23 📝 Original message:On Tue, Apr 20, 2021 at ...
📅 Original date posted:2021-04-23
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/9b78956c/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/9b78956c/attachment.sig>;