Skip to content

File data meta gzip generic versioning#10

Open
JawedAshraf wants to merge 3 commits into
bitcoin-sv-specs:file-data-meta-gzip-genericfrom
JawedAshraf:file-data-meta-gzip-generic-versioning
Open

File data meta gzip generic versioning#10
JawedAshraf wants to merge 3 commits into
bitcoin-sv-specs:file-data-meta-gzip-genericfrom
JawedAshraf:file-data-meta-gzip-generic-versioning

Conversation

@JawedAshraf

Copy link
Copy Markdown

I'd like to open up a proposal for versioning of data in OP_RETURN, using two new optional elements that allow a chain of OP_RETURNS to be identified by clients.

With the right kind of crypto I believe it is possible for a publisher to authenticate each newly published version. This allows clients to reject OP_RETURNS that purport to be new versions if they do not provide the correct elements. But IANAC (I am not a cryptographer) so I'm assuming that this chain based on pairs of keys will work.

Essentially the publisher of an OP_RETURN adds a key which allows them to "spend" the OP_RETURN with a replacement (new version) OP_RETURN, which also provides a new key that they can spend later.

There may be a requirement to allow version-forking (versions 2 and 3 can exist both forked from version 1). I don't want to go deep into that, because I'm initially interested in whether versioning is seen as worthwhile.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant