Random & party

Technically yes, and it is the right trade for any draw somebody might question. An unseeded draw pulls from the browser cryptographic random source, which nobody can reproduce, including us. The moment you supply a seed it has to switch to a deterministic generator, because reproducibility and unpredictability are opposites: a result you can repeat is by definition one somebody could have worked out beforehand. What you gain is worth far more in practice. Nobody has ever disputed a raffle on the grounds that the randomness was of insufficient quality.

Source: Web Cryptography API, W3C

It turns a result into something somebody else can reproduce, which is the opposite of secrecy and exactly what a contested draw needs. Give the same seed and the same list, and the same result comes out every time, so anybody can run it again and get what you got. The rule that makes it worth anything is publish the seed before the draw, not after. A seed announced afterwards proves nothing, because the person announcing it could have tried seeds until one produced the winner they wanted.

Three things, and none of them needs a notary. Publish the full list of entries before you draw, so nobody can be added or removed afterwards. Publish the seed at the same time, so the draw is reproducible. Then run it and publish the result. Anybody can now repeat it. What that does not prove is that the list was honest in the first place, and no tool can prove that, which is why the list goes out first and separately rather than alongside the winner.

Yes, and that is usually what you want rather than a flaw. Drawing without replacement, where each winner leaves the pool, means the remaining entrants odds rise with every prize drawn, and everybody can win at most once. Drawing with replacement leaves them in, so one person can win twice and the odds never move. Neither is fairer in the abstract. What is unfair is not deciding which one you are running until after somebody has won twice.

Easily, and the broken version looks completely reasonable. The classic mistake is to walk the list swapping each item with any random position in the whole list, which feels thorough and produces a measurably uneven distribution: some orders come up more often than others. The correct method swaps each item only with one at or before its own position, and it is barely different to write. Sorting a list by a random number is the other common one, and it is worse, because the result depends on the sorting algorithm.

No, and nothing can. Every combination is equally likely and no method of choosing changes that, including hot numbers, cold numbers, birthdays and patterns. What a picker can genuinely do is help you avoid sharing a prize: a great many people pick dates, so numbers above 31 are chosen less often, and obvious patterns on the slip are chosen by thousands at once. That does not change your odds of winning by a hair. It changes how many people you split with if you do.

Because a weight changes the size of the slice, and the eye reads the slice rather than the odds. Give one name three times the weight and its segment becomes three times as wide, which is honest and also makes the wheel look rigged to anybody watching who does not know the weights. The other half is that people expect weighting to guarantee proportions over a handful of spins. It does not: it changes the chance on each spin, and small numbers of spins are lumpy in exactly the way that makes people suspicious.

Public if you can, and if you cannot, publish enough beforehand that public would have added nothing. A draw watched by twenty people is trusted because everybody saw the same thing at the same moment, and that is genuinely hard to reconstruct afterwards. What gets you most of the way there is ordering: the entry list and the method go out first, the result second. Announcing only a winner is the version that generates questions, and it generates them however carefully you actually ran it.

More than you expect to sell, and print them in books rather than counting singles. The practical trap is not the number, it is what happens if you run out mid-event: a second batch has to continue the numbering, and if it restarts you now have two tickets with the same number in the same drum. Number continuously across the whole print run, keep the stubs in order, and decide before you start whether a stub or a ticket is the thing that gets drawn. Mixing those two is how a draw gets argued about afterwards.

Because a result nobody can check is worth very little in the one situation these tools exist for, which is an argument. Anything here that draws, shuffles or assigns will show you the seed, the method and the counts, so the output is a demonstration rather than an assertion. It is the same instinct as the rest of the site: say the true thing plainly and let the reader decide. A prize draw where somebody quietly disagrees and cannot examine anything is worse than not running one.