[RFC-0005] Unspendable Zero Outputs

I just created a new RFC, feel free to discuss.


I’m all for it :slight_smile:

1 Like

This RFC has been accepted.

1 Like

While wrapping up the v0.8 release this proposal was reconsidered and decided to be rejected.
Bellow is a conversation between me and the @backpacker69.

Peerchemist, [29.04.19 11:44]
let me do some thought experiment
Peerchemist, [29.04.19 11:45]
I have an usecase
Peerchemist, [29.04.19 11:46]
you know counterparty/omin/openassets protocols?
Peerchemist, [29.04.19 11:46]
they are like Peerassets but somewhat different
Peerchemist, [29.04.19 11:46]
on Bitcoin it’s not possible to create a 0-value UTXO
Peerchemist, [29.04.19 11:47]
so this protocols send some dust value along the op-retun entry to create a blockchain record which is now understood as a “token”
Peerchemist, [29.04.19 11:47]
if you want to send out a token, you must include your previous input to prove you control it
Peerchemist, [29.04.19 11:48]
on PA you dont have to use the same UTXO as it works via timestamps
Peerchemist, [29.04.19 11:48]
so you can pull out an UTXO out of the a**

Peerchemist, [29.04.19 11:48]
now hear me what I would want
Shamil Randuev, [29.04.19 11:49]
Peerchemist, [29.04.19 11:49]
I want to have ability to use a token protocol like OpenAssets and others but with 0-value UTXOs
Peerchemist, [29.04.19 11:49]
rather than using dust
Shamil Randuev, [29.04.19 11:49]
in that case you have to scrap this rfc
Peerchemist, [29.04.19 11:49]
Peerchemist, [29.04.19 11:52]
do you see value in not having to include some dust amount just to create an entry? 0-value and a fee sounds much better
Peerchemist, [29.04.19 11:57]
I think the current state of the protocol is good enough
Shamil Randuev, [29.04.19 11:57]
personally i think we don’t need dust on our blockchain, if you want to store data use op_return of almost unlimited size
Shamil Randuev, [29.04.19 11:58]
this way it never becomes valid output already
Peerchemist, [29.04.19 12:00]
our dust is an actual 0

If I recall, the purpose of this RFC was to create a method by which you could create tags that would be indexed by custom (aka PA) clients, but not by the main client. This allows you to reduce the size of the Peercoin UTXO table and to avoid cluttering it with PA transactions. I’m not sure I see the revelation that makes this possibility not true.

What you describe is possible with current protocol as well.

"However, there is one exception to this rule, 0 PPC outputs are allowed. Such zero-value outputs can have some useful applications laid out below, but an unfortunate side-effect is that they take up memory in the node’s UTXO table forever, increasing it’s memory usage. "

This is a quote from the RFC. Is it incorrect?

it is correct, in peercoin currently, from version 0.5 onwards, 0 value ppc outputs are allowed. they can also be included in transactions as valid inputs, as long as they are paid for and signed. does anyone remember the rationale for allowing it?

how much of a problem that creates, i am not sure. it is relatively cheap to add outputs to transaction, I mean each 0 output is ~34 bytes, so for price of 1 ppc you can create about 2700 outputs that would require 148 bytes each to clean it, costing key owner just under 4 ppc to get rid of.

But there is no motivation for the key owner to pay this cost. Rather, the motivation lies with the entire network to eliminate this dust from the utxo table via protocol rules, as defined in this rfc.

i agree with you, i just wonder what the rationale was for enabling 0 value outputs in 0.5, perhaps somebody remembers?

0-value outputs were implemented to accommodate for the “PeerApps” which was to be some sort of messaging app or something. It came along OP_RETURN in the v0.5.

what does it mean fully support op_return?

@Sunny_King could you shed some more light into the matter? why was zero output amount allowed in 0.5? how is it relevant to op_return?

The intention was likely precisely this use case, that you supply a zero-output with an OP_RETURN attached. Making them unspendable is the logical direction to go with this output format.

This is what we have referred as “tag” later on. I think I’ve seen an “anchor” as well.