test: provably locked anyone-can-renew/renew-only addresses for names

[pinheadmz]

This PR just adds a test to hsd, but like #500 it also acts like a standardizing document for wallet implementations to use and most importantly, proves that the following addresses encode the following script hash. Note that 8 is the type for RENEW

Script: OP_TYPE OP_8 OP_EQUAL
Serialized script: d05887
Script hash: e466310e566f8f14ac36f7eb7607a5d77a2351ad6bb5aba20a17396c5b18b8c1

main:    hs1qu3nrzrjkd783ftpk7l4hvpa96aazx5dddw66hgs2zuukckcchrqsw3f8kc
testnet: ts1qu3nrzrjkd783ftpk7l4hvpa96aazx5dddw66hgs2zuukckcchrqsj8gmfv
regtest: rs1qu3nrzrjkd783ftpk7l4hvpa96aazx5dddw66hgs2zuukckcchrqs570axm
simnet:  ss1qu3nrzrjkd783ftpk7l4hvpa96aazx5dddw66hgs2zuukckcchrqs4kzusf

If you send a name to one of these addresses and FINALIZE. No one will ever be able to do anything with that name except RENEW. And anyone can renew it by simply adding a miner fee and broadcasting. This effectively "locks" the name forever, unless the entire community forgets to renew the name within the 2-year window.

[coveralls]

Pull Request Test Coverage Report for Build 615185312

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.006%) to 59.411%

---

Files with Coverage Reduction	New Missed Lines	%
lib/protocol/consensus.js	1	82.79%

Totals
Change from base Build 615122405:	-0.006%
Covered Lines:	19551
Relevant Lines:	30638

---

💛 - Coveralls

[tuxcanfly]

Tested ACK. On the usage of the script itself, feels like a double-edged sword. Going to lose control over updating the resource record to avoid the inconvenience of renewing seems like a pyrrhic victory. Then again, this is purely opt-in optional and totally allowed by the scripting system so idk. Seems like it could be useful in a limited number of cases where updates don't matter.

[tuxcanfly]

Maybe test that the name resource i.e TXT record is preserved here.

[pinheadmz]

👍

[tuxcanfly]

Is there a possibility that someone might grief the network by spamming renewals on every name sent here, using dust fee?

[pinheadmz]

That is a possibility but renewals in general are rate-limited already by two factors:

1. Renewals must be at least 1 tree interval apart (36 blocks):

hsd/lib/blockchain/chain.js

Lines 1262 to 1267 in f2702f8

	if (height < ns.renewal + network.names.treeInterval) {
	throw new VerifyError(tx,
	'invalid',
	'bad-renewal-premature',
	100);
	}

2. Renewals are limited to 600 per block:

hsd/lib/protocol/consensus.js

Line 208 in f2702f8

exports.MAX_BLOCK_RENEWALS = 600;

Of course this pull request doesn't change anything - the cat's out of the bag. @tynes and I actually spoke with the project founders about this potential rule-bypass during testnet and there was some discussion about altering OP_TYPE to more strictly enforce the intent of the renewal requirement, but ultimately it didn't get implemented.

I suppose there is a potential future risk to users that deploy contracts like this, that in the future the community may deploy a fork and break the pattern but right now, and especially in the use case described by @ca98am79, it seems to be a benefit.

[tuxcanfly]

Just curious why this says 'Auction not found' instead of Wallet does not own above.

[pinheadmz]

It's because Alice sent the open, the bid, the transfer - everything. Bob is just an innocent bystander (aka "anyone") so his wallet has no namestate data at all. Alice's wallet has some namestate data because she bid and actually owned the name at some point in the past. So its like, in her "watchlist" (walletDB nameMap). But the UTXO that owns the name is not in her wallet or under her control.

You did make me curious though Im going to add a test to see if this action causes bob's wallet to start tracking the name, especially now that #564 has been merged.

[pinheadmz]

ok updated, Alice's wallet still tracks the name but Bob's never does.

[ca98am79]

On the usage of the script itself, feels like a double-edged sword. Going to lose control over updating the resource record to avoid the inconvenience of renewing seems like a pyrrhic victory. Then again, this is purely opt-in optional and totally allowed by the scripting system so idk. Seems like it could be useful in a limited number of cases where updates don't matter.

We implemented this with our TLD .badass. You can see the transfer history here. The use case for us is to lock the TLD so that 2nd-level domain owners do not have to trust the TLD owner. It is provably owned by no one, but renewable by anyone.

[chjj]

Just a thought: if people are upset by this behavior being abused on chain, it can be avoided with a soft-fork which terminates script execution if OP_TYPE's corresponding output is a RENEW.

Of course, there is a cost to this: names which utilize OP_TYPE must use TRANSFER/FINALIZE as their RENEW mechanism.

edit: New behavior for OP_TYPE could be enabled in a new witness version which censors the RENEW integer (making it look like an UPDATE/TRANSFER possibly).