ninjaboon
Legendary
Offline
Activity: 2114
Merit: 1002
|
|
February 03, 2015, 11:36:01 AM |
|
7 players, 01 day 24 mins remaining.
|
|
|
|
Snail2
Legendary
Offline
Activity: 1512
Merit: 1000
|
|
February 03, 2015, 11:53:48 AM |
|
So, someone finally developed a honest and transparent escrowed ponzi . Good to see such things.
|
|
|
|
ndnh
Legendary
Offline
Activity: 1302
Merit: 1005
New Decentralized Nuclear Hobbit
|
|
February 03, 2015, 12:03:46 PM Last edit: February 03, 2015, 12:18:08 PM by ndnhc |
|
I believe the txid can be changed before broadcasting into the blockchain
Anyone could easily win by simply repeatedly creating raw txids without broadcasting till he gets a txid with a low hex value at the required points.
The system is proven to be fair, to select the random number that determines the order of the payouts, the 13th,14th,15th and 16th character of the deposit TX is used
Example:
TX 0278d4300340724eb37a623089c3398fdaeb34e6a00057f4837c9d3833af5dbf
Would generate this 4 hexadecimal digits 724e So that's 29262 decimal that would be your order number.
Ordered by that method, every user is paid out 135% of your bet until no more funds are available
Posted in public interest. With no intention of misusing it.
|
|
|
|
ndnh
Legendary
Offline
Activity: 1302
Merit: 1005
New Decentralized Nuclear Hobbit
|
|
February 03, 2015, 12:06:27 PM Last edit: February 03, 2015, 12:17:33 PM by ndnhc |
|
Suspicious tx in ROund #1 17 1CG1R4BimSyaFUhaEqiANLsuX28UpziYBt 0.09 0.1215 a3f12bb... [007b] 2/1/2015 9:54:03 AM UTC 123 Win d14e39c... The fact that the highest amount was put in by the same user makes it even more suspicious.
|
|
|
|
ninjaboon
Legendary
Offline
Activity: 2114
Merit: 1002
|
|
February 03, 2015, 01:20:48 PM |
|
Suspicious tx in ROund #1 17 1CG1R4BimSyaFUhaEqiANLsuX28UpziYBt 0.09 0.1215 a3f12bb... [007b] 2/1/2015 9:54:03 AM UTC 123 Win d14e39c... The fact that the highest amount was put in by the same user makes it even more suspicious.tx in question: https://blockchain.info/tx/a3f12bb4f79f007ba4589367aab8e0bcbab90a65faff1d4571de2b5c4dcded8bthe lowest amount paid could have had the lowest number too. don't get your argument on this. and the below argument might be a manual pain? Posted by: ndnhc -> Anyone could easily win by simply repeatedly creating raw txids without broadcasting till he gets a txid with a low hex value at the required points.
|
|
|
|
fluky (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 03, 2015, 04:04:55 PM |
|
Suspicious tx in ROund #1 17 1CG1R4BimSyaFUhaEqiANLsuX28UpziYBt 0.09 0.1215 a3f12bb... [007b] 2/1/2015 9:54:03 AM UTC 123 Win d14e39c... The fact that the highest amount was put in by the same user makes it even more suspicious.Thanks for the tip, didn't know about it sorry , it seems a possibility , it looks to me like a cheater, if so, I'll refund that amount to the players that lost fair playing. Now about the system, It'll be changed to the unix timestamp of the transaction, i.e. for that one https://blockchain.info/rawtx/a3f12bb4f79f007ba4589367aab8e0bcbab90a65faff1d4571de2b5c4dcded8bit would be 1422784443 = 344 I'm almost sure that couldn't be changed, what do you think?
|
|
|
|
funtotry
Sr. Member
Offline
Activity: 420
Merit: 250
Ever wanted to run your own casino? PM me for info
|
|
February 03, 2015, 04:10:57 PM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
|
|
|
|
fluky (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 03, 2015, 04:12:38 PM |
|
So, someone finally developed a honest and transparent escrowed ponzi . Good to see such things. Thanks for the props!
|
|
|
|
ninjaboon
Legendary
Offline
Activity: 2114
Merit: 1002
|
|
February 03, 2015, 10:37:41 PM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all.
|
|
|
|
funtotry
Sr. Member
Offline
Activity: 420
Merit: 250
Ever wanted to run your own casino? PM me for info
|
|
February 03, 2015, 11:22:59 PM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me
|
|
|
|
ndnh
Legendary
Offline
Activity: 1302
Merit: 1005
New Decentralized Nuclear Hobbit
|
|
February 04, 2015, 01:56:54 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me That is a better alternative.
|
|
|
|
fluky (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 04, 2015, 01:58:38 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me Thanks for your reply, You say that the unix time stamp can be changed? The value will be taken from the "received time" by blockchain.info that value can't be changed, can it? Also 00 will win over 01 because the number would be taken from the 3 first digit of the inversed unix time: like 1422265904 = 409. Althought the players could try to get it in the lowest digit it's very easy to fail and get a higher number. Another option is adding the TXID with the hash of the block-height where it was included then hashed again, that way I think there's no way it can be changed, what do you think? Btw, while this get sorted out, the round will be increased by 24 hrs. Btw, we've noticed some other strange transactions.
|
|
|
|
ndnh
Legendary
Offline
Activity: 1302
Merit: 1005
New Decentralized Nuclear Hobbit
|
|
February 04, 2015, 02:07:25 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me Thanks for your reply, You say that the unix time stamp can be changed? The value will be taken from the "received time" by blockchain.info that value can't be changed, can it? Also 00 will win over 01 because the number would be taken from the 3 first digit of the inversed unix time: like 1422265904 = 409. Althought the players could try to get it in the lowest digit it's very easy to fail and get a higher number. Another option is adding the TXID with the hash of the block-height where it was included then hashed again, that way I think there's no way it can be changed, what do you think? Btw, while this get sorted out, the round will be increased by 24 hrs. Btw, we've noticed some other strange transactions. Yeah, good thing the order is reversed. I think it is okay. Most games like this hash the txid and use it to determine the winner, etc. I personally use blockchain wallet, on which doing so is either not possible or unknown? Just check it with someone else, since personally I am not so much into bitcoin and blockcain tech.
|
|
|
|
ndnh
Legendary
Offline
Activity: 1302
Merit: 1005
New Decentralized Nuclear Hobbit
|
|
February 04, 2015, 02:12:11 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me Thanks for your reply, You say that the unix time stamp can be changed? The value will be taken from the "received time" by blockchain.info that value can't be changed, can it? Also 00 will win over 01 because the number would be taken from the 3 first digit of the inversed unix time: like 1422265904 = 409. Althought the players could try to get it in the lowest digit it's very easy to fail and get a higher number. Another option is adding the TXID with the hash of the block-height where it was included then hashed again, that way I think there's no way it can be changed, what do you think? Btw, while this get sorted out, the round will be increased by 24 hrs. Btw, we've noticed some other strange transactions. Yeah, good thing the order is reversed. I think it is okay. Most games like this hash the txid and use it to determine the winner, etc. I personally use blockchain wallet, on which doing so is either not possible or unknown? Just check it with someone else, since personally I am not so much into bitcoin and blockcain tech. I rechecked, but I think I could myself be able to use this to win. Do you want me to do a check? All i take is probably a few tries and I will come up with a good method to do it. Can you provide an address for me to check? (I have helped many sites with similar and different explitable systems, and I don't make a profit out of this. You can trust me. I will use only small amounts to check. and to your address so that you can see, please return the amount after the test.)
|
|
|
|
bobc1994
|
|
February 04, 2015, 03:09:02 AM |
|
this is generated from random numer ? Provably Fair ?
|
|
|
|
fluky (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 04, 2015, 03:43:12 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me Thanks for your reply, You say that the unix time stamp can be changed? The value will be taken from the "received time" by blockchain.info that value can't be changed, can it? Also 00 will win over 01 because the number would be taken from the 3 first digit of the inversed unix time: like 1422265904 = 409. Althought the players could try to get it in the lowest digit it's very easy to fail and get a higher number. Another option is adding the TXID with the hash of the block-height where it was included then hashed again, that way I think there's no way it can be changed, what do you think? Btw, while this get sorted out, the round will be increased by 24 hrs. Btw, we've noticed some other strange transactions. Yeah, good thing the order is reversed. I think it is okay. Most games like this hash the txid and use it to determine the winner, etc. I personally use blockchain wallet, on which doing so is either not possible or unknown? Just check it with someone else, since personally I am not so much into bitcoin and blockcain tech. I rechecked, but I think I could myself be able to use this to win. Do you want me to do a check? All i take is probably a few tries and I will come up with a good method to do it. Can you provide an address for me to check? (I have helped many sites with similar and different explitable systems, and I don't make a profit out of this. You can trust me. I will use only small amounts to check. and to your address so that you can see, please return the amount after the test.) Sure, you can test here 18aR3Buve9nFMrhEpVxxaBku3Kg2sxjU6W I'll return your amount, and a little tip after you finish. You'll try the timestamp method right?
|
|
|
|
funtotry
Sr. Member
Offline
Activity: 420
Merit: 250
Ever wanted to run your own casino? PM me for info
|
|
February 04, 2015, 03:50:39 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me Thanks for your reply, You say that the unix time stamp can be changed? The value will be taken from the "received time" by blockchain.info that value can't be changed, can it? Also 00 will win over 01 because the number would be taken from the 3 first digit of the inversed unix time: like 1422265904 = 409. Althought the players could try to get it in the lowest digit it's very easy to fail and get a higher number. Another option is adding the TXID with the hash of the block-height where it was included then hashed again, that way I think there's no way it can be changed, what do you think? Btw, while this get sorted out, the round will be increased by 24 hrs. Btw, we've noticed some other strange transactions. Timestamp cant be changed but you can still resent the tx if the time received is bad. Also anyone can hash block height with the txid and then resent if its bad. Maybe hash the block hash of the next block that it confirms in, I am not sure if you can guess the next block hash but I dont think you can.
|
|
|
|
fluky (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 04, 2015, 04:04:58 AM |
|
this is generated from random numer ? Provably Fair ?
Yes! For the first round it was based on some digits of the txid of the deposit (the 1st post has details), but we noticed one player probably tried to alter it to gain advantage, so we're testing and deciding if we go with the unix timestamp of the deposit. i.e. b1efe3ed66420f5c0956dfab0f17baaf08626a763d59501d92f3790c4a1071a9 1423018427 = 724or with the txid + hash of the next block from the block_height that included the transaction, then hashed, then the 13,14,15,16 digit then to decimal, like this: b1efe3ed66420f5c0956dfab0f17baaf08626a763d59501d92f3790c4a1071a9 So: b1efe3ed66420f5c0956dfab0f17baaf08626a763d59501d92f3790c4a1071a9 + 00000000000000000fbceb08d7f309339f2307a5941104dace6da723077f112c (That's the next block hash of the block-height 341854 which included that transaction) Then hashed it's: 4b6ecf89594caff0ef2528e636ee682b774e30ae7a180d534a8e9dc2178081b2 So the digits are: aff0 So the draw number would be: 45040 But, every method can be checked and verified by all users so yes it's provably fair.
|
|
|
|
fluky (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 04, 2015, 04:18:52 AM |
|
I took your advice @funtotry, thx!, and put it in the previous post what do you think?
|
|
|
|
ndnh
Legendary
Offline
Activity: 1302
Merit: 1005
New Decentralized Nuclear Hobbit
|
|
February 04, 2015, 04:56:22 AM |
|
Problem with the system i could keep submitting raw hex transactions and keep going for the tx id that I want, and don't broadcast it if its a txid that makes you win. Maybe hash the tx with a secret key, and you provide the sha256 hash of that secret key to verify that you aren't change it. This would make the random number not predictable if you don't know the secret key, which is released at the end of the day (week in this case)
makers sense now. Fluky will be using the unix timestamp from now. thanks all. Unix timestamp with milliseconds, seconds can be changed, also with the timestamp can't you just end at 01 seconds instead of 60 and be in first? Doesn't make sense to me Thanks for your reply, You say that the unix time stamp can be changed? The value will be taken from the "received time" by blockchain.info that value can't be changed, can it? Also 00 will win over 01 because the number would be taken from the 3 first digit of the inversed unix time: like 1422265904 = 409. Althought the players could try to get it in the lowest digit it's very easy to fail and get a higher number. Another option is adding the TXID with the hash of the block-height where it was included then hashed again, that way I think there's no way it can be changed, what do you think? Btw, while this get sorted out, the round will be increased by 24 hrs. Btw, we've noticed some other strange transactions. Yeah, good thing the order is reversed. I think it is okay. Most games like this hash the txid and use it to determine the winner, etc. I personally use blockchain wallet, on which doing so is either not possible or unknown? Just check it with someone else, since personally I am not so much into bitcoin and blockcain tech. I rechecked, but I think I could myself be able to use this to win. Do you want me to do a check? All i take is probably a few tries and I will come up with a good method to do it. Can you provide an address for me to check? (I have helped many sites with similar and different explitable systems, and I don't make a profit out of this. You can trust me. I will use only small amounts to check. and to your address so that you can see, please return the amount after the test.) Sure, you can test here 18aR3Buve9nFMrhEpVxxaBku3Kg2sxjU6W I'll return your amount, and a little tip after you finish. You'll try the timestamp method right? Yes I will be checking the timestamp method.
|
|
|
|
|