Reserved. See others do that, so why not.  |
|
|
|
 https://www.btccake.comFeatures:Player VS Player0% House edgeBet with BitcoinsLive ChatOnly 1% fee taken from the winnings, rest goes to the users!How it works:1. Select a wedge to bet on (join or new):  2. Place bet of choice:  Notice the updated information:  3. DoneWhen time is up, a winning wedge will be chosen, and if you are on it, you will get your share! Note that in the example above, I would increase wedge 2 from 44% chance of winning to 46.15%, and if that wedge would win, I would get 0.01166667 BTC. Hey Bitcoiners! I thought I put this out there more officially now when I have tested the site for a while. (You can read more about it here: https://bitcointalk.org/index.php?topic=680412.msg7715245#msg7715245 ) Briefly about the site:This game is all about the users. I only take 1% fee from the winnings. Users basically bet on a wedge. Then when time is up, a wedge is selected, and those on that wedge wins the pot. Now, don't deposit anything ridiculous high. Just small amounts. Actually, feel free to test with play money first (You get 10 PlayBTC automatically). I still want to test it out and let it grow with time, earning trust and just make it fun. I also plan of taking what I earn and add bonuses. And I would also love to get feedback on this. Yes, sections such as "Find Cake" and "Statistics" aren't implemented yet, but hey, great opportunity for feedback there. Alight, my site is here: I've created this for BTC: https://www.btccake.com/cake/2565bf1195673e39e718c6d9efe03d8c211c2dca477206de160e816bccd8368cAnd this for PlayBTC (playmoney): https://www.btccake.com/cake/31317a9b37877dfcb03dda9d0fe10c96a4ad54477dbcd2ff9b8cafb476726d1bThey both have same parameters so you can see how it works. (and you can create your own with your own parameters, which is one unique thing with the site) How to play: 1. When you arrive to the site an account is automatically generated. Save that unique URL somewhere! To lock it down further, add password and email (and confirm your email). Yes, I've taken many steps to securing the site. 2. Click on a cake of interest. 3. Click on a wedge (or button for a wedge). 4. Place bet. 5. Done. (Yes, I will update this post to make it look better) |
|
|
|
So, as usual, things takes more time than you think when developing. However, this is one of those ideas I just have to try. Anyway, I'm actually trying to implement both ways. "One address" and "Generate unique addresses". Just to see how they compare. While testing this with one address, I noticed that sometimes I don't seem to get the sending address from first offset in the input. See my testing here: http://api.blockcypher.com/v1/btc/test3/addrs/mggchBoqRNoT3beYCX4h2DMGtT2a6AaFFgI've send a few testnet3 bitcoins to the mggchBoqRNoT3beYCX4h2DMGtT2a6AaFFg address, and if you look at the this transaction here: https://api.blockcypher.com/v1/btc/test3/txs/2e11ff66366592fdca419baef8873532594d85d80de5b3f714cbcc301eda3c20I can grab the correct sending address from this input: "inputs": [
{
"prev_hash": "25199d78f200daf77adc7e53883159fc57493d285c1cec0666136d84ece33ada",
"output_index": 1,
"script": "473044022060852275011e0eccf2b1418ab934a71456013408b128bbd44b5819069d9c220102200db6362b8bbbb805beb4463cc4a80d6374a18fc700561d903b9ace55fbf8ac47012103832dc693149e4b10cd8f40b1d54300a26892288c0725cb9a28c0fe07c1316c04",
"output_value": 9990000,
"sequence": 4294967295,
"addresses": [
"n295M4YJiumNFiTasqcHp5g7zr6BhD8G9L"
],
"script_type": "pay-to-pubkey-hash"
}
],
I get the sending address n295M4YJiumNFiTasqcHp5g7zr6BhD8G9L. All fine and dandy. This works for the other transactions as well, but when I look at this one: https://api.blockcypher.com/v1/btc/test3/txs/bd5d6f2a606f45be09c28744bc3b707bc885ee6f5ca0bd5e90ff54c0159b958cThe sending address is n4VQ5YdHf7hLQ2gWQYYrcxoE5B7nWuDFNF for some reason. And I have no idea why. "inputs": [
{
"prev_hash": "2e11ff66366592fdca419baef8873532594d85d80de5b3f714cbcc301eda3c20",
"output_index": 0,
"script": "4730440220614eda9788afbbe4bc2f51bb36adbdfbff6c530ac8907dd83d47008abfcb5abb02202ee62383e2b3561416ee5c0f7eb1aa5a69d4feaa2833fa11e801b41def894ed3012103fee3aa600f2edd4048731b47fc976b8b8cc28afc4ae115b8af02956e71133350",
"output_value": 4980000,
"sequence": 4294967295,
"addresses": [
"n4VQ5YdHf7hLQ2gWQYYrcxoE5B7nWuDFNF"
],
"script_type": "pay-to-pubkey-hash"
}
],
I only have these receiving (sending) addresses in the wallet: mtPw16eSgDNojw5w7VEshLAk55nh8UCihZ n295M4YJiumNFiTasqcHp5g7zr6BhD8G9L msoZ1tjxth5Z6RDXKjPRTvES1QyGs2XkvR So, as this seems tricky I'm now really leaning towards generating unique addresses instead. Anyone that can cast a light on this? If you look at the address here: https://live.blockcypher.com/btc-testnet/address/n4VQ5YdHf7hLQ2gWQYYrcxoE5B7nWuDFNF/ you can see it seems like the address just became some temporary receive and send address... Either way, it's confusing me. I will continue working on "generate addresses" instead, as this "grabbing sending address" doesn't seem too reliable.. |
|
|
|
|
I personally don't have a problem with ponzi schemes as long as they are totally open about it. You know the rules, so if you play, you should know the risks.
|
|
|
|
|
Seems the first option still has more votes... but from the feedback in the comments, I think I would go for #2 anyway. Hope that doesn't disappoint too much, unless you guys that voted for #1 can clarify why that option is better?
|
|
|
|
|
Wow, that scam site with S has gotten 10 BTC... I feel bad about the people fooled....
|
|
|
|
Ok, now this is getting confusing. Why not just do like this: I come to the site. I first input my address I want money send to. Next a deposit address is generated, or password first and then deposit address. With password, I essentially have an account, but I can't change the address money will be send to. That's a lot less convoluted, though. Isn't this good? |
|
|
|
Hey folks,
I'm working on an idea which I plan of releasing in a week or so hopefully.
But, I'm having trouble deciding what method to use.
There are basically 2 ways you can do a bitcoin wallet payment solution.
1. Have one address which everybody sends to, and you use some magic to figure out what address the payment came from and you can send money back to.
This way the address is completely public and everybody can see what happens quite easily. However, there are restrictions as to what wallets people can send from. And might be a bit trickier to get working properly as I don't have much experience using this method myself, so I'm not sure how reliable it is to get users send addresses from the transaction information.
or
2. Create unique addresses for users to send to. Before doing this, you can just let the user specify which address that the user would like to get money to.
This is more of a controlled way to keep track of who payed what, and easy for users to specify where the money should come back. And, they can send from whatever wallet they want to. However, it's hard for anyone to see a total as one can do with the first one. I guess, one actually could just show all those addresses, and sum it up though.
What method do you guys prefer? First method is convenient, but again, you have to be careful with from where you send. And second is more controlled but less transparent (although one can make it more transparent by showing those addresses publicly as well).
Thanks,
Chillance
1 Main Address for Everybody would not work very well, there is bound to be a private key/password with a means to send coins to specific users. If so, would'nt that be putting all your coins in one hell of a basket? If you can implement 1 main address for everyone without risks, you would be filthy filthy rich  I would suggest unique addresses for each user, saves alot of auditing trouble and trouble should unfortunate events happen Yea, this is true. |
|
|
|
3. Get the user to provide a "return" address so then you don't need to try and work out where to send funds to (and works with either 1 or 2).
This has quite a few benefits, a big one being that you can be pretty damn confident you aren't going to run into unauthorized use issues. Locking accounts to return addresses also eliminates a lot of the attraction to would-be thieves (though it doesn't directly impact the attraction to fuck around in your own tables for a bigger reward). Thanks guys for quick feedback. I guess I forgot to mention that the 2 options is really then setup to keep it simple with no accounts where users have to login and stuff. With #3 I guess I need to setup some kind of account system too. With cookies, passwords and all that jazz. How does this work with #1 exactly? How would I best map the the transaction send address information to the user's account? Cookies with addr and username alone could work (rec addr as "username," username as "password"). User enters withdraw address, user enters username ("Generate one for me" preferred), hashed together creates login token saved as cookie. User can provide receiving address and username for account recovery but cannot ever change the receiving address. I'm not sure how you could implement #1 one way or the other with full confidence. You could perhaps prevent conflicts by generating a Bitcoin URI with a random string as the message. -Like bitcoin:1Whatever?amount=1&message=[UniqueHashHere]. If there's a dispute, just have the user relay the hash in the message until push messaging (or whatever They're calling it) is implemented. What are you doing, anyway? I really like this idea! +1 to you sir. I'm not sure what you mean with "Generate on for me" though. Also, what's interesting about this is that even if someone knew both, they can't do anything of importance, which I like very much! Which one of these can be public information? If I want to be transparent I want to show both deposit and users receiving addresses (although I could in the account give an option to hide it). So, that would be public. Meaning "username" is more of a "password" and should not be public, right? You would assume all receiving addresses are compromised since an attacker would see them being sent to from your one BTC address, leaving only the username as a defense. Because of this, it's important users don't reuse usernames for this. Let's say Malicious Marvin looks through transactions sent by your site's BTC address and knows 1Whatever is Bill. -So let's say Bill goes by DrunkonCoins on BTCTalk. There's a good chance Bill's going to re-use that username, so it's good to try getting them to choose a unique username (or generate one for them) or at least make them aware their username is effectively their password. Ideally, you wouldn't use the public address as a username since the username itself should be a kind of password (and I just know someone's about to get up my ass over that  ), so... disclaimer: I'm just putting that out there as one possibility out of many..... but a lot of sites post user's usernames, so... you know.... Ok, now this is getting confusing. Why not just do like this: I come to the site. I first input my address I want money send to. Next a deposit address is generated, or password first and then deposit address. With password, I essentially have an account, but I can't change the address money will be send to. |
|
|
|
3. Get the user to provide a "return" address so then you don't need to try and work out where to send funds to (and works with either 1 or 2).
This has quite a few benefits, a big one being that you can be pretty damn confident you aren't going to run into unauthorized use issues. Locking accounts to return addresses also eliminates a lot of the attraction to would-be thieves (though it doesn't directly impact the attraction to fuck around in your own tables for a bigger reward). Thanks guys for quick feedback. I guess I forgot to mention that the 2 options is really then setup to keep it simple with no accounts where users have to login and stuff. With #3 I guess I need to setup some kind of account system too. With cookies, passwords and all that jazz. How does this work with #1 exactly? How would I best map the the transaction send address information to the user's account? Cookies with addr and username alone could work (rec addr as "username," username as "password"). User enters withdraw address, user enters username ("Generate one for me" preferred), hashed together creates login token saved as cookie. User can provide receiving address and username for account recovery but cannot ever change the receiving address. I'm not sure how you could implement #1 one way or the other with full confidence. You could perhaps prevent conflicts by generating a Bitcoin URI with a random string as the message. -Like bitcoin:1Whatever?amount=1&message=[UniqueHashHere]. If there's a dispute, just have the user relay the hash in the message until push messaging (or whatever They're calling it) is implemented. What are you doing, anyway? I really like this idea! +1 to you sir. I'm not sure what you mean with "Generate one for me" though. Also, what's interesting about this is that even if someone knew both, they can't do anything of importance, which I like very much! Which one of these can be public information? If I want to be transparent I want to show both deposit and users receiving addresses (although I could in the account give an option to hide it). So, that would be public. Meaning "username" is more of a "password" and should not be public, right? |
|
|
|
With #3 I guess I need to setup some kind of account system too. With cookies, passwords and all that jazz. How does #3 work with #1 exactly? How would I best map the the transaction send address information to the users account return address?
It would probably be easiest to use #2 especially if you didn't want to bother with creating accounts or doing session management (and #1 is not recommended for both security and privacy reasons). My main goal with this was to do it how people prefer it. And, as easy as possible. But also secure. I know those don't go hand in hand, but still. Leaning towards #2 now however though, because it still enables me to be transparent which I would like to be. |
|
|
|
3. Get the user to provide a "return" address so then you don't need to try and work out where to send funds to (and works with either 1 or 2).
This has quite a few benefits, a big one being that you can be pretty damn confident you aren't going to run into unauthorized use issues. Locking accounts to return addresses also eliminates a lot of the attraction to would-be thieves (though it doesn't directly impact the attraction to fuck around in your own tables for a bigger reward). Thanks guys for quick feedback. I guess I forgot to mention that the 2 first options is really setup to keep it simple with no accounts where users have to login and stuff. With #3 I guess I need to setup some kind of account system too. With cookies, passwords and all that jazz. How does #3 work with #1 exactly? How would I best map the the transaction send address information to the users account return address? |
|
|
|
|
Hey folks,
I'm working on an idea which I plan of releasing in a week or so hopefully.
But, I'm having trouble deciding what method to use.
There are basically 2 ways you can do a bitcoin wallet payment solution.
1. Have one address which everybody sends to, and you use some magic to figure out what address the payment came from and you can send money back to.
This way the address is completely public and everybody can see what happens quite easily. However, there are restrictions as to what wallets people can send from. And might be a bit trickier to get working properly as I don't have much experience using this method myself, so I'm not sure how reliable it is to get users send addresses from the transaction information.
or
2. Create unique addresses for users to send to. Before doing this, you can just let the user specify which address that the user would like to get money to.
This is more of a controlled way to keep track of who payed what, and easy for users to specify where the money should come back. And, they can send from whatever wallet they want to. However, it's hard for anyone to see a total as one can do with the first one. I guess, one actually could just show all those addresses, and sum it up though.
What method do you guys prefer? First method is convenient, but again, you have to be careful with from where you send. And second is more controlled but less transparent (although one can make it more transparent by showing those addresses publicly as well).
Thanks,
Chillance
|
|
|
|
Forget about that SCUM! http://weeklyponzy.com/ just has started Week#2 of investments! More than 715 btc in first round. It was massive. I think this is the most popular and transparent ponzi game at this time. Better jump in that train at very start. They've paid me at first round. Seems to be a fake/scam version of weeklyponzi.com Nice try! it is :/ I just lost .2 bitcoins fml. I clicked it because the guy below vouched for him? wtf... douchebags man.. Sorry man. The guy was also fooled and was talking about ponzi, not ponzy. |
|
|
|
Ddoss atack , API problem, server problem etc etc
why this kind of system live that problems more than normal systems?
Maybe because this involves more direct money... |
|
|
|
|
Also, new people are born, and they haven't learned yet...
|
|
|
|
I put this elseware, but I think it was the wrong thread. Over the weekend, I made this tool out of curiosity at seeing how this ponzi was playing out. http://wpa.kaladinstrom.com/Let me know what you guys think That is super cool! Nicely done! |
|
|
|
|
Ponzis only benefit the first investors. And the owner of the site. And, the tail of people to be paid grows larger and larger quickly.
For example:
User #1: 1 BTC.
User #2 comes in with 1 BTC.
User #1 is still not paid.
User #3 comes in with 1 BTC.
To keep it simple, User #1 now get 1.3 BTC, but User 2 only has 0.7 BTC.
User #4 comes in with 1 BTC.
User #2 gets its 1.3 BTC, but User #3 only has 0.4 BTC...
So, as you can see, it will require more and more users, and the wait queue grows longer and longer. And I haven't even included the fee the site takes here.
|
|
|
|
My bitcoin go from my wallet (1BpymyoiQh6DJLFeE9GDThi4iMubUGqL9T) to 1hpcrqu3z58C5YoApuLQ3c3LqfsVkcPNw, then go to 12VEVLEaWW97igeKzVUxoBS28HvbUoMp74. All money for this wallet go to 1FsVcdeHbpvUVT3gjeuVR2ZSDnpcsJMsLL (now over 400 BTC). What is going on?
Probably the guy that stole it just moving them and collect it into one bigger wallet. Sorry about that man. |
|
|
|
|
Also, recent drops of bitcoin prices is surely this guy selling his btc. So, don't be alarmed and think that btc is dying...
|
|
|
|
|
Show Posts
