Bitcoin Forum
July 01, 2024, 04:39:29 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Gambling / Re: mutterings from mem: Provable Results vs Provably Fair on: August 20, 2013, 10:52:34 PM
Quote
Once you click the Play button, we shuffle the transaction id that you sent your payment with and add that to the client seed provided by you. We then hash the strings with SHA256 to get the result. The first X numbers in that string set the winning spin. The client seed can be changed by the player and the shuffled transaction ID is printed after every play in order to verify.

Any thoughts on this?
Is this method considered provably fair with provable results?

The player can cheat using this method, since they can make the txid anything they want by repeating the signing process and then set their client seed so they can generate a specific hash and result.
2  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; FREE BITCOINS! on: August 11, 2013, 06:32:27 PM
0,8(3)% is not big different from 0,8%. However it is not the problem for me to change it to match exacly 0,8%, if someone will want. Who want?  Smiley
Quote
But you can't prove that you don't change the secret behind the scenes, or change the client seed
It is hard to find another server seed that will output the same SHA256 hash. If I will change client seed, the outcome will not validate using the script.

Edit: vlees, account funded. Good luck.

No but the user has no proof if you do change it, you can provide the sha256(a) to the user, but use the secret b to do the actual calculation and the user has no way of proving it.
3  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; FREE BITCOINS! on: August 11, 2013, 06:22:31 PM
Good enough for me.


Good enough for me too, I'm dropping to 0.8
4  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; FREE BITCOINS! on: August 11, 2013, 06:17:27 PM
The secret_hash wasn't present before when I posted, neither was the hash method present in the screenshot bitcoininformation posted.

But you can't prove that you don't change the secret behind the scenes, or change the client seed

Also your house edge comes out at 0.8333333%, not 0.8%.

5  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; FREE BITCOINS! on: August 11, 2013, 05:51:16 PM
1. Next server seed hash is now showing.
2. You can now specify custom wager.
3. Rolls history now updates immediately.

I will move the site to another server within few hours, but the site will keep running. Thank you very much for feedback.

What hash method do you use and how can you prove to the player that you dont change it after the bet has been placed?

Also can you provide your calculations on how you came to the assumption that you have a 0.8% house edge?

1-((2+1.4+1.2+1.1+0.25)/6) = 0.00833333
6  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; FREE BITCOINS! on: August 11, 2013, 05:26:53 PM
dice64, you are right, I will add hash. Unfortunately my current server is not working good with such much traffic.
HallowIP, do not worry about it, if you always roll "1", it means that the server is overloaded, but your money is safe.
I'm sorry for troubles.

You should have added it before you started, why would the server always roll 1 if it was overloaded? Shouldn't it raise an HTTP 503? Always returning a 1 shows that you've written some logic to change the result outside of the method you've already said.

Also, just from a single test, I can see you aren't using atomic database transactions.
7  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; FREE BITCOINS! on: August 11, 2013, 05:05:19 PM
HollowIP, account funded.
dice64, I have already implemented this. You can check client/server seed of roll by clicking "i" button on rolls history.

Quote
How is this provably fair when the mt_srand and mt_rand are pseudo-random and not guaranteed to give the same output on every system?
mt_rand will use seed provided using mt_srand. This is system-independed and will always return the same result.

The mt_rand function uses Mersenne Twister to generate its output.

Caution: Mersenne Twister is basically for Monte-Carlo simulations - it is not cryptographically secure "as is"
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

Also, you dont show the user the secret seed, or its hash before the bet is placed. So you're free to generate any result you like, by creating any secret that matches the output you want.
8  Economy / Gambling / Re: FairDice.biz: new bitcoin dice game; only 0,8% house edge; no minimum bets on: August 11, 2013, 04:35:59 PM
Zaih, the provably fair verification will be available soon.

Does this mean you will make the method available soon, or you will implement it soon?

From your site.
Quote
<?php
$server_seed = "SERVER_SEED_HERE";
$client_seed = "CLIENT_SEED_HERE";

function str2int($str) {
   $int = 0;
   foreach (str_split($str) as $char)
      $int += $char;
   return $int;
}

mt_srand(str2int($server_seed . $client_seed));

$roll = mt_rand(1, 6);
echo "Roll result is " . $roll;

How is this provably fair when the mt_srand and mt_rand are pseudo-random and not guaranteed to give the same output on every system?

Also neither the "server seed" or "client seed" are ever shown to the user.
 
9  Economy / Gambling / Re: mutterings from mem: Provable Results vs Provably Fair on: August 11, 2013, 04:30:23 PM
I think we want two solutions to this:

1. With a central server that does not need to be trusted (but can generate the shuffling.)
2. P2P version of poker. No need for servers (except maybe to find other players.)

I like option 1, too. Total decentralization is like the holy grail of online poker, but it seems to me that a central server would still be needed to organize the games, keep them moving along at a reasonable pace, and to act as a trusted escrow service to transfer funds back and forth. Maybe you could build a p2p client to handle all that, but then you'd get cheaters building their own clients to get around any constraints.

It's an interesting problem anyway and I'm pretty sure there is a big market for it. My own informal survey of bitcoin gaming sites tells me that the most profitable sites are also the 'provably fair' sites (bitZino, Just-Dice, etc). People aren't fools (for the most part). A provably fair HU poker site would almost certainly get a lot of action from high-rollers ... is my guess. I can see the $$ in their eyeballs now.

Physical Poker is popular because it is decentralised, you don't need to go to a casino to play, however, you are still depended on the dealer in your group being legit and that no one will run off with all the funds while you play.

A lot of these problems can be solved if using bitcoin as a payment method, using m-of-n transactions helps, but you'll still need a trusted dealer. Otherwise it'd just be like going to an unknown backstreet poker room and trusting that no one will rob you.
10  Economy / Gambling / Re: BitCoin Multiplicator. Easy and 100 % safe on: August 11, 2013, 03:57:59 PM
Such an amount is a lot of money to some people and they're under the impression that its value will increase in the future.
11  Economy / Gambling / Re: BitCoin Multiplicator. Easy and 100 % safe on: August 11, 2013, 03:47:23 PM
He's out of here. It was probably always his plan to return a couple, until enough people thought they could take advantage and then run off with all the deposited funds.



I guess, but I thought he had some deals done before, guess I was mistaken. I don't see why you'd ruin your reputation for ~15$.

He hardly has a reputation to ruin. My guess is he was doing this from the start until someone sent a big bet which he could run off with.
12  Bitcoin / Development & Technical Discussion / Re: Bad signatures leading to 55.82152538 BTC theft (so far) on: August 11, 2013, 01:40:13 PM
Hilariously this is how the encryption on the ps3 was broken.

Quote
In December 2010, a group calling itself fail0verflow announced recovery of the ECDSA private key used by Sony to sign software for the PlayStation 3 game console. However, this attack only worked because Sony did not properly implement the algorithm, because k was static instead of random. As pointed out in the signal generation algorithm, this makes d_A solvable and the entire algorithm useless.[4]
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Security

They always used a k value of 4, instead of it being random.
13  Economy / Gambling / Re: BitCoin Multiplicator. Easy and 100 % safe on: August 11, 2013, 12:55:23 PM
He's out of here. It was probably always his plan to return a couple, until enough people thought they could take advantage and then run off with all the deposited funds.

14  Bitcoin / Development & Technical Discussion / Re: Bad signatures leading to 55.82152538 BTC theft (so far) on: August 11, 2013, 12:47:11 PM
It's not much of a problem if you're using Bitcoin correctly (ie, not reusing addresses).
That can't possibly be your proposed solution to this problem - "Just never use a bitcoin address more than once"?
While it makes sense for privacy reasons, it shouldn't need to be done just so you don't get your coins stolen.

If for example I give someone a bitcoin address so he can make recurring payments of some sort to me, I need to reuse that address. Everything else would just be a major pain in the ass.

You can get every transaction which has been sent by that address and ensure none of its spent outputs have the same signature in the script. But the main problem is random number generation.

Even if you want to make recurring payments, you should still generate an address each time. Otherwise you seriously risk linking your address to your identity. It isn't a pain in the ass, its the best practice for anonymity, regardless of this current bad signature issue.
15  Bitcoin / Development & Technical Discussion / Re: Bad signatures leading to 55.82152538 BTC theft (so far) on: August 11, 2013, 12:17:18 PM
I saw this write up a while ago, seems like there are some web wallets which use poor random number generation for every transaction, or as in this case a hardware wallet.

http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
16  Economy / Gambling / Re: BitCoin Multiplicator. Easy and 100 % safe on: August 11, 2013, 12:11:08 AM
So can anyone just create custom TX id's?

https://en.bitcoin.it/wiki/Raw_Transactions

Not custom txids, but custom transactions, basically everytime you run signrawtransaction, a random number is used in the ecdsa signature generation, this is the signature is the first few bytes in the sigScript.

Run signrawtransaction enough times and you'll end up with a signed hex transaction which will equate to a txid which begins with a 7.
17  Economy / Gambling / Re: Dice64 - Off Blockchain. Provably fair. Instantly verifiable. 0.9% Edge on: August 10, 2013, 11:58:58 PM
Updated python verification code. Increased maximum bets again.

https://gist.github.com/Dice64/6151316
Code:
import hashlib
import requests
 
# Doesn't currently do signature checking, we'll implement that in soon.
URL = "https://dice64.com"
 
 
def dsha256(input):
    return hashlib.sha256(hashlib.sha256(input.decode('hex')).digest()).hexdigest()
 
 
def verify_bet(id):
    r = requests.get(URL + '/api/bets/'+str(id))
 
    if r.status_code != 200:
        print "Couldn't find bet"
        exit()
 
    secret = r.json()['secret']
    secret_hash = r.json()['secret_hash']
    nonce = r.json()['nonce']
    combined_hash = r.json()['combined_hash']
    result = r.json()['result']
    # Calculated results
    combined = int(secret, base=16) + nonce
    combined_hex = hex(combined)[2:].strip("L")
 
    # Add preceeding zeros to make it 64 bytes in length
    while len(combined_hex) < 64:
        combined_hex = "0"+combined_hex
 
    # Print output
    print "\nSecret Hash - dsha256(secret)"
    print "Calculated:", dsha256(secret)
    print "Server val:", secret_hash
 
    print "\nCombined Hash - dsha256(secret + nonce)"
    print "Calculated:", dsha256(combined_hex)
    print "Server val:", combined_hash
 
    print "\nResult - dsha256(secret + nonce) mod 64"
    print "Calculated:", long(combined_hash, base=16) % 64
    print "Server val:", result
 
 
if __name__ == "__main__":
    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument('id', help='id of bet to check', type=int)
    args = parser.parse_args()
 
    verify_bet(args.id)
18  Economy / Gambling / Re: BitCoin Multiplicator. Easy and 100 % safe on: August 10, 2013, 06:50:18 PM
I hope you don't mind, but I build my transaction manually, turns out it began with a 7! I must be lucky today.

7e7a9aae3007f1cfaa853a6f304e07813bbfb0cda5faf8e5ff2a4e467dda5a87

010000000131a942717f4843237f8c11b664f96edb429553a0b4c0a92e144a7d8cf4fe51fc00000 0006b48304502200a3816ca0057a502b49f17e3a2774ecaed77dc8957868d1a34958334a8f78f8e 022100f72678a4c4979669d9a873259f30ceb2934b065c1fff2ec406cc1389b70c8f24012103562 8021c3525ddf260ffa530dc128f52d93af568882ebd1251a7108627c9ac2dffffffff0230eb7f00 000000001976a9149d184da30b40ef36a0bc68afd7351d6bfafeb72788ac40420f0000000000197 6a914afbd00a851a657f1fdb90d0a875d9b9efeadd10388ac00000000

Code:
raw = rpcConn.createrawtransaction([{"txid":"fc51fef48c7d4a142ea9c0b4a0539542db6ef964b6118c7f2343487f7142a931","vout":0}], {"1H2DfhYR3Mkkhd4zRQtUuPY2G6dfU3wrb7":0.01 , "1FKeCjp2ReCEkfjBwNtJyWY7WKq8XajSbj":0.0838328})
signed = rpcConn.signrawtransaction(raw)
hashed = hashlib.sha256(hashlib.sha256(binascii.unhexlify(signed['hex'])).digest()).digest().encode('hex_codec')
txhash = ''
for i in range(32, -1, -1):
txhash += hashed[i*2:i*2+2]

if txhash[0] == "7":
print "collision found"
print txhash
print signed
print nonce
break

What is this sorcery? Are you hacking?

EDIT: Anyways: my 3rd and last transaction has the two confirmations.

Not at all, my code is just lucky.
19  Economy / Gambling / Re: BitCoin Multiplicator. Easy and 100 % safe on: August 10, 2013, 06:36:48 PM
I hope you don't mind, but I build my transaction manually, turns out it began with a 7! I must be lucky today.

7e7a9aae3007f1cfaa853a6f304e07813bbfb0cda5faf8e5ff2a4e467dda5a87

010000000131a942717f4843237f8c11b664f96edb429553a0b4c0a92e144a7d8cf4fe51fc00000 0006b48304502200a3816ca0057a502b49f17e3a2774ecaed77dc8957868d1a34958334a8f78f8e 022100f72678a4c4979669d9a873259f30ceb2934b065c1fff2ec406cc1389b70c8f24012103562 8021c3525ddf260ffa530dc128f52d93af568882ebd1251a7108627c9ac2dffffffff0230eb7f00 000000001976a9149d184da30b40ef36a0bc68afd7351d6bfafeb72788ac40420f0000000000197 6a914afbd00a851a657f1fdb90d0a875d9b9efeadd10388ac00000000

Code:
raw = rpcConn.createrawtransaction([{"txid":"fc51fef48c7d4a142ea9c0b4a0539542db6ef964b6118c7f2343487f7142a931","vout":0}], {"1H2DfhYR3Mkkhd4zRQtUuPY2G6dfU3wrb7":0.01 , "1FKeCjp2ReCEkfjBwNtJyWY7WKq8XajSbj":0.0838328})
signed = rpcConn.signrawtransaction(raw)
hashed = hashlib.sha256(hashlib.sha256(binascii.unhexlify(signed['hex'])).digest()).digest().encode('hex_codec')
txhash = ''
for i in range(32, -1, -1):
txhash += hashed[i*2:i*2+2]

if txhash[0] == "7":
print "collision found"
print txhash
print signed
print nonce
break
20  Economy / Gambling / Re: 5 dice game on: August 06, 2013, 06:38:21 PM
I'm running Firefox 23.0 (updated it just today from 22.0) so I don't think that is this the problem and i don't think that someone is running a MITM attack right now Tongue
I don't want to go Off-Topic anymore but anyway I've appreciated your help, thanks.
 


It's probably due to him not linking his signed public rsa key with his certificate providers key in the web server. Firefox tends to need this, while chrome already has the certificate providers key built-in.
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!