I didn't use Mycelium a whole lot recently, but as I remember it I used to be able to get details of each transaction, and copy/paste the transaction ID. Now I can't figure out how to do that. Touching a transaction in the transaction list is occasionally selecting it, sometimes just making it flicker, but mostly doing nothing. So I turned the tablet off and on again only to find that the non-broadcast transaction has vanished. When I look at the output I tried to spent at blockchain.info I don't see any pending transaction there either.

So I'm thinking I can export the xprv key, use that to find the output's private key, import it into a real Bitcoin client, and make a conflicting transaction there, just in case the first transaction is stuck somewhere in a Mycelium server somewhere. I don't want to end up paying twice...

Edit: That worked. I used something called 'pycoin' to convert the xprv... string you get from exporting the Mycelium wallet into a Bitcoin wif format private key, imported the private key, and spent the output. It was just 7 commands including the installation of pycoin:


The 'false' argument at the end of 'importprivkey' tells bitcoind not to rescan the whole chain. I know there's only one output at that address and I know its txid and vout, so scanning the chain would be a waste of time. I used the raw transaction RPC commands, but you could use the coin-control GUI in bitcoin-qt (but for that you would have to let importprivkey rescan the chain).

The "ku -W -s 0/0 $x" part is dumping the WIF format private key for the 0th non-change address in the wallet. The first 0 means "real address, not change address" and the 2nd 0 means "the first address" (it counts from zero).

Edit2: even after the new transaction confirmed, it doesn't show up in Mycelium. I've refreshed, but my balance there shows the same as it was before I spent it all.

Edit3: Edit2 is a lie. The balance does indeed show 0, but the transaction list only shows a single incoming transaction. It doesn't show the one that I made using the bitcoin-cli raw transaction.

I just sent a transaction from Mycelium and it too isn't showing up anywhere.

Can I get the raw transaction so I can broadcast it myself? Or at ETA for when it might be broadcast? Or any kind of word on what's going on here?

Oh, I see. That's how I did it...

Reload the site now. Chat lines where people mention your name or userid are bolded. You can turn on an audible alert too using a setting in the account tab. And also edit the list of words that trigger the alerts.

As I understand it, f2pool didn't even have a copy of the block they were mining on top of. All they had was the bare minimum needed to build on top of it. If validating a block produces a checksum that is needed to be included in the next block then whoever is giving them the details they need will just add that checksum to the list of details they provide. f2pool still won't have to validate anything.

I don't see a way of checking that the miners even have a copy of the parent block let alone checking that they have verified it without breaking compatibility with all existing mining hardware.

I only just found this thread. I'm not sure why you thought I would happen to notice your thread.

There's an email address at the end of JD's FAQ tab for customer support.

I'll take a look at the logs and see who muted you. Do you have record of when it happened, or a screenshot, or your userid or username or anything that might help me locate it?

Do:

  /whois 1

It's a recently added command for looking up names from userids.


Yes, I'll be changing that 'soon'.


OK.


I don't understand. Can you give some examples please?

That's a good idea. Any idea whether any of them are open source or open to adding new coins?

None of the CLAM block explorers that I am aware of do the address clustering / labelling thing.

I have added an escrow function to Just-Dice now. See the FAQ tab for details - search for "escrow" in there.


Apparently the support person was parroting the official company policy. xploited (CLAM dev) tells me he spoke to bittrex-richie (the real one!) who told him that their lawyers won't let them comment on whether they control particular crypto addresses or not. Which sucks, but at least it's not the support person's fault.

koikoi's argument appears to be "s.cc cannot be a Ponzi because it has been running for two years; Ponzis cannot run for two years, hence s.cc is not a Ponzi".

In order to disprove his argument, all you need to do is find a counterexample. That is what drawer did. Even though bitcoincloudservices was obviously a scam, even it was able to run for two years. And so s.cc which is very slightly less obviously a scam (instead of photoshopped miners we get no photo at all, and claims to be mining with 850 Gh/s) should be able to run for even longer, even if it is a scam.

Get it? It's called logic.

I took the test site down after putting the changes live. You can reload Just-Dice.com now to see the things I was talking about.

You get 1.5 on a win, 0.5 of which is profit. If you win two in a row, one time your balance will go up by 1 satoshi, the other time it will stay still. It's like you really win 0.5 profit, but the displayed balance is rounded to 8 decimal places.

You emailed your investors before you knew any details of the vulnerability telling them that they were safe.

You were wrong.

Once you knew about the vulnerability you denied it because you couldn't reproduce it in your badly coded simulation.

You were wrong again.

So what makes you think that you're qualified to say "Investors are safe" now? And why should they believe you when you have shown yourself to be generally clueless?

This whole issue came about because too many different payout multipliers result in the same chance of winning when the chance is rounded to 2 decimal places.

That's an issue that all dice sites have to consider at some point, and of course they all come to the conclusion that you need to let the player pick the chance and tell them what the multiplier is going to be, and not the other way around.

Just-Dice has been running for 2 years and only today did someone ask about this for the first time. They want to turn 0.6 CLAM into 130k CLAM, and to do so they need a multiplier which results in a chance of winning of 0.00045%. We only allow chances to 4 decimal places, and so he has to go with 0.0004% or 0.0005% and was wondering why he couldn't have the chance he wanted.

It's weird that the issue should come up now for the first time, independently of the crypto-games.net issue. Apparently crypto-games.net has been running for a year without anyone thinking about this issue too.

You can /msg him - that tells you his name.

Once the escrow commands are live, you can /cancel <uid> and that will tell you his name too:


But of course I should include their names in that report too...


So merge "cumulative gains" and "cumulative losses", and sort by the absolute value of the profit. That's a good idea. People care about the biggest changes whether they're positive or negative.

I'll add it to my list. Today I hope to put some kind of confirmation dialog on the /tip command. Yesterday KingDice accidentally tipped 1400 CLAM to a scammer who instantly withdrew it. The same scammer who he tipper 360 CLAMs to a week or two ago. Sigh.

I just made a couple of changes.

1) as soon as you leave the 'payout' field, the payout field is adjusted to match the displayed 'chance to win' value. So type 222222 into 'payout' then hit TAB or click outside the box and see it instantly change to 247500 (the multiplier for 0.0004%).

2) every time you hit a key, a 5 second timer is started. If you go 5 seconds without hitting a key, the 'payout' field is adjusted to match the displayed 'chance to win'. So type '222222' into the 'payout' field and then do nothing for 5 seconds. The 222222 should change to 247500.

I've put neither feature live, but you can try them out here:

    https://54.155.13.216/

That also has the /escrow, /cancel, /paid, /release commands for your testing pleasure. See Q7 in the FAQ for details, or just type /escrow in the chat for more terse usage information.

All feedback gratefully received, as always.

Edit: I improved the automatic 'fixing' of the payout multiplier. When you type a number that isn't one of the allowed multipliers, the field's background goes orange and a message appears in the top right telling you that it will be automatically fixed after 3 seconds of inactivity. It's up at:

    https://54.155.13.216/

Exactly. 'dumpprivkey' in bitcoind, 'importprivkey' in clamd and the CLAMs show up.

I will modify the /dig command in Just-Dice so that it tells you CLAM address for any BTC address you give it:


I'm also working on some changes to implement an escrow feature in JD. I'll put both changes live together.


All Just-Dice chat commands begin with '/'. Typing "!help" simply causes you to say "!help" in the chat. If something is responding to that, it must be some kind of third party bot.


I'll see if I can reproduce that. Put 0.6 into 'bet size', then by trial and error adjust the 'payout' box until the profit is the same as the max profit? (Do you realise how mad people are going to be if I bet 0.6 CLAM and win the max profit testing this for you?!) OK, so I see the problem. You're making a relatively small bet to win a huge amount. That's obviously going to need the chance of winning to be tiny. We have only 4 decimal places of granularity in the chance of winning, because we only roll 6 digit dice rolls (00.0000 to 99.9999). At 0.0004% chance of winning (247,500x) a winning 0.6 CLAM bet makes 148,499.4 profit, and at 0.0005% (198,000x) it makes 118,799.4 profit. The max profit (135k) is somewhere between these, and so you want to roll at something like 0.00045%, but we can't do that when we only have a million different roll outcomes. I notice that if I put 0.6 into the 'bet size' field and then edit the 'payout' field, the 'chance to win' field goes to 0.0005 when I type 215000 but to 0.0004 when I type 225000. It looks like I am seeing the chance field to the closest available chance to the one you're requesting:

>>> 99.0 / 215000 = 0.0004604 -> rounded to 0.0005%
>>> 99.0 / 225000 = 0.0004400 -> rounded to 0.0004%

I guess the question is: when the user asks for a 215000x multiplier, and we don't have a bet like that, should we round down to 198000x, up to 247500x, or round to whatever available multiplier is 'closest' in some sense? We round to the closest one. Sometimes that involves rounding the multiplier up, which puts the profit over the max profit, and so the bet is disallowed.

You say "nothing happened". When I tried, I saw this in the text area in the very top right, next to the 'Just-Dice.com' text:
    "That is over the current maximum allowed profit (135886.52)"
but it's not very obvious. The client should really detect that the bet isn't acceptable before sending it to the server, but it's tricky. The 'chance' depends on the multiplier, and the multiplier can only have 4 decimal places, and the multiplier depends on the rounded chance, so we have a circular dependency here. Changing the multiplier changes the chance, which gets rounded to 4 decimal places, which changes the chance, which changes the multiplier. But you're currently typing in the multiplier field, so it's really annoying if we edit it while you're typing it. A few sites do that, and it makes them really annoying to use.


If you hold shift and hit TAB twice after editing the 'payout' field, you'll see the payout field gets adjusted to reflect the new rounded chance field.


There's a limit on how finely the chance can be adjusted. We only have a million different possible rolls, and so we can't make a bet with a percentage chance of winning which has more than 4 decimal places. We could change the roll algorithm to roll 8 or 10 digit roll numbers, but then I'd have gamblers up in arms. "I was on a 200 roll losing streak and I'm sure I was about to win when you changed everything. You cheater!".


I think you need to pick either 0.0004% or 0.0005% and adjust your stake accordingly. 0.54903858 CLAM at 0.0004% or 0.68629892 CLAM at 0.0005% will hit the max profit right now. If you put 0.0004 in the 'chance to win' field and then click the 'max' bet button, it will fill in the 0.549... value for you. You may have to hit it again if the max profit drops before you get to submit your bet.

Maybe, but then how do you explain his public display of stupidity and rudeness?

These bets have a target of < 0.015:



but the rolls only have 2 decimal places...

Are you saying they added a decimal place to the target but not to the rolls themselves?

That's amazing!

< 0.015 is the same as < 0.02 when your rolls only have 2 decimal places.

So much fail in one place!

I checked your account. The bets you are making seem to be -EV. Are you sure you didn't just get lucky?

(payout * chance = 99.99; less than 100 means it's -EV)