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

[SuperClam]

You don't have a MAC wallet yet though so only windows users can claim CLAM

Thankfully, Linux and Windows make up > 90% of Laptop/Desktop computers.

In the meantime, and assuming the wallet is emptied first, creativeCLAM and/or xploited over in IRC would likely be more than happy to import and send OSX user's CLAMS to the exchange or service of their choice.


I will save you the agony of another promise.
Though there is some expectation of an OSX build soon.

[1713569518]

1713569518

[bram_vnl]

i have a old doge wallet in my clamcoin wallet how can i clam it?

[Vortex20000]

i have a old doge wallet in my clamcoin wallet how can i clam it?

Unintended pun? Clam it?

Do you mean you have an old DOGE address and you want to get the clams on it? Read the above posts, I presented two ways, the first getting preferable.

[ranlo]

how do I claim these? I cant figure out

CLAM wallet -> File -> Import wallet -> Select your BTC, LTC, or DOGE wallet.dat file.
OR use JD's built in /dig command, more help in the faq.

ok thanks

If you need help just ask the troll box, but you may need to ignore the smart asses.  If I'm there I'll help you with anything I can.  Just ask until one of the fuck faces help you haha

In the chat box, type /dig <address> <address' private key>
All done explaining. The balance will be added to your JD balance.

dooglus plan seems to work, there is a high demand but there is a growing supply from people learning they have X CLAMS to claim. If they don't gamble and don't want to invest in a bitcoin casino they are naturally selling it.

Please remember:


If you have sent coins out of the wallet, even just once, those coins are no longer associated with the receive address they were received with.

During every single send (unless spent completely and evenly), the wallet creates what are called "change" addresses.
These change addresses to do not show up in the User-Interface of the client.

Unless you have expert knowledge and understanding concerning "change" addresses, and exactly where your outputs were on May 12th, it is extremely likely that importing individual addresses will not get you all of your CLAMS.

In these cases (the vast majority), the easiest way to be certain you are getting all of the CLAMS you deserve is to download the client and click 'File'->'Import Wallet'.


The Just-Dice claim command is a wonderful feature for those who know exactly which address the given "output" was at during the May 12th snapshot. 

However, if you do not understand exactly what an "output" is, or what a "change" address is, we urge users to claim using the conventional method built into the CLAM client.  This ensures that all private keys are imported (even the ones you don't know are in there) and all CLAMS are claimed.

To confirm, users with Multibit, when exporting addresses, do show all of them, correct?

[dy2k]

Is there a way to split clams in multiple addresses at once?

[ymod123]

for someone that dont gamble in JD have a veryyyy TINYYY chance to stake my coin now...? 

[dooglus]

for someone that dont gamble in JD have a veryyyy TINYYY chance to stake my coin now...? 

If you have X% of the actively staking CLAMs, you have an X% chance of staking the next block.

JD doesn't change that fact.

[SuperClam]

That will never happen. I am already in a position where I could make that the case. I can easily just ignore all blocks staked by non-JD addresses and build on top of the most recent JD block. If I was doing that then of course you have a valid point, but I am not and will not. If you have 1% of the staking weight, you will stake 1% of the blocks whether JD's bankroll is 0 or whether JD has the other 99% of the staking weight.

The time granularity on the CLAM network is currently 16 seconds.
In this context, "most recent" simply means the entire period during which a given block would exist inside of that 16~ second window.

During any "race condition", an often occurrence given the large number of blocks the Just-Dice wallet stakes, the Just-Dice wallet indeed ignores and often eventually orphans the competing block.  This is not malicious, it is competitive and standard behavior.

The concern, however, is that given the Just-Dice wallet's propensity for staking consecutive blocks this might make it nearly impossible for other clients to win any "race condition".


There is no argument that Just-Dice adding CLAMS has increased interest, claim rate, and utility.
Further, there are few people I am aware of that are better trusted to possess such a position in a network.
That said, such control is trouble-some for any decentralized network.

An educated and informed discussion about the future of the CLAM network is warranted.
It very well might be that increased interest will eventually result in an expansion of the network such that this is a temporary issue.
We should all work to expand utility, awareness, and solo staking towards that end.


In that sentiment, I would like to start a discussion about the re-implementation of "Age" as a factor in the chance to stake.

In a system with "age", the above mentioned orphaned outputs would retain their favorable position and chance to stake.
In addition, the accrual of "age" might allow for small outputs and small holders (given the patience to wait) a chance to eventually stake.


I look forward to the commentary of those with specific and insightful knowledge.

[Vortex20000]

Age sounds nice, but [most of] JD's wallet's coins would also age with others, this maintaining the same relative chance to stake, would it not?

Again, no offense meant to JD or doog.

[SuperClam]

Age sounds nice, but [most of] JD's wallet's coins would also age with others, this maintaining the same relative chance to stake, would it not?
Again, no offense meant to JD or doog.

Indeed.

Though it would allow users who have had their blocks orphaned by consecutive JD staking to at least retain the age and thus improved chance to stake in the future.

[dooglus]

During any "race condition", an often occurrence given the large number of blocks the Just-Dice wallet stakes, the Just-Dice wallet indeed ignores and often eventually orphans the competing block.  This is not malicious, it is competitive and standard behavior.

That's a good point, which I hadn't previously considered. JD is most often going to be racing against itself (two blocks both able to stake in the same 16 second slot) and when it does inevitably one of the two blocks goes to waste.

We can roughly work out the odds of the case you're talking about happening, where someone stakes a block which JD then orphans by finding a block at the same time and then staking the next block too. I'm not sure about this math, so please point out any errors I make:

Let's say JD has 75% of the network weight. For JD to orphan a block staked by the 25% of the network it doesn't control, these things must all happen:

1) someone from the 25% of the network stakes a block
2) JD stakes a block in the same 16 second slot
3) JD stakes the next block

We want to know the odds of 2) and 3) happening given that 1) has happened.

The probability of anyone staking a block in a given 16 second time period is 16/60, since we target 1 minute blocks (this is wrong, but probably not too far from the truth). So the probability of JD staking a block in that time slot is 0.75*16/60. That's 2)

The probability of JD staking the next block is 0.75. That's 3)

The probability of 2) and 3) both happening is the product of their probabilities: 0.75*0.75*16/60 = 0.15

ie. there's a 15% chance that your block will be orphaned by JD if you're staking on your own. That's obviously far too high - and more importantly it's a little higher than the 10% commission JD charges for staking! Could someone with a significant holding confirm that they're seeing something like a 15% orphan rate?

If we change the granularity to 8 second slots from 16 seconds, the orphan rate halves (the 16 in the equation is replaced by an 8 and nothing else changes). It seems that the orphan rate is inversely proportional to the granularity.

In that sentiment, I would like to start a discussion about the re-implementation of "Age" as a factor in the chance to stake.

In a system with "age", the above mentioned orphaned outputs would retain their favorable position and chance to stake.
In addition, the accrual of "age" might allow for small outputs and small holders (given the patience to wait) a chance to eventually stake.

That seems fair. The concern with using 'age' is that it removes the incentive for people to stake 24/7. If I can stake for an hour a day, use up all my saved up coin age and earn the same as if I was staking the whole day, why wouldn't I?

I guess we need to design the weight formula such that it rewards people for securing the network. I guess some kind of non-linear function would suffice: weight = value * log(age) : so doubling the age of a coin adds a fixed amount to its weight, rather than doubling its weight.

Edit: the point here being that having age be ignored as it currently is makes it hard for small holders to stake at all, having it count linearly makes it cost effective to only stake for a small percentage of the time, and so something in between seems optimal. y=log(x) is somewhere between y=0 and y=x (for x > 4 hours, at least...)

I look forward to the commentary of those with specific and insightful knowledge.

Me too. But in the mean time you'll have to make do with my ramblings.

[ranlo]

During any "race condition", an often occurrence given the large number of blocks the Just-Dice wallet stakes, the Just-Dice wallet indeed ignores and often eventually orphans the competing block.  This is not malicious, it is competitive and standard behavior.

That's a good point, which I hadn't previously considered. JD is most often going to be racing against itself (two blocks both able to stake in the same 16 second slot) and when it does inevitably one of the two blocks goes to waste.

We can roughly work out the odds of the case you're talking about happening, where someone stakes a block which JD then orphans by finding a block at the same time and then staking the next block too. I'm not sure about this math, so please point out any errors I make:

Let's say JD has 75% of the network weight. For JD to orphan a block staked by the 25% of the network it doesn't control, these things must all happen:

1) someone from the 25% of the network stakes a block
2) JD stakes a block in the same 16 second slot
3) JD stakes the next block

We want to know the odds of 2) and 3) happening given that 1) has happened.

The probability of anyone staking a block in a given 16 second time period is 16/60, since we target 1 minute blocks (this is wrong, but probably not too far from the truth). So the probability of JD staking a block in that time slot is 0.75*16/60. That's 2)

The probability of JD staking the next block is 0.75. That's 3)

The probability of 2) and 3) both happening is the product of their probabilities: 0.75*0.75*16/60 = 0.15

ie. there's a 15% chance that your block will be orphaned by JD if you're staking on your own. That's obviously far too high - and more importantly it's a little higher than the 10% commission JD charges for staking! Could someone with a significant holding confirm that they're seeing something like a 15% orphan rate?

If we change the granularity to 8 second slots from 16 seconds, the orphan rate halves (the 16 in the equation is replaced by an 8 and nothing else changes). It seems that the orphan rate is inversely proportional to the granularity.

In that sentiment, I would like to start a discussion about the re-implementation of "Age" as a factor in the chance to stake.

In a system with "age", the above mentioned orphaned outputs would retain their favorable position and chance to stake.
In addition, the accrual of "age" might allow for small outputs and small holders (given the patience to wait) a chance to eventually stake.

That seems fair. The concern with using 'age' is that it removes the incentive for people to stake 24/7. If I can stake for an hour a day, use up all my saved up coin age and earn the same as if I was staking the whole day, why wouldn't I?

I guess we need to design the weight formula such that it rewards people for securing the network. I guess some kind of non-linear function would suffice: weight = value * log(age) : so doubling the age of a coin adds a fixed amount to its weight, rather than doubling its weight.

Edit: the point here being that having age be ignored as it currently is makes it hard for small holders to stake at all, having it count linearly makes it cost effective to only stake for a small percentage of the time, and so something in between seems optimal. y=log(x) is somewhere between y=0 and y=x (for x > 4 hours, at least...)

I look forward to the commentary of those with specific and insightful knowledge.

Me too. But in the mean time you'll have to make do with my ramblings.

Ah, Doog. You never cease to amaze me. You're one of the few people here that doesn't just throw out assumptions, and instead gives actual information that substantiates your views. Huge +1 with this.

Now, I think the idea of orphaning blocks should be ignored in relation to JD vs. elsewhere. The reason for this is because just like JD can orphan someone's block, someone else can orphan JD's. On the same token, the stake amount should be about equal over time. Take it like this:

Let's say JD has 75% and everyone else has 25%. We look at stakes:

JD
JD
JD
JD
JD
JD
OTHER
JD
JD
OTHER
OTHER
JD

What you'll see here is that JD locks in a lot in a row, leading to people feeling like they're being ripped off. Then they get a couple in a row, evening it out. Staking should be, over time, about equal to your percentage. The only difference being that instead of getting, say 0.0001 CLAM a day, you get the full CLAM when it hits.

So barring JD doing something nefarious (like attacking the network), it shouldn't really matter how many blocks the site is staking. This, of course, ignores the principle that states nobody should have 51%+ regardless of their intentions (as that makes it a centralized system, whether they want to abuse the power or not).

[Vortex20000]

During any "race condition", an often occurrence given the large number of blocks the Just-Dice wallet stakes, the Just-Dice wallet indeed ignores and often eventually orphans the competing block.  This is not malicious, it is competitive and standard behavior.

That's a good point, which I hadn't previously considered. JD is most often going to be racing against itself (two blocks both able to stake in the same 16 second slot) and when it does inevitably one of the two blocks goes to waste.

We can roughly work out the odds of the case you're talking about happening, where someone stakes a block which JD then orphans by finding a block at the same time and then staking the next block too. I'm not sure about this math, so please point out any errors I make:

Let's say JD has 75% of the network weight. For JD to orphan a block staked by the 25% of the network it doesn't control, these things must all happen:

1) someone from the 25% of the network stakes a block
2) JD stakes a block in the same 16 second slot
3) JD stakes the next block

We want to know the odds of 2) and 3) happening given that 1) has happened.

The probability of anyone staking a block in a given 16 second time period is 16/60, since we target 1 minute blocks (this is wrong, but probably not too far from the truth). So the probability of JD staking a block in that time slot is 0.75*16/60. That's 2)

The probability of JD staking the next block is 0.75. That's 3)

The probability of 2) and 3) both happening is the product of their probabilities: 0.75*0.75*16/60 = 0.15

ie. there's a 15% chance that your block will be orphaned by JD if you're staking on your own. That's obviously far too high - and more importantly it's a little higher than the 10% commission JD charges for staking! Could someone with a significant holding confirm that they're seeing something like a 15% orphan rate?

If we change the granularity to 8 second slots from 16 seconds, the orphan rate halves (the 16 in the equation is replaced by an 8 and nothing else changes). It seems that the orphan rate is inversely proportional to the granularity.

In that sentiment, I would like to start a discussion about the re-implementation of "Age" as a factor in the chance to stake.

In a system with "age", the above mentioned orphaned outputs would retain their favorable position and chance to stake.
In addition, the accrual of "age" might allow for small outputs and small holders (given the patience to wait) a chance to eventually stake.

That seems fair. The concern with using 'age' is that it removes the incentive for people to stake 24/7. If I can stake for an hour a day, use up all my saved up coin age and earn the same as if I was staking the whole day, why wouldn't I?

I guess we need to design the weight formula such that it rewards people for securing the network. I guess some kind of non-linear function would suffice: weight = value * log(age) : so doubling the age of a coin adds a fixed amount to its weight, rather than doubling its weight.

Edit: the point here being that having age be ignored as it currently is makes it hard for small holders to stake at all, having it count linearly makes it cost effective to only stake for a small percentage of the time, and so something in between seems optimal. y=log(x) is somewhere between y=0 and y=x (for x > 4 hours, at least...)

I look forward to the commentary of those with specific and insightful knowledge.

Me too. But in the mean time you'll have to make do with my ramblings.

Ah, Doog. You never cease to amaze me. You're one of the few people here that doesn't just throw out assumptions, and instead gives actual information that substantiates your views. Huge +1 with this.

Now, I think the idea of orphaning blocks should be ignored in relation to JD vs. elsewhere. The reason for this is because just like JD can orphan someone's block, someone else can orphan JD's. On the same token, the stake amount should be about equal over time. Take it like this:

Let's say JD has 75% and everyone else has 25%. We look at stakes:

JD
JD
JD
JD
JD
JD
OTHER
JD
JD
OTHER
OTHER
JD

What you'll see here is that JD locks in a lot in a row, leading to people feeling like they're being ripped off. Then they get a couple in a row, evening it out. Staking should be, over time, about equal to your percentage. The only difference being that instead of getting, say 0.0001 CLAM a day, you get the full CLAM when it hits.

So barring JD doing something nefarious (like attacking the network), it shouldn't really matter how many blocks the site is staking. This, of course, ignores the principle that states nobody should have 51%+ regardless of their intentions (as that makes it a centralized system, whether they want to abuse the power or not).

A good point.

[picolo]

for someone that dont gamble in JD have a veryyyy TINYYY chance to stake my coin now...? 

If you have X% of the actively staking CLAMs, you have an X% chance of staking the next block.

JD doesn't change that fact.

Yes, as simple as that. JD is just giving an option to people having CLAM.

[J. J. Phillips]

It's good to see people are discussing this issue. The fact that JD controls so much of the staking power is a potential problem. (I don't know any of you, but it is reassuring to read positive comments about dooglus / JD.)

I don't think putting age back in would really help. (If age is put back in, it definitely should be sublinear. There are a variety of sublinear options we could consider, including dooglus' log suggestion.)

The fact that there are still so many unclaimed clams means someone else could bring JD under 50% without people withdrawing clams from JD.

The best solution IMO is for someone else to do the 2 most important things JD has done: (1) make it very easy for people to claim their unclaimed clams and (2) provide a staking pool.

(1) The JD dig feature seems to be more popular than the import wallet feature. There might be an even easier/more popular way to do this. People are afraid of giving up any of their private keys. Technically they only need to use the private key to sign a tx to send the buried clams to a new address. Maybe someone could find a way for people to easily sign such tx's (on the client side) in exchange for something. They should be able to do this without needing to download the clam client and the first 10000 blocks of the block chain.

(2) A staking pool would not require having a website at all. It could all be done on the blockchain in a provably fair way. I thought about trying to set something like this up myself, but none of you know me. I know I'm trustworthy and won't run away with your clams, but realistically you don't. Plus I wouldn't want to spend more than 1 or 2 hours a week on it. There's probably someone in the clams community trusted enough to run such a pool, or a clever "trustless" way to do it.

[SuperClam]

It's good to see people are discussing this issue. The fact that JD controls so much of the staking power is a potential problem. (I don't know any of you, but it is reassuring to read positive comments about dooglus / JD.)
I don't think putting age back in would really help. (If age is put back in, it definitely should be sublinear. There are a variety of sublinear options we could consider, including dooglus' log suggestion.)
The fact that there are still so many unclaimed clams means someone else could bring JD under 50% without people withdrawing clams from JD.
The best solution IMO is for someone else to do the 2 most important things JD has done: (1) make it very easy for people to claim their unclaimed clams and (2) provide a staking pool.
(1) The JD dig feature seems to be more popular than the import wallet feature. There might be an even easier/more popular way to do this. People are afraid of giving up any of their private keys. Technically they only need to use the private key to sign a tx to send the buried clams to a new address. Maybe someone could find a way for people to easily sign such tx's (on the client side) in exchange for something. They should be able to do this without needing to download the clam client and the first 10000 blocks of the block chain.
(2) A staking pool would not require having a website at all. It could all be done on the blockchain in a provably fair way. I thought about trying to set something like this up myself, but none of you know me. I know I'm trustworthy and won't run away with your clams, but realistically you don't. Plus I wouldn't want to spend more than 1 or 2 hours a week on it. There's probably someone in the clams community trusted enough to run such a pool, or a clever "trustless" way to do it.

Thank you for your input!


I believe your reasoning is somewhat circular, however.

The concern at hand is the concentration and centralization of the CLAM network.  
Your suggested solution appears to be that there should be an alternative which does not require users to download the client.


There are multiple reasons it is desirable that users download the client.  

First, a user can not very well stake, and thus decentralize the network, without the client.  

Second, the vast majority of users do not understand how the protocol works - and thus, any individual key solution will almost certainly result in incomplete claims.  Even use of the command 'listunspent' will not produce the required private keys, as the pertinent keys may very well not contain an unspent output now; though they did at the time of the distribution snapshot.  The fact is that a miniscule portion of the users I have spoken with understand that "change" addresses even exist, let alone the process a client goes through to produce the tree of outputs one finds on the chain.

Third, your solution appears to suggest that third-party services, in which the private key is transferred to a web-server over the wire through a browser into an opaque code system is preferable, from a security stand-point, to importing directly into the client.  Even in the case of Just-Dice, it is impossible to argue from a security stand-point, given that the same individual you trust, dooglus, has thoroughly reviewed and contributed to the code of the client.  Therefore, a great deal of that "trust" must exist in both methods of claiming CLAMS.  The difference being that claiming in the client does not involve the private keys ever leaving your personal system.  Of course, the entire issue of security is nearly moot, considering that the recommended claim process, for Just-Dice OR the client, both involve emptying the private key before claiming regardless.  Empty keys have no more value than any random string of characters.

Fourth, the process of entering the console and utilizing commands to sally-forth individual private keys, which you hope happen to have had control of the outputs on May 12th, can hardly be considered "easier" (though it could indeed be faster, considering the requirement to sync - though individually importing keys is likely NOT faster when more than a handful of keys are concerned) than the three clicks required to click "Import Wallet".


Concerning age:

The re-implementation of age would reduce the occurrence of orphans caused by "race conditions".  For that reason alone, it is likely a sensible option.  

The only argument I have heard against the re-implementation of age concerns the incentive structure and desire to have clients staking continuously for network security.  

CLAMS already has the most sensible incentive structure is this regard, even if EXPONENTIAL age was implemented.

The fact is, we are the only proof-of-stake crypto with a reward structure that doesn't allow users to accrue reward "interest" via accruing age.  That alone is incentive to not "store" age.  Time not spent hashing, is time not spent rolling hashes for nBits.  Making CLAMS easily the crypto with the most well-aligned incentive structure regardless of age.

The only way it would make sense to "accrue" age would be if a user had a single output, which had just staked, and therefore they were not even close to solving a block; and thus decided to forgo the minimal chance of solving a block in favor of not staking.  However, even with a handful of staggered outputs, not staking the client consistently would result in drastically reduced chance to stake, and therefore drastically reduced reward, as surely at least one of the outputs at any given time is near enough to accruing enough age to have at least some chance to stake.

Is age a silver bullet?  
No, absolutely not.  It doesn't solve the crux of the problem at all.

Would competition in the realm of stake-pooling (something entirely un-heard of before CLAMS) be beneficial?
Yes.

However, arguing that it makes any logical sense at all for the average user to claim via any method other than the client simply doesn't hold weight in my opinion.  

The only reasonable argument, in that regard, is for users who KNOW they have all of their keys, have a reasonably small number of keys, and desire the additional speed of not having to sync the client.

[BayAreaCoins]

1. There is no need to trust digging at JD because the wallet should be empty and retired prior to digging.

2.  People trust digging on JD way more than some strange client that magically shifts through your wallets for coins or whatever else.  CLAM CLIENT sketchs me out personally and many many others. (I do think it is safe though, but honestly I personally do not have it downloaded and probably will not download it.)

3.  I don't see centralization as a problem atm.  JD puts all the work out, provides all the services, has the best chat and therefore gets its fair share of the network... honestly I feel like JD should have 80%-95% of the coins right now.

In 6mo prior to JD CLAM got on Poloniex.... In 2 weeks after JD opened this door we have seen huge growth both price wise as well as adoption wise.  

I think it would be wise not to do anything that might appear to be taking away from JD holders in order to be "more fair" to other people. My best advice who don't like the fact that JD has >51% of the network stake would be to make CLAM services and encourage services that you trust to accept clam!

Hell... maybe even lobby your local mining pool to start a CLAM pool!  Very little over head in them at least trying!  Do not be scared to start your own shit for fear that people won't trust you... everyone had to have their first trade somewhere!  I really really expect that the CLAM holders will at least give you a shot in trust, so fucking take the risk!

[cryyptc]

you call yourself a developer yet you don't even know that freenode blocks TOR?
fekkin noob!!!! ====> i got you guys listed on cryptsy now you never pay me my 200 clams.
thats what this is all about ,  you really that greedy?
:\
~ take a look at yourself!!!!

*You
*F*cking
*I
*and you
*paid
*That's
*are you
*Take
Among many.


This has nothing to do with greed.

It has to do with:

• Your inability to speak truthfully,
• Having your attempts at begging refused, and
• Having your attempts at extortion refused.

If you:

• Learn to speak truthfully,
• Stop begging, and
• Offer something of value;

Then, perhaps, those with self-respect might toss you some CLAMS.


Until that time, you have absolutely nothing to offer this community.
Move along, Owsley


P.S.  If you are really nice, and apologize for being a bad troll, I might even let you back into the IRC channel

/\gfys scammers; see how far you get with that attitude i want my 200 clams as promised

[cryyptc]

1. There is no need to trust digging at JD because the wallet should be empty and retired prior to digging.

2.  People trust digging on JD way more than some strange client that magically shifts through your wallets for coins or whatever else.  CLAM CLIENT sketchs me out personally and many many others. (I do think it is safe though, but honestly I personally do not have it downloaded and probably will not download it.)

3.  I don't see centralization as a problem atm.  JD puts all the work out, provides all the services, has the best chat and therefore gets its fair share of the network... honestly I feel like JD should have 80%-95% of the coins right now.

In 6mo prior to JD CLAM got on Poloniex.... In 2 weeks after JD opened this door we have seen huge growth both price wise as well as adoption wise.  

I think it would be wise not to do anything that might appear to be taking away from JD holders in order to be "more fair" to other people. My best advice who don't like the fact that JD has >51% of the network stake would be to make CLAM services and encourage services that you trust to accept clam!

Hell... maybe even lobby your local mining pool to start a CLAM pool!  Very little over head in them at least trying!  Do not be scared to start your own shit for fear that people won't trust you... everyone had to have their first trade somewhere!  I really really expect that the CLAM holders will at least give you a shot in trust, so fucking take the risk!

fyi no one trusts you ! :\  ....just sayin'.

*everyone knows what you are trying to do! = looks like you are trying to distribute a bitcoin wallet stealer? lmfao

[cryyptc]

^^^^
tl;dr



====> let me make this simple : i got you listed on cryptsy = where is my 200 clams


~ and maybe you can connect with some extensions, but no! >> freenode irc blocks most TOR exit nodes so stfu and do your own homework.

fyi: warning I know insiders at okcoin and most all other exchanges so if this is how you do business~ the bitcoin community wants nothing to do with your fraud.


:\


/\you better stop and think before you keep spouting this falsehoods

Go away Owsley!

You ain't getting shit bitch (ever!)

no worries we will just hardfork CLAMS ... sit back and enjoy the ride lmao