nochowderforyou/clams

Clam Project

clams's Issues

"Weight" and other label issues

Staking labels in the UI are inaccurate across the board.

hard to read tooltip in new clam-qt

See http://i.imgur.com/TwDbPzJ.png

The tooltip is kind of black on dark grey.

confusing indentation

What's going on here (in wallet.cpp)?

Looks like the code is correct, but it's laid out all wrong. I'll fix that.

Timestamp granularity and block time inconsistency

(16 * 4) % 60 = 4

expose 'split' and 'merge' in GUI

The client will currently split an output if it stakes within 28 hours of its most recent transaction (previous stake, or previous movement) regardless of the size of the output. It could be a tiny output that just happened to get lucky. I would argue that such an output doesn't need splitting.

It will also re-merge those split outputs the next time either of them stakes if they are both less than 1000 CLAMs.

This results in split - merge - split - merge cycles.

The re-merging is particularly annoying, since it destroys the age of two outputs at once, while only providing a single reward.

We should:

1. make the split and merge happen based on output size and current difficulty, rather than the random luck of a particular output

2. expose the thresholds for split and merge (however the end up after 1) above) in the GUI and RPC interface

3. set reasonable defaults - probably with 'merge' disabled by default

Mined two blocks with a single hash

Hi.

I don't know if this is a bug or not, because I don't really understand the design.

I just mined two blocks in the same second because the same "stake modifier" was used two blocks in a row. The result of the hash was very low, which is what you need to mine a block, but then the exact same very low hash was used to mine another block, on another output from another address in the same second.

I'm talking about these two blocks (35004 and 35005):

http://khashier.com:2750/block/eb18e05bd9118378029445df411086f3bc6ab17ed818014c6648b887860a6a4c
http://khashier.com:2750/block/8061d8a894e22d2a40c813be6856ed07361ab79101c5a5c55363623eef2386d9

I added some debug to show the comparison between the hash and the target (both right shifted 224 bits to hide the insignificant bits). See how the same hash is used, and the same modifier:

  000038a8 <=     cfec (14)
CheckStakeKernelHash() : using modifier 0xae486833e969e2af at height=33032 timestamp=2014-07-11 12:33:10 UTC for block from height=32880 timestamp=2014-07-11 06:38:01 UTC
CheckStakeKernelHash() : pass modifier=0xae486833e969e2af nTimeBlockFrom=1405060681 nTxPrevOffset=149 nTimeTxPrev=1405060681 nPrevout=1 nTimeTx=1405355226 hashProof=000038a8c86aacde8681725c904abfc52e63c02b5d85bb3356edf2c50d4e0971

  000038a8 <=     bcc8 (14)
CheckStakeKernelHash() : using modifier 0xae486833e969e2af at height=33032 timestamp=2014-07-11 12:33:10 UTC for block from height=32881 timestamp=2014-07-11 06:38:01 UTC
CheckStakeKernelHash() : pass modifier=0xae486833e969e2af nTimeBlockFrom=1405060681 nTxPrevOffset=149 nTimeTxPrev=1405060681 nPrevout=1 nTimeTx=1405355226 hashProof=000038a8c86aacde8681725c904abfc52e63c02b5d85bb3356edf2c50d4e0971

Edit: I see this is only possible because I was staking using two outputs which themselves were mined at exactly the same time, in these blocks:

Transaction 55c00702d2...8d4b Appeared in Clams 32880 (2014-07-11 06:38:01)
Transaction 1cb68c4e39...2d4e Appeared in Clams 32881 (2014-07-11 06:38:01)

and they in turn were staked from outputs which themselves were mined together:

Transaction f73f152fa5...f6d3 Appeared in Clams 31250 (2014-07-08 10:44:59)
Transaction 113b44afcb...42fd Appeared in Clams 31249 (2014-07-08 10:44:59)

So it looks like in the future, whenever I am able to stake one of this pair, I am able to stake the other one at the same time as well.

This could be fixed by including the txid in the hash as well.

src/kernel.cpp says:

//   block/tx hash should not be used here as they can be generated in vast
//   quantities so as to generate blocks faster, degrading the system back into
//   a proof-of-work situation.

but that's talking about the hash of the block or tx we're creating, not of the tx we're staking from.

Horrendous colored UI buttons

Ick.

timestamp error on freshly 'dug' clams

I just found a Bitcoin private key that I hadn't "dug" before, so I ran:

clamd importprivkey $privkey '' false

to import it without rescanning, then stopped clamd and restarted it with the -rescan flag.

Here are edited highlights of the debug.log:

CheckStake() : new proof-of-stake block found  
SetBestChain: new best=02eef96e3ba0cafecec4  height=40423  trust=45813345548  blocktrust=1052706  target=4079  date=14-07-23 23:47:36
ProcessBlock: ACCEPTED

SetBestChain: new best=ced76c44453a46fe4d2e  height=40424  trust=45814394125  blocktrust=1048577  target=4095  date=14-07-23 23:51:47
ProcessBlock: ACCEPTED

ThreadRPCServer method=importprivkey
NotifyAddressBookChanged xFKHcpoE3bfYjaY1gEDPqs4qaCx233Awns  isMine=0 status=0

SetBestChain: new best=1bd4a24847c841d3c2d0  height=40425  trust=45815442702  blocktrust=1048577  target=4095  date=14-07-23 23:56:00
ProcessBlock: ACCEPTED

ThreadRPCServer method=stop
Clam exited





Clam version v1.4.2.0-53-ga3c48a7-dirty (2014-07-23 12:47:28 -0700)
Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014
Startup time: 14-07-23 23:57:23

LoadBlockIndex(): hashBestChain=1bd4a24847c841d3c2d0  height=40425  trust=45815442702  date=14-07-23 23:56:00
LoadBlockIndex(): synchronized checkpoint 00000c3ce6b3d823a35224a39798eca9ad889966aeb5a9da7b960ffb9869db35

Rescanning last 40425 blocks (from block 0)...
AddToWallet 388759bc07  
AddToWallet 52acdaa69f  
AddToWallet 322a813e5c  
WalletUpdateSpent found spent coin 1.33260167 CLAM 1da2b416c8e392eaafb7ce0dac6be3604a6f6669e711ed73f87feebd79027227
 rescan               286969ms

SetBestChain: new best=f31662b93cace2d2da9d  height=40426  trust=45816491279  blocktrust=1048577  target=4095  date=14-07-24 00:02:10
ProcessBlock: ACCEPTED

and here's a screenshot of the wallet:

Note the time on the new 4.6 CLAMs. It's 16:47. I ran the 'importprivkey' after a block was found at 23:51:47, so where does 16:47 come from? It's clearly wrong.

(The log timestamps are UTC, and the wallet timestamps are 7 hours earlier, in PDT, so 23:51 in the log corresponds to 16:51 in the wallet GUI).

rescan form imported wallet doesn't happen automatically

Sometimes when a wallet.dat is imported a rescan does not occur.

It should.

khashier crashes showing blocks 0 and 1

Block 2 is OK:

http://khashier.com/block/0000042f7f9811948352d2ecc9215916f2276a5259ca4cdc4ccfb77a72ed8ebc

but block 1 isn't:

http://khashier.com/block/00000feca63cbde350712358668e0fe90e96c97efab3f0ff5fd9f3147dd2f53e

Menu on OSX

Although the new menu (File, Misc) on windows is real improvement, it does provide a worse UI integration in osx. Suggest to make it back the way it was in for OSX.

Tor does not work with network updates

Something in the network updates seem to have broken tor.

It does connect to other peers, but afterwards the peers disconnect tor nodes quickly

Proxy error: general failure

menu bar doesn't show up

When I run bitcoin-qt, I see a menu bar, as expected:

But when I run clam-qt, I don't:

This makes the GUI pretty useless since I can't access any of the features that are on the menu.

Send Tab Details Size

On the send tab, the box where users input amount/address/label is severely undersized and can't display even a single recipient, let alone multiple recipients.

widget spacing and size is ridiculous on osx

khashier displays this transaction incorrectly

See http://khashier.com/tx/24acea41498b2f387ff751997f8dc90a4551f7b638e7cfc00750a9966f3bc018

It says the fee is -3.9961 when it was really 0.0039.
It says it has 839 outputs when it really has 838.

It lists one of the outputs twice, with two different 'spent' links:
http://khashier.com/tx/5d46a5d2596e41b3f42c161a362532ce82a54c599b2fb5e75e153aa941acb553
http://khashier.com/tx/53a63ff503e39486cafc279d4ae3feabbbaf539c396404c1fff4ad70512244dd

The 'output' link in both of the above points at http://khashier.com/tx/24acea41498b2f387ff751997f8dc90a4551f7b638e7cfc00750a9966f3bc018#o465

The output in question staked twice, but one of them was orphaned.

master branch fails to build

The fix for issue #14 includes this statement:

assert(!strWalletFileName.empty())

with no trailing semicolon.

It has been merged to the master branch, but doesn't compile.

I always make sure I have the latest master branch before making changes so my changes are easier to merge back, and it's inconvenient when the master branch is broken.

Could we do development work on other branches and only merge working code to master please?

outputs aren't being rejoined properly?

See http://khashier.com:2750/address/xM6RZyyM16Ehx1CQYLHUQqqxS4Qov66XHM - that address won a 709 CLAM lottery block in block 37893 (2014-07-19 02:10:04).

It staked those 709 into two 354 CLAM outputs in block 38403 (2014-07-19 18:55:11).

One of those 354 CLAM outputs staked again in block 39031 (2014-07-21 03:16:46) but it wasn't recombined with the other 354 CLAM output.

Why not?

wallet.cpp says:

int64_t nStakeCombineThreshold = 1000 * COIN;

meaning if there are multiple sub-1000 CLAM coins at the staking address they should be recombined.

At first I thought I had found the bug, because the code that combines the outputs says:

        // Do not add input that is still too young
        if (nTimeWeight < nStakeMinAge)
            continue;

but:

        int64_t nTimeWeight = GetWeight((int64_t)pcoin.first->nTime, (int64_t)txNew.nTime);

and GetWeight() does this:

return min(nIntervalEnd - nIntervalBeginning - nStakeMinAge, (int64_t)nStakeMaxAge);

ie. it already takes nStakeMaxAge into account, so we should be doing < 0 not < nStakeMinAge in the comparison.

But:

unsigned int nStakeMinAge = 4 * 60 * 60; // 4 hours

and the time between blocks is well over 8 hours, so that's not the problem (although it probably is a problem).

coincontrol window shows incorrect output weights

src/qt/coincontroldialog.cpp does this:

        // weight
        int weight = floorf((GetTime() - out.tx->GetTxTime() - nStakeMinAge) * out.tx->vout[out.i].nValue / BitcoinUnits::factor(BitcoinUnits::BTC) / (double)(1440 * nTargetStakeSpacing));

Weight is no longer dependent on age except for setting the weight to 0 for coins which are immature or which have moved in the last 4 hours.

**** exception ncountered ***** during startup on wallet import

lots of the following error during initial wallet import

ERROR: CTxMemPool::accept() : CheckTransaction failed
ERROR: CTransaction::CheckTransaction() : vout empty

salvagewallet and rescan are failing to remove all the false tx data from the original wallet in certain cases.

Need to determine the exact cause and create new importwallet option

[LTS] Integrated One-Off Lottery and Dice

The first clone of our distribution method, and a fellow open source crypto, has a very interesting "Play" Tab in-client.

I believe an implementation of this one-off lottery feature would go perfectly with the CLAM Proof-Of-Pearl Lottery. In addition, I am interested in whether dooglus might have any comments concerning a similar dice implementation; considering his extensive experience with numbers games/dice.

Any in-client use of CLAMS makes economic sense, especially if designed to be inflation neutral.

https://github.com/LottoShares/lottoshares/
https://bitcointalk.org/index.php?topic=694341.0

RPC 'getstakinginfo' command expected staking time is inaccurate

It does this:

int nExpectedTime = staking ? (nTargetSpacing * nNetworkWeight / nWeight) : -1;
obj.push_back(Pair("expectedtime", nExpectedTime));

which is very inaccurate when the network is generating blocks less often than one per minute.

Issue #19 fixed a related bug in the GUI display, and can probably be used here too.

Incorrect chronological sorting in main window after reindex

With clam client d20edac, after running ./clam-qt -reindex (after being advised to do so due to an apparent libdb incompatibility), the main window displays of transactions that are not the claimed latest. Moreover, the 6 transactions displayed are themselves also not in chronological order. This hints that the data this is taken from is not sorted, and that this window just picks the first 6, assuming sorting.
The transactions window itself displays properly sorted transactions.

Title-bar Menu color inconsistency

The color of the title bar menu is inconsistent across platforms. On one Windows system, it displays with the black theme, on another it displays in gray.

Icon Always in Top Left of Screen

The CLAM icon is always at the very left of my top menu bar. It obstructs the title of whatever window I have in focus. The icon stays there no matter which workspace I'm in. Using version 1.4.3.0, compiled on Ubuntu Linux.

importing wallet blocks gui thread

Transaction tab contrast

Rows in the transaction tab of the new UI have extremely poor contrast and it can be difficult to discern details.

feature request: watch-only addresses

bitcoin/bitcoin#4045 has been merged into their master branch, and allows us to import addresses without the corresponding private key, and so effectively have watch-only addresses.

That would be a useful thing for the CLAM client to have.

Are there plans to rebase with a more recent Bitcoin version? If so, I guess we'll get this feature as a part of that rebase. If not, I'd like just this one merged it, if possible. :)

Setting Reserve Without Client Restart

Low Priority

Some new users may be confused by the requirement to restart before reserve settings take effect. No notification is given that the reserve is not in effect after setting it.

stylesheet needs version control and failsafe conditions

If no style.qss is found in the configuration folder, the embedded one is written and used.
Bugfixes/extensions in the default stylesheet requires every user to delete the style.qss when upgrading.
It would be better to check for a style.qss as it is now but use the embedded one if it does not exist.

difficulty code is vulnerable

In main.cpp:

if (nActualSpacing < 0) nActualSpacing = currentTargetSpacing;

ie. if the date on the most recent block is older than the date on the previous block, difficulty doesn't change.

So if I am staking a whole bunch of distribution clams, I can deliberately publish my blocks with timestamps like this:

X, X-1, X-2,
X+60, X+59, X+58,
X+120, ...

The difficulty will stay at the minimum while I get to stake 3 blocks per minute.

Notification icons (osx)

Notification:

Notification history:

block explorer fails if you try to view an unconfirmed transaction

I can't give a link, because unconfirmed transactions confirm quickly, but if you send a transaction and immediately try to view it on khashier.com/tx/$txid you see a page full of errors:

http://i.imgur.com/lhkbNjh.png

"lottery" based subsidy code seems flawed

The current block subsidy makes sense, and gives around 1% interest per year:

nSubsidy = nCoinAge * COIN_YEAR_REWARD * 33 / (365 * 33 + 8)

The new "lottery" code completely ignores nCoinAge, and gives every block a random subsidy which completely ignores the size of the coin being staked.

This incentivises me to split my big coins up into lots of smaller coins so I get more chances per second of staking a block.

Please rethink this change before it goes live.

Currently:

const int LOTTERY_START = 34000;

protocol allows unlimited splitting on stake

See this transaction: http://khashier.com/tx/71f60ecbb97a69ead2722efb973aa3f8aaa4d22618ecccd2824de762f29c358a

I staked a 5 CLAM output into 6 separate 1 CLAM outputs and 4 0 CLAM outputs. There's no transaction fee for doing so. This could be abused to make arbitrarily large transactions up to the block size limit.

We'll need a hard fork to fix this.

I propose disallowing any output less than 1 CLAM in the staking transaction. So I can split a 5 CLAM input into 6 separate 1 CLAM outputs, but no more than that. Since the block reward is 1 CLAM, the total output will always be greater than 1 CLAM, since the input is always greater than 0.

This will prevent people from staking a 0.1 input into two 0.55 outputs, but I think that's fine.

Aside: maybe we should have a 'hardfork' label to collect all the hardforking issues together, so we can easily find them all when it comes to fork time.

Dropdown 'caret' of CLAMspeech field on Send Tab, missing.

The field found in the send tab, where CLAMspeech comments can be added to transactions, is actually a drop down; though on at least some platforms the conventional 'caret' which would signify this is not displayed. The drop down is still functional - just doesn't appear to be a drop down.

Refactor networking to current bitcoin networking

Our networking code is quite old and prone to issues, for example the unreasonable long sync time on initial sync.

The code needs to be refactored to the current bitcoin.

This will also fix issues with proxys/tor

Versions report back improperly

The versions report different in getinfo and the qt client, and both are wrong.

Coin-Control Sorting

There appears to be some issues related to coin-control column sorting not functioning in the new UI.

blocks are staking too slowly

The target time per block is 1 minute, but we're seeing around half that rate. The last two days we've seen around 700 blocks per day.

I looked to see why that is, and found:

1. we are often at the minimum difficulty

CBigNum bnProofOfStakeLimit(~uint256(0) >> 20);

changing the 20 to 18 or something would probably fix the problem by increasing the max target / decreasing the min difficulty.

2. GetNextTargetRequiredV2() in main.cpp effectively does this for each block to get 'new' difficulty from 'old':

new = old * (15 * currentTargetSpacing + nActualSpacing + nActualSpacing) / (17 * currentTargetSpacing)

Issue #4 means that it's not unusual for two blocks to have the same timestamp, causing nActualSpacing to be 0, and causing a 2/15 = 13.3% leap in difficulty which then takes a while to recover from.

Changing bnProofOfStakeLimit would cause a hard fork.

importing wallets fails on Windows for paths containing spaces

I've seen many people complaining of an error trying to import their old wallets:

CDB : Error 2, can't open database (code -1)

It turns out that this happens if there is a space in the pathname to the wallet they're importing. ".../Documents and Settings/..." for example.

Copying the wallet to C:\wallet.dat and importing from there fixes it.

I'm told the same issue happens using 'clamd importwallet' too, so it's not a Qt issue.

I've been unable to reproduce it on Linux.

rpc getstakinginfo call

getstakinginfo is returning wrong weight.

Needs to be divided by COIN to get correct weight

Feature to unlock only for staking

pull in the novacoin feature to only unlock the wallet for staking features so leaving your wallet upon isn't as much of a security risk.

khashier doesn't show how many confirmations a transaction has

It will show what block a transaction was confirmed in, but I have to go to the front page to see the current chain length, and then do a subtraction.

It would be better if the page did that for me.

trouble building clam-qt

I've been trying to test the recent commits to the 1.4.3.1 branch, but couldn't get clam-qt to build.

I ended up making two changes, as follows.

bitcoin.cpp was failing to compile, with this error:

In file included from /usr/include/openssl/crypto.h:125:0,
                 from src/allocators.h:12,
                 from src/qt/walletmodel.h:8,
                 from src/qt/bitcoin.cpp:5:
src/qt/bitcoin.cpp: In function ‘void DebugMessageHandler(QtMsgType, const QMessageLogContext&, const QString&)’:
src/qt/bitcoin.cpp:132:33: error: variable ‘QTextStream 'has initializer but incomplete type'
     static QTextStream qstdout( stdout, QIODevice::WriteOnly );
                                 ^
make: *** [build/bitcoin.o] Error 1

so I added a missing header file:

diff --git a/src/qt/bitcoin.cpp b/src/qt/bitcoin.cpp
index e6c1517..97ef183 100644
--- a/src/qt/bitcoin.cpp
+++ b/src/qt/bitcoin.cpp
@@ -22,6 +22,7 @@
 #include <QTranslator>
 #include <QSplashScreen>
 #include <QLibraryInfo>
+#include <QTextStream>

 #if defined(BITCOIN_NEED_QT_PLUGINS) && !defined(_BITCOIN_QT_PLUGINS_INCLUDED)
 #define _BITCOIN_QT_PLUGINS_INCLUDED

and the link step was failing like this:

/usr/bin/ld: cannot find -ldb_cxx-4.8
collect2: error: ld returned 1 exit status
make: *** [clam-qt] Error 1

until I changed:

diff --git a/clam-qt.pro b/clam-qt.pro
index ee336f5..2a42480 100644
--- a/clam-qt.pro
+++ b/clam-qt.pro
@@ -425,7 +425,7 @@ macx:QMAKE_INFO_PLIST = share/qt/Info.plist
 # Set libraries and includes at end, to use platform-defined defaults if not overridden
 INCLUDEPATH += $$BOOST_INCLUDE_PATH $$BDB_INCLUDE_PATH $$OPENSSL_INCLUDE_PATH $$QRENCODE_INCLUDE_PATH
 LIBS += $$join(BOOST_LIB_PATH,,-L,) $$join(BDB_LIB_PATH,,-L,) $$join(OPENSSL_LIB_PATH,,-L,) $$join(QRENCODE_LIB_PATH,,-L,)
-LIBS += -lssl -lcrypto -ldb_cxx$$BDB_LIB_SUFFIX
+LIBS += -lssl -lcrypto -ldb_cxx
 # -lgdi32 has to happen after -lcrypto (see  #681)
 windows:LIBS += -lws2_32 -lshlwapi -lmswsock -lole32 -loleaut32 -luuid -lgdi32
 LIBS += -lboost_system$$BOOST_LIB_SUFFIX -lboost_filesystem$$BOOST_LIB_SUFFIX -lboost_program_options$$BOOST_LIB_SUFFIX -lboost_thread$$BOOST_THREAD_LIB_SUFFIX

Option to import multiple private keys before rescanning

Looking for an option to import 10+ private keys using importprivkey without having to rescan on each address import

dooglas previous info

I edited src/rpcdump.cpp, commented out "pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);" and "pwalletMain->ReacceptWalletTransactions();"
but would be better with an option

QFileDialog does not show hidden files

it's a relatively easy fix, will put in next release

coloring for QTreeView is wrong(appears all white)

coloring for QTreeView is wrong

Unable to send to multiple recipients using 'Add recipients'

Sending to one address works as expected.

I am able to add recipients as expected but when clicking send, I see the 'SEND' button being pushed when I click but nothing happens. No error messages.

Windows Server 2008
Wallet v1.4.2.1-355-gf36c215

CWallet::ClearOrphans() blows up tx timestamps

It seems to set all tx timestamps to the current time in the coin view, although they sort properly? I'm not sure what's going on.