Search content
Sort by
Showing 20 of 46 results by jlcooke
Investors breakdown spreadsheets. Also includes charts on supplementary tabs (x-y scatter and pie chart)
https://docs.google.com/spreadsheet/ccc?key=0AipZG8vQw9AXdFdzZzVsc1BVSlQydWRhYnhDSllfbmc
I find it interesting how there are over 700 investors, but over 50% of the bankroll is held by 7 investors. And 75% of the bankroll is from 38 investors. 90% from 103 investors.
Feel free to suggest improvements.
https://docs.google.com/spreadsheet/ccc?key=0AipZG8vQw9AXdFdzZzVsc1BVSlQydWRhYnhDSllfbmc
I find it interesting how there are over 700 investors, but over 50% of the bankroll is held by 7 investors. And 75% of the bankroll is from 38 investors. 90% from 103 investors.
Feel free to suggest improvements.
Fun feature suggestion:
Google Auth Poker (was RSA SecurID Poker)
I do this for fun at work. We all decide that on the next 6-digit code update we'd each try to form our best 5-card hand.
Eg:
Alice: 123456 (Straight to the 6)
Bob: 111333 (Full House - 3 full of 1s)
Charlie: 121434 (2 pair - 4s and 1s)
So, Alice would win.
just-dice having given out so many Google Auth codes could have a 1% fee to the house for any players (up to 8 ) wanting to play.
Thoughts?
Google Auth Poker (was RSA SecurID Poker)
I do this for fun at work. We all decide that on the next 6-digit code update we'd each try to form our best 5-card hand.
Eg:
Alice: 123456 (Straight to the 6)
Bob: 111333 (Full House - 3 full of 1s)
Charlie: 121434 (2 pair - 4s and 1s)
So, Alice would win.
just-dice having given out so many Google Auth codes could have a 1% fee to the house for any players (up to 8 ) wanting to play.
Thoughts?
Re: Just-Dice.com : Play or Invest : 1% House Edge : Banter++
For those who missed it:
https://bitcointalk.org/index.php?topic=242962.msg3336468#msg3336468
nobody came down on SDice, although they stopped US players playing.
I assume that if JD wanted to cover their ass more fully, it could have a dialog box that pops up when you first visit the page asking people to pick their country from a long list, and if they pick US, then it doesn't let them play. IANAL but this should be sufficient to plead in court that you are not letting US players play on a 'best efforts' basis. It's what many other sites do.
Will
https://bitcointalk.org/index.php?topic=242962.msg3336468#msg3336468
Is anyone worried about gambling regulators coming down on JD?
Ireland and Canada and the US, UK are very serious about this sort of thing.
Bitcoins, Dollars or cans of beans - gambling among people in their jurisdictions is what they'll come down on.
Thoughts?
Ireland and Canada and the US, UK are very serious about this sort of thing.
Bitcoins, Dollars or cans of beans - gambling among people in their jurisdictions is what they'll come down on.
Thoughts?
nobody came down on SDice, although they stopped US players playing.
I assume that if JD wanted to cover their ass more fully, it could have a dialog box that pops up when you first visit the page asking people to pick their country from a long list, and if they pick US, then it doesn't let them play. IANAL but this should be sufficient to plead in court that you are not letting US players play on a 'best efforts' basis. It's what many other sites do.
Will
Re: Just-Dice.com : Play or Invest : 1% House Edge : Banter++
Is anyone worried about gambling regulators coming down on JD?
Ireland and Canada and the US, UK are very serious about this sort of thing.
Bitcoins, Dollars or cans of beans - gambling among people in their jurisdictions is what they'll come down on.
Thoughts?
Ireland and Canada and the US, UK are very serious about this sort of thing.
Bitcoins, Dollars or cans of beans - gambling among people in their jurisdictions is what they'll come down on.
Thoughts?
Quote
Doog proposed a solution: make max bet a market. You choose what your tolerance is and the site will adjust. Mech could have set his to 0.25%, I would have kept it at 1%, every investor votes with their wallet. From there you get the max bet and the proportion to be paid out to each investor.
No controversy, no arbitrarily choosing numbers. House edge can remain fixed so that from the player's point of view, nothing changes or is unfair.
No controversy, no arbitrarily choosing numbers. House edge can remain fixed so that from the player's point of view, nothing changes or is unfair.
The more I think about this, the more I like it. This is doable.
It would be cool. Big work for Doog however.
Only way for the house to limit min/max spreads is to put each user in a "time out" in whatever min/max bracket they're in. But then they'd just open a 2nd account and both each bracket with a different bot.
min/max spreads is the reason physical casinos don't get hammered like this. It's also because they can keep track of physical humans.
Let's consider nakawa has some information on a weakness of SHA-512.
http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
⊕ is exclusive-or
PHP Code to compute the lucky number:
The SHA-512 compression function uses 80 x 64-bit words (5120 bits) plus the 8 x 64-bit (512 bits) state words to output 8 x 64bit (512 bits).
That means the final outer hash of the HMAC-512 bits
- size of server seed (K here) is 64 characters [0-9A-Za-z\._] (512 bits, 384 bits maximum entropy)
- client seed is usually 24 characters (192 bits) (is there a minimum? maximum?)
- nonce can be 1,2,3,4,etc charactors. Lets assume 1..4 (32bits) based on nakowa's pattern of behaviour.
That means:
If there was an attack via the SHA-512 compression function, it would be by exploiting the fact that bits 1024...1215 (bytes 128...151) are totally under client control and bits 1216...1247 (bytes 152...155) are totally predictable (sequential).
So let's look and see if nakowa's bets vary based on the bits of his nonce (it's been shown he hardly ever changes his client seed, so let's focus on the nonce).
PHP code for others to take and improve:
if (!function_exists("stats_standard_deviation")) {
print "need to install stats package\n".
"pecl install stats\n".
"echo extension=stats.so > /etc/php.d/stats.ini\n";
exit;
}
// Source data
// https://just-dice.com/nakowa.txt.bz2
// https://just-dice.com/nakowa2.txt.bz2
$fh = fopen("nakowa.txt","rb");
if (!$fh) {
exit;
}
# remove headers
$line=fgets($fh); $line=fgets($fh); $line=fgets($fh);
# init our counts
$sum = 0;
$gray_bets = array();
resetGrayBets($gray_bets);
// reset sums
function resetGrayBets(&$gray_bets) {
$bits = 12;
// 1 bit
for ($i=0; $i<$bits; $i++)
$gray_bets[1 << $i] = array();
// 2 bits
for ($i=0; $i<$bits; $i++)
for ($j=$i+1; $j<$bits; $j++)
$gray_bets[(1 << $i) | (1 << $j)] = array();
// 3 bits
for ($i=0; $i<$bits; $i++)
for ($j=$i+1; $j<$bits; $j++)
for ($k=$j+1; $k<$bits; $k++)
$gray_bets[(1 << $i) | (1 << $j) | (1 << $k)] = array();
// 4 bits
for ($i=0; $i<$bits; $i++)
for ($j=$i+1; $j<$bits; $j++)
for ($k=$j+1; $k<$bits; $k++)
for ($l=$k+1; $k<$bits; $k++)
$gray_bets[(1 << $i) | (1 << $j) | (1 << $k) | (1 << $l)] = array();
# ksort($gray_bets);
}
// display sums
function dumpGraySums($gray_bets) {
$report = array();
foreach ($gray_bets as $i=>$arr) {
$ibin = substr("00000000000000000". decbin($i), -16);
if (count($arr) == 0)
continue;
$sum = $mean = $stdev = 0;
if (count($arr) != 0) {
$sum = array_sum($arr);
$mean = $sum / count($arr);
$min = min($arr);
$max = max($arr);
$stdev = stats_standard_deviation($arr);
}
$report[] = array(
'i' => $i,
'ibin' => $ibin,
'sum' => $sum,
'count' => count($arr),
'mean' => $mean,
'min' => $min,
'max' => $max,
'stdev' => $stdev,
);
}
usort($report, function($a,$b){
return $b['mean'] - $a['mean'];
# return $b['stdev'] - $a['stdev'];
});
foreach ($report as $i=>$info) {
$info['sum'] = sprintf("%4.3u", $info['sum']);
$info['count'] = sprintf("%4.3u", $info['count']);
$info['min'] = number_format($info['min'], 3);
$info['mean'] = number_format($info['mean'], 3);
$info['max'] = number_format($info['max'], 3);
$info['stdev'] = number_format($info['stdev'], 3);
print " {$info['ibin']}: sum={$info['sum']}, count={$info['count']}, min/mean/max={$info['min']}/{$info['mean']}/{$info['max']}, stdev={$info['stdev']})\n";
}
}
$last_nonce = -1;
while (($line=fgets($fh)) !== false) {
list($uid,$bid,$nonce,$bet,$chance,$profit) = preg_split('/\t/', $line);
// cast to int
$uid = (int)$uid;
$bid = (int)$bid;
$nonce = (int)$nonce;
$bet = (int)$bet;
$change = (int)$change;
$profit = (int)$profit;
if ($last_nonce == -1)
$last_nonce = $nonce;
if ($bet == 0)
continue;
// values in BTC
$bet /= 100000000;
$profit /= 100000000;
$nonce_bin = substr("00000000000000000". decbin($nonce), -16);
# if ($bet >= 10)
print "$uid\t$bid\t$nonce\t$nonce_bin\t{$bet}BTC\t$chance\t{$profit}BTC\n";
$sum += $profit;
foreach ($gray_bets as $code=>$ignore) {
# edit-1 start
if ($nonce < 0x0000100) $nonce_bytes = $nonce << 24;
else if ($nonce < 0x0010000) $nonce_bytes = $nonce << 16;
else if ($nonce < 0x1000000) $nonce_bytes = $nonce << 8;
else $nonce_bytes = $nonce;
if (($nonce_bytes & $code) == $code) {
#edit-1 end
$gray_bets[$code][] = $bet;
}
}
if ($nonce < $last_nonce) {
print "sum = $sum\n";
dumpGraySums($gray_bets);
$sum = 0;
resetGrayBets($gray_bets);
}
$last_nonce = $nonce;
}
dumpGraySums($gray_bets);
Running this against nakowa.txt from just-dice.com there is no discernible favouring of certain bits over others.
So if there is some evil crypto genious behind nakowa's streak, this isn't the angle.
Edit: updated PHP code - bug.
http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
Code:
HMAC-SHA512(K,m) = SHA512((K ⊕ opad) + SHA512((K ⊕ ipad) + m))
+ is concatenation⊕ is exclusive-or
PHP Code to compute the lucky number:
Code:
function getLuckyNumber($server, $client, $nonce) {
$str = hash_hmac("sha512", "$client:$nonce", $server);
for ($i=0; $i $hex = substr($str, $i, 5);
$dec = hexdec($hex);
if ($dec < 1000000)
return $dec / 10000;
}
}
$str = hash_hmac("sha512", "$client:$nonce", $server);
for ($i=0; $i $hex = substr($str, $i, 5);
$dec = hexdec($hex);
if ($dec < 1000000)
return $dec / 10000;
}
}
The SHA-512 compression function uses 80 x 64-bit words (5120 bits) plus the 8 x 64-bit (512 bits) state words to output 8 x 64bit (512 bits).
That means the final outer hash of the HMAC-512 bits
- size of server seed (K here) is 64 characters [0-9A-Za-z\._] (512 bits, 384 bits maximum entropy)
- client seed is usually 24 characters (192 bits) (is there a minimum? maximum?)
- nonce can be 1,2,3,4,etc charactors. Lets assume 1..4 (32bits) based on nakowa's pattern of behaviour.
That means:
Code:
HMAC-SHA512(K,m) = SHA512( <512 bits> + <512 bits> + <192 bits> + ':' + <32 bits> )
If there was an attack via the SHA-512 compression function, it would be by exploiting the fact that bits 1024...1215 (bytes 128...151) are totally under client control and bits 1216...1247 (bytes 152...155) are totally predictable (sequential).
So let's look and see if nakowa's bets vary based on the bits of his nonce (it's been shown he hardly ever changes his client seed, so let's focus on the nonce).
PHP code for others to take and improve:
Code:
if (!function_exists("stats_standard_deviation")) {
print "need to install stats package\n".
"pecl install stats\n".
"echo extension=stats.so > /etc/php.d/stats.ini\n";
exit;
}
// Source data
// https://just-dice.com/nakowa.txt.bz2
// https://just-dice.com/nakowa2.txt.bz2
$fh = fopen("nakowa.txt","rb");
if (!$fh) {
exit;
}
# remove headers
$line=fgets($fh); $line=fgets($fh); $line=fgets($fh);
# init our counts
$sum = 0;
$gray_bets = array();
resetGrayBets($gray_bets);
// reset sums
function resetGrayBets(&$gray_bets) {
$bits = 12;
// 1 bit
for ($i=0; $i<$bits; $i++)
$gray_bets[1 << $i] = array();
// 2 bits
for ($i=0; $i<$bits; $i++)
for ($j=$i+1; $j<$bits; $j++)
$gray_bets[(1 << $i) | (1 << $j)] = array();
// 3 bits
for ($i=0; $i<$bits; $i++)
for ($j=$i+1; $j<$bits; $j++)
for ($k=$j+1; $k<$bits; $k++)
$gray_bets[(1 << $i) | (1 << $j) | (1 << $k)] = array();
// 4 bits
for ($i=0; $i<$bits; $i++)
for ($j=$i+1; $j<$bits; $j++)
for ($k=$j+1; $k<$bits; $k++)
for ($l=$k+1; $k<$bits; $k++)
$gray_bets[(1 << $i) | (1 << $j) | (1 << $k) | (1 << $l)] = array();
# ksort($gray_bets);
}
// display sums
function dumpGraySums($gray_bets) {
$report = array();
foreach ($gray_bets as $i=>$arr) {
$ibin = substr("00000000000000000". decbin($i), -16);
if (count($arr) == 0)
continue;
$sum = $mean = $stdev = 0;
if (count($arr) != 0) {
$sum = array_sum($arr);
$mean = $sum / count($arr);
$min = min($arr);
$max = max($arr);
$stdev = stats_standard_deviation($arr);
}
$report[] = array(
'i' => $i,
'ibin' => $ibin,
'sum' => $sum,
'count' => count($arr),
'mean' => $mean,
'min' => $min,
'max' => $max,
'stdev' => $stdev,
);
}
usort($report, function($a,$b){
return $b['mean'] - $a['mean'];
# return $b['stdev'] - $a['stdev'];
});
foreach ($report as $i=>$info) {
$info['sum'] = sprintf("%4.3u", $info['sum']);
$info['count'] = sprintf("%4.3u", $info['count']);
$info['min'] = number_format($info['min'], 3);
$info['mean'] = number_format($info['mean'], 3);
$info['max'] = number_format($info['max'], 3);
$info['stdev'] = number_format($info['stdev'], 3);
print " {$info['ibin']}: sum={$info['sum']}, count={$info['count']}, min/mean/max={$info['min']}/{$info['mean']}/{$info['max']}, stdev={$info['stdev']})\n";
}
}
$last_nonce = -1;
while (($line=fgets($fh)) !== false) {
list($uid,$bid,$nonce,$bet,$chance,$profit) = preg_split('/\t/', $line);
// cast to int
$uid = (int)$uid;
$bid = (int)$bid;
$nonce = (int)$nonce;
$bet = (int)$bet;
$change = (int)$change;
$profit = (int)$profit;
if ($last_nonce == -1)
$last_nonce = $nonce;
if ($bet == 0)
continue;
// values in BTC
$bet /= 100000000;
$profit /= 100000000;
$nonce_bin = substr("00000000000000000". decbin($nonce), -16);
# if ($bet >= 10)
print "$uid\t$bid\t$nonce\t$nonce_bin\t{$bet}BTC\t$chance\t{$profit}BTC\n";
$sum += $profit;
foreach ($gray_bets as $code=>$ignore) {
# edit-1 start
if ($nonce < 0x0000100) $nonce_bytes = $nonce << 24;
else if ($nonce < 0x0010000) $nonce_bytes = $nonce << 16;
else if ($nonce < 0x1000000) $nonce_bytes = $nonce << 8;
else $nonce_bytes = $nonce;
if (($nonce_bytes & $code) == $code) {
#edit-1 end
$gray_bets[$code][] = $bet;
}
}
if ($nonce < $last_nonce) {
print "sum = $sum\n";
dumpGraySums($gray_bets);
$sum = 0;
resetGrayBets($gray_bets);
}
$last_nonce = $nonce;
}
dumpGraySums($gray_bets);
Running this against nakowa.txt from just-dice.com there is no discernible favouring of certain bits over others.
So if there is some evil crypto genious behind nakowa's streak, this isn't the angle.
Edit: updated PHP code - bug.
One of the many fallacies with Martingale is that bettors think extended losing streaks are rare when, in fact, they are an exceedingly common - and statistically probable - outcome in any long sequence of bets
Perhaps a bit OT (frankly, moving OT sounds a great idea at this point).
Question: is there a way to view my investment balance over time as a chart? The past 30 days would be great to illustrate my question.
The past few weeks I saw my investment profits in JD go from 0.80 BTC Mondays up to 1.08 BTC Sundays only to see it go back down to 0.78 BTC the next Monday morning (Eastern Time zone).
Understanding that 10% of profits I make in a given week I wonder if others are seeing this would like to comment on why this is happening?
10% of (1.08-0.80) = 0.028
So Monday I should see my profit stand at 1.062 BTC but it's currently at about 0.78 BTC.
Volatility I understand, even this behaviour is statistically possible (lots of players losing Sundays but then they go on a winning streak last-Sunday to early-Monday). But this seems like a very low probability to occurr 3 weeks in a row.
Code:
2013-09-07 15655.98310993
2013-09-08 5150.63159109
2013-09-09 1663.19716859
2013-09-10 2809.54404842
2013-09-11 3895.55491310
2013-09-12 3776.94898158
2013-09-13 3569.81366765
2013-09-14 4849.77142126
2013-09-15 4188.36475008
2013-09-08 5150.63159109
2013-09-09 1663.19716859
2013-09-10 2809.54404842
2013-09-11 3895.55491310
2013-09-12 3776.94898158
2013-09-13 3569.81366765
2013-09-14 4849.77142126
2013-09-15 4188.36475008
Code:
biggest cumulative gains in last 24 hours
+--------+--------------+
| uid | profit |
+--------+--------------+
| 127021 | 221.02813105 |
| 13839 | 27.23663092 |
| 12433 | 16.019802 |
| 124162 | 13.8435 |
| 88818 | 8.2501 |
| 9780 | 5.73832733 |
| 129398 | 5.09825233 |
| 114382 | 4.256836 |
| 128071 | 3.71 |
| 125863 | 3.07536812 |
+--------+--------------+
biggest cumulative losses in last 24 hours
+--------+---------------+
| uid | profit |
+--------+---------------+
| 128039 | -119.95574434 |
| 23069 | -22.47396041 |
| 55555 | -19.08584 |
| 78612 | -7.4543464 |
| 128872 | -7 |
| 129734 | -6.76 |
| 110477 | -6.0217465 |
| 113327 | -4.7746 |
| 76634 | -4.4653 |
| 123187 | -4.337 |
+--------+---------------+
biggest cumulative amount wagered in last 24 hours
+--------+---------------+
| uid | wagered |
+--------+---------------+
| 127021 | 5266.83490895 |
| 128039 | 903.97145621 |
| 13839 | 597.19132332 |
| 23069 | 465.92495 |
| 9780 | 356.15823636 |
| 128119 | 273.19112971 |
| 129398 | 166.05712256 |
| 124162 | 127.9935 |
| 129734 | 100.38998501 |
| 125863 | 94.32733625 |
+--------+---------------+
+--------+--------------+
| uid | profit |
+--------+--------------+
| 127021 | 221.02813105 |
| 13839 | 27.23663092 |
| 12433 | 16.019802 |
| 124162 | 13.8435 |
| 88818 | 8.2501 |
| 9780 | 5.73832733 |
| 129398 | 5.09825233 |
| 114382 | 4.256836 |
| 128071 | 3.71 |
| 125863 | 3.07536812 |
+--------+--------------+
biggest cumulative losses in last 24 hours
+--------+---------------+
| uid | profit |
+--------+---------------+
| 128039 | -119.95574434 |
| 23069 | -22.47396041 |
| 55555 | -19.08584 |
| 78612 | -7.4543464 |
| 128872 | -7 |
| 129734 | -6.76 |
| 110477 | -6.0217465 |
| 113327 | -4.7746 |
| 76634 | -4.4653 |
| 123187 | -4.337 |
+--------+---------------+
biggest cumulative amount wagered in last 24 hours
+--------+---------------+
| uid | wagered |
+--------+---------------+
| 127021 | 5266.83490895 |
| 128039 | 903.97145621 |
| 13839 | 597.19132332 |
| 23069 | 465.92495 |
| 9780 | 356.15823636 |
| 128119 | 273.19112971 |
| 129398 | 166.05712256 |
| 124162 | 127.9935 |
| 129734 | 100.38998501 |
| 125863 | 94.32733625 |
+--------+---------------+
Anybody know how to edit this script so it doesn't send so many bets after betting?
I guess the thing to do would be to have it do an on('result') to wait for the result of a bet before sending the next bet.
As an investor in just-dice I'd like to thank all who wrote this and use it regularly.
exploring which input bits effect which output bits (1, 2 or 3 at a time) might be interesting
I don't expect SHA2 to be broken by the ways discussed in this thread, but it's a good thing that someone tries it. A good result from such approach would be not analytical solution (seems impossible, but there always is a hope that equations system will collapse 
), but representation of double SHA2 better (by operations count or height) that ones currently used in ASICs. I think I know how to chop 10% (or so) off from ~120000 binary operations, but let's hope that this thread will bring some fresh ideas logred_v8.zip ready - faster computation of !a which is the most expensive operation.
ri seems to have almost exactly 2i-1 terms. So the last bit r31 will have 230 terms. I've confirmed this with ri i=0..12 and it's bang on. The Quine-McClumskey reduction sure does a number on the complexity but it's not enough.
botnet - to take this further, you need to demonstrate that one of the input bits of the sha256 compression function does not pass through the Least Significant Bit inputs of the adds.
Or show one of the compression function output bits do not depend on the Most Significant Bit outputs of the 32bit adds.
Or that chained 32-bit adds have some reductions.
Cheers
But I still think you haven't quite grasped the magnitude of the P/NP problem yet! Then again, if the impossible ever gets done, it'll be as always, by someone who didn't know it was impossible.
Also botnet - If you've got the crypto-bug - exploring which input bits effect which output bits (1, 2 or 3 at a time) might be interesting. This kind of differential analysis is what took down MD5 and cost me $10,000 (http://en.wikipedia.org/wiki/MD5CRK)
Eg:
Code:
SHA256(000000...0000) = A
SHA256(000000...0001) = B
SHA256(000000...0011) = C
SHA256(000000...0010) = D
SHA256(000000...0110) = E
SHA256(000000...0111) = F
SHA256(000000...0101) = G
...
SHA256(000000...0001) = B
SHA256(000000...0011) = C
SHA256(000000...0010) = D
SHA256(000000...0110) = E
SHA256(000000...0111) = F
SHA256(000000...0101) = G
...
then
Code:
A^B = ?
A^C = ?
A^D = ?
...
B^C = ?
B^D = ?
...
A^C = ?
A^D = ?
...
B^C = ?
B^D = ?
...
Note: working on Quine-McClusky now. Always wanted a high speed lib for logic reductions ...
Always wanted a high speed lib for logic reductions ...Alright, got Quine-McCluskey implemented. Also implements logred_set_equiv(a,b) which goes through all possible input permutations and confirms "a" behaves the same as "b".
Q-McC is an expensive operation (Q-McC on r05 takes a full second when compiled with -s -O6), so I have not included it in logred_set_reduce().
It reduces r05 (the 6th bit in 32bit addition) from
Code:
r05 (terms= 1120, symbols= 8842, uniqueSymbols=12)
toCode:
r05 (terms= 156, symbols= 1080, uniqueSymbols=12)
It has no effect on c00,c01,..ci
Still don't think you'll find what you're looking for. But have fun!
logred_v7.zip
Note: working on Quine-McClusky now. Always wanted a high speed lib for logic reductions ...
Nope. A or A == A. A or !A == 1 and A!A = 0
a = "a00"
b = "!a00"
c = "a00" ^ "!a00"
= a00!(!a00) + !(a00)!a00
= a00 + !a00
= 1
Yup, it crashes. Comments out "logred_set_reduce_4_A_nAB_n(src)" in "logred_set_reduce()" to fix this.
It doesn't resolve down to "1" yet. soon.
Version I'm working on doesn't crash on this.
Humm, good point. Will not be ready for this release. Soon.
The code should be x32/x64 agnostic. logred_v6.zip is a snapshot of what I have so far. Ignore the logred_set_reduce_5_Quine_McCluskey() functions.
The Makefile now lets you define a bunch of flags like VAR_A_BITS. But it should work for values up to 960. It may work beyond that with some tweeks to the variable string lenghts ("a960" and "a1024" are different lengths).
Cheers.
Always wanted a high speed lib for logic reductions ...Been trying this out, so many questions...
1) logred_set_scanf(a, "a00 + a00");
logred_set_reduce(a);
logred_set_printf(a);
Shouldn't that always produce 0? for me it outputs a00
1) logred_set_scanf(a, "a00 + a00");
logred_set_reduce(a);
logred_set_printf(a);
Shouldn't that always produce 0? for me it outputs a00
Nope. A or A == A. A or !A == 1 and A!A = 0
2) Similarly I would expect (a + !a) = 1
logred_set_scanf(a, "a00");
logred_set_not(b, a);
logred_set_xor(c, a, b);
= crash
logred_set_scanf(a, "a00");
logred_set_not(b, a);
logred_set_xor(c, a, b);
= crash
a = "a00"
b = "!a00"
c = "a00" ^ "!a00"
= a00!(!a00) + !(a00)!a00
= a00 + !a00
= 1
Yup, it crashes. Comments out "logred_set_reduce_4_A_nAB_n(src)" in "logred_set_reduce()" to fix this.
It doesn't resolve down to "1" yet. soon.
3) Haven't debugged enough, but part 2 could be related to this?:
logred_set_scanf(a, "!a00!b00"); = works
logred_set_scanf(a, "!a00"); = crash
logred_set_scanf(a, "!a00!b00"); = works
logred_set_scanf(a, "!a00"); = crash
Version I'm working on doesn't crash on this.
4) Actually, is there support for numeric literals (0, 1)? c = a+b is purely symbolic, but during SHA256 you add in those K-Constants which can sometimes help reduce things further.
Humm, good point. Will not be ready for this release. Soon.
4) x64 only? This is giving me heap problems:
#define VAR_T size_t
#define VAR_T_SIZE_BITS ( 8 * sizeof(VAR_T) )
#define VAR_A_BITS 256
#define VAR_A_LEN 4L
(worked around setting VAR_A_BITS = 128... maybe this is the source of all my problems?)
#define VAR_T size_t
#define VAR_T_SIZE_BITS ( 8 * sizeof(VAR_T) )
#define VAR_A_BITS 256
#define VAR_A_LEN 4L
(worked around setting VAR_A_BITS = 128... maybe this is the source of all my problems?
)The code should be x32/x64 agnostic. logred_v6.zip is a snapshot of what I have so far. Ignore the logred_set_reduce_5_Quine_McCluskey() functions.
The Makefile now lets you define a bunch of flags like VAR_A_BITS. But it should work for values up to 960. It may work beyond that with some tweeks to the variable string lenghts ("a960" and "a1024" are different lengths).
Cheers.
The network speed fluctuates a LOT. Any idea why?
Ah, I misunderstood.
It varies because some people back out of mining, and other times they jump-in because they just made the dive into bitcoin. Or they got delivery of an ASIC and want use it quickly before it's worthless.
If the price of BTC in their currency of choice is too low, they may give up.
If it's high enough, they start mining again.
There are many reasons for global hashrate fluctuations.
http://bitcoin.sipa.be/speed-thumbnail.png
This doesn't really match up to the stats right now. Can anyone make sense of this?
This doesn't really match up to the stats right now. Can anyone make sense of this?
These charts tell us the price of Bitcoins are not correlated to difficulty. Plain and simple.
Supply and Demand have taken over and are keeping each other in check for now.
Re: Bitcoiniacs -or- How to get Cash for Bitcoins in Vancouver
nice option if you need bitcoin locally too bad i dont live there
Ottawa has one - much shadier feeling to it. https://www.canadianbitcoins.com/
$110 and $123
http://www.bitcoiniacs.com/rates/ site was telling me $1CAD would buy "infinity" BTC. Sweet!
Re: How long have you been waiting for your Mt Gox withdrawal?
I waited way longer than I should have to get USD Wire transfers... over 2 months! Last week I cancelled them all,converted to BTC and withdrew all BTC. Maybe someday I'll use them again, but they have to get rid of their wire transfer management team that they hired from Butterfly labs.
If Mt Gox SWIFT transfers open up - I'd expect to USD/BTC to plummet as everyone sells their coins.
bump - Update 2013-08-27: Email response from my bank in first post.
Good luck. I hope to see a favourable outcome for you in this. It truly sickens me that there exists individuals with such a low regard for others property, time, and reputation.
Thanks.
Question: I'm thinking of requiring higher number of localbitcoins.com trades plus account age of 3 months. Any thoughts on using bitcointalk.org post counts, reputation and account age as verification? PMing being enough to prove jdoe@localbitcoins == whatever@bitcointalk.org
The LocalBitcoins.com people have responded to support issue of signature verification issue:
Quote from: localbitcoins.com
I kicked the developer sitting next to me yesterday.
Now I kick harder.
No ETA yet, but he is yelling.
Now I kick harder.
No ETA yet, but he is yelling.
I'll PM you a link to my C code for logic reduction in a few mins. You can compile C right? And know how to code? It should be quite a bit faster than Mathmatica or Maple.
It uses de Morgan's rules and some basic reduction rules to optimize the circuit.
It uses de Morgan's rules and some basic reduction rules to optimize the circuit.
This is excellent by the way
I will start integrating with my code. Right now my stuff is all C#, so I will have to compile your code into a lib and do marshaling - though at first glance of your API I don't think marshaling will have too bad of a perf impact. I'll try with c=a+b to test the runtime and validate the results match yours. Do you know how your de Morgan approach compares to this Quine McCluskey one I keep reading about? http://en.wikipedia.org/wiki/Quine%E2%80%93McCluskey_algorithm
Quine-McCluskey is the analytical twin of Karnaugh Maps (http://en.wikipedia.org/wiki/Karnaugh_map)
Basically, QMC/KMap takes I/O and creates formulas. My lib lets you build the formulas directly and simplify them. You *could* create the formulas based on I/Os I guess. But since we know the SHA-256 formulas you could skip that step.
In fact you really want to, otherwise you will never have the correct formula unless you iterate all possible inputs for the SHA256 compression function (2^256 + 2^(W-array inputs) ).
Even 2^32 addition is going to be massive. The nth (0..31) output bit of 32bit-add will be 2^(n+1) terms long. You're only hope is multiple 32bit-adds start simplifying.
Download logred_v3.zip - there was a bug in performing (A+BCD+EFG+...)(HI+!JK+...)(...)... operations.
Cheers
Edit:
Playing a bit here, turns out the A=A+AB and A+B=A+!AB reductions have no effect in 32bit add. Guess that's what makes it a nice 32bit bijection.
Download logred_v4.zip which will be faster for your application.
You can disable those reduction algorithms by commenting out logred_set_reduce_2_A_AB() and logred_set_reduce_4_A_nAB_n() inside logred_set_reduce()
A thief however can still dispute they never made the charge. "It wasn't me, I have no idea who this Bitcoin hacker guy is, or how he stole my money but I never made these transfers. Please Mr. Bank Customer support person they stole all my money I can't pay the rent unless I get this back".
I would imagine this scenario would only work once per bank account. After that, the bank would be onto the scammer's MO. The 2nd and subsequent claims by a person doing this scam from their own account would be treated with extreme suspicion by their bank. It would have to be a decent amount of money to be worth burning one's own reputation with their bank to try this scam.
I also find it amazing that there are many legitimately 'hacked' bank accounts in Canada. I've been using online banking for years in Canada with no problems. I would think their security would be heavy duty. I know if someone hacked my account and tried to do an Interac e-Transfer out, I'd get a phone call from my bank.
I'm not convinced he was hacked. But maybe. We exchanged emails (using reply-to the communication@localbitcoins.com alerts) and I saw the name of dpwebb's business and his title (CEO). He claimed to be trying to do arbitrage against MtGox - an almost plausible angle for playing BTC.
I suspect he was going to gamble $1300 on bitcoin and see if he could get an "extra percentage" but claiming "hacker!". That between him and his bank. I will not take a loss on this ... other than my time today. Already wiping out any profit I would have made.
Share and enjoy.