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

[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.

[Trent Russell]

I did find a bit of a hackish way to check if a vector of unsigned chars is a "prefix" of a CKeyID:

Code:

                CKeyID keyid = vchPubKey.GetID();
                std::vector<unsigned char> vchID = ParseHex(strID);
                bool isprefix=true;
                unsigned char* keyidarr = (unsigned char*) &keyid;
                for (unsigned int i = 0; i < vchID.size() && isprefix; ++i) {
                  if (vchID[i] != keyidarr[i])
                    isprefix=false;
                }

This rejects the old register (since it uses the checksum instead of a prefix) and accepts the new one. As a result there's one pubkey registered. I have commands "listrpubkeys" and "getrpubkey":

Code:

cct listrpubkeys
[
  {
    "id" : "73",
    "pubkey" : "039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5",
    "txid" : "8690cfc9b0e40b7fb328da478e2523071ac759eea7cac729038b47b8f180948d",
    "confirmations" : 446
  }
]

cct getrpubkey 73
{
  "pid" : "73",
  "id" : "73",
  "pubkey" : "039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5",
  "txid" : "8690cfc9b0e40b7fb328da478e2523071ac759eea7cac729038b47b8f180948d",
  "confirmations" : 446
}

The "pid" field given in response to "getrpubkey" shouldn't be there. I'll track it down later.

I'm saying "rpubkey" for "registered pubkey" to avoid confusing with ordinary public keys.

If someone has a suggestion for how I should've done it, I'd be happy to listen.

[dooglus]

I did find a bit of a hackish way to check if a vector of unsigned chars is a "prefix" of a CKeyID:

How about this?

Code:

                 bool isprefix=true;
                unsigned char* keyidarr = (unsigned char*) &keyid;
                for (unsigned int i = 0; i < vchID.size(); i++)
                  if (vchID[i] != keyidarr[i]) {
                    isprefix=false;
                    break;
                  }

The 'break' will stop the loop as soon as it finds a difference without needing to check isprefix each time through the loop.

You could get rid of isprefix all together, and just check whether i == vchID.size() after the loop is done. Iff that's true then it's a prefix:

Code:

                 unsigned char* keyidarr = (unsigned char*) &keyid;
                unsigned int i;
                for (i = 0; i < vchID.size(); i++)
                  if (vchID[i] != keyidarr[i])
                    break;
                if (i == vchID.size()) // it's a prefix ...

Edit: I meant to say that I was meaning to help you out with this about 12 hours ago, but when I went to check on my testnet instance it was dead, and crashed every time I tried to restart it, so I spent today tracking down and fixing the bugs that caused that instead.

[Trent Russell]

You could get rid of isprefix all together, and just check whether i == vchID.size() after the loop is done. Iff that's true then it's a prefix:

Code:

                 unsigned char* keyidarr = (unsigned char*) &keyid;
                unsigned int i;
                for (i = 0; i < vchID.size(); i++)
                  if (vchID[i] != keyidarr[i])
                    break;
                if (i == vchID.size()) // it's a prefix ...

Edit: I meant to say that I was meaning to help you out with this about 12 hours ago, but when I went to check on my testnet instance it was dead, and crashed every time I tried to restart it, so I spent today tracking down and fixing the bugs that caused that instead.

Thanks, that code is an improvement. I'd forgotten about break.

I was originally hoping to take advantage of the representation in memory of the vchID "unsigned char vector" to avoid needing to loop at all, but it became clear that the representation isn't what I hoped it was (an array).

I'm happy with the response time I've been getting from the Clam team members, so thanks to all of you for that.

Now that I have "register pubkey" I started writing support for "register escrow agent", "create contract", "trade contract" and "settle contract" -- but found I have to rethink things again. For example, I had planned to have CLAMspeech declarations like:

register escrow agent 73 USD <timeout> <terms>

in which the controller of the pubkey registered to 73 indicates his/her willingness to act as an escrow agent under the given terms until the timeout.

Obviously this tx should be signed by the corresponding private key. The easiest way to enforce this is to check that the first input to the tx with the CLAMspeech came from the corresponding address. In which case the pubkey is explicitly in the tx already, and so why did it need to be registered in advance?

In other words, it's been one of those days of taking two steps back.