[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 335.

tspacepilot

legendary

Activity: 1456

Merit: 1081

I may write code in exchange for bitcoins.

Quote from: chriswen on June 29, 2015, 03:17:30 PM

Quote from: tspacepilot on June 29, 2015, 11:40:40 AM

Quote from: Bitcoiner2015 on June 29, 2015, 10:54:32 AM

I have a few noob questions.
I have my clams in my wallet, they are staking but even though I have quite a few, it is only expected to stake every 49710 days! how can that be?
I moved them to my wallet on Saturday, but the age hasn't increased. They are still staking at 1 per CLAM, does the age only increase when I have the client open? Can they only stake when it is open?

Does it matter that I use 1.4.3.0? The new ones want to re-index, so I am not in a hurry to update!

I'm pretty sure that in all of the POS coins you can only stake when your wallet is open. If you're not connected, you're not in the race. I'm not an expert (and many others in this thread actually are experts) but if I understand correctly, POS is a lot like POW in that you are racing against others to find a hash that fulfills certain criteria.

Actually most POS coins have age and you can't rewards based on the age. Clam has a system where there is no age. So only the people that are online more and secure the network get more rewards.

So to reiterate, clams doesn't have age.

Right, this is the "proof of working stake" thing. I had forgotten bout this when trying to answer bitcoiner2015's question. Clam is not really POS or POW but a hybrid.

chriswen

hero member

Activity: 756

Merit: 500

Quote from: tspacepilot on June 29, 2015, 11:40:40 AM

Quote from: Bitcoiner2015 on June 29, 2015, 10:54:32 AM

I have a few noob questions.
I have my clams in my wallet, they are staking but even though I have quite a few, it is only expected to stake every 49710 days! how can that be?
I moved them to my wallet on Saturday, but the age hasn't increased. They are still staking at 1 per CLAM, does the age only increase when I have the client open? Can they only stake when it is open?

Does it matter that I use 1.4.3.0? The new ones want to re-index, so I am not in a hurry to update!

I'm pretty sure that in all of the POS coins you can only stake when your wallet is open. If you're not connected, you're not in the race. I'm not an expert (and many others in this thread actually are experts) but if I understand correctly, POS is a lot like POW in that you are racing against others to find a hash that fulfills certain criteria.

Actually most POS coins have age and you can't rewards based on the age. Clam has a system where there is no age. So only the people that are online more and secure the network get more rewards.

So to reiterate, clams doesn't have age.

chriswen

hero member

Activity: 756

Merit: 500

Quote from: chilly2k on June 26, 2015, 08:03:18 AM

Quote from: almightyruler on June 26, 2015, 01:36:18 AM

Quote from: chilly2k on June 25, 2015, 12:48:30 PM

Along these lines, I seem to be getting a lot of clients connecting to me, that are not up to sync. They end up killing my bandwidth. I have to stop/start the client.
Last time I checked it was 8 out of 40 connections were not even close to the current block height. I'm going to start writing down the connections and initial block height before I recycle, and see if there is a pattern.

Otherwise is there a setting to limit the number of new connections that require syncing?

I'm having problems with large syncs hogging my outbound bandwidth too, and now I see that my IP is now listed as an addnode in the OP of this thread. Wink

It should be possible to add code to drop the connection if the connecting peer reports a height well below yours, but that's a kind of rude thing to do in a peer to peer network. I doubt the official client would ever support anything like this.

Perhaps a reasonable compromise would be an option to send at most X (older only?) blocks to a new peer, or perhaps some sort of outbound bandwidth rate limiting.

I have no problem with the new clients syncing, I'm often on the other side of the equation. It would be nice if the client kept track of nodes that were syncing and only allow X number to be syncing at the same time. Once a client gets up to speed allow another to join. I make this problem even worse because I run a daemon on linux for staking, and the full client on windows to see whats going on. So I can end up with a lot of new connections.

I was testing out maxconnections, and noticed I had 6 connections and 4 of those were still syncing. I think as the price of clams climbs, the number of new clients will grow too. People getting the wallet to see if they have unclaimed clams.

Interesting, sort of like initial seeding for torrents.

presstab

legendary

Activity: 1330

Merit: 1000

Blockchain Developer

Quote from: dooglus on June 29, 2015, 01:21:15 PM

I think I found a bug in presstab's CLAM blockchain explorer.

Compare the balance shown here:
http://www.presstab.pw/phpexplorer/CLAM/address.php?address=xA8UkspL1WwC5KWMzi7jXvo4fXj1pRTk9v
here:
http://www.blocktree.io/address/CLAM/xA8UkspL1WwC5KWMzi7jXvo4fXj1pRTk9v
and here:
http://khashier.com/chain/Clam/q/addressbalance/xA8UkspL1WwC5KWMzi7jXvo4fXj1pRTk9v

presstab.pw shows a balance of 97.149200 CLAM, but I just emptied out the last ~2k CLAM from that address, so I think the true balance is zero, which blocktree and khashier agree with.

Fixed.... these next few days I will be redesigning a few things, including orphan handling, which is what caused this error.

dooglus

legendary

Activity: 2940

Merit: 1333

I think I found a bug in presstab's CLAM blockchain explorer.

Compare the balance shown here:
http://www.presstab.pw/phpexplorer/CLAM/address.php?address=xA8UkspL1WwC5KWMzi7jXvo4fXj1pRTk9v
here:
http://www.blocktree.io/address/CLAM/xA8UkspL1WwC5KWMzi7jXvo4fXj1pRTk9v
and here:
http://khashier.com/chain/Clam/q/addressbalance/xA8UkspL1WwC5KWMzi7jXvo4fXj1pRTk9v

presstab.pw shows a balance of 97.149200 CLAM, but I just emptied out the last ~2k CLAM from that address, so I think the true balance is zero, which blocktree and khashier agree with.

tspacepilot

legendary

Activity: 1456

Merit: 1081

I may write code in exchange for bitcoins.

Quote from: Bitcoiner2015 on June 29, 2015, 10:54:32 AM

I have a few noob questions.
I have my clams in my wallet, they are staking but even though I have quite a few, it is only expected to stake every 49710 days! how can that be?
I moved them to my wallet on Saturday, but the age hasn't increased. They are still staking at 1 per CLAM, does the age only increase when I have the client open? Can they only stake when it is open?

Does it matter that I use 1.4.3.0? The new ones want to re-index, so I am not in a hurry to update!

I'm pretty sure that in all of the POS coins you can only stake when your wallet is open. If you're not connected, you're not in the race. I'm not an expert (and many others in this thread actually are experts) but if I understand correctly, POS is a lot like POW in that you are racing against others to find a hash that fulfills certain criteria.

Bitcoiner2015

full member

Activity: 120

Merit: 100

I have a few noob questions.
I have my clams in my wallet, they are staking but even though I have quite a few, it is only expected to stake every 49710 days! how can that be?
I moved them to my wallet on Saturday, but the age hasn't increased. They are still staking at 1 per CLAM, does the age only increase when I have the client open? Can they only stake when it is open?

Does it matter that I use 1.4.3.0? The new ones want to re-index, so I am not in a hurry to update!

Trent Russell

full member

Activity: 132

Merit: 100

willmathforcrypto.com

I wrote a short paper on an idea about how multisig can be used to trade risk. I used clams (in particular, clamSpeech was important) to do the examples.

Here's the pdf:

http://willmathforcrypto.com/multisigderivs.pdf

Here's a post about it:

https://bitcointalksearch.org/topic/multisig-derivatives-1102062

As a side note, the first example was boring because the price early last week was too stable. Later it got more fun. I think Alice really regrets shorting clams on Wednesday. (That's only a joke about the price spike. I was both Alice and Bob in the examples, so there were no real losses.)

SuperClam

hero member

Activity: 784

Merit: 1002

CLAM Developer

Quote from: dooglus on June 26, 2015, 12:17:21 PM

...
To tell whether we already have a block we find in a bootstrap file, we hash it and see if we have a block with that hash. Before block 203501 blocks were hashed using scrypt, which is designed to be slow. After block 203500 we switched to sha256 which is fast. Notice how blocks 0 and 10000 have hashes that start with a lot of zeroes - that's because they were proof-of-work blocks.
...

Very interesting to see the efficiency gain of switching over to sha256 in practice.

The change made sense on it's face; but seeing it in action adds a certain pleasure to it.

dooglus

legendary

Activity: 2940

Merit: 1333

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: almightyruler on June 26, 2015, 01:43:19 AM

Quote from: dooglus on June 25, 2015, 01:42:40 PM

Quote from: almightyruler on June 25, 2015, 09:19:41 AM

One thing that just popped into my head. Wouldn't a -rescan reject the previous corrupt block? That's the first thing I tried after a couple of restarts.

If the blk0001.dat file was OK, but the txleveldb/ files contained some corruption then -rescan wouldn't see the corruption. As I understand it, -rescan recreates the txleveldb/ files from the blk0001.dat file.

That doesn't make sense. If only txleveldb/* was corrupt, then rebuilding it would fix the corruption (or at least reject the corrupt block), surely? I restarted the client several times, including at least one -rescan and -reindex, and I think I may have also tried -salvagewallet. My command history has been rotated out, so I can't see for sure.

So I think I'm just confused now.

You asked whether -rescan would reject the previous corrupt block.
I said it would fix the corruption if the problem was only in the db and not in the blk file.
You seem to agree, that rebuilding will fix the corruption, but then say that you tried rebuilding it and it didn't?

We're probably just misunderstanding each other, and you don't have the corrupted blockchain any more anyway, so it doesn't really matter...

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: almightyruler on June 26, 2015, 01:43:19 AM

Did you check debug.log to see what happened immediately before the crash?

I didn't, but that's a good idea. I just ran the QT client 3 times, and here's the end of the debug.log after each of the 3 crashes:

Quote

ProcessBlock: ACCEPTED
Added time data, samples 3, offset +1 (+0 minutes)
SetBestChain: new best=00000d363a91ba2ef20a15fb80d0e49bdbb091a0897feed6bb4e4c23cb327052 height=3718 trust=5295569433 blocktrust=1048596 date=05/16/14 04:23:21
ProcessBlock: ACCEPTED
SetBestChain: new best=000001a56178f4f4402475b66974cd5fc8284277944f9719e15cccdab0b0d801 height=3719 trust=5296618010 blocktrust=1048577 date=05/16/14 04:23:27
ProcessBlock: ACCEPTED
receive version message: version 60014, blocks=527206, us=...:..., them=...:31174, peer=...:31174
socket recv error 10054

--

SetBestChain: new best=00000ea6c282e448eda289f52f0d7a2e513300df012ef0cd8b077253309672a5 height=4008 trust=5601150626 blocktrust=1048577 date=05/16/14 06:06:01
ProcessBlock: ACCEPTED
SetBestChain: new best=00000e30f6a0669b74c7dff2a137df42ca5adcab8def589be6d6c4094139067c height=4009 trust=5602205763 blocktrust=1055137 date=05/16/14 06:06:15
ProcessBlock: ACCEPTED
SetBestChain: new best=00000a46eaf6f75c9423f2865837a970f5ca4d9f44cc3183dd10ec648d21e1f2 height=4010 trust=5603254340 blocktrust=1048577 date=05/16/14 06:06:26
ProcessBlock: ACCEPTED

--

SetBestChain: new best=00000ae65f90e6d818c1957e7df489958f482a4b5707dfd3628e0ba58bf0f045 height=4741 trust=6374326490 blocktrust=1048577 date=05/16/14 08:22:23
ProcessBlock: ACCEPTED
SetBestChain: new best=0000080f2216d4c6dc3c7f5fbe89808d1cc108ec0c0d52eb8e4ac76591b49aa1 height=4742 trust=6375375067 blocktrust=1048577 date=05/16/14 08:22:25
ProcessBlock: ACCEPTED
SetBestChain: new best=00000578f2016b4f36486c6b157fc0c9d2849a34739b45bb96f7d31b502fe211 height=4743 trust=6376430204 blocktrust=1055137 date=05/16/14 08:22:39
ProcessBlock: ACCEPTED

presstab

legendary

Activity: 1330

Merit: 1000

Blockchain Developer

Quote from: chilly2k on June 26, 2015, 08:03:18 AM

Quote from: almightyruler on June 26, 2015, 01:36:18 AM

Quote from: chilly2k on June 25, 2015, 12:48:30 PM

Along these lines, I seem to be getting a lot of clients connecting to me, that are not up to sync. They end up killing my bandwidth. I have to stop/start the client.
Last time I checked it was 8 out of 40 connections were not even close to the current block height. I'm going to start writing down the connections and initial block height before I recycle, and see if there is a pattern.

Otherwise is there a setting to limit the number of new connections that require syncing?

I'm having problems with large syncs hogging my outbound bandwidth too, and now I see that my IP is now listed as an addnode in the OP of this thread. Wink

It should be possible to add code to drop the connection if the connecting peer reports a height well below yours, but that's a kind of rude thing to do in a peer to peer network. I doubt the official client would ever support anything like this.

Perhaps a reasonable compromise would be an option to send at most X (older only?) blocks to a new peer, or perhaps some sort of outbound bandwidth rate limiting.

I have no problem with the new clients syncing, I'm often on the other side of the equation. It would be nice if the client kept track of nodes that were syncing and only allow X number to be syncing at the same time. Once a client gets up to speed allow another to join. I make this problem even worse because I run a daemon on linux for staking, and the full client on windows to see whats going on. So I can end up with a lot of new connections.

I was testing out maxconnections, and noticed I had 6 connections and 4 of those were still syncing. I think as the price of clams climbs, the number of new clients will grow too. People getting the wallet to see if they have unclaimed clams.

One option is to startup your windows wallet with 'connect=yourlinuxdaemonipaddress' and that should make it so you are only connected to your daemon. If you don't mind your daemon allowing peers to sync, then this would at least solve part of the problem.

I have added a bit of code to HYP a while back that cutoff nodes requesting the same thing over and over. This was happening due to a fork and those other nodes on the wrong client, but I don't see why the code couldnt be modified to say something like "if this node send get blocks 100 times, ignore it for the next 60 minutes". The danger of something like this is that new nodes have a harder time syncing, that is why it would need to be an obscure rpc command to activate it.

chilly2k

legendary

Activity: 1007

Merit: 1000

Quote from: almightyruler on June 26, 2015, 01:36:18 AM

Quote from: chilly2k on June 25, 2015, 12:48:30 PM

Along these lines, I seem to be getting a lot of clients connecting to me, that are not up to sync. They end up killing my bandwidth. I have to stop/start the client.
Last time I checked it was 8 out of 40 connections were not even close to the current block height. I'm going to start writing down the connections and initial block height before I recycle, and see if there is a pattern.

Otherwise is there a setting to limit the number of new connections that require syncing?

I'm having problems with large syncs hogging my outbound bandwidth too, and now I see that my IP is now listed as an addnode in the OP of this thread. Wink

It should be possible to add code to drop the connection if the connecting peer reports a height well below yours, but that's a kind of rude thing to do in a peer to peer network. I doubt the official client would ever support anything like this.

Perhaps a reasonable compromise would be an option to send at most X (older only?) blocks to a new peer, or perhaps some sort of outbound bandwidth rate limiting.

I have no problem with the new clients syncing, I'm often on the other side of the equation. It would be nice if the client kept track of nodes that were syncing and only allow X number to be syncing at the same time. Once a client gets up to speed allow another to join. I make this problem even worse because I run a daemon on linux for staking, and the full client on windows to see whats going on. So I can end up with a lot of new connections.

I was testing out maxconnections, and noticed I had 6 connections and 4 of those were still syncing. I think as the price of clams climbs, the number of new clients will grow too. People getting the wallet to see if they have unclaimed clams.

almightyruler

legendary

Activity: 2268

Merit: 1092

Quote from: dooglus on June 25, 2015, 01:42:40 PM

Quote from: almightyruler on June 25, 2015, 09:19:41 AM

One thing that just popped into my head. Wouldn't a -rescan reject the previous corrupt block? That's the first thing I tried after a couple of restarts.

If the blk0001.dat file was OK, but the txleveldb/ files contained some corruption then -rescan wouldn't see the corruption. As I understand it, -rescan recreates the txleveldb/ files from the blk0001.dat file.

That doesn't make sense. If only txleveldb/* was corrupt, then rebuilding it would fix the corruption (or at least reject the corrupt block), surely? I restarted the client several times, including at least one -rescan and -reindex, and I think I may have also tried -salvagewallet. My command history has been rotated out, so I can't see for sure.

Quote from: dooglus on June 25, 2015, 01:42:40 PM

I just tried running the Windows binary of v1.4.12 but didn't have much luck. I put the bootstrap.dat file in place and it started syncing, but then this happens after it has loaded a few blocks:

Is that something that happens a lot on Windows still? It's part of why I stopped using Windows in the first place.

Did you check debug.log to see what happened immediately before the crash?

Quote from: dooglus on June 25, 2015, 01:42:40 PM

I'm surprised to see that the processes are CPU bound:

I run several *coin daemons and it's quite normal to see high CPU load when they're syncing a large number of blocks.

almightyruler

legendary

Activity: 2268

Merit: 1092

Quote from: chilly2k on June 25, 2015, 12:48:30 PM

Along these lines, I seem to be getting a lot of clients connecting to me, that are not up to sync. They end up killing my bandwidth. I have to stop/start the client.
Last time I checked it was 8 out of 40 connections were not even close to the current block height. I'm going to start writing down the connections and initial block height before I recycle, and see if there is a pattern.

Otherwise is there a setting to limit the number of new connections that require syncing?

I'm having problems with large syncs hogging my outbound bandwidth too, and now I see that my IP is now listed as an addnode in the OP of this thread. Wink

It should be possible to add code to drop the connection if the connecting peer reports a height well below yours, but that's a kind of rude thing to do in a peer to peer network. I doubt the official client would ever support anything like this.

Perhaps a reasonable compromise would be an option to send at most X (older only?) blocks to a new peer, or perhaps some sort of outbound bandwidth rate limiting.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: dooglus on June 25, 2015, 01:42:40 PM

I'm running 4 clamd processes, all syncing from bootstrap.dat into different datadirs. None of them have "encountered a problem" yet:

Quote

==> /home/clam/.clam.bs3/debug.log <==
SetBestChain: new best=9109e501431fb62e64dfce26112a22703e5feecb56501232bd4a5e8bf09c63a2 height=12200 trust=14866939091 blocktrust=1130602 date=05/28/14 02:23:26
==> /home/clam/.clam.bs1/debug.log <==
SetBestChain: new best=10a98d283d1952cf2ef5cf073faf1b9ec955f785511634fc202b5af0e9ed4bff height=19200 trust=22450387823 blocktrust=1048577 date=06/12/14 02:06:00
==> /home/clam/.clam.bs2/debug.log <==
SetBestChain: new best=2c47724a65e02a69a103f0bbf5f7e15b17e7915b92052e529b554226972edf4f height=14800 trust=17681301681 blocktrust=1157520 date=06/02/14 15:45:53
==> /home/clam/.clam.bs4/debug.log <==
SetBestChain: new best=28c04885cd701375d847853b814decb4bf1ef346f8b996703834f1cd0c6f080d height=10400 trust=12685082747 blocktrust=1231051 date=05/25/14 07:15:07

I'm surprised to see that the processes are CPU bound:

Quote

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16265 clam 20 0 817072 29660 11732 S 95.0 0.4 7:41.56 clamd
16295 clam 20 0 823492 32428 11340 S 93.4 0.4 6:20.31 clamd
16187 clam 20 0 815872 34408 11760 S 88.4 0.4 9:49.87 clamd
16226 clam 20 0 837548 44116 26332 S 80.1 0.5 8:37.20 clamd

I would expect the 4 of them all reading from bootstrap.dat and writing to database files to hit an hdd bottleneck, but no.

11 hours later and they're almost synced:

Quote

==> /home/clam/.clam.bs3/debug.log <==
SetBestChain: new best=4c0d2aba8bee376948a003197aaeeb75f9d0ae2ec9a9470962ab09ffbc0c1ce9 height=518500 trust=46209241304519735506 blocktrust=214081308084412 date=06/19/15 16:16:16
==> /home/clam/.clam.bs4/debug.log <==
SetBestChain: new best=77ea9911d97d948ecb2db594cd4d25057fe1d172da0463f17e2dc6bbed33ba21 height=520900 trust=46720474082846055251 blocktrust=187154986340951 date=06/21/15 08:46:08
==> /home/clam/.clam.bs1/debug.log <==
SetBestChain: new best=0aa6d484cb63573b9201b62cb4a4f1aa1e0c9e51b39951c18a55f958f530caec height=520700 trust=46680370544722329270 blocktrust=191413849329254 date=06/21/15 05:30:08
==> /home/clam/.clam.bs2/debug.log <==
SetBestChain: new best=1a93ba543b1826bbfafb7f38937638ad14d1eb647d87630186e7d0c20f57c76b height=511700 trust=44734730882778317181 blocktrust=206964479678105 date=06/14/15 21:59:44

Quote

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17289 clam 20 0 1201112 255176 17416 S 91.8 3.2 433:21.03 clamd
17266 clam 20 0 1202744 258492 14580 S 85.9 3.2 434:16.70 clamd
17272 clam 20 0 1200672 246056 6472 S 84.5 3.1 434:00.44 clamd
17269 clam 20 0 1197652 252428 16520 S 83.6 3.1 434:49.66 clamd

SuperClam

hero member

Activity: 784

Merit: 1002

CLAM Developer

CLAM v. 1.4.13 Test Build Released!
Release Notes

Linux 32bit
43c0c0e47efb0c459a2b9c8fc28dc621e03be9be7ca0048f409bb1e55aa2fc9a

Linux 64bit
0ff672c900c2e337a24049f625a3ac1c3f8333bf840c05f3b8b1aff856da9731

Windows 32bit
7915eefb92508df6faae9fb257821103ff8df5ed3dc92a524a2ea89800a2f12a

Windows 64bit
55504d541ac6a5d46437810bde189ddfae7683741be16cd89f4021854e9f55f3

OSX
f910c3014f8b44cd8219ee4aeff774f32f92e32bd7f0c59a40ef11fc8d1b712f

SuperClam

hero member

Activity: 784

Merit: 1002

CLAM Developer

Updated the addnode list in the OP post via http://blocktree.io/peers/CLAM/

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: cloverme on June 25, 2015, 09:20:15 AM

Quote from: ShapeShift.io on June 23, 2015, 11:22:03 AM

Clam friends! ShapeShift has re-added Clams to our instant altcoin exchange! So for the downtime. Instantly exchange Clams with 35+ altcoins today with ShapeShift.io

Shows as "Unknown exchange pair" this morning.... run out of clam?

They were having problems recently but say they're fixed now:

https://bitcointalksearch.org/topic/m.11711979

Quote from: chilly2k on June 25, 2015, 12:48:30 PM

Along these lines, I seem to be getting a lot of clients connecting to me, that are not up to sync. They end up killing my bandwidth. I have to stop/start the client.
Last time I checked it was 8 out of 40 connections were not even close to the current block height. I'm going to start writing down the connections and initial block height before I recycle, and see if there is a pattern.

Otherwise is there a setting to limit the number of new connections that require syncing?

I don't think there's anything to limit that, other than limiting your total number of connections:

-maxconnections= Maintain at most connections to peers (default: 125)

Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 335. (Read 1151252 times)