[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin"

[dooglus]

v1.4.17 -- I didn't recompile it. I just used the binary. I don't remember if it's 32 bit or 64 bit; let me know if you need me to find out. (It seems to be 32 bit based on "history | grep wget." I did a wget of the 64 bit version and then a bit later the 32 bit version. This is very likely to mean I tried the 64 bit version and it didn't work, so I fell back on the 32 bit version which did.) I could try to recompile if you think that might help. The mainnet version is working fine, though.

It's fine that you bring up that it should be running in the background, but that's not what's happening. The first time I just noticed "getinfo" still didn't work after half an hour. After that I started doing "ps aux | grep clam" to check if it's running. That's how I know it dies after a second or so.

It seems that no released version works with testnet, for at least these reasons:

1) the checkpoint list is empty, causing the crash you saw
2) the testnet genesis block hash is wrong, meaning it won't accept any blocks from peers

I tried making changes to v1.4.17 to get testnet working, but it needs more still.

I suggest building from the 'master' branch in the nochowderforyou repository if you can, and want to use testnet. Other than that I guess the answer is "no, there's no testnet available yet, but there will be in the next release".

[Trent Russell]

I suggest building from the 'master' branch in the nochowderforyou repository if you can, and want to use testnet. Other than that I guess the answer is "no, there's no testnet available yet, but there will be in the next release".

No problem. Thanks for the quick replies on a holiday. I might try to compile from the master branch in a day or two.

[SuperClam]

The data is essentially an expression of users' perceptions, perhaps even users' perceptions of others' perceptions.
The threat of perceptual distortions introduced by pluralistic ignorance is an important issue to consider, especially given the inexpressiveness of the value transfer protocol. There is no mechanism to transfer value other than that which can be described with cryptography, specifically it is incapable of transmitting the societal values that are normally mediated by all the stuff that comes with embeddedness.

A fair point.
Though, I would think that the pseudo-anonymous nature of the network would blunt social effects such as 'pluralistic ignorance'.
It is quite possible I am conceptualizing it incorrectly, however.
The good news is, of course, that CLAMour has no innate effect on the network.
Data is agnostic (though actions taken pursuant may not be).

Isn't embeddedness usually referred to as an external force causing inefficiency and false signals?
I hadn't encountered 'Embeddedness' since leaving school; I will need to brush up a bit before I feel comfortable responding.

No it isn't voting, but it is opinion polling and that's not exactly an under-developed field.

I have read talk in the past about a multi-triggered-fork bit-field in BTC (as opposed to version reporting, etc.).
And yet, I am not aware of another network that implements a provable means to gather this data.
This is particularly so for Proof-Of-Stake; to which the data is likely more useful.

Exactly how useful it is, of course, remains to be seen.

This is a social thing in essence and so all you're ever going to have to work with are warm fuzzies (aka “statistics”).

True.
Yet... warm fuzzies are almost always preferable to blind stumbling, no?

Cheers and Season's Greetings

To you as well

[gjhiggins]

Isn't embeddedness usually referred to as an external force causing inefficiency and false signals?
I hadn't encountered 'Embeddedness' since leaving school; I will need to brush up a bit before I feel comfortable responding.

Not as I understand the general meaning, no. I'll idly paste a chunk of wikipedia instead of actually crafting a response (it is Christmas) ..

Mark Granovetter[edit]
Economic Sociologist Mark Granovetter provided a new research paradigm (neo-substantivism) for these researchers. Granovetter argued that the neoclassical view of economic action which separated economics from society and culture promoted an 'undersocialized account' that atomises human behavior. Similarly, he argued, substantivists had an "over-socialized" view of economic actors, refusing to see the ways that rational choice could influence the ways they acted in traditional, "embedded" social roles.

Actors do not behave or decide as atoms outside a social context, nor do they adhere slavishly to a script written for them by the particular intersection of social categories that they happen to occupy. Their attempts at purposive action are instead embedded in concrete, ongoing systems of social relations. (Granovette 1985:487)[2]

Granovetter applied the concept of embeddedness to market societies, demonstrating that even there, "rational" economic exchanges are influenced by pre-existing social ties.[2] In his study of ethnic Chinese business networks in Indonesia, Granovetter found individuals' economic agency embedded in networks of strong personal relations. In processes of clientelization the cultivation of personal relationships between traders and customers assumes an equal or higher importance than the economic transactions involved. Economic exchanges are not carried out between strangers but rather by individuals involved in long-term continuing relationships.

(My emphasis --- and the reason for my interest in the phenomenon)

Cheers

Graham

[Trent Russell]

Earlier this year I wrote up an idea I called "multisig derivatives" that could be used to hedge against volatility. (I guess that would've been useful during Clampocalypse.) I've been thinking about it again, and now know how to present the idea in what I hope is a simpler way. It's basically a way of simulating buying and selling cryptocurrencies relative to other assets (e.g., fiat currencies). I wrote up a short explanation yesterday, using bitcoins and dollars:

https://medium.com/@trentrussell/contracts-simulating-crypto-fiat-exchanges-6f9421ea520c

I plan to implement this to work over clams, using clamSpeech to record the details of the contract.

One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.

A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.

Here's how this could be done on-chain:

Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.

It would probably also be important to allow Alice to change her pubkey registration. Changing from Q (A) to Q' (A') could be done by spending from A (input 1) and A' (input 2) in a tx with clamspeech "changepubkey".

Some of these identities could advertise themselves as escrow agents by registering certain terms under which they will act as an escrow agent.

Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?

There is another possibility I've considered. Instead of storing the "identities" explicitly in the clamSpeech with the contract, the "identities" could be determined for each "contract tx" by looking at the inputs: (1) for party, (2) for counterparty and (3) for escrow.

I can see arguments for doing it either way. Thoughts?

[bhokor]

Earlier this year I wrote up an idea I called "multisig derivatives" that could be used to hedge against volatility. (I guess that would've been useful during Clampocalypse.) I've been thinking about it again, and now know how to present the idea in what I hope is a simpler way. It's basically a way of simulating buying and selling cryptocurrencies relative to other assets (e.g., fiat currencies). I wrote up a short explanation yesterday, using bitcoins and dollars:

https://medium.com/@trentrussell/contracts-simulating-crypto-fiat-exchanges-6f9421ea520c

I plan to implement this to work over clams, using clamSpeech to record the details of the contract.

One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.

A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.

Here's how this could be done on-chain:

Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.

It would probably also be important to allow Alice to change her pubkey registration. Changing from Q (A) to Q' (A') could be done by spending from A (input 1) and A' (input 2) in a tx with clamspeech "changepubkey".

Some of these identities could advertise themselves as escrow agents by registering certain terms under which they will act as an escrow agent.

Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?

There is another possibility I've considered. Instead of storing the "identities" explicitly in the clamSpeech with the contract, the "identities" could be determined for each "contract tx" by looking at the inputs: (1) for party, (2) for counterparty and (3) for escrow.

I can see arguments for doing it either way. Thoughts?

Nice project ithink it should be possible, and  implement it to clams would be a nice add which should  get up a little more the price

[Trent Russell]

After thinking some more, I think it would be a mistake for the parties to such contracts to register an identity. There's no reason for the party/seller/Alice or the counterparty/buyer/Bob to reuse addresses since they don't need to have a persistent identity across trades. For privacy reasons, it's probably best to discourage address reuse for the party and counterparty. The escrow, on the other hand, will have policies across many contracts and future parties will want to audit and make sure the escrow agent has never misbehaved.

It probably makes sense for escrow agents to register an identity along with information about the terms under which they provide escrow. This will correspond to a fixed pubkey.

The "contract tx" would store the contract information and the chosen escrow agent (identified by the registered id) in the clamSpeech slot. The party and counterparty could be derived from the first and second inputs of the tx.

But obviously I'm still thinking this through, so I'm open to suggestion.

Nice project ithink it should be possible, and  implement it to clams would be a nice add which should  get up a little more the price

Thanks for the positive feedback!

[TRilon]

Something I can not quite understand why my antivirus activity is perceived as a purse suspicious activity. Other purses on my PC work

[dooglus]

One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.

A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.

Are you familiar with the CLAMour system?

To voice your support for a petition you post "clamour xxxxxxxx" as your CLAMspeech when staking, where xxxxxxxx is the first 8 hex digits of the sha256 hash of the full text of the petition you are supporting.

There's an obvious attack there, in that it's not hard to find another text with an opposite meaning but which has the same first 8 hex digits in its hash. There are only 4 billion different 8 digit prefixes, and so brute forcing it wouldn't take too long.

To combat that, we require that the full sha256 hash be registered using a "create clamour" CLAMspeech before its prefix is acceptable for supporting. Then if a petition ever gains widespread support and two opposing parties step forward claiming that their text is the one being supported, we can tell which one is the right one by checking which was registered first. The CLAM client keep track of this automatically, like this:

Code:

$ clamd getclamour deaddea1
{
  "pid" : "deaddea1",
  "hash" : "deaddea108069f92a0538fea6f08f63f7bbae2caa12d272a6393ced034bb1ec2",
  "url" : "http://txti.es/deaddea1",
  "txid" : "76a2e1689c06e2d0cd809523345f90112a9143719a567253279815968e7b3eaf",
  "confirmations" : 18590
}

You could use a similar scheme to associate short codes with public keys on a first-come first-served basis.

Here's how this could be done on-chain:

Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.

I think it's a mistake to assume that people have control of transaction creation. Maybe they are creating transactions by withdrawing from a web wallet, and so even own the pubkey of the first input. The web wallet will hopefully allow them to specify the CLAMspeech for their transaction however.

Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?

I think it's best to use CLAMspeech when possible rather than making assumptions about the ownership of input addresses.
[/quote]

[dooglus]

Something I can not quite understand why my antivirus activity is perceived as a purse suspicious activity. Other purses on my PC work

I guess there's something in the CLAM blockchain that your antivirus program recognises.

That won't stop the CLAM client from working - you just need to tell your antivirus program to ignore the CLAM blockchain.

[Trent Russell]

One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.

A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.

Are you familiar with the CLAMour system?

To voice your support for a petition you post "clamour xxxxxxxx" as your CLAMspeech when staking, where xxxxxxxx is the first 8 hex digits of the sha256 hash of the full text of the petition you are supporting.

There's an obvious attack there, in that it's not hard to find another text with an opposite meaning but which has the same first 8 hex digits in its hash. There are only 4 billion different 8 digit prefixes, and so brute forcing it wouldn't take too long.

To combat that, we require that the full sha256 hash be registered using a "create clamour" CLAMspeech before its prefix is acceptable for supporting. Then if a petition ever gains widespread support and two opposing parties step forward claiming that their text is the one being supported, we can tell which one is the right one by checking which was registered first. The CLAM client keep track of this automatically, like this:

Code:

$ clamd getclamour deaddea1
{
  "pid" : "deaddea1",
  "hash" : "deaddea108069f92a0538fea6f08f63f7bbae2caa12d272a6393ced034bb1ec2",
  "url" : "http://txti.es/deaddea1",
  "txid" : "76a2e1689c06e2d0cd809523345f90112a9143719a567253279815968e7b3eaf",
  "confirmations" : 18590
}

You could use a similar scheme to associate short codes with public keys on a first-come first-served basis.

The CLAMour system did influence my thinking about registering identities. Are you suggesting I should use CLAMour directly for this purpose? Since the "getclamour" command is being added, this would be easiest for me. I was thinking I'd need to keep track of the registry in a separate database.

Someone could register an identity using clamour by publishing a tx with CLAMspeech:

create clamour <hash> <url>

where <url> points to text like "I have public key 02... (clam address x...). I offer escrow services under XYZ terms." which hashes to <hash>. Then the first 8 hex characters of <hash> could be used to refer to this identity in future CLAMspeech records. In order to interpret the identity, the "getclamour" command could be used.

To be clear, if the clam devs object to me using CLAMour this way I won't. Maybe the clam devs could be a more general registry not just for petitions. Something like

create identity <hash> <url>

and then "getidentity" that works the same way as CLAMour, but with a different "space."

Here's how this could be done on-chain:

Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.

I think it's a mistake to assume that people have control of transaction creation. Maybe they are creating transactions by withdrawing from a web wallet, and so even own the pubkey of the first input. The web wallet will hopefully allow them to specify the CLAMspeech for their transaction however.

Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?

I think it's best to use CLAMspeech when possible rather than making assumptions about the ownership of input addresses.

I understand what you're saying. I mostly agree with you and am back to leaning towards registering identities referred to in CLAMspeech. On the other hand, I'm doubtful that anyone who isn't handling their own private keys will even consider using a service designed to avoid giving control over coins to third parties. Centralised exchanges that take custody over coins will (always? probably?) provide for much more flexible trading.

PS: This morning I cloned the git source and have the mainnet and testnet running. They both seem to be working. It's forcing me to reindex, so the mainnet will only be "caught up" later today, if all goes well.

[Kefkius]

...
The CLAMour system did influence my thinking about registering identities. Are you suggesting I should use CLAMour directly for this purpose? Since the "getclamour" command is being added, this would be easiest for me. I was thinking I'd need to keep track of the registry in a separate database.

Someone could register an identity using clamour by publishing a tx with CLAMspeech:

create clamour <hash> <url>

where <url> points to text like "I have public key 02... (clam address x...). I offer escrow services under XYZ terms." which hashes to <hash>. Then the first 8 hex characters of <hash> could be used to refer to this identity in future CLAMspeech records. In order to interpret the identity, the "getclamour" command could be used.

To be clear, if the clam devs object to me using CLAMour this way I won't. Maybe the clam devs could be a more general registry not just for petitions. Something like

create identity <hash> <url>

and then "getidentity" that works the same way as CLAMour, but with a different "space."
...

I'm not sure exactly what your goal is, but it sounds like Namecoin could be a viable alternative.

CLAMour is one application of the overall ClamSpeech system, created for petitions. So if you want to store identities, I would recommend something along the lines of 'create identity <hash> <url>' as per your example. At one point we explored a potential format for ClamSpeeches that included metadata before the rest of the ClamSpeech - a "category identifier." Ultimately something more plain-language was used.

There are no enforced rules on the contents of ClamSpeeches (and I'm confident that there never will be), only on their lengths. So if somebody wants to store identity data in the CLAM chain, it doesn't really matter what anyone else approves of.

If you do use the CLAM chain for identity data, there is one thing you should be aware of: The requirement that a petition be declared with 'create clamour <petition_hash> [<url>]' exists because petitions are identified by their first 4 bytes when voting for them (so multiple petitions can be voted for in one stake transaction). Since you probably won't need to refer to multiple identities in one ClamSpeech, you can just omit the 'create identity' step. Thus, you can simply put 'identity <hash> [<url>]' in a ClamSpeech instead of 'create identity <hash> [<url>]'.

[Trent Russell]

...
I'm not sure exactly what your goal is, but it sounds like Namecoin could be a viable alternative.

CLAMour is one application of the overall ClamSpeech system, created for petitions. So if you want to store identities, I would recommend something along the lines of 'create identity <hash> <url>' as per your example. At one point we explored a potential format for ClamSpeeches that included metadata before the rest of the ClamSpeech - a "category identifier." Ultimately something more plain-language was used.

There are no enforced rules on the contents of ClamSpeeches (and I'm confident that there never will be), only on their lengths. So if somebody wants to store identity data in the CLAM chain, it doesn't really matter what anyone else approves of.

If you do use the CLAM chain for identity data, there is one thing you should be aware of: The requirement that a petition be declared with 'create clamour <petition_hash> [<url>]' exists because petitions are identified by their first 4 bytes when voting for them (so multiple petitions can be voted for in one stake transaction). Since you probably won't need to refer to multiple identities in one ClamSpeech, you can just omit the 'create identity' step. Thus, you can simply put 'identity <hash> [<url>]' in a ClamSpeech instead of 'create identity <hash> [<url>]'.

I mainly need a short unambiguous way to refer to a public key, so using CLAMour for this is probably overkill. I've done some testnet tests and the next post will be about it. (It's already written, but wanted to respend to your post first.)

[Trent Russell]

I've registered an identity on testnet using CLAMour as follows:

The tx c82f27a509bf2c04ffb037f683d8259894f273f8d8f849a8e0545879d5444a2c has CLAMspeech

create clamour 1a762d2507760a436061029547245e434fa89da6e9d22cf07d6f8a6140b31f37 http://txti.es/1a762d25

The text at the link is "Testnet identity 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 (address mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH)".

The "identity" can (in a sense) be looked up using the client:

Code:

cct getclamour 1a762d25
{
  "pid" : "1a762d25",
  "hash" : "1a762d2507760a436061029547245e434fa89da6e9d22cf07d6f8a6140b31f37",
  "url" : "http://txti.es/1a762d25",
  "txid" : "c82f27a509bf2c04ffb037f683d8259894f273f8d8f849a8e0545879d5444a2c",
  "confirmations" : 16
}

While this would work, I think it's better to separate it from CLAMour. Also, I think I shouldn't say "identity" when what I really mean is "pubkey". Here's an alternative approach:

The tx 6c08736d725217eeaf04dd3e1cc90ee17123f4361b7318fd9f68b02d87823b0b has CLAMspeech

register pubkey 8b8070fe 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5

Here the hex "8b8070fe" is the 4 byte checksum of the corresponding address: mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH.

A "getpubkey" command (like "getclamour") would be helpful.

Thoughts?

[Kefkius]

I've registered an identity on testnet using CLAMour as follows:

The tx c82f27a509bf2c04ffb037f683d8259894f273f8d8f849a8e0545879d5444a2c has CLAMspeech

create clamour 1a762d2507760a436061029547245e434fa89da6e9d22cf07d6f8a6140b31f37 http://txti.es/1a762d25

The text at the link is "Testnet identity 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 (address mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH)".

The "identity" can (in a sense) be looked up using the client:

Code:

cct getclamour 1a762d25
{
  "pid" : "1a762d25",
  "hash" : "1a762d2507760a436061029547245e434fa89da6e9d22cf07d6f8a6140b31f37",
  "url" : "http://txti.es/1a762d25",
  "txid" : "c82f27a509bf2c04ffb037f683d8259894f273f8d8f849a8e0545879d5444a2c",
  "confirmations" : 16
}

While this would work, I think it's better to separate it from CLAMour. Also, I think I shouldn't say "identity" when what I really mean is "pubkey". Here's an alternative approach:

The tx 6c08736d725217eeaf04dd3e1cc90ee17123f4361b7318fd9f68b02d87823b0b has CLAMspeech

register pubkey 8b8070fe 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5

Here the hex "8b8070fe" is the 4 byte checksum of the corresponding address: mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH.

A "getpubkey" command (like "getclamour") would be helpful.

Thoughts?

I'm not sure why you need to use any URL. The register pubkey 8b8070fe 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 one seems easiest. But the checksum is only valid for Bitcoin testnet. So unless you specify either "Bitcoin testnet" or "111" (i.e. Bitcoin testnet prefix byte), it would take 112 iterations of sha256d to verify the checksum, assuming the verifier starts at prefix_byte = 0. That's not a heavy burden, but it seems unnecessary.

[Trent Russell]

I'm not sure why you need to use any URL. The register pubkey 8b8070fe 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 one seems easiest. But the checksum is only valid for Bitcoin testnet. So unless you specify either "Bitcoin testnet" or "111" (i.e. Bitcoin testnet prefix byte), it would take 112 iterations of sha256d to verify the checksum, assuming the verifier starts at prefix_byte = 0. That's not a heavy burden, but it seems unnecessary.

The URL was only needed in order to give the pubkey in a way that technically would match what CLAMour expects. I won't do this. I'm likely to go with the "register pubkey <checksum> <pubkey>" approach.

I'll try to modify my copy of the clam code to have a "getpubkey" command.

[rfisher1968]

I have a question about a clam private key.

For bitcoin:

1. you have a 32 byte random number
2. you append 1 to 0x80
3. sha256 the result of 2
4. sha256 the result of 3
5. take the first 4 bytes of 4 and append to 2
6. base58 encode 5

Whats different for clamcoin?

[dooglus]

I have a question about a clam private key.

For bitcoin:

1. you have a 32 byte random number
2. you append 1 to 0x80
3. sha256 the result of 2
4. sha256 the result of 3
5. take the first 4 bytes of 4 and append to 2
6. base58 encode 5

Whats different for clamcoin?

The only difference is that the 0x80 becomes 0x85 in step 2.

Note that for DOGE it's 0x9e and for LTC it's 0xb0.

[SuperClam]

I have a question about a clam private key.
For bitcoin:
1. you have a 32 byte random number
2. you append 1 to 0x80
3. sha256 the result of 2
4. sha256 the result of 3
5. take the first 4 bytes of 4 and append to 2
6. base58 encode 5
Whats different for clamcoin?

The only difference is that the 0x80 becomes 0x85 in step 2.
Note that for DOGE it's 0x9e and for LTC it's 0xb0.

I will leave this here, for the curious:
https://en.bitcoin.it/wiki/List_of_address_prefixes

[Trent Russell]

I've managed to add registration of ids to a version of clams I'm running on testnet. I've switched to having ids that are N prefix bytes of the underlying 20 byte address instead of using the checksum. In hex this is a 2N char id. An example is in tx 8690cfc9b0e40b7fb328da478e2523071ac759eea7cac729038b47b8f180948d with the clamspeech:

register pubkey 73 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5

Here the given pubkey is from the address mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH, which in hex is

Version Byte: 6f
20 byte address: 732e7e8744a30f55ff7c43b77e473ff462777b43
Checksum: 8b8070fe

In principle, possible ids to register would be 73 (as above), 732e, 732e7e, etc.

I don't yet have code that correctly actually checks that the given id corresponds to a prefix of the address, so I wanted to ask (technically) how to do this.

Here's what I've found:

I can use CPubKey(ParseHex(strPubkey)) to convert "039d...f5" into a CPubKey. IsFullyValid will make sure it's a valid pubkey. GetID can be used to obtain the 20 byte address as a CKeyID (which seems to be the same as uint160).

On the other hand, I can use ParseHex on the given hex ID in the clamspeech to obtain a vector of unsigned chars. I crossed my fingers and tried to use memcmp as a way checking for a prefix, but it doesn't seem to work. Here's the current code snippet I have in main.cpp:

Code:

...
                CPubKey vchPubKey = CPubKey(ParseHex(strPubkey));
...
                  CKeyID keyid = vchPubKey.GetID();
                  std::vector<unsigned char> vchID = ParseHex(strID);
                  if (memcmp(&vchID,&keyid,vchID.size()) != 0) {
                    LogPrintf("invalid pubkey registration attempt %s; id %s is not a prefix of the address: %s\n", strPubkey, strID, tx.strCLAMSpeech.substr(0, MAX_TX_COMMENT_LEN));
                  } else {
                    pindex->vRpubkey.push_back(*(mapRpubkey[pid] = new CRpubkey(pindex->nHeight, tx.GetHash(), strID, strPubkey)));
                  }

I'm going to try to get on the #clams channel on IRC. If successful, I'll start asking questions there. I don't want to "spam" this thread with posts that aren't of general interest. I could also start a separate thread if people think I should.

Edit: I'm now registered at irc.freenode.net with nick TrentRussell and have joined the #clams channel. I've never used irc before, but will try to use it now and try to log the channel when I'm not online.