|
That does make it more difficult.
I think we reached the point of "good enough" long ago. The last big Bitcoin lottery, TAABL, just used a plain block hash, and no one complained about that.
|
|
|
|
|
You need to reinstall. wallet.dat won't be touched, and the data format didn't change between those versions.
|
|
|
|
Once a block is 'in the system' the time is set though right?
Yes. |
|
|
|
|
That should be pretty secure. Whoever gets the last block has the opportunity to do 1-3 "re-rolls" if he is really lucky. I'd hash the final hash a few trillion times just to be safe.
Some potential problems:
- It's possible that no blocks will be solved in an hour. It's happened before.
- The block time can go past 0:00, then go before 0:00 in the next block, and then go forward again. Which time is used?
Also, it's possible that a series of blocks are replaced by other blocks if the network is segmented or there is an attack going on. The blocks used to calculate the winner could be replaced after the funds are awarded. To make this less likely, you should wait at least 120 blocks after the blocks are solved before awarding anything. Reversals of that size will only happen in response to major events that you will almost certainly hear about.
|
|
|
|
It was disabled: I suspect the reason e-mails from bitcoin.org such as the validation e-mail from the wiki are getting spamblocked is because we didn't have e-mail validation turned on for the forum, so maybe spammers used the forum to set their e-mail to people they wanted to send spam to and then PM themselves so it would e-mail there. The only way to really know would be to look at the mail server logs and see if there's a large volume and what it is.
I turned on e-mail validation of new accounts on the forum, but now people can't sign up because the validation e-mail gets spamblocked. Someone said gmail is one case.
So here we are, nobody new can sign up to the forum.
It would help if we could turn off the forum's notification e-mail features. I tried to disable what I could, but it only had settings for forum thread notifications. Can someone tell me if PM notifications are still active or any e-mail notification anywhere else on the forum.
Maybe we should disable the forum's access to the e-mail server entirely, then turn off registration e-mail until we work this out further. I don't know where that setting is in the SMF interface.
|
|
|
|
|
Using time probably won't work. Whoever creates the block can specify the block time within a large range. They can even put the timestamp before the last block's timestamp.
You could just hash the block hash 200 trillion times or something to get the final hash. There's no way a miner could do that while mining.
|
|
|
|
|
That's a terrible password. You should be able to crack it in not too much time by using a bash script and GPG with the --passphrase option.
|
|
|
|
|
Whoever solves the 7th block still has the ability to choose between the 16 different starting values (assuming they have infinite CPU power), though I think mixing like that is better than not.
|
|
|
|
How do you get that windows with all the extra transaction details?! How do you enter comments?
Run with the -debug switch. Bitcoin does a lot of unnecessary extra stuff when it's in debug mode, though, so I don't recommend running in that mode all the time. I think you can only add comments through bitcoind. |
|
|
|
By getting a block I'm assuming solving it right? Yes. I wouldn't use it if changing one or two numbers is ever meaningful. If the attacker needs to get all six numbers, it's good. |
|
|
|
Got ya. So if I use the last digit it's all good. So when you say lucky how hard would it be to get the last digit to match what the person wanted?
First they need to get the block. Then, there's a 1 in 16 chance (or 1 in 10 chance if you're using decimal) that they get the right number. Probably they'll have to re-do the block a few times. So if you're really lucky, you might get one number, but getting two blocks in a row is very difficult by itself, and getting the correct number two times in a row is even more difficult. |
|
|
|
|
That's similar. You'd want to take the digits from the end, though, since the first digits after the 0 are not completely random. Or hash the hash to get a random number again.
If someone gets lucky, they might be able to change one of these digits, but even two would be almost impossible.
|
|
|
|
|
It's not easy to influence, even if there is no random number. The attacker would have to have more than 50% of the Bitcoin network's CPU to have any reasonable chance of influencing the result.
|
|
|
|
|
1. Post the hash of a random number publicly. It is not important that your random number is random, only that it is secret.
2. Pick some block number when the lottery will end. Take the hash of that block and hash it with the random number picked earlier. This is the random data you will use for the draw.
3. Post your random number.
This is immune to manipulation by players. The owner has some ability to manipulate the result, but it's very difficult. You'd need to solve a block at that exact position with a difficulty much higher than normal. You can make owner manipulation even more difficult (almost impossible) by taking winning number 1 from <end block>, number 2 from <end block>+1, etc. This would be better randomness than the Canadian lottery, probably.
|
|
|
|
|
Loans don't add much to my trust of a person, since there's no risk to the borrower. If loans added to your trust, you could quickly get up to 100,000 BTC loans by paying only a few thousand BTC in interest, and you would have no risk. Traders have the risk that their trades will lose them lots of money, so they earn more trust.
What matters most is community participation and time since joining the community, which are both expensive.
|
|
|
|
Can you define "better"?
Definitely interested in hearing ideas... The existing solutions have very poor documentation. This is the main issue. Merchant gateways should be using separate wallets so attacks against the EWallet service don't affect merchants. I consider MyBitcoin to be particularly insecure, since it accepts deposits after just 1 confirmation. Gateways should offer all the features of PayPal, such as gathering shipping info. |
|
|
|
|
A merchant gateway better that MyBitcoin's or MtGox's would be useful.
|
|
|
|
|
I've noticed that it stalls for a while at that point if you don't forward the ident port, but it should timeout after a while and continue.
|
|
|
|
|
With 0.001, a spammer can send 10,000 transactions with just 10 BTC, which seems too cheap. I think 0.01 is fine for now.
In any case, keeping transactions completely free for as long as possible is desirable. A 0.0000001 fee will seem much more expensive than "free" to people considering using Bitcoin.
|
|
|
|
|
Show Posts
