Author

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

legendary
Activity: 1007
Merit: 1000
Quick question.  For staking purposes, would it be better to have all outputs tied to one address, or does it not matter.  What if you had 100 clams divided into 4 clam outputs.  so 25 outputs all tied to one address, or 25 different addresses. 

It doesn't matter at all.

Staking works on outputs, not addresses.

   I'm getting myself more and more confused.  Since the odds of staking are based the number of coins.  Some where that has to tie in.  Are larger outputs more likely to stake then smaller output?  I would guess yes?  But I could be wrong.  If that's the case then making my output's larger should give them more of a chance to stake more regularly. 

    Conversely,  if all outputs are equal then more output's equals more of a chance to stake.  So I could divide the output's up into smaller unit's assuming I have enough CPU power to hash them all.   
 
   My staking is all over the board.  From 1 per day to 10 and everything in between.  This is with 2.1K in my wallet. 
legendary
Activity: 2940
Merit: 1333
Quick question.  For staking purposes, would it be better to have all outputs tied to one address, or does it not matter.  What if you had 100 clams divided into 4 clam outputs.  so 25 outputs all tied to one address, or 25 different addresses. 

It doesn't matter at all.

Staking works on outputs, not addresses.
legendary
Activity: 1007
Merit: 1000

   Quick question.  For staking purposes, would it be better to have all outputs tied to one address, or does it not matter.  What if you had 100 clams divided into 4 clam outputs.  so 25 outputs all tied to one address, or 25 different addresses. 
legendary
Activity: 2940
Merit: 1333
Why not just update the client to allow conditional zero-fee transactions, just like BTC, LTC and DOGE which CLAM was originated from?

BTC, LTC and DOGE codes all allow nMinFee = 0 if the transaction priority is over 57.6M. It is disappointing we cannot do the same on CLAM network.

It would mean making a hard-fork, and everyone would have to upgrade. It doesn't seem worth it just to save a tiny fraction of a CLAM. The fee (0.0001 CLAM per kB) is worth about a hundredth of a US cent.
full member
Activity: 217
Merit: 100
Part-time Altcoin Developer
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.


Why not just update the client to allow conditional zero-fee transactions, just like BTC, LTC and DOGE which CLAM was originated from?

BTC, LTC and DOGE codes all allow nMinFee = 0 if the transaction priority is over 57.6M. It is disappointing we cannot do the same on CLAM network.
legendary
Activity: 2940
Merit: 1333
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.
sr. member
Activity: 304
Merit: 252
CLAM Dev
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. 
member
Activity: 64
Merit: 20
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.
legendary
Activity: 2268
Merit: 1092
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)
legendary
Activity: 2940
Merit: 1333
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.
sr. member
Activity: 304
Merit: 252
CLAM Dev
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

legendary
Activity: 2940
Merit: 1333
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.
legendary
Activity: 2254
Merit: 1290
I decided to experiment with a zero-fee transaction. ...

Very nice illustration of the principle.

Cheers

Graham
legendary
Activity: 2940
Merit: 1333
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.
legendary
Activity: 1316
Merit: 1000
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?
legendary
Activity: 2940
Merit: 1333
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)
legendary
Activity: 1316
Merit: 1000
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.
hero member
Activity: 784
Merit: 1002
CLAM Developer
* 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?!? Wink
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 Grin
legendary
Activity: 2940
Merit: 1333
* 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?!? Wink

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.
hero member
Activity: 784
Merit: 1002
CLAM Developer
* 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.
Jump to: