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

[garthkiser]

Changed the OP post links over to the new block explorer @ CLAMsight.com.

CLAMs, getting better every day! The website directly links to CLAMsight now too.

[1713293361]

1713293361

[1713293361]

1713293361

[gaba]

It's clear that dev received jackpot when Doog decide to go with CLAM. But what else can we expect from dev. That plans from beginning (http://clamclient.com/#/development-plan/) are still have very slow progress or not progress at all (CLAMprivacy, CLAManon). Beside that; these is only coin that give better reword to those who come later, again thanks to Doog.  Can we expect some change ( reducing rewords) or that 4.6 CLAM per address will stay forever?

[chriswen]

It's clear that dev received jackpot when Doog decide to go with CLAM. But what else can we expect from dev. That plans from beginning (http://clamclient.com/#/development-plan/) are still have very slow progress or not progress at all (CLAMprivacy, CLAManon). Beside that; these is only coin that give better reword to those who come later, again thanks to Doog.  Can we expect some change ( reducing rewords) or that 4.6 CLAM per address will stay forever?

The rewards have already been distributed.  I don't think its possible to change that.

[garthkiser]

It's clear that dev received jackpot when Doog decide to go with CLAM. But what else can we expect from dev. That plans from beginning (http://clamclient.com/#/development-plan/) are still have very slow progress or not progress at all (CLAMprivacy, CLAManon). Beside that; these is only coin that give better reword to those who come later, again thanks to Doog.  Can we expect some change ( reducing rewords) or that 4.6 CLAM per address will stay forever?

We talked about the development plan page this week in IRC. Thanks for keeping us on our toes

The CLAMs team is growing organically, which does pose some difficulty in managing the development plan page. But this is a good problem, a VERY good problem!

But yes, we will be updating the page soon.

[dooglus]

It's clear that dev received jackpot when Doog decide to go with CLAM. But what else can we expect from dev. That plans from beginning (http://clamclient.com/#/development-plan/) are still have very slow progress or not progress at all (CLAMprivacy, CLAManon). Beside that; these is only coin that give better reword to those who come later, again thanks to Doog.  Can we expect some change ( reducing rewords) or that 4.6 CLAM per address will stay forever?

The coin gives the same reward whenever you find CLAM: a little over 4.6 CLAM per address. I can't take much credit for the price of CLAM. The price of CLAM depends on the demand for it which is largely out of my control. I provide the JD platform but don't have control of how much people want to use it.

The rewards have already been distributed.  I don't think its possible to change that.

It's possible to change pretty much anything. It would be possible to add code to the client saying "in all blocks after block 500k all inputs created in the first 10k* blocks are worth half their apparent value" (or double, or nothing at all). That would create or destroy coins the same way that staking currently does.

* the initial distribution was done in blocks 558 to 9262 inclusive, and no other unspent outputs from the first 10k blocks exist.

[SuperClam]

* the initial distribution was done in blocks 558 to 9262 inclusive, and no other unspent outputs from the first 10k blocks exist.

Not entirely accurate: there were also rewards from initial staking/mining (to get the chain to the launch height of 10,000 blocks as well as to smooth the launch itself as we were 100% PoS immediately at launch) in blocks 9262++.  That said, all of those unspent outputs ended up at the unspendable burn address.

Edit:
I suppose those outputs used to stake initially would now be "unspent outputs" at a greater height than 10,000.

[dooglus]

* the initial distribution was done in blocks 558 to 9262 inclusive, and no other unspent outputs from the first 10k blocks exist.

Not entirely accurate: there were also rewards from initial staking/mining (to get the chain to the launch height of 10,000 blocks as well as to smooth the launch itself as we were 100% PoS immediately at launch) in blocks 9262++.  That said, all of those unspent outputs ended up at the unspendable burn address.

Edit:
I suppose those outputs used to stake initially would now be "unspent outputs" at a greater height than 10,000.

Not entirely accurate? How very DARE you?!?

The burn transactions happened after block 10k, so I think I'm right in saying that all unspent outputs from the first 10k blocks are all initial distribution outputs. I think I remember checking once and am pretty sure it's true, but I don't have a proof on hand right now.

[SuperClam]

* the initial distribution was done in blocks 558 to 9262 inclusive, and no other unspent outputs from the first 10k blocks exist.

Not entirely accurate: there were also rewards from initial staking/mining (to get the chain to the launch height of 10,000 blocks as well as to smooth the launch itself as we were 100% PoS immediately at launch) in blocks 9262++.  That said, all of those unspent outputs ended up at the unspendable burn address.
Edit:
I suppose those outputs used to stake initially would now be "unspent outputs" at a greater height than 10,000.

Not entirely accurate? How very DARE you?!?
The burn transactions happened after block 10k, so I think I'm right in saying that all unspent outputs from the first 10k blocks are all initial distribution outputs. I think I remember checking once and am pretty sure it's true, but I don't have a proof on hand right now.

Don't bother scraping together proof; the "edit" above already conceded the point - just left the post itself as historical record of my inaccuracy

[ethought]

I have a script which cleans up dust transactions. Basically it combines 49 dust transactions with 1 large transaction using createrawtransaction, signrawtransaction, sendrawtransaction

However it does not seem to work with Clams for some reason...

I keep getting the following error:

error: {"code":-22,"message":"TX rejected"}

After looking into the issue and test sending transactions manually with clamd in a console I get the same error.

Any idea why this might be happening?

It seems to work sometimes if I limit createrawtransaction to using only 2 or 3 input transactions.

On coinwallet.co I have around 7600 dust transactions in the wallet, and am not able to send out even 4 CLAMs with out a "transaction too large" error because of all the dust.

[dooglus]

Any idea why this might be happening?

Watch the debug.log - it probably tells you something like:

2015-05-13 07:00:58 ERROR: AcceptToMemoryPool : not enough fees 22f5cf1835d3f2135d10e460af30eb7ccd6329f0cf9f40a730b0726fe76964e2, 10000 < 20000

or:

2015-04-30 16:19:31 CWallet::CreateTransaction failed: transaction too big (104430 >= 100000)

[ethought]

Any idea why this might be happening?

Watch the debug.log - it probably tells you something like:

2015-05-13 07:00:58 ERROR: AcceptToMemoryPool : not enough fees 22f5cf1835d3f2135d10e460af30eb7ccd6329f0cf9f40a730b0726fe76964e2, 10000 < 20000

or:

2015-04-30 16:19:31 CWallet::CreateTransaction failed: transaction too big (104430 >= 100000)

Thanks!

Code:

ERROR: AcceptToMemoryPool : not enough fees 02ce86ccb2dcce0841410b4e243363aa80c7aa5978572f9529074eade0040f75, 0 < 10000

I usually use the following to determine fees:

Code:

Calculating Fee:
Vout_Count = 50
  Debug: estimated transaction size: 9042 bytes (fee required at 10000 bytes or more)
tx_size_ok = 1
  Debug: transaction priority: 238.31M (fee required at 57.6M or less)
sugg_fee = 0

I even tried forcing a small fee but the transaction still failed.

So how can I calculate the required fee?

[dooglus]

Any idea why this might be happening?

Watch the debug.log - it probably tells you something like:

2015-05-13 07:00:58 ERROR: AcceptToMemoryPool : not enough fees 22f5cf1835d3f2135d10e460af30eb7ccd6329f0cf9f40a730b0726fe76964e2, 10000 < 20000

or:

2015-04-30 16:19:31 CWallet::CreateTransaction failed: transaction too big (104430 >= 100000)

Thanks!

Code:

ERROR: AcceptToMemoryPool : not enough fees 02ce86ccb2dcce0841410b4e243363aa80c7aa5978572f9529074eade0040f75, 0 < 10000

I usually use the following to determine fees:

Code:

Calculating Fee:
Vout_Count = 50
  Debug: estimated transaction size: 9042 bytes (fee required at 10000 bytes or more)
tx_size_ok = 1
  Debug: transaction priority: 238.31M (fee required at 57.6M or less)
sugg_fee = 0

I even tried forcing a small fee but the transaction still failed.

So how can I calculate the required fee?

I use this in a shell script I wrote once:

    fee=$((($(eval $sign | wc -c) / 2 + 999) / 1000))

ie. sign the transaction, count the characters in the hex string, halve it to get the size in bytes, and round up to a multiple of 1000. Then I use 0.0001*$fee as the fee.

Of course, changing the fee requires you to re-sign the transaction, which can cause the length to change a little (since each input is signed separately, and the length of each signature can increase or decrease by one byte). So to by on the safe side you might want to add 999 + number_of_inputs in there, not just 999. Or just iterate on failure, recalculating the fee from the signed tx length until it succeeds.

Edit: CLAM doesn't have fee-free transactions, I don't think. Every transaction has to include a fee of 0.0001 per 1000 bytes or part thereof. So that's where you're going wrong. I'm not sure whether this is a hard rule (enforced on received transactions and/or blocks) or simply enforced by the client before it will transmit a transaction. Maybe you could modify your local client code to have it send zero-fee transactions and have the network accept them. I never looked into that.

Edit2: I decided to experiment with a zero-fee transaction.

First off, AcceptToMemoryPool() does this check:

Code:

       int64_t txMinFee = GetMinFee(tx, 1000, GMF_RELAY, nSize);
        if ((fLimitFree && nFees < txMinFee) || (!fLimitFree && nFees < MIN_TX_FEE))
            return error("AcceptToMemoryPool : not enough fees %s, %d < %d",
                         hash.ToString(),
                         nFees, txMinFee);

That's where the error you saw came from.

Removing that check isn't enough. You just get a different error:

    2015-05-13 16:37:44 ERROR: AcceptToMemoryPool : ConnectInputs failed c2287daabc7a7b86b723a6c791932fe89371c7c1e8d0cabeb1f4078dcbcda131

That's coming from ConnectInputs() which does this check:

Code:

           // enforce transaction fees for every block
            int64_t nRequiredFee = GetMinFee(*this);
            if (nTxFee < nRequiredFee)
                return fBlock? DoS(100, error("ConnectInputs() : %s not paying required fee=%s, paid=%s", GetHash().ToString(), FormatMoney(nRequiredFee), FormatMoney(nTxFee))) : false;

Removing that check too allows me to send a transaction with no fees:

Code:

$ cc sendrawtransaction $(cc signrawtransaction $(cc createrawtransaction '[{"txid":"951c5cebf8b04a8251f8617331e797a003e52daebdde9670381979e418b8e5cd","vout":1}]' '{"xW42Nau4hpdSu5931gaRHgx6B2ah3WpEvX":{"count":1,"amount":0.25}}') | grep hex | cut -d'"' -f4)
e812bf578bbc0157ac3fd0ed90e0634537d846b50ea71223391739a9ed55f54d

But checking on other nodes in the network, the transaction was either never seen, or seen and rejected with this error message:

Code:

2015-05-13 16:42:55 ERROR: AcceptToMemoryPool : not enough fees e812bf578bbc0157ac3fd0ed90e0634537d846b50ea71223391739a9ed55f54d, 0 < 10000

So maybe if I staked the block myself it would be accepted? To do that I need to run with -mintxfee=0 otherwise my node won't try to include the zero-fee transaction in the blocks it stakes:

Code:

           // Skip free transactions if we're past the minimum block size:
            if (fSortedByFee && (dFeePerKb < nMinTxFee) && (nBlockSize + nTxSize >= nBlockMinSize))
                continue;

Then there was another check for fee size in the miner code, so I commented that out too:

Code:

           int64_t nTxFees = tx.GetValueIn(mapInputs)-tx.GetValueOut();
            if (nTxFees < nMinFee)
                continue;

Finally I managed to stake my zero-fee transaction into a block. When the block was sent to a standard node, it rejected it:

Code:

2015-05-13 18:12:13 ERROR: ConnectInputs() : e812bf578bbc0157ac3fd0ed90e0634537d846b50ea71223391739a9ed55f54d not paying required fee=0.0001, paid=0.00
2015-05-13 18:12:13 InvalidChainFound: invalid block=0c4d66dc6fb8ff9bec6c9e26f12feddec1e3adb6a6f041b309b4947b02bfbc52  height=465778  trust=35361372754116997652  blocktrust=188138013378102  date=05/13/15 18:12:16
2015-05-13 18:12:13 InvalidChainFound:  current best=85b33a65171b31060c66516d5c51c04149e39434eca3a8389e39eb60bd8ab779  height=465777  trust=35361184616103619550  blocktrust=188715424952782  date=05/13/15 18:09:52
2015-05-13 18:12:13 ERROR: SetBestChain() : SetBestChainInner failed
2015-05-13 18:12:13 ERROR: AcceptBlock() : AddToBlockIndex failed
2015-05-13 18:12:13 ERROR: ProcessBlock() : AcceptBlock FAILED

So I guess that answers that question. ConnectInputs() is called both when creating a transaction and when checking the transactions in received blocks, and it rejects transactions which don't have enough fees.

I was worried I would have to reindex my blockchain on the node that staked the invalid block to get it to continue staking from a valid block, but it turned out I didn't need to. The rest of the network carried on staking from the last valid block, generated a longer chain than my invalid chain, and my node switched to that longer chain, orphaning the invalid block containing the zero-fee transaction.

[gjhiggins]

I decided to experiment with a zero-fee transaction. ...

Very nice illustration of the principle.

Cheers

Graham

[dooglus]

I'm having trouble with the new block explorer.

I recently made a transaction, but the block explorer seems unable to calculate the fee:



[Edit: 4 days later the same page works fine - the clamsight database was regenerated or something which seems to have cleared up the problem:



end edit]

When I click to see more inputs and scroll down, I see a couple that it can't parse:



If I click the plus sign, I see that the problem may be to do with unconfirmed inputs (but the transaction I'm looking at is confirmed, so how can it have unconfirmed inputs?):



The transaction link is http://clamsight.com/tx/36f003dd4f9eaa6199e5a36a30a0f63ddd207d150c413f10d33ba4eff189f094.

Edit: I reloaded the clamsight page. It now has 9 confirmations but the fee is still not being shown, and it's still complaining about unconfirmed inputs:



The 'copy' icons next to that error copy these values:

Code:

3045022100ede3648703ff5f9cfa9d3b07d133ce7a4c92d072ada33a6899ba251fd89fab74022039f172ef9d48f2f4295665757e3508548bfb5b2609be95ad34e35885c601456401

and

Code:

025f15e4986a504a3771f70e65e1bfe27640ef614c6c1103257d3c881a70756bf3

Tracing it back, it looks like the problem is caused by "double spend attempts":



I wouldn't have thought it would be easy to double-spend on the CLAM network when a single node has over 70% of the staking weight. I expect this is a false alarm, but it is messing up clamsight.

Clicking the plus sign on that transaction causes what looks like corruption:



It shouldn't be showing "doubleSpentTXId}}" - I imagine that's a bug.

[xploited]

I'm having trouble with the new block explorer.

...

It shouldn't be showing "doubleSpentTXId}}" - I imagine that's a bug.

Thank you for pointing this out!  I expected there to be little problems that needed to be ironed out but I need to see them as they are often rare occurrences. If you or anyone else notices any oddities with clamsight please let me or Kef know.

Also the entire codebase is available and I'm willing to offer bounties for bug fixes like this.  

Its currently in my personal repo at  https://github.com/l0rdicon/clamsight https://github.com/l0rdicon/clamcore and https://github.com/l0rdicon/clamsight-api

[dooglus]

Thank you for pointing this out!  I expected there to be little problems that needed to be ironed out but I need to see them as they are often rare occurrences. If you or anyone else notices any oddities with clamsight please let me or Kef know.

Is posting in this thread a good way to let you know?

I found another issue:



That's on http://clamsight.com/tx/27bc5fd460e8834be3cfd74b75670e6348197d7c37127a6e1052aeab75af6ec8

Maybe that happens with all unconfirmed transactions; I'm not sure. Waiting for it to confirm then reloading made the red errors go away.

[almightyruler]

Odroid C1 update: the little cigarette pack sized computer has now successfully staked.

http://clamsight.com/tx/36402fb5bfccb4651d4bf0cfbf1fcc114d5caaa7d3164028ac189439303b0fc7

(For those of you who have no idea what an Odroid C1 is - it's like a Raspberry Pi 2, but faster. Quad core ARM @1.5GHz)

[Kefkius]

Thank you for pointing this out!  I expected there to be little problems that needed to be ironed out but I need to see them as they are often rare occurrences. If you or anyone else notices any oddities with clamsight please let me or Kef know.

Is posting in this thread a good way to let you know?

I found another issue:



That's on http://clamsight.com/tx/27bc5fd460e8834be3cfd74b75670e6348197d7c37127a6e1052aeab75af6ec8

Maybe that happens with all unconfirmed transactions; I'm not sure. Waiting for it to confirm then reloading made the red errors go away.

I'm not particularly active here, but I'm sure xploited will let me know of major issues that come up, as he has thus far. I'm still investigating the cause of this problem.

[xploited]

Thank you for pointing this out!  I expected there to be little problems that needed to be ironed out but I need to see them as they are often rare occurrences. If you or anyone else notices any oddities with clamsight please let me or Kef know.

Is posting in this thread a good way to let you know?

I found another issue:

That's on http://clamsight.com/tx/27bc5fd460e8834be3cfd74b75670e6348197d7c37127a6e1052aeab75af6ec8

Maybe that happens with all unconfirmed transactions; I'm not sure. Waiting for it to confirm then reloading made the red errors go away.

Forum works great.

Do you happen to know how quickly after you sent you looked at it in clamsight?  I ask because I suspect what you saw was a tx that was unconfirmed due to a reorg and when it was put in a new block the leveldb updated the spent outputs. You happened to look at it in the state where the leveldb entries had been erased. 

At least thus is my current best guess. I've been looking at unconfirmed tx's and haven't seen one come up with that issue yet. 

[dooglus]

Do you happen to know how quickly after you sent you looked at it in clamsight?

I guess about 5 seconds. I copy/pasted the txid, use a Chrome shortcut to visit the clamsight page. Pretty sure it would have been less than 10 seconds. Probably not long enough for the transaction to get into a block and then be reorg-ed back out of the blockchain, but it's possible.

Edit: I just tried again. Made a big transaction, visited its clamsight page about 5 seconds later, saw the same errors:

http://clamsight.com/tx/e245be1508654e45fcdae628e5fe10df30074a48d21025c3a86e9669da6f06fe



So I don't think it can be related to reorgs. I think it's just what happens if I view a big transaction too soon after making it.