Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 438. (Read 1151252 times)
November 01, 2014, 08:33:09 PM
I completely forgot about this one. I might have a BTC wallet that works with this. What are the average amount coins sent to each wallet? 23?
November 01, 2014, 07:32:14 PM
do i need to delete peers.dat?
Feel free to swing into freenode irc #clams, we will try and get you straightened out
November 01, 2014, 07:21:51 PM
do i need to delete peers.dat?
November 01, 2014, 07:15:56 PM
Have you tried the methods above? You can also try creating a clams.conf file in your clams data directory and use the addnode lines I specified. Been working for me no problem.
https://bitcointalksearch.org/topic/m.9369794
https://bitcointalksearch.org/topic/m.9369794
i tried the addnotes you listed in i add listen=0
is noy working for me
November 01, 2014, 07:11:25 PM
Have you tried the methods above? You can also try creating a clams.conf file in your clams data directory and use the addnode lines I specified. Been working for me no problem.
https://bitcointalksearch.org/topic/m.9369794
not yet i will try it now tnx.. https://bitcointalksearch.org/topic/m.9369794
November 01, 2014, 06:30:49 PM
Have you tried the methods above? You can also try creating a clams.conf file in your clams data directory and use the addnode lines I specified. Been working for me no problem.
https://bitcointalksearch.org/topic/m.9369794
https://bitcointalksearch.org/topic/m.9369794
November 01, 2014, 03:57:18 PM
my wallet wont sync stuck at 9565 block remaining help?
im using the new update
help?im using the new update
November 01, 2014, 01:48:46 PM
sorry to bother you guys again, I have another small question (problem)
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
Quote
getblocks 170613 to 00000000000000000000 limit 500
getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this my client requesting blocks or other node requesting blocks from me?getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
Yes, it doesn't matter if you are listening on a port or not, you're still essentially a "server" to the people you connect *to* even if you connected to them.
November 01, 2014, 12:41:22 AM
Indeed, we are aware of the issue.
In the last couple days, we have merged well over 100 upstream commits.
The intention is to release a new feature designed to make us more resilient to censorship, a fix to tame misbehaving forked clients, and a ton of house-cleaning.
Thanks for being patient
In the last couple days, we have merged well over 100 upstream commits.
The intention is to release a new feature designed to make us more resilient to censorship, a fix to tame misbehaving forked clients, and a ton of house-cleaning.
Thanks for being patient
October 31, 2014, 11:57:52 PM
listen=0
connect=109.195.211.62
connect=184.6.148.172
connect=203.20.114.252
connect=85.191.52.188
connect=72.10.216.54
This disables inbound connections, and forces a connect to the configured peers. I can't remember if it will also still try to connect to other peers it becomes aware of (which will defeat the purpose of this workaround)
If you specify any connect= at all, the addresses you list will be the only addresses you connect to. You don't need to specify listen=0 as well.
clamd --help tells us:
Quote
-connect= Connect only to the specified node(s)
-listen Accept connections from outside (default: 1 if no -proxy or -connect)
-listen Accept connections from outside (default: 1 if no -proxy or -connect)
October 31, 2014, 11:24:28 PM
sorry to bother you guys again, I have another small question (problem)
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
Quote
getblocks 170613 to 00000000000000000000 limit 500
getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this my client requesting blocks or other node requesting blocks from me?getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
This is most likely the same problem I mentioned. Clients on the wrong fork are going crazy trying to resolve your view of the world versus theirs.
It's a peer to peer network that needs to share data, so even if you block incoming connections, any peer you are connected to (eg via outbound connect) will still request blocks.
One possible temporary workaround (not tested) is to force a connect to only nodes you know are on the correct chain. In your clam.conf you'd have something like this:
listen=0
connect=109.195.211.62
connect=184.6.148.172
connect=203.20.114.252
connect=85.191.52.188
connect=72.10.216.54
This disables inbound connections, and forces a connect to the configured peers. I can't remember if it will also still try to connect to other peers it becomes aware of (which will defeat the purpose of this workaround)
Note that if this does work it would only be a temporary workaround, as it ties you to these specific nodes, which are just 5 random IPs I've happened to note are on the right chain.
October 31, 2014, 11:19:05 PM
sorry to bother you guys again, I have another small question (problem)
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
Try to add "listen=0" in config, it means "do not accept incoming connections".I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
Quote
getblocks 170613 to 00000000000000000000 limit 500
getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this my client requesting blocks or other node requesting blocks from me?getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
I do not think it will work but worth to give it a try.
Problem is that "outgoing connections only" still alows uploading.
When you upload a lot it means the swarm likes you and have many clients updating using your connection.
Once swarn has updated most clients and are in sync it should normalise.
October 31, 2014, 05:55:43 PM
sorry to bother you guys again, I have another small question (problem)
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,
Quote
getblocks 170613 to 00000000000000000000 limit 500
getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this my client requesting blocks or other node requesting blocks from me?getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
getblocks stopping at limit 169612 09777d16b5cf14ad79ee
is this the same problem as almightyruler said couple days ago?
if it is how could it be, coz my firewall blocks incoming requests
October 31, 2014, 12:29:12 PM
hey guys i know i posted alot on here earlier, i talked to creative in the IRC..all is going well over here and CLAMS seems to be doing great. EVEN WITHOUT THE LOTTERY! i dont own a ton of clams but i still have a decent pile to start, good work DEV's you guys are doing great i cant wait to hear the new news
October 31, 2014, 02:25:26 AM
So far my biggest stake block is Credit: 0.6888463 CLAM
Please check immediately that you are the correct chain.
There was a recent mandatory update.
See:
https://bitcointalksearch.org/topic/m.9314100
All block rewards are 1 CLAM each now.
Good catch. I assumed he wasn't staking very often, and that his last stake was before the upgrade.
October 31, 2014, 02:18:58 AM
So far my biggest stake block is Credit: 0.6888463 CLAM
Please check immediately that you are on the correct chain.
There was a recent mandatory update.
See:
https://bitcointalksearch.org/topic/m.9314100
All block rewards are 1 CLAM each now.
October 31, 2014, 12:12:42 AM
So far my biggest stake block is Credit: 0.6888463 CLAM
October 30, 2014, 11:34:08 PM
"How often do I get 1 CLAM?"
"How much interest do I get on CLAMS?"
"I want numbers!"
Some users have reported their current percentage return as very similar to HYP.
Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"
"How much interest do I get on CLAMS?"
"I want numbers!"
Some users have reported their current percentage return as very similar to HYP.
Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"
to provide sample data, can be very different to others depending on how many clams you have and how many clams per pile you set them up
i have a sample 18.3 clams divided into 3 piles of about ~6 clams per pile
they have staked 5 times in the month of october to generate 5 clams
5 / 18.3 = 27.32% interest for a month
or
27.32% * 12 = 327.84 interest a year (not compounded)
* ok ok, i cheated a bit, 4 other stakes where during lotto so really .1 stake but i just imagined they were already after the fork and giving out 1 clam just for sampling
Staking is random. Every second you have a small chance of being able to stake, which is proportional to the size of your output and its age, and inversely proportional to the current network difficulty.
Here's an example:
http://khashier.com:2750/address/xSeRBfdnw1vVtabmpZugCXKS8jGujKYXr5
That address started staking with 4.6 CLAMS in August, and now, almost 3 months later it has 8.8 CLAMS. So it hasn't quite doubled in 3 months.
October 30, 2014, 11:08:36 PM
"How often do I get 1 CLAM?"
"How much interest do I get on CLAMS?"
"I want numbers!"
Some users have reported their current percentage return as very similar to HYP.
Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"
"How much interest do I get on CLAMS?"
"I want numbers!"
Some users have reported their current percentage return as very similar to HYP.
Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"
to provide sample data, can be very different to others depending on how many clams you have and how many clams per pile you set them up
i have a sample 18.3 clams divided into 3 piles of about ~6 clams per pile
they have staked 5 times in the month of october to generate 5 clams
5 / 18.3 = 27.32% interest for a month
or
27.32% * 12 = 327.84 interest a year (not compounded)
* ok ok, i cheated a bit, 4 other stakes where during lotto so really .1 stake but i just imagined they were already after the fork and giving out 1 clam just for sampling
October 30, 2014, 04:39:44 PM
thanks all for all the help... I finally back on the main chain. However I think I kinda cheated to get it to work 
instead of using bootstrap.dat from dooglus, I use my own... but without actually making bootstrap like dooglus said
I was just experimenting, so don't blame me if this doesn't work for you:
I simply just deleted database & txleveldb directories, renamed blk0001.dat to bootstrap.dat
I thought at first this won't work because the blk0001.dat might be in different format than a bootstrap.dat should have
I ran it with "clam-qt.exe -listen=0" and it worked fine just took quite long time (maybe because my slow laptop)
then the next step is not recommended, but I dont know what to do to make it stop at certain block height
so I do some calculations and guess the size of the blockchain should be around 189,xxx,xxx bytes to be near block 170000
when I see blk0001.dat around that size... I forcefully kill the clam-qt process
instead of using bootstrap.dat from dooglus, I use my own... but without actually making bootstrap like dooglus said
I was just experimenting, so don't blame me if this doesn't work for you:
I simply just deleted database & txleveldb directories, renamed blk0001.dat to bootstrap.dat
I thought at first this won't work because the blk0001.dat might be in different format than a bootstrap.dat should have
I ran it with "clam-qt.exe -listen=0" and it worked fine just took quite long time (maybe because my slow laptop)
then the next step is not recommended, but I dont know what to do to make it stop at certain block height
so I do some calculations and guess the size of the blockchain should be around 189,xxx,xxx bytes to be near block 170000
when I see blk0001.dat around that size... I forcefully kill the clam-qt process
That sounds like a reasonable method. I guess the blk* file is the same format as bootstrap.dat. It probably imported all the blocks up to 170000 and then was trying to import the later ones but was finding none of them were acceptable (since they were all on the wrong fork). It would have finished on its own in the end, and when it finishes it renames bootstrap.dat to something similar but different, so it doesn't see it again next time you run the client.
That would have been safer than forcibly killing it. Just wait for it to finish the import.
Jump to: