Skip to content

Conversation

@SilentCicero
Copy link
Contributor

Abstract

This output is for including arbitrary data within a transaction. This allows users and developers to include arbitrary data that can be signed over that cannot be included in a script, input, smart contract or within predicate code.

Note, this output is not spendable.

Prior Art

https://en.bitcoin.it/wiki/OP_RETURN

@SilentCicero SilentCicero added the enhancement New feature or request label Jun 20, 2023
@xgreenx
Copy link
Contributor

xgreenx commented Jun 21, 2023

Why can't we use predicate_data or script_data to store arbitrary data?

One potential use case for an output type like this would be providing the preimage to an asset ID to determine the contract ID without having to annoyingly include that data as an argument in a deposit method for things like AMMs. Instead, you can have a function included in the standard library which just scans the outputs for this preimage in a specific output data.

People can still use this new output to store different kinds of data(not only the preimage of the asset id), so SDK should understand the purpose of each output somehow. I think that if your code requires a preimage of the asset id, then you should provide it as an argument. Otherwise, it is chaos with random outputs.

@SilentCicero
Copy link
Contributor Author

SilentCicero commented Jul 7, 2023

Hmm, the script data could be used for arbitrary data, yes.

My main concern was that this may negatively effect some scripts and design patterns, as they might be looking for specific data as well, and we would need to calculate the expected data in runtime to determine the additional arbitrary data that is appended.

Similarly, appending in a predicate data field is fine, but there are issues if you actually want to use that data for a specific predicate and again would have to calculate the expected data length to see what data has been appended.

If I was designing a piece of code looking for specific data, having that available in a known non-spendable output index would be easier to work with and handle IMO. So this is really an ergonomics feature if anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants