Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New OutputData type #498

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

New OutputData type #498

wants to merge 2 commits into from

Conversation

SilentCicero
Copy link
Member

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
Member 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