Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 191. (Read 1151369 times)

JD chat is probably the most active. There is also #clams on freenode IRC but not too much activity there.

Where does the community hang out the most for this coin? The subreddit's last post was over two months ago. Is the community active?

i lost all my clams in JD

This is a good point. It's another reason for me to step back and think more carefully about "design" issues.


I've read before that bitcoin restricted OP_RETURN to 40 bytes because this is enough for key value pairs for a distributed hash table. Maybe a feature for storing such key value pairs would be sufficient for many different purposes.

Be careful. Just because one of my privkeys signed the first input to a transaction, it doesn't mean I agree with the content of the CLAMspeech. The transaction could be a withdrawal from Just-Dice. When withdrawing from Just-Dice you can specify any CLAMspeech you like. The transaction's inputs will be signed by private keys in the hot wallet, but the owner of those keys doesn't endorse the content of the CLAMspeech.


I worry that we're going to end up hard-coding many different similar-but-different features into the CLAM client, and wonder if there's some way we could generalize it so we don't have to edit C++ code for the next person to dream up a use for CLAMspeech.

(Cue sighs and groans from Creative and Kef...)

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

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.

How about this?


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:


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.

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


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":


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.

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:



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.

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

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 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 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 " approach.

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

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.

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:


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

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 ' 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 []' 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 []' in a ClamSpeech instead of 'create identity []'.

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

where points to text like "I have public key 02... (clam address x...). I offer escrow services under XYZ terms." which hashes to . Then the first 8 hex characters of 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

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

Quote from: dooglus on December 26, 2015, 01:59:42 PM

Quote from: Trent Russell on December 26, 2015, 09:14:39 AM

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.

Quote from: Trent Russell on December 26, 2015, 09:14:39 AM

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.

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.

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:


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


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.


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