|
I didn'#t hold any PURCHASE for transfers at midnight - looks like I did transfers out right before then, last one being:
2013-07-13 23:59:48 DMS.SELLING transfer-out
So I finished catching up 12 seconds before the dividend triggered.
|
|
|
|
|
Noone noticed it in advance = or even noticed it had happened, but today's dividend went out at midnight. Only just noticed myself. Looks like I failed to set the time and only set the date.
I'm not going to try to work out what was sold at midnight etc to provide accounts for that time - there'll be days when I won't be around to produce accounts anyway (it's only really important for days where SELLING dividend is due).
I'm going to check to see if I held any PURCHASE sent in fro transfer at midnight (in which case I'll manually send them the dividend they missed). Then I'll produce a shortened report showing no dividend but current value etc. That won't be until after the scheduled dividend time - as PURCHASE dividend was set for correct time so hasn't paid out yet.
The transfers for increased investments went through and have now been applied - so it'll show a higher JD balance and two Coinlenders CDs (I've added the dates at which they end into the spradsheet).
|
|
|
|
Deprived, how come BTC Balance (BTC-TC) went down to -(84+254) in just one day?
As stated earlier, he put more into investments No, those haven't gone out yet (EDIT: I did the withdrawals shortly after my post aboit it but burnside hasn't processed them yet). It's to do with the 320+ BTC dividend paid to SELLING yesterday lol. The dividends come from BTC balance - not out of thin air. |
|
|
|
One solution for this sort of problem is fully auditted code running on a server hosted by a third-party in a controlled and monitored environment
What third-party sets that up? Do you trust that they didn't install a back door? Who audits it? Do you trust them? You're still left trusting somebody not to cheat. Indeed - to do it securely would cost a load. You're having to look at a reputable large company hosting with live video feed of the hosting area, secured and logged access, insurance in place for security breeches etc. End result being greatly enhanced confidence for investors of fair-play (but not zero risk) with new CP for yourself at a massive cost and with serious delays any time an update is needed (delays both to get access and for changes to be audited). Auditing would have to be done live on-site by multiple independent parties etc. A whole lot of effort when there's zero reason for you to do it - but without the servers in a controlled environment there's essentially no way to do it. Which is why I think the idea is just a waste of time. |
|
|
|
So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.
You actually need a LOT more than that. Getting a provable source of entropy isn't actually the real difficult part. The hard part is means by which dooglus can use that source to process rolls AND can prove that the details of the bet weren't changed after he obtained the random number. What you seem to miss is that distinction - and it's massive. Here's the rough flow of what should happen : Player makes a bet Dooglus obtains verifiable random number Result of bet is calculated. How do you ensure that the right random number is applied to an unchanged bet? Without massively slowing down the system it's very hard to do. But if you can't guarantee that the bet processed is the one intended before the result was calculated then suddenly NOTHING is secure any more. Dooglus could cheat players by getting 10 random numbers then working out which combination of applying them to 10 pending bets gave the house the most. Or he could cheat investors by betting himself, working out the result then changing the bet size (or even odds) dependent on what the result was. We'd be worse off than we already are. Conceptually the solution is easy - bets are logged in public first then some combination of a hash of the bet details + a timestamp used to generate the seed for a random number. But putting that concept into practice is harder than it might sound - you have to deal with things like what if the external source becomes unavailable (do bets hang or are they cancelled? can he selectly choose not to receive results if he doesn't like them?). And you also then have to find a random source where it's verifiable which output is produced from which input - but where such results can't be obtained in advance (which means real-time sampling of entropy based on the time-stamp element). It's using a sledgehammer to crack a walnut. The solution already exists - if you don't believe he'll act in good faith then don't invest. Every investment without a fixed rate of return has the potential for the issuer to act in bad faith and cheat investors subtly. There's no reason why this one should be any different. I read your post a several times, and it seems you are talking about being provably fair for the bettors. And I have a certain understanding of that concept: apply a hash function on the server-side secret and send to the client, combine the server-side secret with some client-side input then process the bet according to commonly agreed rules. When the server-side secret is revealed, the client can verify that the rules were followed. I find that quite straight-forward. My problem is a slightly different one, since JD has three parties: player, investor and operator. The operator is in this case the site/dooglus and acts as a mediator between the bank (investors) and the player. The player gets to have "provably fair" gaming. But what would it take to give the investors the same "provably fair" investing? The operator, who knows the server-side secret, can pretend he is a player and make bets against the investors -- and win every time! How can that, theoretically, be prevented? And the most sensible answer so far is to link the outcome of the bet to the outcome of an unpredictable future event which is not known or knowable by any of the three parties involved. The more I think about it, linking the outcomes to future blocks in the bitcoin blockchain actually solves the problem -- but would simply be way too slow for the players! Edit: By the way, I'm not saying that I don't trust dooglus (because I believe dooglus is one of the most honorable members of the forum). I'm saying that *proof* is better than *trust*. I obviously didn't make myself clear as I WAS talking mainly about proving fairness to investors. It's all fine and well having a provable random string of numbers but you STILL have to somehow ensure dooglus applies them correctly. Otherwise he can just get the stream of numbers, see whether bets using them win and, if those bets win, make a big bet on an alt account. Just getting random numbers doesn't help unless how they're used is fully auditted - which puts us back to square one of trusting activity carried out on dooglus' server. One solution for this sort of problem is fully auditted code running on a server hosted by a third-party in a controlled and monitored environment (where server-side seeds would be generated from entropy and not revealed to ANYONE until after they'd expired). But there's a very significant cost to that sort of setup - and with it being a gambling site there's reasons why a formal, public, legally contracted system such as that may not be too attractive (as every aspect of the hosting has to be publicised to ensure the third-party really is a third-party). There's also a seperate very good reason why this sort of thing is unlikely to happen. Any solution is going to add cost and non-zero CP risk for dooglus - so there's no reason for him to even consider it unless he can't get however much investment he wants anyway. And looks like he CAN get the investment he needs - so run by me again why he should even consider it? |
|
|
|
So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.
You actually need a LOT more than that. Getting a provable source of entropy isn't actually the real difficult part. The hard part is means by which dooglus can use that source to process rolls AND can prove that the details of the bet weren't changed after he obtained the random number. What you seem to miss is that distinction - and it's massive. Here's the rough flow of what should happen : Player makes a bet Dooglus obtains verifiable random number Result of bet is calculated. How do you ensure that the right random number is applied to an unchanged bet? Without massively slowing down the system it's very hard to do. But if you can't guarantee that the bet processed is the one intended before the result was calculated then suddenly NOTHING is secure any more. Dooglus could cheat players by getting 10 random numbers then working out which combination of applying them to 10 pending bets gave the house the most. Or he could cheat investors by betting himself, working out the result then changing the bet size (or even odds) dependent on what the result was. We'd be worse off than we already are. Conceptually the solution is easy - bets are logged in public first then some combination of a hash of the bet details + a timestamp used to generate the seed for a random number. But putting that concept into practice is harder than it might sound - you have to deal with things like what if the external source becomes unavailable (do bets hang or are they cancelled? can he selectly choose not to receive results if he doesn't like them?). And you also then have to find a random source where it's verifiable which output is produced from which input - but where such results can't be obtained in advance (which means real-time sampling of entropy based on the time-stamp element). It's using a sledgehammer to crack a walnut. The solution already exists - if you don't believe he'll act in good faith then don't invest. Every investment without a fixed rate of return has the potential for the issuer to act in bad faith and cheat investors subtly. There's no reason why this one should be any different. |
|
|
|
Deprived,
They would not know the server seed, so that would not be a vulnerability. There would be the client seed, server seed and then the server seed would be hashed using a random number generated by random.org. This would make the game provably fair to investors. There are many proven true random # generator sites out there besides random.org also
It wouldn't change anything. Dooglus could just request a random number from random.org then change his bet size once he calculated what the result was. And that's IF there was some way of proving which random number was used for which bet. It adds complexity but no solution. EDIT: If your concern is trusting dooglus then you can't trust ANY server logs or similar he has access to. That's what makes the problem (if it is one) very hard to solve. |
|
|
|
All I am concerned about is security as I do not understand technology that well so I cannot be sure all the bets are played with the intended rules. I understand EV and variance. If there are no signs of foul play, nothing could have been better for us - investors - than what just happened today. (less competition, more bets)
Yeah it's unfortunate short-term but great advertising for the site longer term. There's no signs of foul play. I watched it for a bit before doing our daily report. Another whale had gone up a lot then lost it all back with interest (think he was up best part of 1k at one point before losing it all). Then the 2nd one showed up and profit was up and down like mad. I left J-D before making our report - and of course that's when he finally had a decent length winning streak and won his money. It was just the standard thing of people believing that by varying bet sizes and looking for patterns in rolls they can beat a house edge. And when someone does win - and it reinforces their belief - that's great for the house as they'll tell everyone else about it. I view the losses today as pretty cheap advertising. |
|
|
|
Why don't you just use as a salt for each roll a random # generated by http://www.random.org/ or another true random generator site (this one uses atmospheric noise I believe)? Wouldn't that close any loophole for the operator or someone who has compromised the site and can see the server seeds to cheat? I'm not familiar with everything random.org has to offer. But is it probably fair? Is there any way I can prove to the player that the seed that made them lose was fairly chosen by random.org, and not carefully calculated by JD to make them lose? It wouldn't change anything unless random.org were told the bet in advance, recorded it and disclosed it - as otherwise you could change what you bet once you knew the result from them. And if they recorded the bet BEFORE revealing the random number then suddenly we have to start trusting that THEY aren't betting and exploiting it. Beyond a certain point investors just have to trust - not just in this but in many investments. How do investors know mining companies who have a machine break down didn't swap a good one for a bust one of their own? How do investors know an investment/trading funs isn't creaming off cash by buying/selling from alt accounts? etc. At a certain stage people have to stop worrying about things that are only detectable from statistical analysis after the fact. Short of having a 24/7 live video feed it's hard to stop or detect a lot of types of fraud. You have to either be willing to assume some degree of good faith or just not invest. |
|
|
|
Thanks - that's all I needed to know. I knew you had funds of his on deposit - just didn't know if you blocked inputs.io deposits that would take exposure above that.
To be clear, I don't block or return deposits over the 500 BTC. I just don't credit them to user accounts until I've withdrawn the funds from inputs.io into my real wallet. Same effect - and the effect is all I was concerned about. |
|
|
|
Deprived, are you sure the Just-Dice site is secure and the bets were just lucky? If you are, I will be putting all my available money in there as it really is starting to look interesting there... (what was 10% loss a day for me will be 3% gain a day in the long run if the bets continue)
I can't be absolutely certain - but with the bets that were made today the resulting loss is an entirely reasonable outcome and there's no reason at all to suspect foul play. The guy who one made claims about having found a loophole - but from his semi-explanation it's just him not understanding math properly, getting lucky and believing that confirms his theory. That's why I'm still sending more of DMS' funds there - and also moving some of my own in there. With +EV things like being the house I'm NEVER that fussed about actual results - jus about the EV and the degree of variance expected. The level of variance at JD is higher than would be ideal - but that's pretty inevitable when results will be determined by a handful of whales, with the steady profit from the smaller fish just background noise. |
|
|
|
I notice people can deposit with inputs.io. Are those of us who don't use online wallets taking on any exposure from that?
I have over 500 BTC of TF's on hold. I only accept deposits up to that 500 BTC threshold. If inputs.io disappears with JD funds, we take the funds from TF's balance. He's agreed to this to limit JD's CP risk. * it was over 500 BTC before this morning's losses. It's probably still over 500 BTC now. Thanks - that's all I needed to know. I knew you had funds of his on deposit - just didn't know if you blocked inputs.io deposits that would take exposure above that. |
|
|
|
This will be a major flop. The IPO issuer is not willing to clarify squat!
In fairness, if I was trying to sell 2 BFL preorders + a few GPUs for $60k I wouldn't be too keen on clarifying either. Which is what we have to assume to be the case given the total lack of clarity on the very key point of whether the funds raised by IPO go into the fund or into the issuer's pocket. I had a conversation with PHM before this announcement. It looks like some of the details discussed were not included in the final version here. While I cannot speak for PHM, it was my understanding that the funds for the IPO will be owned by the shareholders under PHM, but that the current market value of the BFL orders and the GPUs will be deducted in order for the fund to buy the equipment and own it. He quoted the BFL value as what they paid for them in cash, but we did not discuss how they would determine the value of the GPUs. PHM, please update the details to clarify that the fund owns money raised via the sale of shares, and what exact cost will be deducted to purchased the existing equipment/orders. That changes the whole complexion of things obviously - it's rather important information to have forgotten to include. It's actually one of the worst errors made commonly on IPOs here - not identifying current assets and obligations. Anf of course there's a big difference between buying the BFLs for what they cost in BTC (ridiculous) and buying them for what they cost in USD (reasonable). |
|
|
|
|
Question for dooglus about CP exposure.
I notice people can deposit with inputs.io. Are those of us who don't use online wallets taking on any exposure from that?
i.e. if someone deposited 50k via inputs.io then TF vanished would those of us who didn't use inputs.io bear any risk? Or do you have something in place that withdraws payments made via inputs.io before they're allowed to be used on the site? Or maybe some block that prevents larger deposits from there than he has on deposit with J-D (though then it would be messy if the house lost).
I don't ask this because I distrust TF - I have 200 BTC on deposit with him and another 100 BTC going there later. But at same time I have to be careful in controlling my CP risk - and if investment at J-D has CP risk with TF then I have to add it to Coinlenders deposits when evaluating my total exposure to him. That's especially the case when it's investors' funds I'm deploying not my own.
|
|
|
|
...and now look at J-D balance again...  Yeah our J-D balance is now slightly below what we originally invested - a whale got lucky and won best part of 3K BTC. J-D is high theoretical return but high variance too - fine for 10% of our BR but it can't be increased too far or we'd risk losing funds that could be owed to MINING (if diffiuclty rises slow down then I'd have to consider reducing it further). Have just done LTC-ATF.B1 dividends - after conversion back to BTC DMS got 0.75762183 BTC. Also sold a few hundred more of them earlier - this time at 20% above face value. Am regretting let DMS have my personal LTC-ATF.B1 at face value now  Am sending 60 more BTC to J-D (takes it to a bit over 8% of capital) and also buying another 100 BTC Coinlenders bond (takes it to about 18% of capital). That's assuming I can figure out how to use the annoying inputs.io thing that we have to deposit via now (I never intentionally use any sort of online wallet that pays no interest - CP risk without benefit isn't my thing and saving 1 hour on transfers isn't enough to justify the risk to me). |
|
|
|
This will be a major flop. The IPO issuer is not willing to clarify squat!
In fairness, if I was trying to sell 2 BFL preorders + a few GPUs for $60k I wouldn't be too keen on clarifying either. Which is what we have to assume to be the case given the total lack of clarity on the very key point of whether the funds raised by IPO go into the fund or into the issuer's pocket. |
|
|
|
Can the Havelock admins look at lowering the maximum allocation of shares per user for this one?
Why? You think there's more than 3 people who will buy it if the operator doesn't clarify things? |
|
|
|
02:41:14 (2548) <nakowa> don't challenge me, I'm not a gambler, I'm just an amateur mathematician.
02:43:21 (2548) <nakowa> I'm tired. if you really want to watch, wait till tomorrow. I'll start from a very small amount of BTC.
02:44:22 (2548) <nakowa> I'd like dooglus fix the game.
02:44:51 (2548) <nakowa> I'll tell him what to fix.
02:44:57 (2548) <nakowa> not here.
02:44:58 (1) <dooglus> I'm busy making a withdrawal from the cold wallet for nakowa
02:45:09 (1) <dooglus> if anyone's talking to me here, sorry I missed it
Likely or unlikely, I wouldn't have said anything but for nakowa's comments.
If nakowa found a statistical anomaly why did you process the withdrawl? And if he didn't, can you tell us what he said?
It isn't a statistical anomaly. He has a huge bankroll and thinks that the range from min bet to max bet is too high and allows players to successfully martingale if they have a big enough bankroll. What do you think about that? Martingale is a losing strategy, no matter what your limits, in my opinion. Yep, you can't remove the house edge with strategy. What you CAN do is devise a betting strategy that with 90% certainty will win you X BTC - but you have to be willing to risk more than 9X BTC. And you can achieve the same results with a single bet that's a 90% win anyway. Players with large bankrolls add a ton of variance - totally drowning out all the smaller bets' impact - but they don't change the EV. Gambling (vs the house) is only so profitable (for operators) because of everyone who thinks they have a system - there's no need to change anything when (as will happen from time to time) one of them wins. You could lower the variance - by massively dropping the max bet - but why? Investors just need to accept that backing the house s very +EV but also has massive variance. The large variance DOES exist largely as a result of the wide range between min and max bets - but raising the min would make it worse and lowering the max would lose volume. One possible solution is to go the route of allowing investors to choose their exposure level (from, say 0.1% to 10%) with action over the minimum being given only to those accepting that level of risk. That would allow those who want a much smaller but more reliable profit to choose 0.1%, those who want roughly what happens at present to take 1% and those who essentially want to gamble to take 10%. I think the complexity it adds doesn't warrant it - but others may have a different view. Investors need to realise that the same variance which allowed the house to lose this cash also allowed it to rapidly get to double expected edge before. You can't have fast gains from losing big bets without allowing fast losses from winning ones. |
|
|
|
|
Sold 6308
Swapped 0
Total 6308
Price 0.040366
Total 254.628728
Less Fee 254.1194705
Man Fee 7.623584116
BTC Balance (BTC-TC) 1411.442945
12380 LTC-ATF.B1 123.80000000
Coinlenders CD 201.88925251
Just-Dice Balance 107.63591754
TOTAL ASSETS 1,844.76811521
Outstanding MINING 47031
Outstanding SELLING 47031
Outstanding PURCHASE 854
Effective Units 47885
Block reward 25
Difficulty 26,162,876
Hashes per MINING 5000000
Daily Dividend 0.00009611
50 days (Min Liquid) 0.00480554
100 days (Forced Close) 0.00961107
365 days (Buyback) 0.03508041
405 days (IPO) 0.03892484
400 days (Post SELLING div) 0.03844428
410 days (Pre SELLING div) 0.03940539
NAV Post MINING Div 1,840.16585387
NAV/U Post MINING Div 0.03842886
Days Dividend Post Div 399.84
SELLING Dividend -
NAV Post SELLING Div 1,840.16585387
NAV/U Post Selling Div 0.03842886
PURCHASE selling price 0.04035030
PURCHASE buy-back price 0.03766028
J-D balance is down a bit - in fact it's moving around a lot right now as there's been 2 gamblers making large bets : have seen it as low as 105 and as high as 110 in last few hours. The high volume of PURCHASE sales more than made up for that - meaning most of today's MINING dividend was covered (days dividend only dropped to 399.84 rather than to 399_. We also sold some more LTC-ATF.B1 off at ~15% markup to face.
Got to go out for a few hours shortly. When I get back I'll look at increasing our J-D investment (keeping it below 10%) and a 2nd Coinlenders CD (keeping it below 20%).
|
|
|
|
I talked to them and the BFL orders are actually from April, I think they may have messed up the wording on that...
So are those added to the fund for free - or is some portion of the funds raised from IPO being taken in return for them? If so, how much? |
|
|
|
|
Show Posts
