nochowderforyou / clams Goto Github PK
View Code? Open in Web Editor NEWThis project forked from blacknet-ninja/blackcoin-old
Clam Project
License: MIT License
This project forked from blacknet-ninja/blackcoin-old
Clam Project
License: MIT License
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. :)
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.
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.
Sometimes when a wallet.dat is imported a rescan does not occur.
It should.
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.
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.
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.
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
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.
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.
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.
coloring for QTreeView is wrong
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
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:
make the split and merge happen based on output size and current difficulty, rather than the random luck of a particular output
expose the thresholds for split and merge (however the end up after 1) above) in the GUI and RPC interface
set reasonable defaults - probably with 'merge' disabled by default
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
(16 * 4) % 60 = 4
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.
getstakinginfo is returning wrong weight.
Needs to be divided by COIN to get correct weight
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.
See http://i.imgur.com/TwDbPzJ.png
The tooltip is kind of black on dark grey.
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.
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.
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.
Staking labels in the UI are inaccurate across the board.
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.
The versions report different in getinfo and the qt client, and both are wrong.
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).
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?
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
There appears to be some issues related to coin-control column sorting not functioning in the new UI.
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.
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.
it's a relatively easy fix, will put in next release
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.
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:
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
Rows in the transaction tab of the new UI have extremely poor contrast and it can be difficult to discern details.
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;
Ick.
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).
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.
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:
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.
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.
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.