yes the original idea of thinking you were getting away with something by creating your own token will not help you. You mustregister your gambling site as a money transmitter & gambling commission or you going to end up in court(in my honest opinion)

>> same ole story here it appears Just-dice will be going offline soon imho! ~good LUCK!!!! bwaahahaha

See above (and in several previous posts) the warnings about change addresses. If you use JD solely for digging it's possible you may not get access to all of the CLAM you're entitled to.

It's odd that you would trust a third party website over a client that has source available, which you can even compile yourself, and that additionally, by trusting this third party website, you're opening the entire network up to a potential 51% attack.

I'm going to try to be nice, but your making it difficult.

I disagree wholeheartedly with just about everything you said.  The client is significantly safer then a website you send your private keys to. dooglus himself trusted it and continues to use it. It is after all where those 200k+ clams are being held. In all the hundreds of wallets that been imported by now there's never been one case of anything nefarious and there never will be.  

You say you think its safe but it sketches you out?  how can you have it both ways.. The fact you haven't even downloaded the client shows me you have no care at all about clams, its just a game to you and you make your decisions on anything but fact or logic.

The price is certainly one aspect of any coin, but for the 6 months before the increase in adoption things were doing just fine and development continued along. For some there's more concern then just price, but where not all just day traders like yourself, some of us care and believe in the technology and are trying to improve it in some way. Its not very valuable if all the adopters are not actually interested in clams but just want to make a quick buck. Adoption is great but the wrong type of adoption is not.  

If all the investors at JD want to devest and drop all the coins in the market, so be it, I welcome that. At least the network would almost certainly be secure which it currently isn't.

Crypto currency should not be based on trust. The fact you think its all right speaks volume to your character and the reasons you do what you do. It does not matter how trustworthy the individual is in the slightest.  

Me and dooglus discussed the situation just last night and came to the conclusion its too early to decided if JD having the coins and the hold over the network that comes with it is temporary or something that will get worse over time. If another service pops up and the problem resolves its self that would be wonderful but I would much rather have people dump coins into users who care about clams and will help secure the network themselfs at any price then have the JD stack become larger and larger making the issue worse.

There is no magic in anything we do with your wallet. Its quite simple what we've done. Its all encapsulated in a single function and is almost a complete direct copy of the standard LoadWallet function but we ignore all other data other private keys where thats the only important information.

All the times you've been on irc and talking to us I would have been more then happy to exactly explain what we did, why did you never ask?

All you do is transfer all the money out of your Bitcoin client to a temporary address on a different device, scan the wallet, delete wallet.dat, and then create a new wallet in the client and send the money back to yourself. I don't see how this is any riskier than using JD, other than the fact that disregarding the fact I trust xploited and the other coders, they might install malware on my computer. My keys are no biggie, xD.

Let's get real for a minute here. Exchanges take fees on each coin traded. This is where they make their money. Exchanges are then taking money from stake as well. This is where the staking should really be shared. We shouldn't have them just racking in whoknowshowmuch money on staking when they're already racking it in from fees. I think this needs to be the first priority: one that shares its stake with users. On every coin they support that uses PoS.

It seems I've been neglecting the forum for a day or two. We've had a big player beating us senseless at JD which has left me distracted.


I never really got the point of arguing from emotion. But I'm kind of autistic, so whatever.


The problem is that as far as the CLAM network is concerned, the clock only 'ticks' once every 16 seconds. All block timestamps are exact multiples of 16 seconds. And so it's very possible that JD and OTHER both find blocks at the same 'time' (given such a grainy version of time). When that happens, JD will accept the block it found, and attempt to build on top of it. The rest of the network will accept whichever block they saw first. Since JD has 75% of the weight, the most likely outcome is that JD finds the next block, orphaning the OTHER's block.

And the solution that I discussed with xploited is to make the clock tick more often, reducing the chance of two blocks having the same timestamp.


I hope this doesn't sketch you out too much, but I have a newsflash for you...

When you type "/dig <addr> <privkey>" in the JD chat box, guess what JD does with that information. It makes an RPC call *to the official client* asking it to sign a raw transaction *with your private key*. ie. JD takes your private key, and gives it to the CLAM client. The CLAM client doesn't do anything with it other than using it to sign a transaction, and your key isn't stored anywhere, but it's important to realise that you are trusting the official client whether you use JD or not.


Would you just fuck off already? Thanks.


I don't like third party sites either, but until we have "smart contracts" readily available and accepted, I don't see a way around it. People like the idea of having their coins "work for them" like they can at JD (in theory at least - we've been losing more than winning recently) and I don't see how we can achieve that without the third party holding their coins. Although, that reminds me:

About a year ago the idea was floated of allowing JD 'investors' to only actually deposit a fraction of their bankroll to the site while declaring the size of their total bankroll. The site would then act as if they had deposited the whole amount, using the actual deposit as collateral in the event that they lose. This would allow people to stake the majority of their own coins in their own wallet, while still having them "work" as if they were in the JD bankroll. I hope to finally implement such a system "soon".


Exactly. The client is used by the website to hold the coins. Any badness in the client is automatically also in the site, since the client is a component of the site.


Bay's a bigger fan of JD than I am. I see you guys looking out for the best interests of CLAM as a whole. He sees you attacking JD, and so is springing to its defence. I'm sure that's unnecessary, and we'll work it out reasonably. Adding 'age' to staking weight doesn't disadvantage JD unreasonably. If anything it makes things fairer. I suspect that JD is currently staking more than its fair share of the blocks (due to the way orphaning works when there's a race), which isn't how I want things to be.


I think I know where he's coming from. You must have heard a hundred times "why do you guys want my BTC keys?" and other such misunderstandings. People have been told to keep their wallets private, then you guys come along asking them to "import" their most precious file. People are suspicious. "Sketched out". Yes, we can say "review the code", or "we only use the keys to sign transactions", but most people don't have the skills to review the code or the understand to know what private keys even really are let alone how they're used. We're lucky if they know to keep their wallet safe in a lot of cases and there is a conflict when you then ask them to share their BTC wallet with the CLAM client.


I didn't think of it at the time, but I think adding the ability for people to hold the majority of their coins locally (in their own copy of the client, as I described a few responses up) will help with this. I'll encourage the bigger investors to do just that. It's in their best interest, as well as the interest of the network as a whole.


Oh dear. I'm answering this thread as I catch up on it. Things are getting unnecessarily messy here. Can't we all just get along?

The Clam Client only opens the wallets you explicitly ask it to. You make a good point that at JD you can 'dig' individual addresses rather than having to do it on a per-wallet level, but for people willing to 'dumpprivkey' in BTC and 'importprivkey' in CLAM, they can do the same too. And as Creative always points out, people who import their keys one by one are likely going to miss some, because they likely don't know about change addresses in enough detail.

So in summary:

* JD has an unfair advantage, and is staking too much
* JD threatens the network by being a single point of failure
* I support any reasonable attempt by the CLAM developers to help resolve these issues
* I will attempt to implement a system at JD that will allow investors to hold the majority of their coins locally, which I'm sure will at least partially fix the issues
* CLAM developers and JD aren't at war, and will work together to fix things!

Yeah?

What remains to be seen is how the price and amount of CLAM wagered will move overtime when JD will return 140% in a year at the current pace. Can a website be such a portion of the market?

   I think this is a great idea, but implementing it sounds like a nightmare.  As a quick fix, have you thought about running multiple copies of the client?  You would still have control of over 51% of the network, but no one client would have that power.  I have not looked at this any more then writing these words.  But I read a lot and haven't seen a technical reason you couldn't do it. 

    Good Luck, and thanks for JD.   

Thanks for your reply. I can't respond to everything and the thread has moved on anyway. It's OK to assume I agree with everything I didn't reply to.


I agree it's desirable if people who realize they have clams from the initial distribution download the client and become part of the network. I encourage people to do so.

I suspect given a choice between doing that and using the kind of quick method Just Dice allows, most people will use the quick method and probably convert to BTC as quickly as possible. If there were an alternative quick method run by someone other than dooglus, then there would be at least two independent people staking in the network and collecting lots of the clams from the initial distribution. (Three or four would be much better.) I think the concentration is partly due to Just Dice being the only quick, easy way to claim those clams.


Actually, I was suggesting people could sign a transaction (even offline) and never give up their private key. I probably didn't make that clear. For example, someone (Alice) could just make a big list of all the bitcoin addresses that still have clams and publish them with codes for transactions spending those clams to Alice's own clam address. Then Alice could say: "If you use some little piece of code that is only doing digital signatures to sign this transaction to my clams address, then I will send 3 mbits to your bitcoin address." Alice only needs the signed transaction to get the clams, not the private key.


I'm guessing you've had to explain this hundreds of times. You're correct, of course, and that's what I did myself just to be on the safe side. I'm trying to suggest an alternative answer: "You don't have to give up your private key, you just have to sign one thing with it." Realistically, most people don't understand and are scared as a consequence. I'm not sure much can be done about that, but I suspect it means most people who have clams from the initial distribution will never claim them.

By the way, there is a problematic corner case with emptying addresses before claiming clams. Some bitcoins (well, tx outs) are really tokens standing for some meta-protocol (e.g., colored coins, master coin, counterparty). Care would need to be taken to move these, or they could lose their intended meaning and lose significant value as a result.


Yes, it should reduce occurrences of "race conditions" -- as should switching 16s to 1s. How many such race conditions occur in an average day at the moment?


Ah, because the reward is fixed at 1 clam? You're right. I hadn't thought about that. With a fixed reward staking all the time provides optimal rewards. Eh, I'm OK with putting age back in.

To some extent, "age" is still in the staking algorithm now since minted coins take 510 blocks to mature (so the age goes from 0 to 1 and stays at 1). I noticed Just Dice mostly gets around this (completely legitimately) by keeping lots of transactions with approximately 4 clams as an output. (I might be doing the same thing, but I'm not telling.) This way there is the same chance of staking as if there were one big txout, but when one of the small ones stakes there are only 5 clams waiting to mature leaving the other small txouts still staking. (I'm not sure if 4 clams is optimal for this strategy. Someone should do the maths.)

Keep in mind that however age is included, stakers will (legitimately) split their clams to optimize their rewards.

I don't know the real numbers, but suppose JD has 25,000 transaction outputs staking with 4 clams on each. No matter how many of these have recently staked, most of them necessarily haven't staked recently and will have some age saved up.

I doubt there is a modification that would cause JD to stake fewer blocks. There could simply be a modification that the same *address* cannot stake twice in a row, but this has the obvious workaround that JD (and everyone else) would use different addresses for each staking output.

I was hoping it would be relatively simple, but have just spotted a problem with it:

Currently we treat both staking rewards and player losses as "income" for the bankroll, and split it equally between those providing the bankroll. But with the proposed scheme, where you only deposit a fraction of your bankroll, and leave the rest locally, we don't want to consider the whole amount as active for staking (since it isn't). And that breaks the whole scheme (I only track the percentage of the bankroll that each user owns - I don't update their balance every time something happen, and don't want to).

I guess the solution is to treat staking rewards differently. They happen relatively rarely; the bankroll changes due to betting many times per second, and due to staking at most 4 times per minute. I can reduce the frequency at which staking rewards are credited to investors if necessary, and have them treated as a special kind of 'investment' event. This complicates things, but not too much.


I have tried running multiple copies of the client on different sites. I found that it really doesn't handle orphans very well. When both clients found a block at the same time, the one with the smaller weight would quickly get left behind, since its block would be orphaned. It would take up to 30 blocks before the smaller weight client realised this and did a reorg. For those 30 blocks it would see all the new blocks it received as "orphans" (which is weird, since they aren't) and would continue clinging to the hope that the single block it had staked would be accepted.

I should really have looked into this and fixed it, but instead all I did was move all the coins back to a single wallet to avoid the problem.