Bitcoin Forum
June 16, 2024, 03:50:58 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: [ANN] Bitcointalk Giveaway Manager  (Read 731 times)
Pmalek
Legendary
*
Offline Offline

Activity: 2800
Merit: 7201



View Profile
January 27, 2023, 07:24:48 PM
 #21

I might sound like an unknowledgeable jackass, but what is the problem with random.org and why can't it be used for all kinds of random draws?

Is it the 'it's closed-source so we don't like it' problem or something else? Is there proof the randomness is unsatisfactory?
I fail to see the motive of random.org creators to built a non-random generator that shows a tendency to certain selections over others. Especially because they don't know what kind of selection and for what purpose the software is being used.

I understand that 3rd-parties can't verify that the selection was indeed random and drawn only once. Therefore, there is a need to trust whoever makes the draw to have done it fairly and not generate draws until the number/numbers he wants comes up. Is that the main reason or is there something else?

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
bitmover (OP)
Legendary
*
Offline Offline

Activity: 2338
Merit: 6008


bitcoindata.science


View Profile WWW
January 27, 2023, 08:03:04 PM
 #22

I might sound like an unknowledgeable jackass, but what is the problem with random.org and why can't it be used for all kinds of random draws?

I didn't know this website until now, but let me point a few things this tool can do (I don't know if random.org can do all of not  , but probably not all)

1 - code and results easily verified. No trust involved.
2 - it uses blockhash of a block to select multiple winners, which is already a culture of this forum for a long time.
3 - it allows anyone to share the results here in a simple URL.
4 - easy to use. Random.org is much more complicated as it is much bigger.
5 - you will always get the same winner no matter how many times you roll

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
Pmalek
Legendary
*
Offline Offline

Activity: 2800
Merit: 7201



View Profile
January 28, 2023, 07:24:42 AM
 #23

1 - code and results easily verified. No trust involved.
...
3 - it allows anyone to share the results here in a simple URL.
...
5 - you will always get the same winner no matter how many times you roll
It essentially boils down to creating a system where each participant has a way to check that the draw was fair and not staged. The fairness is already guaranteed using the hash method of an upcoming block as you mentioned. But this improves and builds upon that idea with more advanced features.

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
PowerGlove
Hero Member
*****
hacker
Offline Offline

Activity: 526
Merit: 4294



View Profile
January 30, 2023, 05:14:20 AM
Merited by LoyceV (8), bitmover (6)
 #24

Thank you a lot for pointing this out.
No problem, happy to help. Smiley

I believe this will solve the problem in a much simpler way. What do you think?
Hmm, that's getting a bit too hacky I would say (i.e. adding one imperfect approach onto another). It's worth pointing out that if you did have a good way to shuffle the participants (e.g. with a modern variant of the Fisher-Yates algorithm, and enough entropy to feed it with) then you wouldn't need anything else, because after a properly-executed shuffle you could simply read off the winners according to position (i.e. index 0 = winner 1, index 1 = winner 2, etc.)

Shuffling is actually a very natural way to think about this problem, and the code I provided earlier is capable of doing a "perfect" (unbiased) shuffle. If you call pick_winners_unbiased with a list of (let's say) 50 names and you ask it to return 50 winners, then what results is a shuffled version of the original list.

Sorry to be discouraging, but I don't think the approach you've settled on (i.e. using the available entropy directly, and coming up with an improvised scheme to generate a sequence of random numbers) is one that you should stick with for too long. Stretching out the entropy (with a cryptographic hash function, like Loyce and I have suggested) will let you explore better algorithms (and remove the limit on the number of winners, too).

Your algorithm suffering from "modulo bias" is not that much of a big deal (particularly for this application, and especially with the divisors being so much smaller than your random numbers), but it's a strong indication that you've probably gotten other details wrong, too. For example, the way you're prepending an extra hexadecimal digit for each winner beyond the first one, seems very sketchy to me. Aside from it having no mathematical basis for working correctly (at least, not one that I can see), that approach will overflow; after around 8 "steps" you'll start to lose precision (i.e. you'll be passing things into parseInt that are greater than Number.MAX_SAFE_INTEGER).

One way to test the quality of algorithms like these is to run simulations and compute histograms. So, I simulated 1,000,000 giveaways between 30 participants using your algorithm. In each giveaway "LoyceV" was included in the list of participants with 29 other names. Here's how many times LoyceV won, or came second, or third, etc:



For reference, here's the same simulation data run through the algorithm I proposed earlier:



Now, one of these is clearly working correctly and the other needs a little help. Cheesy

If you feel like I must have made some kind of mistake, then feel free to replicate my results:

  • Use the first 30 names from my previous post as the list of participants.
  • Keep an array H of 30 integers, initialized to 0.
  • Keep a running counter T set to the current trial # (from 0 to 999,999).

Then, do this 1,000,000 times:

  • Compute an imaginary "blockhash" by taking the SHA-256 of T (as a string; e.g. "0" == "5feceb66ffc86f38d952786c6d696c79c2dbc239dd4e91b46729d73a27fb57e9").
  • Pick 30 winners from the list of participants using your algorithm and the above blockhash.
  • Find the position of "LoyceV" in the list of winners and increment H accordingly.

My suggestion to you would be to take a more careful look at my previous post. But, if you're committed to sticking with your approach (which you seem to be), then I suggest changing this line:

Code:
let n_winner_decimal = parseInt(blockhash.slice(-(6 + step)), 16)

To this:

Code:
let n_winner_decimal = parseInt(blockhash.slice(-(6 + step), blockhash.length - step), 16)

That will improve things quite a bit (both by avoiding overflow, and also by producing a less correlated sequence). With the above fix applied, your histogram looks very similar to mine:

LoyceV
Legendary
*
Offline Offline

Activity: 3346
Merit: 16832


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
January 30, 2023, 09:01:58 AM
Merited by bitmover (3)
 #25

For example, the way you're prepending an extra hexadecimal digit for each winner beyond the first one, seems very sketchy to me. Aside from it having no mathematical basis for working correctly (at least, not one that I can see), that approach will overflow; after around 8 "steps" you'll start to lose precision (i.e. you'll be passing things into parseInt that are greater than Number.MAX_SAFE_INTEGER).
An easy fix would be to remove a digit on the right when adding one on the left.

Quote
One way to test the quality of algorithms like these is to run simulations and compute histograms. So, I simulated 1,000,000 giveaways between 30 participants using your algorithm. In each giveaway "LoyceV" was included in the list of participants with 29 other names. Here's how many times LoyceV won, or came second, or third, etc:
Without checking the math, a question: did you remove one participant each time you calculated a next winner? The 0 wins at 15th (16th?) makes me think you didn't.

Quote
If you simulated 1 million giveaways and made a graph for places 1-30, why is the average around 33,333, and not 1 million?

bitmover (OP)
Legendary
*
Offline Offline

Activity: 2338
Merit: 6008


bitcoindata.science


View Profile WWW
January 30, 2023, 12:48:05 PM
 #26

Shuffling is actually a very natural way to think about this problem, and the code I provided earlier is capable of doing a "perfect" (unbiased) shuffle. If you call pick_winners_unbiased with a list of (let's say) 50 names and you ask it to return 50 winners, then what results is a shuffled version of the original list.

This kind of approach will not work for 2 reasons:

1 - not verifiable by third party and cannot be reproduced.
2 -  don't use blockhash, which is a "must" for this project, as this is a deep culture in forum giveaways.

For example, the way you're prepending an extra hexadecimal digit for each winner beyond the first one, seems very sketchy to me. Aside from it having no mathematical basis for working correctly (at least, not one that I can see), that approach will overflow; after around 8 "steps" you'll start to lose precision (i.e. you'll be passing things into parseInt that are greater than Number.MAX_SAFE_INTEGER).
An easy fix would be to remove a digit on the right when adding one on the left.

Thats a very good idea, I will implement it.

But also, I believe giveaways with more than one winner are quite unusual, and we won't see this is a lot here.

Anyway, I will implement LoyceV idea to remove a digit when adding another

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
PowerGlove
Hero Member
*****
hacker
Offline Offline

Activity: 526
Merit: 4294



View Profile
January 30, 2023, 01:55:49 PM
Merited by LoyceV (12)
 #27

An easy fix would be to remove a digit on the right when adding one on the left.
Did you read my whole post? Tongue

Without checking the math, a question: did you remove one participant each time you calculated a next winner? The 0 wins at 15th (16th?) makes me think you didn't.
Yes. That's a pretty essential detail, so I made sure to get it right.

With bitmover's algorithm, where you appear in the list of participants (in your case, near the middle) affects the probabilities of where you'll appear in the list of winners (which is a sign that something is very wrong). For example, here's the same simulation, but done for o_e_l_e_o (who's near the end of the participants list):



And here's how it looks (i.e. as it should) when repeated with the reference algorithm:



If you simulated 1 million giveaways and made a graph for places 1-30, why is the average around 33,333, and not 1 million?
Hmm, these graphs must be much more confusing than I think they are. 1,000,000 simulated outcomes distributed between 30 "bins", leaves each bin with ~33,333 (on average).



An easy fix would be to remove a digit on the right when adding one on the left.
Thats a very good idea, I will implement it.
I don't know how both of you have managed to miss the fact that I suggested that. Cheesy
LoyceV
Legendary
*
Offline Offline

Activity: 3346
Merit: 16832


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
January 30, 2023, 05:08:16 PM
Last edit: January 30, 2023, 06:06:34 PM by LoyceV
Merited by PowerGlove (4)
 #28

Did you read my whole post? Tongue
Lol, no, I missed clearly the last part.

Quote
With bitmover's algorithm, where you appear in the list of participants (in your case, near the middle) affects the probabilities of where you'll appear in the list of winners (which is a sign that something is very wrong).
Thanks for simulating this, otherwise it could have gone unnoticed for a very long time! O_e_l_e_o's graph doesn't look like what I expected at all.

Quote
I don't know how both of you have managed to miss the fact that I suggested that. Cheesy
We're not alts Tongue

bitmover (OP)
Legendary
*
Offline Offline

Activity: 2338
Merit: 6008


bitcoindata.science


View Profile WWW
January 30, 2023, 09:28:20 PM
Merited by PowerGlove (4)
 #29

An easy fix would be to remove a digit on the right when adding one on the left.
Thats a very good idea, I will implement it.
I don't know how both of you have managed to miss the fact that I suggested that. Cheesy

Just added your suggestions here




I also add a feature to tell when the future block will be mined, considering 10 minutes per block.


.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
bitmover (OP)
Legendary
*
Offline Offline

Activity: 2338
Merit: 6008


bitcoindata.science


View Profile WWW
February 01, 2023, 03:51:29 PM
 #30

I am happy to announce that this tool is already being used, and it was first used in this giveaway :
https://bitcointalk.org/index.php?topic=5437138.0;all

Results can be verified in this link
shareable result


I am open for ideas for similar projects!

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
examplens
Legendary
*
Offline Offline

Activity: 3318
Merit: 3264


Crypto Swap Exchange


View Profile WWW
February 07, 2023, 01:03:52 PM
Merited by bitmover (1)
 #31

I am happy to announce that this tool is already being used, and it was first used in this giveaway :
https://bitcointalk.org/index.php?topic=5437138.0;all

Results can be verified in this link
shareable result


I am open for ideas for similar projects!

you responded well to the giveaway transparency problem, the solution has already been used.

why didn't you integrate it with your main site?
on these giveaway pages, you could at least have a menu linked. There are some interesting tools there, why not inform the giveaway visitors about them?
Just my 2c.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
bitmover (OP)
Legendary
*
Offline Offline

Activity: 2338
Merit: 6008


bitcoindata.science


View Profile WWW
February 07, 2023, 07:38:52 PM
 #32

you responded well to the giveaway transparency problem, the solution has already been used.

why didn't you integrate it with your main site?
on these giveaway pages, you could at least have a menu linked. There are some interesting tools there, why not inform the giveaway visitors about them?
Just my 2c.

Thanks your suggestion. you are right about them.

The point is that this website needs a new version.
Most of the stuff there is somehow broken already. API changed, many web standards changed, my skills improved and so on. There are many broken links as well.

I need to change so many things there. I also need to figure out a different model for it.

I might make something in react.

Edit: For example, I just took a look at the website and I saw that the most used tool (balance checker) is down because mempool.space changed their API structure. I will try to fix it soon.

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
PowerGlove
Hero Member
*****
hacker
Offline Offline

Activity: 526
Merit: 4294



View Profile
February 08, 2023, 11:43:45 AM
Merited by bitmover (1)
 #33

Shuffling is actually a very natural way to think about this problem, and the code I provided earlier is capable of doing a "perfect" (unbiased) shuffle. If you call pick_winners_unbiased with a list of (let's say) 50 names and you ask it to return 50 winners, then what results is a shuffled version of the original list.

This kind of approach will not work for 2 reasons:

1 - not verifiable by third party and cannot be reproduced.
2 -  don't use blockhash, which is a "must" for this project, as this is a deep culture in forum giveaways.
Hmm, we must have our wires crossed somewhere because both of those points are wrong. Let me try again: I'm saying that if you were to call pick_winners_unbiased (from this post) with the blockhash as the "seed" and with the same number of winners as there are contestants, then you would have performed a completely deterministic shuffle. By deterministic I mean that it would always come out the same way (which is your first point) and that the particular way it comes out would depend on the blockhash (which is your second point).

I think maybe I overcomplicated that post with too many ideas (modulo bias, rejection sampling, HMACs, using the SubtleCrypto interface, etc.) and that (as a result) you didn't properly understand the code. Smiley

I'm not suggesting that you switch to shuffling, I'm just pointing out that it would work correctly and that you already have everything you need if you decided to approach the problem from that angle.

I think your algorithm (since the overflow fix) is fine as is, and it has the important advantage of being simple to understand (and easy to explain). But, if you wanted to remove the 30-winner limit, and you wanted to keep things simple (no rejection sampling), then one way to do it (since you're already using CryptoJS) would be to change these two lines:

Code:
let decimal = parseInt(blockhash.slice(-6), 16)

Code:
let n_winner_decimal = parseInt(blockhash.slice(-(6 + step), blockhash.length - step), 16)

To these:

Code:
let decimal = parseInt(CryptoJS.HmacSHA256("0", blockhash).toString(CryptoJS.enc.Hex).slice(-8), 16)

Code:
let n_winner_decimal = parseInt(CryptoJS.HmacSHA256(String(step), blockhash).toString(CryptoJS.enc.Hex).slice(-8), 16)

That would adjust the range of your random numbers from 0-16777215 to 0-4294967295 (making modulo bias even less of a problem) and would let you pick as many winners as you like.

Here's a simulation/histogram (same parameters as before) to confirm that the above algorithm works as expected:

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!