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

 I don't think clam has a limit on the total supply

Has anyone already done this comparison?

Supply:
14.900.000 CLAM (including not digged)
14,896,275 BTC
Emision:
20 CLAM in 20 minutes
25 BTC in 20 minutes

In the future there will be more supply of BTC than CLAM. Will it affect the price in long time?

The next 24 hours are extremely busy for me; I will try to check in periodically if I can.

dooglus will likely keep us updated on the progress of the UI for the users of Just-Dice.

Our CLAM - The CLAMour Specification

---

CLAMour will allow the stakeholders of CLAM to record their support for changes to the CLAM network consensus rules.

CLAMour gives the community a method of establishing what changes are supported.
Supported changes can then be implemented (by anybody) with a high chance of being accepted by the majority of the staking weight.

The process is designed to be decentralized and provable.
There is no need for permission to propose a change to the network.
It is designed such that any user can 'create' a petition and evangelize to fellow CLAM stakeholders for support.
It will aggregate data on what changes are supported by stakeholders over a time window.

CLAMour happens on-chain using the existing CLAMspeech transaction field so no update to the core software is required to participate.
An optional update will be provided to make the process more user-friendly.

The following rules are a draft proposal.

---

---

CLAMour Petitions

CLAMour petitions are specially formatted CLAMspeech messages.
A petition is a block of free-form text describing the change to be made in sufficient detail to unambiguously implement the change.
Code isn’t required, but specificity is.
Each petition is identified by a petition ID, which is the first 8 hex digits of the sha256 hash of its text.

---

Registering a CLAMour Petition

Before a petition can be voted for, it must be registered on-chain.

This can be done simply by creating any transaction (coinstake or regular) with a CLAMspeech message saying:
where:
is the full 64 hex digit lowercase sha256 hash of the full petition text, and
is the full URL (http://etc) for the text or document that has been hashed.

The first 8 hex digits of this hash should be unique, since they will be used as the petition ID.
In the unlikely event of a collision, you’ll need to slightly edit the petition text.

The text itself can be stored wherever you like.
It is the responsibility of the community supporting the petition to disseminate the petition ID.
It is planned that the reference client will be able to assist with this in the future.

---

Supporting a CLAMour Petition

Once a petition has been registered on-chain, anyone can vote for it by staking a block with the CLAMspeech field set to:
where is the 8 hex digit petition ID of the petition being supported.

It is possible to register support for multiple petitions at once by listing multiple space-separated petition IDs:

Code:

clamour …

Only CLAMspeech messages associated with staked blocks ('coinstake') will be counted.

Petition support will be counted over a 10,000 block rolling window representing approximately one week’s worth of blocks.
(60 * 24 * 7 = 10,080).

---

Creating a CLAMour Petition
Step-by-Step Instructions

Write the petition.


If you are using version 1.4.19 of the reference client or newer and wish to use its new GUI feature to create your petition:

Click the tab:

Code:

CLAMour

Enter the petition text into the textbox:

Code:

Create Petition

Click the button:

Code:

Create Identifier

to create the sha256 hash of your petition.

Optionally, click the button:

Code:

Set Vote

to immediately begin staking with the new petition ID.

Post the petition text/document, with the attached petition ID to a public forum.


If you are using an older version of the client, or don’t wish to use the new GUI feature:

sha256 hash the petition text/document. SHA256 Calculator

The first 8 hex digits of the hash are the petition ID.

Create a transaction with CLAMspeech set to:

Code:

create clamour

Where:

Code:

is the full 64 hex digit hash.

Post the petition text/document, with the attached petition ID to a public forum.
It is now up to you to rally support for the petition and prove that the network supports the change.

---

Supporting a CLAMour Petition (voting)
Step-by-Step Instructions

Set your stake(coinstake) CLAMspeech to:

Code:

clamour

Replace:

Code:

with the (space-separated) 8 hex digit petition ID(s) you intend to support.

Stake as normal.
The more blocks you stake, the more votes you will cast.

---

Setting the Stake CLAMspeech Message
Step-by-Step Instructions

In the following, should be replaced by the (space-separated) list of petition IDs you wish to support.


When using version 1.4.18 of the reference client or older

There is no way of specifying a default CLAMspeech to be used only when staking, so we have to set a CLAMspeech which is used for all transactions.
Only speech in staking transactions will be counted as 'votes'.

Either, using the console inside clam-qt:

Code:

setspeech “clamour ”

Or, using the operating system command line:

Code:

clamd setspeech “clamour ”

When using version 1.4.19 of the reference client or newer.

To use the User-Interface:
Click the Tab:

Code:

CLAMour

Enter the petition ID(s) you wish to support, one per line, into the textbox:

Code:

Petition ID

Click the button:

Code:

Set Vote

To use the console or command-line:

Either, using the console inside clam-qt:

Code:

setstakespeech “clamour pid”

Or, using the operating system command line:

Code:

clamd setstakespeech “clamour pid”

---

Interpreting the Data

In the event that two petition texts have the same 8 hex digit petition ID, the one with the “create clamour ” registration speech which appears first in the blockchain is the one being supported by votes.
This prevents an attacker from faking support for an unpopular petition by brute-forcing a partial hash collision.

A 'majority' exists when greater than 50% of staked blocks over the window express support for a petition.

A 'super-majority' exists when greater than 75% of staked blocks over the window express support for a petition.

These definitions serve to inform our discussion about the data.
Following discussion, decisions will be made.
The impact, security, and likelihood of success of any change to the network will be considered.

EDIT:
Corrected erroneous command.

I don't think there's a limit on the amount you can split, until you start hitting dogecoin-like amounts, in the billions.

There is a limit on transaction size however - no transaction can be bigger than 100,000 bytes, and so that limits the number of outputs you can create. The client will complain if you try to create too many.

When I try to create 10k outputs:


I see this in the terminal:


and this in the debug.log:


And when I try to create 3k outputs, this in the debug.log:


So somewhere around 2900 outputs seems to be the limit, although it will depend on the number of inputs, and whether the addresses are compressed or not.

They will stake separately, but may be recombined when you stake, depending on your config.

He's referring to the developers being open to the idea of changing the consensus rules to change the initial distribution.

The initial distribution was (is?) unique.

What is the largest amount that is safe to split up using:


Its fine to do a large amount at one time?  Also, those will all stake as separate outputs?

Is it better to do this between separate wallet on separate computers?   
In other words, what if on the same wallet / machine I add more coins at a later date, then I try to do the same thing, will it pull from the other outputs and mess things up?

Thanks.

What unique attributes are the developers not committed to?

I make it a point to attempt to play devil's advocate for ideas which are suggested, such as the idea to require 'dig' outputs to be staked to be claimed.

The only idea 'explicitly' supported by me personally was also suggested and brainstormed out well before the digger, despite appearances.
I am referring to various ideas surrounding fixing the fee structure - specifically those which include the element of time/blocks.

EDIT:
For what it's worth, I personally feel that CLAM is fine without removing 'digs'.
Still think the dynamic fee structure should be implemented eventually, though for reasons of DDoS/Bloat, sustainability and other reasons.
We will see what how the network feels about it.

The phrases are interchangeable:

What I believe strongly should be walked back is the discussion about taxing or stopping digging, and especially the perceived (and in some cases quite explicit) support the idea has received from the de facto leaders of the community. It was a horrible mistake to put the very core of the design of the coin on the table in response to market fluctuations, and that is most certainly what happened. It makes the coin and the community and leadership look weak and fragile, not to mention the horrible precedent of even talking about going after coins that for two years have been advertised as something people "already own".

The on-chain petition system is a mixed bag, we could argue positives and negatives in the abstract, and you can claim it has nothing to do with digging or The Digger, and how you discussed it with xploited long ago, but the recent history has now (though perhaps somewhat unintentionally and maybe even unfairly) tainted it as part of the Great 2015 Digger Panic.

These are my options on the merits of the idea (especially on pushing it out now on at apparently accelerated pace), but they are also my opinions on what has impaired the market sentiment and caused a 90% price decline rather than something closer to the 40% decrease that the numerical size of the new supply would imply. 

Hey, could you get your somewhat biased ass into the IRC channel to continue talking about it?

Ta.

I disagree - though I am obviously a bit biased on this issue

There have been talks between xploited and I for months concerning distributed governance.
Likely at least since the idea of larger blocks came up as a widely debated issue in the BTC network.

The process we are preparing is essentially a means to establish support in the same way one would establish support for a soft-fork.

The difference is that our system will allow anyone to initiate the process, anyone to vote according to their stake in the network and have the data available before any development effort is spent on a proposal.
I believe this is a net boon for the network, and hence there is nothing to 'walk back'.

---

This a double-edged sword.

For instance: consider the conversation around privacy in the BTC network.
Getting such a change implemented into the BTC codebase may very well be difficult given the variety of parties, including governmental bodies, with interests in the network.

This would allow the users of CLAM, purely on their own initiative, to evangelize for such a change and prove the network supports it.

At that point, it does not matter what 'dev team' issues the update/code.
Support has been provably demonstrated, with no permission need.
With support proven, the success of the forking change can be considered more likely.

That is quite important, in my honest opinion.
It adds resilience.
It adds decentralization of development, in a fashion, though crippled at the moment with such a small community.

In college, I was taught 'proposition'; but, basically the same I suppose.

What is USP ?  Unique selling point?

My prediction.

As long as the Just-Dice site remains successful and popular and continues to use CLAMs, the price will recover quickly. The lower price means that people will gamble larger numbers of CLAMs (this is already somewhat apparent on the site stats), which means it will be profitable to buy CLAMs for the purpose of putting them in the bankroll to back that higher volume of play. Ultimately most of the active supply will find its way into the bankroll, as it has before.

I expect the price to recover to around 0.002-0.003 before long, which is a 100-200% return from the current price. This opportunity won't be lost on investors. Capital will flow in, absorb the digger's coins (if he even chooses to sell them here -- I wouldn't) and then it will be business as usual, including pushing for more adoption and decentralization of CLAMs beyond JD which can take the price sustainably beyond the 0.003 level.

There is no need to panic, no need to start gutting the USP of the coin, nor running petitions to gut the USP of the coin. Just relax and focus on adoption. The price will take care of itself. If you are in a position to invest here, consider my previous paragraph carefully.

Obviously do your own research, understand risks, and don't invest based on what some idiot on an Internet forum wrote.


Somewhat agree. Unfortunately what did change is that the episode revealed that many in this community, including unfortunately the lead developers, are not committed to the unique attributes of the coin and willing to throw all that under the bus as soon as people start crying about the price. That is a fundamental negative. Ideally they would walk some of that back, but even so the damage is done.

Nothing fundamental has changed about CLAMs. It's going now the same place it was going before, the rate it was getting there has just been accelerated.

btw i bought coffee from this guy http://cryptomercado.com/collections/all w/ clams (via email ultimately) and he claims it is in the mail

so, it's not just 'jd' anymore

As usual, you have misunderstood. He is saying that he USES deadmansswitch.net, not that he OWNS it.

Were you being just as careless when you let the crypto world know the who and where of how to access your vast crypto wealth ?

Only an uber noob would do that.

Ti les bvre Stavo ! O agios malakas !

edit


You were looking for the best encryption for your site right ?

Magas ?