I just tried this 4 times... and I didn't win any?
I know each time I only have a 49% chance to win but it just seemed fishy to me...
Because there is only a .51^4 chance of me losing 4 times in a row which equates to around 6%... Maybe I'm just unlucky, but this doesn't seem legit to me.
Edit-
I just made 2 more microbets, both losses.
the chance of 6 losses is .51^6 if done concurrently.
I know the chance of me losing is 51% each time, but this is BS o.O
Topic: Ripple coin flip win 2x your money 49 out of 100 times! (Read 7939 times)
The max bets are way too low.
nice work, i played around with it for a little bit, no delays whatsoever. made a few ripples too 
Thanks GoWest! I pasted your link and oscar worthy performance to the top of the thread.
LOL.
Thanks GoWest! I pasted your link and oscar worthy performance to the top of the thread.
Just tried it a couple times with 5 XRP. To say I'm impressed is an understatement. This makes the Bitcoin verison (i.e SatoshiDice) feel absolutely dated.
This is a great example of how micro-transactions are going to move off of the Bitcoin network and onto Ripple.
This is a great example of how micro-transactions are going to move off of the Bitcoin network and onto Ripple.
yeah, Ripple smokes. It will be interesting to see if it can maintain these fantastic speeds without a practically pristine pipe.
By the way... http://www.thebitcointrader.com/2013/04/ripple-coin-flip-satoshidice-of-ripple.html
Just tried it a couple times with 5 XRP. To say I'm impressed is an understatement. This makes the Bitcoin verison (i.e SatoshiDice) feel absolutely dated.
This is a great example of how micro-transactions are going to move off of the Bitcoin network and onto Ripple.
This is a great example of how micro-transactions are going to move off of the Bitcoin network and onto Ripple.
yeah, Ripple smokes. It will be interesting to see if it can maintain these fantastic speeds without a practically pristine pipe.
Just tried it a couple times with 5 XRP. To say I'm impressed is an understatement. This makes the Bitcoin verison (i.e SatoshiDice) feel absolutely dated.
This is a great example of how micro-transactions are going to move off of the Bitcoin network and onto Ripple.
This is a great example of how micro-transactions are going to move off of the Bitcoin network and onto Ripple.
@fancy_pants i was truly inspired by your effort in creating this ripple bot. i'm in the process of releasing an open source gaming engine for bitcoin and i thought it would be a great exercise to create a ripple port. i threw this together over the weekend and i'm hoping it will help gain support for the ripple gaming community.
check it out when you have a chance
https://github.com/houseofsdot/ripple360
check it out when you have a chance
https://github.com/houseofsdot/ripple360
Hi nyusternie!
I haven't been on this forum for a while, so I'm sorry I haven't responded to you. But - your project looks great! The "refill code" is cool. I was thinking about doing something like that with the last couple of digits of the amount, but your way seems more professional. I was bummed to see you have also hard-coded XRP. I'm working on getting multiple currencies this afternoon and was hoping to see how someone else handles that. Thanks for the pointers on provably fair.
I'll post when I get multi-currency then implement your ideas for provably fair after that. (That is if I don't get sidetracked first)
Cole
@fancy_pants i was truly inspired by your effort in creating this ripple bot. i'm in the process of releasing an open source gaming engine for bitcoin and i thought it would be a great exercise to create a ripple port. i threw this together over the weekend and i'm hoping it will help gain support for the ripple gaming community.
check it out when you have a chance
https://github.com/houseofsdot/ripple360
check it out when you have a chance
https://github.com/houseofsdot/ripple360
here is a working example of provably fair based on hmac of txid
http://pastebin.com/x3vJ0xX7
there really is much more to it than this, the most important being the management of the daily secret.
another thing i suggest is to sign the tx before sending it to the server (to protect your secret key)
also, you'll have to properly set the odds (i think i left it at straight 50/50)
this was a great lesson for me in understanding the transaction system of ripple.
it will be a lot easier for me if i port this to nodejs so i can experiment further.
i'll be sure to publish the result up on github
if you have any questions, don't hesitate to ask
http://pastebin.com/x3vJ0xX7
there really is much more to it than this, the most important being the management of the daily secret.
another thing i suggest is to sign the tx before sending it to the server (to protect your secret key)
also, you'll have to properly set the odds (i think i left it at straight 50/50)
this was a great lesson for me in understanding the transaction system of ripple.
it will be a lot easier for me if i port this to nodejs so i can experiment further.
i'll be sure to publish the result up on github
if you have any questions, don't hesitate to ask
I think this code, sophomoric as it is, proves that ripple is much faster and better for gaming than bitcoin. Admittedly there's not much traffic on the ripple network, but after watching this thing go I'm a believer.
speed is really not a problem for bitcoin. most games will allow you to use deposits with 0 confirmations (which is pretty much instant). the only restriction comes with withdrawals (this is where ripple may actually have an advantage). but still not a big deal, as you'll probably satisfy the min confirmations of the site during the time your playing whatever game (e.g. 2 confirmations is only ~20 min); so by the time you're ready to withdraw, you're deposits should already be sufficiently confirmed.
I'm also an early adopter to XRPs so I can benefit if you just copy it and use it to drive XRP adoption.
so, here you go!
http://podstreamer.com/rippledoubler.py.txt
If you'd like to send back the proof of fairness code, I'll use it. Otherwise I'll figure out how to roll my own.
so, here you go!
http://podstreamer.com/rippledoubler.py.txt
If you'd like to send back the proof of fairness code, I'll use it. Otherwise I'll figure out how to roll my own.
nice. thanks!
i think the greatest benefit would be to open source this code for others to use in their own creative implementations. would you have any objections if i threw this up on github when i'm done? i'd obviously credit you as the original author.
-------------------
actually, i don't even like to gamble (at least not casino style). i prefer "real money games" (like skins when golfing). i believe bitcoin and ripple could do well in facilitating the creation of fun and unique real money "online" games. my new platform https://www.btcvillage.nl will hopefully provide a framework for average developers to create "real money venues" without all the hurdles that come with cryptographic currencies.
edit:
just ran another test on your bot. incredibly fast indeed. nice work
https://ripple.com/client/#/tx?id=84FBE84F437E6A1DCC2F16FE5AA65AF2037D03BEF64CB11C9052823AE1B89E24
You are seriously using python's random function to generate random functions? That is completely deterministic.
Ripple offers a random number generator through the rpc api, but I couldn't find it in the web socket. Doesn't really matter if I switch to provably fair. I can just use the Ripple RPC tool to generate a bunch of numbers and then refer skeptics to the vaunted ripple cryptographers.
i've got a full implementation for both php and nodejs that i'd be happy to share with you. (am actually planning on open-sourcing it on github -- maybe over this weekend). but i'm assuming ur bot is written python? i'd be willing to write a "custom" port for ur bot (not interested in stealing ur idea; just looking to get a better understanding of the ripple back-end) pm me if ur interested
Not my idea, and mostly not my code. I pulled the important stuff out of the bitcoin client on the ripple repo.
By the way, this is WAY faster since you tested it. I switched over to the websocket API instead of logging into the RPC every 10 seconds (and after a day or two of abuse waiting for 3 minutes)
I think this code, sophomoric as it is, proves that ripple is much faster and better for gaming than bitcoin. Admittedly there's not much traffic on the ripple network, but after watching this thing go I'm a believer. I'm also an early adopter to XRPs so I can benefit if you just copy it and use it to drive XRP adoption.
so, here you go!
http://podstreamer.com/rippledoubler.py.txt
If you'd like to send back the proof of fairness code, I'll use it. Otherwise I'll figure out how to roll my own.
If I understand you correctly,
- I hash the txid of the incoming transaction instead of using python's "random" (incoming to the dice address)
- generate a secret number daily and publish to the web
- Does daily make everyone happy?
I went to a bitcoin meetup last night but none of the discussions seemed to get to the provably fair discussion. Ripple meetup is tomorrow night.
- I hash the txid of the incoming transaction instead of using python's "random" (incoming to the dice address)
- generate a secret number daily and publish to the web
- Does daily make everyone happy?
I went to a bitcoin meetup last night but none of the discussions seemed to get to the provably fair discussion. Ripple meetup is tomorrow night.
1. hashing the "public" txid allows anyone (especially the bettor) to verify your win-calculation procedure. python's "random" function is not publicly verifiable.
2. many sites will (sha256) hash a list of secrets for like 10 years and publish it. whether you decide to do this or not is up to you, but the bottom line is you need a static location where people can view the daily secrets (obviously after they have been changed for a sufficient amount of time)
3. it should, just as long as you're consistent (imo, a scheduled job to insert the new secret -- wait -- then reveal the old secret would be ideal)
i've got a full implementation for both php and nodejs that i'd be happy to share with you. (am actually planning on open-sourcing it on github -- maybe over this weekend). but i'm assuming ur bot is written python? i'd be willing to write a "custom" port for ur bot (not interested in stealing ur idea; just looking to get a better understanding of the ripple back-end) pm me if ur interested
Quote
don't know much about the inner workings of ripple, but given that ripple uses a public tx id, i'd suggest:
1. hashing the tx id with hmac_256(txid, secret[123456])
16F3CFF07A73110CD5E6CD9797EC316DAC1CA5BB2ED0D60A2C2CE4AB8FC5D35B
2. taking whatever bytes you want (e.g. first 2)
16F3 (5875)
3. using a basic hi-lo win/loss rule (e.g. under 32768)
WINNER!
sound familiar? yeah, its sd for ripple (well not exactly -- but its close enough and should satisfy fairplay)
good luck!
1. hashing the tx id with hmac_256(txid, secret[123456])
16F3CFF07A73110CD5E6CD9797EC316DAC1CA5BB2ED0D60A2C2CE4AB8FC5D35B
2. taking whatever bytes you want (e.g. first 2)
16F3 (5875)
3. using a basic hi-lo win/loss rule (e.g. under 32768)
WINNER!
sound familiar? yeah, its sd for ripple (well not exactly -- but its close enough and should satisfy fairplay)
good luck!
If I understand you correctly,
- I hash the txid of the incoming transaction instead of using python's "random" (incoming to the dice address)
- generate a secret number daily and publish to the web
- Does daily make everyone happy?
I went to a bitcoin meetup last night but none of the discussions seemed to get to the provably fair discussion. Ripple meetup is tomorrow night.
You are seriously using python's random function to generate random functions? That is completely deterministic.
Quote
don't know much about the inner workings of ripple, but given that ripple uses a public tx id, i'd suggest:
1. hashing the tx id with hmac_256(txid, secret[123456])
16F3CFF07A73110CD5E6CD9797EC316DAC1CA5BB2ED0D60A2C2CE4AB8FC5D35B
2. taking whatever bytes you want (e.g. first 2)
16F3 (5875)
3. using a basic hi-lo win/loss rule (e.g. under 32768)
WINNER!
sound familiar? yeah, its sd for ripple (well not exactly -- but its close enough and should satisfy fairplay)
good luck!
1. hashing the tx id with hmac_256(txid, secret[123456])
16F3CFF07A73110CD5E6CD9797EC316DAC1CA5BB2ED0D60A2C2CE4AB8FC5D35B
2. taking whatever bytes you want (e.g. first 2)
16F3 (5875)
3. using a basic hi-lo win/loss rule (e.g. under 32768)
WINNER!
sound familiar? yeah, its sd for ripple (well not exactly -- but its close enough and should satisfy fairplay)
good luck!
If I understand you correctly,
- I hash the txid of the incoming transaction instead of using python's "random" (incoming to the dice address)
- generate a secret number daily and publish to the web
- Does daily make everyone happy?
I went to a bitcoin meetup last night but none of the discussions seemed to get to the provably fair discussion. Ripple meetup is tomorrow night.
I was planning to make this faster and multicurrency before addressing provably fair, but you're not the only person to request that. Provably fair is now my first priority. Thanks!
if anyone is going to take this game seriously, then this is pretty much a required. so its best to get this out the way first. you mentioned you were attending a meetup over the weekend to discuss ripple and the possibilities of provably fair. how did that go?
The transaction shows right here: https://ripple.com/client/#/tx?id=1E98555119A16C46FDB78C4945EE07D9EC4C41F8B66347483D7902BFB3FF3A9A
don't know much about the inner workings of ripple, but given that ripple uses a public tx id, i'd suggest:
1. hashing the tx id with hmac_256(txid, secret[123456])
16F3CFF07A73110CD5E6CD9797EC316DAC1CA5BB2ED0D60A2C2CE4AB8FC5D35B
2. taking whatever bytes you want (e.g. first 2)
16F3 (5875)
3. using a basic hi-lo win/loss rule (e.g. under 32768)
WINNER!
sound familiar? yeah, its sd for ripple (well not exactly -- but its close enough and should satisfy fairplay)
good luck!
Make it provably fair.
also, inb4 move to alt cryptocurrencies (and ripple is nothing but a scam anyways)
also, inb4 move to alt cryptocurrencies (and ripple is nothing but a scam anyways)
Hi TradeFortress,
I was planning to make this faster and multicurrency before addressing provably fair, but you're not the only person to request that. Provably fair is now my first priority. Thanks!
I originally posted this to the alt cryptocurrencies chain and they told me to move here. Since the world's first ripple based gambling bot is of such monumental import, I instead posted to the main forum. Them main forum bumped me to gambling. So here we are!
"Ripple is nothing but a scam" As far as I can tell Ripple is a bitcoin blockchain with a 10 second reward and some pretty cool features surrounding multi currency transactions. Like most people I don't know or trust any bitcoin miners just like I don't know or trust any ripple miners. With that said, I'd like to hear how exactly ripple is a scam before I consider them to be just another scam like bitcoin.
Ripple has a txid / hash too, so using a similar system like SatoshiDICE would work (secret keys, hash secret keys and publish in advance)..
I was planning to make this faster and multicurrency before addressing provably fair, but you're not the only person to request that. Provably fair is now my first priority. Thanks!
if anyone is going to take this game seriously, then this is pretty much a required. so its best to get this out the way first. you mentioned you were attending a meetup over the weekend to discuss ripple and the possibilities of provably fair. how did that go?
The transaction shows right here: https://ripple.com/client/#/tx?id=1E98555119A16C46FDB78C4945EE07D9EC4C41F8B66347483D7902BFB3FF3A9A
don't know much about the inner workings of ripple, but given that ripple uses a public tx id, i'd suggest:
1. hashing the tx id with hmac_256(txid, secret[123456])
16F3CFF07A73110CD5E6CD9797EC316DAC1CA5BB2ED0D60A2C2CE4AB8FC5D35B
2. taking whatever bytes you want (e.g. first 2)
16F3 (5875)
3. using a basic hi-lo win/loss rule (e.g. under 32768)
WINNER!
sound familiar? yeah, its sd for ripple (well not exactly -- but its close enough and should satisfy fairplay)
good luck!
Jump to: