OP_RETURN code has some interesting, but highly controversial, applications. It’s used to mark a transaction output as invalid, allowing users to burn bitcoin, its also used to add some data to a transaction or store data on the blockchain, which you shouldn’t do.

Some use OP_RETURN prefixes as a way of confirming that they are behind this transaction, using colored coins or storing data.

Recently there were discussions on how to claim these OP prefixes but some members of the community thought it was a bad idea as it would allow censorship and reduce anonymity.

This relates to an old BIP from 2016, but work on this BIP is still in progress.

A new SIGHASH scheme is currently being discussed, called SIGHASH2, it is said to have more flexibility without introducing much complexity and it solves a few minor issues with BIP143.

Some of the new hashtype definitions are signing fees to make sure they are correct without signing some inputs, decoupling INPUT and SEQUENCE to have a NOINPUT option with a relative lock-time, signing INPUTINDEX, putting NOVERSION, for enforcing BIP68, and NOSCRIPTCODE, in case the public key is being reused, in the second byte some reserved bits for the future and lastly sigversion to avoid any conflict between past SIGHASH schemes and any future ones.

Pedro Moreno Sanchez via Bitcoin Dev linked the following paper, Multi-Hop Locks for Secure, Privacy-Preserving and Interoperable Payment-Channel Networks.

…my co-authors and I have been working hard to get ready an extended version of the paper for this work…

In this paper, we describe in detail the scriptless script (SS) ECDSA construction and formally prove its security and privacy guarantees. Additionally, we describe several other constructions of interest for the LN:

-The SS Schnorr, initially proposed by A. Poelstra. We formally describe the protocol and prove its security and privacy guarantees

-Interestingly, we show that it is possible to combine SS ECDSA and SS Schnorr without losing security or privacy. This allows interoperability between different implementations.

-A framework to combine script-based cryptographic locks using partially homomorphic one-way functions.

-Possible applications. For instance, SS ECDSA could be used today in Bitcoin to perform atomic swaps where the resulting transaction no longer reveals the cryptographic condition. Instead, it is embedded in a regular ECDSA signature. This provides several advantages such as reduced transaction size and better privacy/fungibility among others.

A cornerstone of their approach is to provide interoperability between different signature schemes. The utility of such an approach is a form of “cryptographic future-proofing” where if one scheme is broken there are fall-back functions that are still secure.