FlukyBet.com WIN 135% of your bet, 75+ % of players WIN [3rd Party escrow used]

[ninjaboon]

7 players, 01 day 24 mins remaining.

[Snail2]

So, someone finally developed a honest and transparent escrowed ponzi . Good to see such things.

[ndnh]

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]

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]

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/a3f12bb4f79f007ba4589367aab8e0bcbab90a65faff1d4571de2b5c4dcded8b

the 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]

http://cs621422.vk.me/v621422036/bc29/-JaBDqXykUw.jpg

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/a3f12bb4f79f007ba4589367aab8e0bcbab90a65faff1d4571de2b5c4dcded8b

it would be 1422784443  = 344

I'm almost sure that couldn't be changed, what do you think?

[funtotry]

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]

So, someone finally developed a honest and transparent escrowed ponzi . Good to see such things.

Thanks for the props!  

[ninjaboon]

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]

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]

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]

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]

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]

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]

this is generated from random numer ? Provably Fair ?

[fluky]

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]

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]

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 = 724

or 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]

I took your advice @funtotry, thx!, and put it in the previous post what do you think?

[ndnh]

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.