Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 388. (Read 1151252 times)
February 03, 2015, 04:41:07 AM
just downloaded 1.4.5 and it works fine. soon it will be filled with 5k clam
February 02, 2015, 03:17:43 PM
Clams has been added to Comkort exchange!
Three markets are live CLAM <-> BTC, LTC, DOGE.
Best buy prices:
0.00838987 BTC per 1 CLAM - BTC market
Happy & Profitable Trading!
Three markets are live CLAM <-> BTC, LTC, DOGE.
Best buy prices:
0.00838987 BTC per 1 CLAM - BTC market
Happy & Profitable Trading!
Welcome to the CLAM family
Adding to the OP post now.
February 02, 2015, 03:02:45 PM
I updated the bootstrap.dat file again. It goes to block 323111 now. If you're having trouble getting your CLAM client to sync over the p2p network, this should help.
February 02, 2015, 07:11:20 AM
ok
thanks for the explanation dooglus
thanks for the explanation dooglus
February 02, 2015, 07:09:17 AM
Clams has been added to Comkort exchange!
Three markets are live CLAM <-> BTC, LTC, DOGE.
Best buy prices:
0.00838987 BTC per 1 CLAM - BTC market
Happy & Profitable Trading!
Three markets are live CLAM <-> BTC, LTC, DOGE.
Best buy prices:
0.00838987 BTC per 1 CLAM - BTC market
Happy & Profitable Trading!
February 02, 2015, 04:59:30 AM
Hi SuperClam
I've downloaded and installed Windows 64bit
All synced up seems to work quite nicely thank you
Jon
Great to hear!
Please keep an eye on it, and let us of know of any abnormalities or problems!
February 02, 2015, 04:42:06 AM
Hi SuperClam
I've downloaded and installed Windows 64bit
All synced up seems to work quite nicely thank you
Jon
February 01, 2015, 11:24:05 PM
February 01, 2015, 11:15:30 PM
hi i have 1 adress on blockchaininfo wallet
with transaction before may 2014
but justdice say me BTC address [1BV2Eupx] was not funded on 12th May 2014;
however i can see transaction before may
https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked
if someone had an idea it would be nice
with transaction before may 2014
but justdice say me BTC address [1BV2Eupx] was not funded on 12th May 2014;
however i can see transaction before may
https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked
if someone had an idea it would be nice
You can get a list of the balances at various dates here:
https://blockchain.info/charts/balance?showDataPoints=true×pan=&show_header=true&daysAverageString=1&scale=0&format=csv&address=1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
Specifically it was 0.00000543 BTC on 30/04/2014 and stayed at that until 18/06/2014. So on 12th May the balance was pretty much zero. It needed to be over 0.0001 BTC to be funded with CLAM I think.
February 01, 2015, 10:57:43 PM
hi i have 1 adress on blockchaininfo wallet
with transaction before may 2014
but justdice say me BTC address [1BV2Eupx] was not funded on 12th May 2014;
however i can see transaction before may
https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked
if someone had an idea it would be nice
with transaction before may 2014
but justdice say me BTC address [1BV2Eupx] was not funded on 12th May 2014;
however i can see transaction before may
https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked
if someone had an idea it would be nice
your balance during the distribution was 0.00000543
http://bitref.com/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
clams were distributed to btc with balances > 0.0001
February 01, 2015, 05:41:33 AM
hi i have 1 adress on blockchaininfo wallet
with transaction before may 2014
but justdice say me BTC address [1BV2Eupx] was not funded on 12th May 2014;
however i can see transaction before may
https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked
if someone had an idea it would be nice
with transaction before may 2014
but justdice say me BTC address [1BV2Eupx] was not funded on 12th May 2014;
however i can see transaction before may
https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE
I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked
if someone had an idea it would be nice
January 29, 2015, 07:26:41 PM
To my knowledge, there has never been any issue of forking or core service separation on the chain.
Rest assured it is being looked at - as always, anyone with expertise is invited to take part at the project repository.
This is, after all, an open source volunteer project.
We rise or fall together
Rest assured it is being looked at - as always, anyone with expertise is invited to take part at the project repository.
This is, after all, an open source volunteer project.
We rise or fall together
I made an issue in the github repository so we can have all the discussion in one place:
https://github.com/nochowderforyou/clams/issues/133
With allejuppa's help I seem to have discovered the cause of the problem. It's in the handling (or lack of handling) of orphan blocks in v1.4.4.
This does look like a pretty serious problem with v1.4.4. It would be easy for a service to get stuck on the wrong side of a fork. The bug appears to make it relatively simple to hobble peers running v1.4.4. Until it is fixed it's not a good idea to run v1.4.4.
Are there any issues with downgrading to the previous release?
Edit: this seems to fix the problem
January 29, 2015, 04:55:10 PM
SuperClam any response or progress on this ? This seems rather problematic
Indeed.
This is an ongoing issue that has, up until recently, been difficult to reliably reproduce and most often solved by a simple restart of the client.
A recent update seems to have possibly aggravated the issue.
Not a horrible situation, as aggravation often breeds incentive and motivation.
I am by no means the most technically savvy of those involved in the project; so I will defer to xploited, dooglus, allejuppa, and others concerning the technical details.
To my knowledge, there has never been any issue of forking or core service separation on the chain.
Rest assured it is being looked at - as always, anyone with expertise is invited to take part at the project repository.
This is, after all, an open source volunteer project.
We rise or fall together
January 29, 2015, 12:47:01 PM
Dooglus:
Look at my comment on
https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112
Look at my comment on
https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112
I'm not familiar enough with this part of the client to know whether you're right about that commit causing the problem.
Can you explain what that commit does, and why it's a problem?
I see the code that rejects duplicate proofs of stake existed before that chance. What was the mechanism for recovering from the network building on top of a rejected block before this commit? Does this commit break that mechanism?
January 29, 2015, 11:30:28 AM
Dooglus:
Look at my comment on
https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112
Look at my comment on
https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112
January 29, 2015, 09:31:22 AM
SuperClam any response or progress on this ? This seems rather problematic
January 29, 2015, 01:57:55 AM
I received an email to the Just-Dice support address saying the following:
I figure it's not a Just-Dice issue, so have reposted it here.
My guess is that he was on a fork, possibly caused by the de-syncing that lots of people have been reporting recently, and that the wallet only realised it was on a losing fork when he resynced it.
Is anyone looking into the issue of the client losing sync? It seems to be a pretty common problem. I wonder if it is being triggered on purpose by somebody looking to disrupt the network.
The crux of the issue appears to be the following code in main.cpp:
which discards blocks if two or more stake the same output at the same time. It seems to be easy enough to publish multiple different blocks whenever you get a chance to stake. If peers disagree on which one was seen first, this could cause some of them to desync.
Quote
date: 2015-01-28 6:36pm
subject: Missing Clam
I have around 1480 Clam in my wallet, the other day it staked 10 times for 1x clam each time.
I had staked 12 but 2 wound up being an Orphan.
Most of the clams staked had 60 + confirmations before I closed my wallet.
Loaded it the next day, it wouldn't leave 12 hours behind. So I rebuilt my wallet and everything loaded fine, my deposit from poloniex finally came in.
What was odd though, is that now all 12 clam I had staked are no orphans, losing me all 12 staked.
Why is the reason for this?
I could understand one or two, but all 12 even when many had over 50 confirmations when I closed my wallet.
subject: Missing Clam
I have around 1480 Clam in my wallet, the other day it staked 10 times for 1x clam each time.
I had staked 12 but 2 wound up being an Orphan.
Most of the clams staked had 60 + confirmations before I closed my wallet.
Loaded it the next day, it wouldn't leave 12 hours behind. So I rebuilt my wallet and everything loaded fine, my deposit from poloniex finally came in.
What was odd though, is that now all 12 clam I had staked are no orphans, losing me all 12 staked.
Why is the reason for this?
I could understand one or two, but all 12 even when many had over 50 confirmations when I closed my wallet.
I figure it's not a Just-Dice issue, so have reposted it here.
My guess is that he was on a fork, possibly caused by the de-syncing that lots of people have been reporting recently, and that the wallet only realised it was on a losing fork when he resynced it.
Is anyone looking into the issue of the client losing sync? It seems to be a pretty common problem. I wonder if it is being triggered on purpose by somebody looking to disrupt the network.
The crux of the issue appears to be the following code in main.cpp:
Code:
// ppcoin: check proof-of-stake
// Limited duplicity on stake: prevents block flood attack
// Duplicate stake allowed only when there is orphan child block
if (pblock->IsProofOfStake() && setStakeSeen.count(pblock->GetProofOfStake()) && !mapOrphanBlocksByPrev.count(hash) && !Checkpoints::WantedByPendingSyncCheckpoint(hash))
return error("ProcessBlock() : duplicate proof-of-stake (%s, %d) for block %s", pblock->GetProofOfStake().first.ToString(), pblock->GetProofOfStake().second, hash.ToString());
which discards blocks if two or more stake the same output at the same time. It seems to be easy enough to publish multiple different blocks whenever you get a chance to stake. If peers disagree on which one was seen first, this could cause some of them to desync.
January 28, 2015, 06:28:55 AM
Good option, maybe add the value in $.
I was looking at Poloniex, trying to figure out how to ask its API for the most recently traded CLAM/BTC price.
It turns out there wasn't a way without either asking for the most recently traded price of all their currency pairs, or getting a list the most recent 200 CLAM trades. But now there is:
Just GET:
https://poloniex.com/public?command=returnTradeHistory¤cyPair=BTC_CLAM&limit=1
It returns:
[{"tradeID":188881,"date":"2015-01-26 21:44:26","type":"buy","rate":"0.00555597","amount":"0.20668765","total":"0.00114835"}]
which is a lot less data than the previous best way of doing it.
Nice way to get the information
Today it returns
[{"tradeID":189520,"date":"2015-01-28 11:18:46","type":"buy","rate":"0.00547257","amount":"2.74642444","total":"0.01502999"}]
January 27, 2015, 03:00:31 PM
I had similar problems with version 1.4.4 on linux (32 bit) over the weekend and posted on this thread.
I just saw your post and remembered that I rebooted my laptop last night and didn't restart my local CLAM client.
I'm running 1.4.4 64 bit locally, on linux.
When I started the CLAM client it quickly caught up most of the way (the network was at block 314498, my local client started at 313818, and it very quickly synced to block 314318, then paused for almost a minute before continuing:
Hard to stake if block explorer always 7 blocks ahead.
Wow sounds like some problems....
January 27, 2015, 02:40:14 PM
I had similar problems with version 1.4.4 on linux (32 bit) over the weekend and posted on this thread.
I just saw your post and remembered that I rebooted my laptop last night and didn't restart my local CLAM client.
I'm running 1.4.4 64 bit locally, on linux.
When I started the CLAM client it quickly caught up most of the way (the network was at block 314498, my local client started at 313818, and it very quickly synced to block 314318, then paused for almost a minute before continuing:
Hard to stake if block explorer always 7 blocks ahead.
Jump to: