The current idea is to follow the standard for bitcoin/counterparty to use base58 addresses with a prefix, however with a seperate prefix for contracts, so that an example contract address would be: CiLUGp1hc7aooWWh89MAV6Gu11E7tMz267 starting with a C.
This will make 100% sure you can never excidently send BTC there (BTC wallets won’t allow it and counterparty wallets should be smart enough to not allow BTC sends to it either).
It will also give a visual clue to users that they’re dealing with a contract,
many contracts will not simply work when you send some XCP or asset to it, instead they will have one or more ‘functions’ that need to be executed with extra information.
eg; a bet will require specify which side of the bet you’re taking.
having a visual que that it’s a contract will again help prevent accidental sends to a contract.
while typing this up, I’m even considering, maybe we could have 2 different prefixes, one for contracts that support normal sends and one that doesn’t, though it would be up to the contract creator to pick the correct address.
I am in favor of a different address format for contracts.
I think separate address prefixes for different types of contracts is not necessary. Is it possible to let the wallet developers determine if a contract can receive funds and update the UI accordingly?
How is the contract address generated? Is it based on a the creator and number of sends like Ethereum?
I’m no expert in the subtleties of this question but it makes sense that the contract address is a different class and first letter C is a simple and fast way to avoid confusions for both human and machine.
a bitcoin address for a P2PKH (OP_DUP OP_HASH160 421be79cb72be588ae2445ba2b0b2ecbbab80007 OP_EQUALVERIFY OP_CHECKSIG) takes the hash out of it (421be79cb72be588ae2445ba2b0b2ecbbab80007) and then creates an address by prefixing that with version byte (which results in a 1etcetcetc) and adding a checksum suffix.
every wallet understand that when you put in an address (172Z2Wv7YnqV4iBrneVK3KU9kqYtZtmWNn) it should take the hash and wrap it with OP_DUP OP_HASH160 <HASH> OP_EQUALVERIFY OP_CHECKSIG.
the address really is just a human friendly shortcut.
so when we create our own CP contract address, we can make up our own rules of what the address should translate too (which is a 32byte int, because the EVM works with 32byte ints everywhere).
Adams testnet-only EVM implementation already added a execute TX for contracts, which is to send to a contract with metadata to execute a specific function of the contract.
The execute specifies the contract address in the OP_RETURN (or encoded with 2-of-3 multsigs if the data exceeds 80 bytes).
A plain send would also be possible if we’d do a send to OP_HASH160 <contract_hash> OP_EQUALVERIFY OP_CHECKSIG in which case a small portion of BTC would be burned, I think we should be able to stick to executes, though this is something I’m diving into next week