OP_REMOVE?

[coins101]

Say Bob wants to generate an OP_RETURN with some information that will give his customer, Alice, a confirmation for purchase proof.

But neither Bob or Alice care about that confirmation still being held in the blockchain after x period. Let's say x period = 6 years for statute of limitations purposes, but it could equally be redundant data after 90 days, or an equivalent block time.

There could be many reasons for wanting an OP_RETURN message proof from being removed.

Executing an OP_RETURN should also be supplemented with another option for OP_RETURNREMOVE

This would give the person signing the OP_RETURNREMOVE with the option to set a removal date when the blockchain can effectively delete the data and maintain a record of its creation with a smaller size alternative or a group of OP_RETURNREMOVE signed with the same private key hashed into a single string and moved to the merkle root when they have common removal periods set at the outset (lets say its a retailer that does thousands of transactions each month).

So, this is not to replace OP_RETURN, but give an alternative with an expiry period on the full data. At the very least it could be an ignore function so some nodes just never download these messages when the expiry date is effective.

Edit

What the network needs, if it is to last 100+ years of data growth, is a rescan to remove these temporary pieces of information.

Whilst dangerous and not very practical to do, a rescan voted upon by 95% of miners, or some other consensus rule, could see temporary additional data removed.

For example, anyone using OP_RERTURNREMOVE, could be given fee incentives or penalties. Store your data for <90 days, then its almost free; 90-365 days the fee is x; and so on.

While some might use the chain for spam, if it's got a temporary life and people pay a fee for temporary storage, why not have this option?

Ok, let's face it. It's got some problems. But you get the gist.

[1715049699]

1715049699

[achow101]

That doesn't make sense. The point of the OP_RETURN is too allow arbitrary data into the blockchain, not necessarily a proof of anything. The point is to make that output prunable from the UTXO set. There is no way to remove that from the blockchain without changing the signature algorithm. This would allow retroactively changing the blockchain, something that should not be allowed. If you want an "expriation date" to whatever data you are encoding, you should just encode that expiration into the data itself and have your own parser be able to understand that.

[coins101]

That doesn't make sense. The point of the OP_RETURN is too allow arbitrary data into the blockchain, not necessarily a proof of anything. The point is to make that output prunable from the UTXO set. There is no way to remove that from the blockchain without changing the signature algorithm. This would allow retroactively changing the blockchain, something that should not be allowed. If you want an "expriation date" to whatever data you are encoding, you should just encode that expiration into the data itself and have your own parser be able to understand that.

Look, I understand the idea has issues. I'm not looking for some kind of permissioned ledger that can be changed at will.

But an 'ignore me after x-period' opcode might act something like a default pruning option that you don't have to activate.

[achow101]

Look, I understand the idea has issues. I'm not looking for some kind of permissioned ledger that can be changed at will.

But an 'ignore me after x-period' opcode might act something like a default pruning option that you don't have to activate.

It's already "ignore me after you see this" for OP_RETURN. That's what it means. There isn't any wallet software which parses an OP_RETURN and gives it some meaning unless it is designed to parse specific OP_RETURN outputs. OP_RETURNS contain no meaningful information to normal Bitcoin wallets so they already ignore those outputs.

[coins101]

Look, I understand the idea has issues. I'm not looking for some kind of permissioned ledger that can be changed at will.

But an 'ignore me after x-period' opcode might act something like a default pruning option that you don't have to activate.

It's already "ignore me after you see this" for OP_RETURN. That's what it means. There isn't any wallet software which parses an OP_RETURN and gives it some meaning unless it is designed to parse specific OP_RETURN outputs. OP_RETURNS contain no meaningful information to normal Bitcoin wallets so they already ignore those outputs.

I updated the OP to put forward a blockchain rescan to remove temporary data only needed in the chain for x period.

Not great, but leaving it out there as a suggestion for a while.