Namecoin Forum

At some point in the future, we should support P2SH in Namecoin. Any suggestions for the address prefix to use? See also https://en.bitcoin.it/wiki/List_of_address_prefixes.

Current prefixes in use:

pubkeyhash address: 52 -> N or M as initial character
private key: 180 -> 7 or T as initial character (uncompressed / compressed public keys)

Also note that private keys with the same format as Bitcoin (5 for uncompressed and K/L for compressed public keys) are accepted for compatibility. Testnet uses the same prefixes as Bitcoin, and I suggest to keep that also for P2SH addresses.

Suggestions I have for the P2SH prefix/version are:

8/13/18 -> prefix 4, 6 or 8. Would fit into the scheme of Bitcoin (prefix 2/3 for testnet/mainnet) without clashing with 5, 7 or 9.
40 -> prefix H, for "script hash"
58 -> prefix Q, the next after M/N (for ordinary addresses) that is not (to my knowledge) in wide usage (P is used by PPC; Q was Quarkcoin, but that seems to have died)
63 -> prefix S (for script), clashes with "Bitcoin mini private keys"

My favourite so far is 13 (prefix 6), but not by a strong preference. Any ideas?

We should support multisignature transactions in the future.
And they are supported on the protocol level also without P2SH.
- They were some discussions on
nothing(multisig directly) vs P2SH vs CHV or OP_EVAL
but I know that the mainstream of Bitcoin developers are going with Gavin(and GMaxwell) on P2SH now. (Mike Hearn and Amir Taaki are rejecting it)
- However they are also some representants of the other versions.
Multisig on the protocol level would be the most secure.
P2SH has some more features and a little bit more security risk. BIP16/BIP13
The main argument against OP_EVAL was the reduced security because being Turing complete(however the most possibilities).
- I know that Armory began to implement multisig without P2SH but I am not sure how it is now.

Of course we can discuss about what addresses to use for any eventuality.
- If we use P2SH we shouldn't collide with the Bitcoin addresses to not cause any confusion by the users and for the developers if posting a Bitcoin multisig application.
- We should avoid also if possible avoid to interfere with other major coin addresses like LTC, PPC and some others.
- To keep account of all the 500+ coins would be anyway impossible. Personally I have no preference what address prefix to use.

Another point what what I am thinking how would behave such an address prefix interference with another coin if it is with Namecoin in the same multicoin wallet. From that point of view probably would be optimal if we use an address prefix which is still unused for a coin supported by the Ufasoft multicoin wallet. What do you think ?

I think we should definitely support P2SH. It is an elegant solution to the problem of specifying "where" to send funds in the case of multisig. Also, it helps with compatibility to Bitcoin.

Pure multisig is already supported, even with the old client (in case that's not widely known - it wasn't for me until recently). So as long as you make your client send / receive those, it works already and will continue to do so in the future. (This is also the same as with Bitcoin.)

I fully agree about avoiding clashes with the address format, that's why I wanted to get as much input as possible on this one.

domob wrote:I think we should definitely support P2SH. It is an elegant solution to the problem of specifying "where" to send funds in the case of multisig. Also, it helps with compatibility to Bitcoin.

This is a good argument. I agree with you.
I just listed all available possibilities.

virtual_master wrote:- I know that Armory began to implement multisig without P2SH but I am not sure how it is now.

This is tangential, but I'm pretty sure Armory is using P2SH now. Joseph would know for certain.

I don't have a strong opinion on what prefix to use.

biolizard89 wrote: This is tangential, but I'm pretty sure Armory is using P2SH now. Joseph would know for certain.

Yes, Armory uses P2SH. I think I've disabled it for now for Namecoin by leaving the P2SHBYTE string as an empty string, but I need to do more testing to verify that. Anyway, I have disabled all the multisig GUI elements, so it shouldn't matter.

Back on topic, I don't have a strong opinion on the prefix.

What implications or other possibilities would arise from P2SH with specific to name operations if any ? I do not mean the transaction specific uses.
Multisignature name operations where more parties could exercise control over a domain name ?

Since noone has a strong preference, I plan to go with the prefix "6". Please let me know if that causes forseeable problems with some usecase or important conflicts with other coins.

So, what happens if a name opcode is hashed into a P2SH script? Obviously the name operation won't happen immediately, since the hash can't be reversed by itself. Will the name opcode suddenly have an effect once the P2SH output is spent (revealing the name opcode)? I realize that such a script would probably be considered nonstandard (and therefore wouldn't be relayed), but I'm quite curious how it would behave if it were mined.

biolizard89 wrote:So, what happens if a name opcode is hashed into a P2SH script? Obviously the name operation won't happen immediately, since the hash can't be reversed by itself. Will the name opcode suddenly have an effect once the P2SH output is spent (revealing the name opcode)? I realize that such a script would probably be considered nonstandard (and therefore wouldn't be relayed), but I'm quite curious how it would behave if it were mined.

Name op codes are only interpreted in tx outputs and only if they have a strict format (name op code as very first one and then correct arguments). So no, they are not specifically interpreted when in P2SH scripts (since those appear in the tx input's scriptsig).