Got my BFL Single today and I'm raffling it away for 0.5BTC!

[wogaut]

I'm going to hang myself if c267a549d21a37b371b8d4fa5b944d55bd5624dfcc735f4045031fd53a640bff didn't win

Congrats, man!

Happy mining!

[danieldaniel]

Well this was fun.

I'm emailing the winner right now with instructions on how to earn his BFL single by completing some simple offers online and answering some surveys.

Hehe.  You're so mean!

[Garr255]

Ha nice, I hope your humor will be incorporated into your magazine

[Matthew N. Wright]

Ha nice, I hope your humor will be incorporated into your magazine

They're trying their best to stop me.

[draco49]

send congrats to degreal@gmail.com

Congratulations on winning this exciting, if not bizarre, raffle!  Go forth and mine some coinage

[deepceleron]

The only issue is the "remainder" greater than the max multiple.

10 hex digits = 16^10 = 1099511627776

1099511627776 / 40270 = 27303492.12  (that last 0.12 is unfair)

So max valid random number is 40270 * 27303492 = 1099511622840

Matt a "fix" is simple and fair.

If the value of last 10 digits of the block hash is > 1099511622840 then it is a "no-go" and you use the next block.

Don't worry the odds of that happening are very small.  Only 1099511622841 to 1099511627776 are "bad".  4936 unfair numbers out of 1099511627776 or 0.0000004%

I have updated my raffle ticket picker here: http://we.lovebitco.in/raffle.html. It will now alert you if the hash is greater than the last modulo interval with a full number of tickets (however you would describe that). Just so everyone knows they have an absolutely equal chance of winning.

Feel free to pore over the javascript source and try to break it or find any type of unfair calculation. As an example, in this raffle (with tickets 0-40269), the highest hash without error is FFFFFFECB7, which gives #40269 as winner; FFFFFFECB8 or higher gives an error.

Large hashes near the maximum are also only a problem if 0x10000000000h is not evenly divisible by the number of tickets. For example, with 65536 tickets (0x010000h), a hash of FFFFFFFFFF is still valid.

BTW, even with a raffle happening every block, this would likely never happen in your lifetime...

[Red Emerald]

I have updated my raffle ticket picker here: http://we.lovebitco.in/raffle.html.

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

[deepceleron]

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

I didn't like that, it becomes easier for a raffle operator to disguise his own fake entries (instead of showing forum user names, etc., which allows us to intuit that every ticket purchase in the list is legitimate).

[wogaut]

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

I didn't like that, it becomes easier for a raffle operator to disguise his own fake entries (instead of showing forum user names, etc., which allows us to intuit that every ticket purchase in the list is legitimate).

Not sure that clear text email entries help that much. One can easily create a series of different email addresses that really have the same owner.

[deepceleron]

I have updated my raffle ticket picker here: http://we.lovebitco.in/raffle.html.

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

Done. Works for emails, I'm not doing any input validation, so you can probably confuse it by pasting a bunch of junk into the input field.

[kano]

I have updated my raffle ticket picker here: http://we.lovebitco.in/raffle.html.

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

Done. Works for emails, I'm not doing any input validation, so you can probably confuse it by pasting a bunch of junk into the input field.

Don't forget to lower case the input for those who don't realise that upper/lower case is not relevant in email addresses

[deepceleron]

I have updated my raffle ticket picker here: http://we.lovebitco.in/raffle.html.

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

Done. Works for emails, I'm not doing any input validation, so you can probably confuse it by pasting a bunch of junk into the input field.

Don't forget to lower case the input for those who don't realise that upper/lower case is not relevant in email addresses

People just need to remember how they typed their email address. You can not alter the case in email addresses, as they can be case-sensitive.

rfc5321 says:
The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts.  In particular, for some hosts, the user "smith" is different from the user "Smith".

If a user inputs inputs the domain part of an email address in upper case, then bit-pay should not accept the invalid domain, instead alerting the user that they are a retard.

[kano]

LOL it took until 2008 for someone to realise that MS had messed that up in Exchange and write an RFC that was actually wrong?
I wonder how hard it is to delete an RFC that someone came up with.
... and why did anyone bother to agree to that

Do any mail servers except exchange do that "MUST BE"?
I'm pretty sure the majority of mail servers on the internet don't do that.

Edit: Ah - OK, I read that again.
The case is not relevant in the email address, it's just that computer accounts can have case sensitivity so a mail server that uses the front part of the address to determine the account name on the server may screw that up ...
Still, not a problem for anyone who uses the norm like e.g. virtusertable on sendmail.

[deepceleron]

LOL it took until 2008 for someone to realise that MS had messed that up in Exchange and write an RFC that was actually wrong?
I wonder how hard it is to delete an RFC that someone came up with.
... and why did anyone bother to agree to that

Do any mail servers except exchange do that "MUST BE"?
I'm pretty sure the majority of mail servers on the internet don't do that.

http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

If there's a difference between standards and how Microsoft does stuff, it is because Microsoft does stuff wrong.

Your mail server may send either kano or Kano or even KANO@ emails to your email box. My email server might send deepceleron@ and DeepCeleron@ to different mailboxes. Nothing along the line can mess with the case of the email address that you type in to email me, otherwise deepceleron might get DeepCeleron's email.

[kano]

Didn't notice the new page when I added an edit to my comment.
Yes I do realise that about Microsoft
The only time I know of where they failed to do that was with Java - thankfully.
I have vowed ever since that incident to never use C# (as I never have) since that is basically the reason why MS has C#.

[DeathAndTaxes]

C# is an international open standard.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42926

[notme]

C# is an international open standard.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42926

But .Net is a layer on top of C# with strong encouragement of private APIs.  I couldn't watch the olympic streaming last time because of their lame shit.

Thankfully, this year NBC is going with youtube over silverlight.

[DeathAndTaxes]

What does .net have to do with C#?   

C# + mono framework = open source
C# + .net framrwork = closed source

C++ + open source API = open source
C++ + closed API = closed source

[notme]

What does .net have to do with C#?   

C# + mono framework = open source
C# + .net framrwork = closed source

C++ + open source API = open source
C++ + closed API = closed source

Nothing, other than it is an example of the "extend" part of "embrace and extend".  They leave off the "extinguish" for home-grown technologies like C#.

Also, I have a hatred for using .Net C# APIs because their documentation is lousy.  Open source doesn't always have the greatest documentation (although it often does have great documentation), but where it lacks it is easy enough to dig in and see what the code is actually doing.  If you want to add a feature, you submit a patch and it gets added.

Proprietary software harshes my mellow when I code, and the mellow is why I code.

[Matthew N. Wright]

You should add a thing to sha256 a text field.  I liked having the list of emails be hashes.

I didn't like that, it becomes easier for a raffle operator to disguise his own fake entries (instead of showing forum user names, etc., which allows us to intuit that every ticket purchase in the list is legitimate).

I also didn't like having to do that and didn't plan on it originally, but I didn't provide a disclaimer on the Bit-Pay site that the email address provided would be published publicly, so I thought it was unfair to do so regardless of what the thread said.

As for verifying uniqueness:

• There is no way to do that anyway. E-mail addresses are free, you know?
• It wouldn't matter anyway because the original has a link to the paid invoices, so even if the operator was buying tickets himself, it doesn't give him any advantages over anyone else in itself.