I've installed v1.4.17 for Linux and am running the console via ./clam-qt
I am only getting 2 peers. I'm wondering if there are nodes I can add to my clam.conf? I've looked around and the info seems to be pretty old and ineffective.
I've also added bootstrap.dat files in my ./clam folder posted by dooglus elsewhere here but that doesn't really address the lack of peers or will it when I catch up?
Thanks in advance.
Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 128. (Read 1151252 times)
May 08, 2017, 01:31:27 PM
May 08, 2017, 06:28:03 AM
Here's a more extreme example:
2017-05-08 10:53:48 SetBestChain: new best=3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52 height=1488925 trust=467199909733765990559 blocktrust=408204117585960 date=04/29/17 11:44:32
2017-05-08 10:54:04 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:54:09 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:54:11 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:55:31 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:55:58 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:02:13 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:02:23 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:10:39 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:14:29 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
The block was received and determined to be valid (it was appended to the local copy of the blockchain), yet the same block was still received from peers a further 9 times over the next 21 minutes.
2017-05-08 10:53:48 SetBestChain: new best=3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52 height=1488925 trust=467199909733765990559 blocktrust=408204117585960 date=04/29/17 11:44:32
2017-05-08 10:54:04 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:54:09 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:54:11 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:55:31 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 10:55:58 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:02:13 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:02:23 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:10:39 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
2017-05-08 11:14:29 ERROR: ProcessBlock() : already have block 1488925 3839a28441d4f9c06791f9d57e54180dc65c17b15759229d03d24cd97ed8be52
The block was received and determined to be valid (it was appended to the local copy of the blockchain), yet the same block was still received from peers a further 9 times over the next 21 minutes.
May 08, 2017, 05:31:42 AM
Maybe I don't understand something so you guys could explain it to me. Why should this coin rise? As far as I know it has no development work at the moment and it just seems dead.
because polo margin trading
May 08, 2017, 05:25:07 AM
I left CLAM alone for about 80 days, then restarted it a few days ago - and it's still trying to sync...
The debug log is full of "already have block" and "ORPHAN BLOCK 751" entries.
2017-05-08 10:22:14 SetBestChain: new best=e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a height=1486871 trust=466372186589834826465 blocktrust=338273748876064 date=04/28/17 01:14:40
2017-05-08 10:22:26 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
2017-05-08 10:22:26 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
2017-05-08 10:22:30 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
Here's a random but typical example. The same block was received four times over a period of 16 seconds.
Why are peers sending blocks multiple times, and seemingly (due to all the orphan blocks) out of order?
It's taken 3 or 4 days just to advance the blockchain by a couple of months. Any further work on fixing this?
The debug log is full of "already have block" and "ORPHAN BLOCK 751" entries.
2017-05-08 10:22:14 SetBestChain: new best=e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a height=1486871 trust=466372186589834826465 blocktrust=338273748876064 date=04/28/17 01:14:40
2017-05-08 10:22:26 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
2017-05-08 10:22:26 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
2017-05-08 10:22:30 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
Here's a random but typical example. The same block was received four times over a period of 16 seconds.
Why are peers sending blocks multiple times, and seemingly (due to all the orphan blocks) out of order?
It's taken 3 or 4 days just to advance the blockchain by a couple of months. Any further work on fixing this?
May 07, 2017, 12:21:37 PM
Maybe I don't understand something so you guys could explain it to me. Why should this coin rise? As far as I know it has no development work at the moment and it just seems dead.
Better yet, why should this coin even exist?
May 07, 2017, 07:05:29 AM
Maybe I don't understand something so you guys could explain it to me. Why should this coin rise? As far as I know it has no development work at the moment and it just seems dead.
May 07, 2017, 05:28:49 AM
Is there a recent dig chart?
That is a good question I wonder if another Clamwhale will come out of the shadows although the recent rally is affecting pretty much all altcoins it was quite the nice rally today and yesterday.
May 07, 2017, 01:20:02 AM
Is there a recent dig chart?
May 06, 2017, 08:36:20 PM
Hey guys, glad to see CLAM s doing well. Anything new and interesting causing this price pump?
CLAM segwit?
lol 
May 06, 2017, 03:37:53 AM
Hey guys, glad to see CLAM s doing well. Anything new and interesting causing this price pump?
May 06, 2017, 12:49:06 AM
Hmm, still having problems with importing a raw key into the wallet, via WIF.
One thing I've noticed is that CLAM (and probably most coins that share its codebase) doesn't seem to complain if the key you import doesn't have the correct prefix. Slightly convoluted example:
1. Export bitcoin private key to raw format:
> bitcoin-cli getnewaddress
1DNMvoz7q3QMEnUWwctqXNSWBcnf7JJC1J
> bitcoin-cli dumpprivkey 1DNMvoz7q3QMEnUWwctqXNSWBcnf7JJC1J
KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin
> ku KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin
hex : 2eb01b9cdbc459b141d9a31e618cab20f938d95be3544bf038eeb3e50083acf9 <- private key in hex
2. Convert raw format to WIF and import:
> ku -n CLAM 2eb01b9cdbc459b141d9a31e618cab20f938d95be3544bf038eeb3e50083acf9
wif : Lhgcr241kxrdS9Zedp6tLSJJqPZGSJ4UWXCY687DuxTH7DZj8Rf7
> clamd -importprivkey Lhgcr241kxrdS9Zedp6tLSJJqPZGSJ4UWXCY687DuxTH7DZj8Rf7 "" false <- this is the key in CLAM WIF format
> ku -n BTC 2eb01b9cdbc459b141d9a31e618cab20f938d95be3544bf038eeb3e50083acf9
wif : KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin
> clamd -importprivkey KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin "" false <- this is the same key in BTC WIF format - no error reported!
I already have the keys in raw hex format (I'm extracting them from files/raw disks by looking for appropriate header bytes) so what I want to do is part 2, but for some reason CLAM doesn't seem to be picking up the keys/addresses on a rescan.
One thing I've noticed is that CLAM (and probably most coins that share its codebase) doesn't seem to complain if the key you import doesn't have the correct prefix. Slightly convoluted example:
1. Export bitcoin private key to raw format:
> bitcoin-cli getnewaddress
1DNMvoz7q3QMEnUWwctqXNSWBcnf7JJC1J
> bitcoin-cli dumpprivkey 1DNMvoz7q3QMEnUWwctqXNSWBcnf7JJC1J
KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin
> ku KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin
hex : 2eb01b9cdbc459b141d9a31e618cab20f938d95be3544bf038eeb3e50083acf9 <- private key in hex
2. Convert raw format to WIF and import:
> ku -n CLAM 2eb01b9cdbc459b141d9a31e618cab20f938d95be3544bf038eeb3e50083acf9
wif : Lhgcr241kxrdS9Zedp6tLSJJqPZGSJ4UWXCY687DuxTH7DZj8Rf7
> clamd -importprivkey Lhgcr241kxrdS9Zedp6tLSJJqPZGSJ4UWXCY687DuxTH7DZj8Rf7 "" false <- this is the key in CLAM WIF format
> ku -n BTC 2eb01b9cdbc459b141d9a31e618cab20f938d95be3544bf038eeb3e50083acf9
wif : KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin
> clamd -importprivkey KxnTzDFWtCGwZZVosS8RMZpsbDZ1GChqhK5tHrNkTZgihZXYymin "" false <- this is the same key in BTC WIF format - no error reported!
I already have the keys in raw hex format (I'm extracting them from files/raw disks by looking for appropriate header bytes) so what I want to do is part 2, but for some reason CLAM doesn't seem to be picking up the keys/addresses on a rescan.
May 05, 2017, 06:49:03 PM
WIF prefix is 133 instead of Bitcoin's 128. I have this change for pycoin:
Thanks. I have added another coin to pycoin before, but in this instance I was scratching my head trying to figure out the BTC/LTC/DOGE defines in the CLAM source. Much appreciated!
May 05, 2017, 06:35:13 PM
What Wallet Import Format (WIF) does CLAM use? I'm trying to import private keys generated by pycoin - in Bitcoin WIF format - but they don't seem to be recognised.
A rescan finds keys that were imported via importwallet (entire wallet), but ignores keys imported via importprivkey (single key, Bitcoin WIF, no error reported.)
A rescan finds keys that were imported via importwallet (entire wallet), but ignores keys imported via importprivkey (single key, Bitcoin WIF, no error reported.)
WIF prefix is 133 instead of Bitcoin's 128. I have this change for pycoin:
Code:
diff --git a/pycoin/networks/legacy_networks.py b/pycoin/networks/legacy_networks.py
index 98132a9..1770689 100644
--- a/pycoin/networks/legacy_networks.py
+++ b/pycoin/networks/legacy_networks.py
@@ -81,5 +81,7 @@ NETWORKS = (
# DCR Decred testnet : tprv/tpub
NetworkValues("Decred", "testnet", "DCRT", b'\x23\x0E', b'\x0F\x21', b'\x0E\x6C', h2b('04358397'), h2b('043587D1')),
+
+ NetworkValues("Clams", "mainnet", "CLAM", b'\x85', b'\x89', b'\x0d', h2b("0488ADE4"), h2b("0488B21E")),
)
Then do
Code:
$ ku--override-network CLAM
May 05, 2017, 03:08:10 PM
Joined the CLAM train today through BTCPop... I look forward to working with the community a little more 
May 05, 2017, 03:05:46 PM
What Wallet Import Format (WIF) does CLAM use? I'm trying to import private keys generated by pycoin - in Bitcoin WIF format - but they don't seem to be recognised.
A rescan finds keys that were imported via importwallet (entire wallet), but ignores keys imported via importprivkey (single key, Bitcoin WIF, no error reported.)
A rescan finds keys that were imported via importwallet (entire wallet), but ignores keys imported via importprivkey (single key, Bitcoin WIF, no error reported.)
May 05, 2017, 10:37:44 AM
What do you mean by that? 1000 CLAMs per address? Wouldn't people just split their coins into multiple addresses? I don't see how you are going to be able to limit the amount of CLAMs any person can stake when you have no way of knowing which addresses are owned by which people.
One node only must choose one biggest address for staking.I don't see how your scheme is either workable or desirable.
While it is 'possible' to blacklist specific nodes, this type of 'solution' is not only fragile, but violates a core principle of the project.
May 05, 2017, 08:40:58 AM
What do you mean by that? 1000 CLAMs per address? Wouldn't people just split their coins into multiple addresses? I don't see how you are going to be able to limit the amount of CLAMs any person can stake when you have no way of knowing which addresses are owned by which people.
One node only must choose one biggest address for staking.
If you limit staking to one address per node and 10k CLAMs per address then large holders would simply set up multiple nodes.
I don't see how your scheme is either workable or desirable.
That is better for the network. The more nodes there are, the more secure the network is.
A possible solution to limiting the amount of nodes one person can run is to blacklist or ban nodes with digitalocean and amazon aws IPs. These two services are among the cheapest VPN providers and the chances are that people will use them for setting up extra nodes. Or you can lift the CLAM price and that will make running a node unaffordable for many clamers.
May 05, 2017, 07:49:12 AM
What do you mean by that? 1000 CLAMs per address? Wouldn't people just split their coins into multiple addresses? I don't see how you are going to be able to limit the amount of CLAMs any person can stake when you have no way of knowing which addresses are owned by which people.
One node only must choose one biggest address for staking.
May 04, 2017, 08:51:15 PM
What do you mean by that? 1000 CLAMs per address? Wouldn't people just split their coins into multiple addresses? I don't see how you are going to be able to limit the amount of CLAMs any person can stake when you have no way of knowing which addresses are owned by which people.
One node only must choose one biggest address for staking.
If you limit staking to one address per node and 10k CLAMs per address then large holders would simply set up multiple nodes.
I don't see how your scheme is either workable or desirable.
That is better for the network. The more nodes there are, the more secure the network is.
May 04, 2017, 08:28:53 PM
What do you mean by that? 1000 CLAMs per address? Wouldn't people just split their coins into multiple addresses? I don't see how you are going to be able to limit the amount of CLAMs any person can stake when you have no way of knowing which addresses are owned by which people.
One node only must choose one biggest address for staking.
If you limit staking to one address per node and 10k CLAMs per address then large holders would simply set up multiple nodes.
I don't see how your scheme is either workable or desirable.
Jump to: