* [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN @ 2021-04-20 15:46 Jeremy 2021-04-23 18:15 ` David A. Harding 0 siblings, 1 reply; 7+ messages in thread From: Jeremy @ 2021-04-20 15:46 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 3509 bytes --] Hi All, Introducing the notion that we might want to have an address type defined for OP_RETURN. I came across this when writing some code that wanted to handle common classes of user transactions generically, it's kind of annoying that you have to write code that's effectively: ``` try { print(script.address()); } catch { try { print(script.op_return()); } catch { print("unknown thing"); } } ``` I think that OP_RETURN, being relatively well defined, could have an address type. This would aid in simplifying types for programs. E.g., in Rust I want to have: ``` struct Coin(Address, Amount) impl Coin { fn get_coin(o: Outpoint) -> Result<Coin, Error>{/**/} } enum Error { UnknownType, CoinDoesNotExist, } ``` and without Address defining OP_RETURN I can't read a Coin containing an OP_RETURN. It would be possible to define Coin to store script, but then everywhere I want an address I would have to perform a conversion and Script is technically "too wide" a type as what I really want is to only return coins with known output types. More concretely this is a challenge for me as I'm building the Sapio compiler and I want to make it so that all contract compilations result in an Address, but I need to support OP_RETURN for various reasons, so I cannot make Sapio only output addresses. As far as I understand the counterargument against this, it is (thanks to Luke Jr): 1) We should only have addresses or descriptors for things we know exactly what they are, and also for things that represent something that is not only payable but also potentially spendable. 2) OP_RETURN, being unspendable and usually proprietary in purpose, should not have an address. 3) Further, most uses of OP_RETURN are proprietary (e.g., we don't know what it represents) so therefore it would be lying to the user to pretend we know how to interpret it. My counterargument is that: 1) Addresses should represent things that people commonly create outputs for -- perhaps regrettably, OP_RETURN is such a thing so software (e.g., https://citp.github.io/BlockSci/reference/addresses/address.html) already does treat OP_RETURN as an address type, just without a standard representation. 2) Many things are unspendable. E.g., a 0 value payment to an address, a payment to P2SH(OP_RETURN <data>), etc. We can't know spendability based on address type. 3) All scripts can have proprietary interpretations, the job of the address is to do our best job of interpreting standard types to the best of our ability. An example where this has been (ab)used previously is P2SH wrapped SegWit, where one cannot distinguish if the underlying is to be evaluated as P2SH or SegWit. Further, future OP_RETURN address types could take precedence if they are well specified. Do folks agree with the motivations for defining an address type? Are there any design constraints? Some starter thoughts 1) Should it be human readable & checksummed or encoded? 2) Should it have a fixed length of max 40-80 bytes or should we support arbitrary length strings? 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) (my answers are 1. human readable + checksum, 2. arbitrary to support nonstandard ones which miners create 3. non payable in standard software) Cheers, Jeremy Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> [-- Attachment #2: Type: text/html, Size: 11549 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN 2021-04-20 15:46 [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN Jeremy @ 2021-04-23 18:15 ` David A. Harding 2021-04-24 20:05 ` Jeremy 0 siblings, 1 reply; 7+ messages in thread From: David A. Harding @ 2021-04-23 18:15 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2804 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN 2021-04-23 18:15 ` David A. Harding @ 2021-04-24 20:05 ` Jeremy 2021-04-24 21:59 ` David A. Harding 0 siblings, 1 reply; 7+ messages in thread From: Jeremy @ 2021-04-24 20:05 UTC (permalink / raw) To: David A. Harding; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5693 bytes --] Inline responses On Fri, Apr 23, 2021, 11:18 AM David A. Harding <dave@dtrt.org> wrote: > 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?* > I meant the type itself is too wide, not the length of the value. As in Script can represent things we know nothing about. There's a bit of leaky abstraction since the values self describe the type they are. For addresses it's just representations IMO for the standard output types one might expect from standard software. Btw: According to... Oh wait... You? https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey the max size is 10k bytes. Still probably too big for an address, but I'd be ok with making op_return addresses only defined for a small size (e.g. 128 bytes?) > > > > > > > > > > > > > > > * > 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.* > Is it possible/easy to, say, using bech32m make an inappropriate message in the address? You'd have to write the message, then see what it decodes to without checking, and then re encode? I guess this is worse than hex? But it seems this is a general thing... If you wanted an inappropriate message you could therefore just use bech32m addressed outputs. > > > > > > * 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.* > So 10,000 bytes? Or do we care to represent outputs that would be consensus invalid? > > > > > > > > > > > > * > 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.* > One of the nice things is that the current psbt interface uses a blind union type whereby the entires in an array are either [address, amount] or ["data", hex]. Having an address type would allow more uniform handling, which is convenient for strongly typed RPC bindings (e.g. rust bitcoin uses a hashmap of address to amount so without a patch you can't create op returns). > > > > > > * 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*. > Thats a fair point. I'm mostly thinking about this in the context of strongly typed languages/frameworks where you'll get an address object or enum out, rather than something *stringly* typed. But yes in terms of stringy languages I don't think any changes are needed. *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.* Hmm. I agree it should get priced out over time. However there are some uses for this kind of stuff. E.g. stealth addresses, or a single instance of open time stamps. The main reason I think they merit some sort of std address type is that I'm writing software that can handle things that we might reasonably see on the network. And it's relatively annoying (without a custom type) to represent OP_RETURN as a not-exceptional type of thing. In my code what I have done is added the following type: pub enum ExtendedAddress { /// A regular standard address type Address(bitcoin::Address), /// An OP_RETURN OpReturn(OpReturn), /// Unknown Unknown(bitcoin::Script), } Which works more or less fine, but I would much prefer to not have to do this in a custom way, as opposed to a way which is defined in a standard manner across all software (after all, that's the point of standards). Best, Jeremy [-- Attachment #2: Type: text/html, Size: 10657 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN 2021-04-24 20:05 ` Jeremy @ 2021-04-24 21:59 ` David A. Harding 2021-04-24 22:29 ` Jeremy 2021-04-24 23:37 ` Zac Greenwood 0 siblings, 2 replies; 7+ messages in thread From: David A. Harding @ 2021-04-24 21:59 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4841 bytes --] On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote: > I meant the type itself is too wide, not the length of the value. As in > Script can represent things we know nothing about. I guess I still don't understand your concern, then. If script can represent things we know nothing about, then script commitments such as P2SH, P2WSH, and P2TR also represent things we know nothing about. All you know is what container format they used. For P2PK, bare multisig, OP_RETURN, and other direct uses of scriptPubKey, that container format is "bare" (or whatever you want to call it). > Btw: According to... Oh wait... You? > https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey > the max size is 10k bytes. I'm not sure what I knew at the time I wrote that answer, but the 10,000 byte limit is only applied when EvalScript is run, which only happens when the output is being spent. I've appended to this email a demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried 999,000 bytes but ran into problems with bash's maximum command line length limit). I've updated the answer to hopefully make it more correct. > Is it possible/easy to, say, using bech32m make an inappropriate message in > the address? You'd have to write the message, then see what it decodes to > without checking, and then re encode? I guess this is worse than hex? If someone wants to abuse bech32m, I suspect they'll do it the same way people have abused base58check[1], by using the address format's alphabet directly. E.g., you compose your message using only the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append the appropriate checksum. [1] https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes > But it seems this is a general thing... If you wanted an inappropriate > message you could therefore just use bech32m addressed outputs. Yes, and people have done that with base58check. IsStandard OP_RETURN attempts to minimize that abuse by being cheaper in two ways: 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I think) for OP_RETURN versus 40 bytes for a BIP141 payload. Maximizing payload size better amortizes the overhead cost of the containing transaction and the output's nValue field. 2. Exemption from the dust limit. If you use a currently defined address type, the nValue needs to pay at least a few thousand nBTC (few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC. For OP_RETURN, the nValue can be 0, so there's no additional cost beyond normal transaction relay fees. Although someone creating an OP_RETURN up to ~1 MB with miner support can bypass the dust limit, the efficiency advantage remains no matter what. > One of the nice things is that the current psbt interface uses a blind > union type whereby the entires in an array are either [address, amount] or > ["data", hex]. Having an address type would allow more uniform handling, > which is convenient for strongly typed RPC bindings (e.g. rust bitcoin uses > a hashmap of address to amount so without a patch you can't create op > returns). I don't particularly care how the data in PSBTs are structured. My mild opposition was to adding code to the wallet that exposes everyday users to OP_RETURN addresses. > I would much prefer to not have to do this in a custom way, as opposed > to a way which is defined in a standard manner across all software > (after all, that's the point of standards). I'm currently +0.1 on the idea of an address format of OP_RETURN, but I want to make sure this isn't underwhelmingly motivated or will lead to a resurgence of block chain graffiti. -Dave ## Creating an 11,000 byte OP_RETURN $ bitcoind -daemon -regtest -acceptnonstdtxn Bitcoin Core starting $ bitcoin-cli -regtest -generate 101 { "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r", "blocks": [ [...] } $ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000 count=11 | xxd -g0 -p | tr -d '\n' )'"}]' 11+0 records in 11+0 records out 11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s { "txid": "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51", "complete": true } $ bitcoin-cli -regtest getrawmempool [ "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51" ] $ bitcoin-cli -regtest -generate 1 { "address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh", "blocks": [ "2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b" ] } $bitcoin-cli -regtest getblock 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b 2 | jq .tx[1].txid "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51" [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN 2021-04-24 21:59 ` David A. Harding @ 2021-04-24 22:29 ` Jeremy 2021-04-24 23:37 ` Zac Greenwood 1 sibling, 0 replies; 7+ messages in thread From: Jeremy @ 2021-04-24 22:29 UTC (permalink / raw) To: David A. Harding; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5667 bytes --] I guess in the interest of being clear; I don't particularly want a OP_RETURN address either, they're just annoying to program around, and they exist historically, as well as perhaps in the future. Maybe people will start using the annex space to add any metadata required? E.g. stealth addresses. I kinda hope not, but probably will be proposed as a SF since it's much cheaper (witness + no amount) and per-input vs. per-tx. It's interesting that they can be created with any length... i guess any script can be an op return if you make it long enough... -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Sat, Apr 24, 2021 at 3:00 PM David A. Harding <dave@dtrt.org> wrote: > On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote: > > I meant the type itself is too wide, not the length of the value. As in > > Script can represent things we know nothing about. > > I guess I still don't understand your concern, then. If script can > represent things we know nothing about, then script commitments such as > P2SH, P2WSH, and P2TR also represent things we know nothing about. All > you know is what container format they used. For P2PK, bare multisig, > OP_RETURN, and other direct uses of scriptPubKey, that container format > is "bare" (or whatever you want to call it). > > > Btw: According to... Oh wait... You? > > > https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey > > the max size is 10k bytes. > > I'm not sure what I knew at the time I wrote that answer, but the 10,000 > byte limit is only applied when EvalScript is run, which only happens > when the output is being spent. I've appended to this email a > demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried > 999,000 bytes but ran into problems with bash's maximum command line > length limit). I've updated the answer to hopefully make it more > correct. > > > Is it possible/easy to, say, using bech32m make an inappropriate message > in > > the address? You'd have to write the message, then see what it decodes to > > without checking, and then re encode? I guess this is worse than hex? > > If someone wants to abuse bech32m, I suspect they'll do it the same way > people have abused base58check[1], by using the address format's > alphabet directly. E.g., you compose your message using only > the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append > the appropriate checksum. > > [1] > https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes > > > But it seems this is a general thing... If you wanted an inappropriate > > message you could therefore just use bech32m addressed outputs. > > Yes, and people have done that with base58check. IsStandard OP_RETURN > attempts to minimize that abuse by being cheaper in two ways: > > 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I > think) for OP_RETURN versus 40 bytes for a BIP141 payload. > Maximizing payload size better amortizes the overhead cost of the > containing transaction and the output's nValue field. > > 2. Exemption from the dust limit. If you use a currently defined > address type, the nValue needs to pay at least a few thousand nBTC > (few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC. For > OP_RETURN, the nValue can be 0, so there's no additional cost beyond > normal transaction relay fees. > > Although someone creating an OP_RETURN up to ~1 MB with miner support > can bypass the dust limit, the efficiency advantage remains no matter > what. > > > One of the nice things is that the current psbt interface uses a blind > > union type whereby the entires in an array are either [address, amount] > or > > ["data", hex]. Having an address type would allow more uniform handling, > > which is convenient for strongly typed RPC bindings (e.g. rust bitcoin > uses > > a hashmap of address to amount so without a patch you can't create op > > returns). > > I don't particularly care how the data in PSBTs are structured. My mild > opposition was to adding code to the wallet that exposes everyday users > to OP_RETURN addresses. > > > I would much prefer to not have to do this in a custom way, as opposed > > to a way which is defined in a standard manner across all software > > (after all, that's the point of standards). > > I'm currently +0.1 on the idea of an address format of OP_RETURN, but I > want to make sure this isn't underwhelmingly motivated or will lead to a > resurgence of block chain graffiti. > > -Dave > > ## Creating an 11,000 byte OP_RETURN > > $ bitcoind -daemon -regtest -acceptnonstdtxn > Bitcoin Core starting > > $ bitcoin-cli -regtest -generate 101 > { > "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r", > "blocks": [ > [...] > } > > $ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000 > count=11 | xxd -g0 -p | tr -d '\n' )'"}]' > 11+0 records in > 11+0 records out > 11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s > { > "txid": > "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51", > "complete": true > } > > $ bitcoin-cli -regtest getrawmempool > [ > "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51" > ] > > $ bitcoin-cli -regtest -generate 1 > { > "address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh", > "blocks": [ > "2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b" > ] > } > > $bitcoin-cli -regtest getblock > 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b 2 | jq > .tx[1].txid > "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51" > [-- Attachment #2: Type: text/html, Size: 7650 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN 2021-04-24 21:59 ` David A. Harding 2021-04-24 22:29 ` Jeremy @ 2021-04-24 23:37 ` Zac Greenwood 2021-04-25 0:25 ` Jeremy 1 sibling, 1 reply; 7+ messages in thread From: Zac Greenwood @ 2021-04-24 23:37 UTC (permalink / raw) To: David A. Harding, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5961 bytes --] > 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I > think) for OP_RETURN versus 40 bytes for a BIP141 payload. > Maximizing payload size better amortizes the overhead cost of the > containing transaction and the output's nValue field. In order to reduce the footprint of data stored on-chain, could it perhaps be beneficial to introduce some non-transaction data structure in order to facilitate storing data on-chain such that it maximizes payload size vs. on-chain size, while at the same time ensuring that using such data structure is (almost) as expensive in use per payload-byte as the next-cheapest alternative (which now is using OP_RETURN) with help of weight units? Zac On Sun, Apr 25, 2021 at 12:01 AM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote: > > I meant the type itself is too wide, not the length of the value. As in > > Script can represent things we know nothing about. > > I guess I still don't understand your concern, then. If script can > represent things we know nothing about, then script commitments such as > P2SH, P2WSH, and P2TR also represent things we know nothing about. All > you know is what container format they used. For P2PK, bare multisig, > OP_RETURN, and other direct uses of scriptPubKey, that container format > is "bare" (or whatever you want to call it). > > > Btw: According to... Oh wait... You? > > > https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey > > the max size is 10k bytes. > > I'm not sure what I knew at the time I wrote that answer, but the 10,000 > byte limit is only applied when EvalScript is run, which only happens > when the output is being spent. I've appended to this email a > demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried > 999,000 bytes but ran into problems with bash's maximum command line > length limit). I've updated the answer to hopefully make it more > correct. > > > Is it possible/easy to, say, using bech32m make an inappropriate message > in > > the address? You'd have to write the message, then see what it decodes to > > without checking, and then re encode? I guess this is worse than hex? > > If someone wants to abuse bech32m, I suspect they'll do it the same way > people have abused base58check[1], by using the address format's > alphabet directly. E.g., you compose your message using only > the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append > the appropriate checksum. > > [1] > https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes > > > But it seems this is a general thing... If you wanted an inappropriate > > message you could therefore just use bech32m addressed outputs. > > Yes, and people have done that with base58check. IsStandard OP_RETURN > attempts to minimize that abuse by being cheaper in two ways: > > 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I > think) for OP_RETURN versus 40 bytes for a BIP141 payload. > Maximizing payload size better amortizes the overhead cost of the > containing transaction and the output's nValue field. > > 2. Exemption from the dust limit. If you use a currently defined > address type, the nValue needs to pay at least a few thousand nBTC > (few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC. For > OP_RETURN, the nValue can be 0, so there's no additional cost beyond > normal transaction relay fees. > > Although someone creating an OP_RETURN up to ~1 MB with miner support > can bypass the dust limit, the efficiency advantage remains no matter > what. > > > One of the nice things is that the current psbt interface uses a blind > > union type whereby the entires in an array are either [address, amount] > or > > ["data", hex]. Having an address type would allow more uniform handling, > > which is convenient for strongly typed RPC bindings (e.g. rust bitcoin > uses > > a hashmap of address to amount so without a patch you can't create op > > returns). > > I don't particularly care how the data in PSBTs are structured. My mild > opposition was to adding code to the wallet that exposes everyday users > to OP_RETURN addresses. > > > I would much prefer to not have to do this in a custom way, as opposed > > to a way which is defined in a standard manner across all software > > (after all, that's the point of standards). > > I'm currently +0.1 on the idea of an address format of OP_RETURN, but I > want to make sure this isn't underwhelmingly motivated or will lead to a > resurgence of block chain graffiti. > > -Dave > > ## Creating an 11,000 byte OP_RETURN > > $ bitcoind -daemon -regtest -acceptnonstdtxn > Bitcoin Core starting > > $ bitcoin-cli -regtest -generate 101 > { > "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r", > "blocks": [ > [...] > } > > $ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000 > count=11 | xxd -g0 -p | tr -d '\n' )'"}]' > 11+0 records in > 11+0 records out > 11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s > { > "txid": > "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51", > "complete": true > } > > $ bitcoin-cli -regtest getrawmempool > [ > "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51" > ] > > $ bitcoin-cli -regtest -generate 1 > { > "address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh", > "blocks": [ > "2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b" > ] > } > > $bitcoin-cli -regtest getblock > 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b 2 | jq > .tx[1].txid > "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51" > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 7590 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN 2021-04-24 23:37 ` Zac Greenwood @ 2021-04-25 0:25 ` Jeremy 0 siblings, 0 replies; 7+ messages in thread From: Jeremy @ 2021-04-25 0:25 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 342 bytes --] Zac -- this is kind of offtopic for this thread, which is primarily to do with making software/standards that supports existing practices in the bitcoin community rather than new standards/formats for a similar task. I think there have been some other related posts recently where it might be more topical? Sorry for any confusion, Jeremy [-- Attachment #2: Type: text/html, Size: 1169 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-25 0:25 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-20 15:46 [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN Jeremy 2021-04-23 18:15 ` David A. Harding 2021-04-24 20:05 ` Jeremy 2021-04-24 21:59 ` David A. Harding 2021-04-24 22:29 ` Jeremy 2021-04-24 23:37 ` Zac Greenwood 2021-04-25 0:25 ` Jeremy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox