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 new transaction type is needed for sending from human address to contract address, right?
(Traditional human-human CP transaction encodes the recipient by sending some satoshis to the recipient and all other info in e.g. an op-return.)
The satosh-trick won’t work when sending to a C-address. Can all info be encoded in an op-return or must multisig encoding be used?
The downsides with multisig are that it is controversial among some bitcoiners and the end-user will need to sweep up redeemable multisig dust.
If op-return send is impossible with the suggested C-address format, will it be better to make a shorter contract address format to make it fit op-return?
@deweller - I looked deeper into the anatomy of a send tx. You’re indeed right. There’s enough of room to spare.
It starts with prefix 434e54525052545900000000 which indicates CNTRPRTY in hex.
Then asset ID hex, e.g. 0000ab8619e21208 for BITCRYSTALS.
Followed by 00000002dddf7c4e which is the amount in hex.
This is a total of 56 hex chars, which means they take up 28 bytes. An 80 byte op-return thus has 52 bytes left for the receiving address.
Most bitcoin addresses are 34 characters. Each character takes up less than one byte, and the transaction (prefix+ID+amount+recipient) easily fits in an op-return.
P.S. This opens up another discussion; why not also let the recipient in a traditional CP send transaction be encoded in op-return? It will make transactions a few cents cheaper.
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
