Topic: A couple of questions/comments (Read 4758 times)

He did it!

I already sent 100 BTC. So I hope the author will fix it.

Take care your money!

It seems that Bitcoin Darts does not work. Is an author ok?

I can generate many signatures and pick one so that the user has lost his money.

I can recast my solution in terms of ECDSA signatures, the security of which is a prerequisite for the correct operation of Bitcoin. This might reassure you.

A simpler, essentially equivalent (but actually unsuitable) method is the following.

When you receive a the payment transaction, you sign it with your public key. You use the signature as the result of your dart throw or random numbers or whatever. Everyone can verify that signature using your published public key to check that the calculation is correct.

Puzzle: Can anyone else work out why the RSA solution is appropriate and the ECDSA solution is not?

ByteCoin

This is exactly safe? Has anyone checked?


You can describe this in detail? I do not understand this point.

Suddenly puzzled problem of generating a checkable (auditable?) random numbers

This is a nice problem! Public key cryptography to the rescue!
What you need to do is generate an RSA public and private key.
n=p*q where p and q are large primes.
Choose e, 3 or 65537 are popular choices
Calculate d = 1/e mod (p-1)(q-1)
You publish the public key (n,e) on the webside while keeping the secret key (d) private.
When you recieve the payment information, you generate a number x less than n in a verifiable, previously published fashion from the transaction information that nobody can change and everyone can verify.
You calculate  s = x^d mod n, send it to the dart thrower and use that to determine the result of the dart throw in a previously published fashion and then send him winnings if any.
The dart thrower can verify that the dartboard has done the maths correctly by calculating x from the payment and verifying that s^e mod n =x.
The dart thrower can't engineer his transaction to win the darts because he can't compute x^d mod n.
The dartboard can't change any parameters to say that the thrower has not won when he has.

ByteCoin
  

I recently intentionally lost about 1,000 BTC playing darts. Is someone ready to win it?

P.S. Subscription to full statistics is still available: link.

By this time we will have light clients without the need to have
all blocks and also all data will be compressed. Or anyone (who
does not generate blocks) will use MyBitcoin-like services. 

i have a question
Right now folder "Bitcoin" in "Application data" has a size of 80 MB. What size will be this folder in a year... in a few years?

If someone needs a subscription to the Bitcoin Darts full statistics, just contact me.



Just got 1000%!

It's set so the double bullseye at maximum bet will take half or less of what is available (meaning the current balance minus what is already scheduled to go out assuming it gets confirmed properly), there's enough delay in the system that I don't want it to run into problems from a couple big winners playing at about the same time.

I am rather surprised by the number of plays it has gotten already for just being a simple test project.  Maybe I need to set it up with some affiliate tracking and see what it does if someone started pushing it 

I don't really see the harm. It isn't too important though, so if anyone does care then maybe it is better to not.

Are you setting the max bet so that the double bullseye will take most of what you have, or are you more conservative than that? Can I get in as a backer before I lose all my coins? ;-)

The requested max bid is automatic based on what kind of balance it has available, it'll change as people play and is basically there as a warning so you don't start bidding more than it has available to pay off.  Was close for a while, I know the recommended max had dropped to 0.1 earlier this afternoon but for now it seems to have more of a reserve built up.

Only issue with having the play again autofill the address is that there is no authentication on any of those pages, you can fill in any transaction id and it will give the page for it.  I don't put the amounts or address on that page for that reason either.  To do otherwise would require some sort of registration and account and it was intended more as something to try quickly (and relatively anonymously) without needing an account.

Would it actually be a problem if the return address was available to anyone?  I suppose they are visible to anyone as they cross the bitcoin network anyway, not sure if having it available on the page would give any more information than could be gotten anyway.  I suppose I'm just accustomed to being very careful with any data entered by the user that may be private, if there isn't any harm done by having the addresses show it could easily be changed to use the same return address automatically for the next play.

Very cool.

Purple
Green
Triple Green
Red

It takes quite a few clicks to throw one dart. Not much can be done about the open client, copy, paste, type 1, press send - at least not yet. But "play again" could assume the same receiving address, and give you the send to addy right away.

Edit: I just saw that it is 2BTC now!
Woah: 5 now, have you added a lot of coins? Will it go higher?

That is kind of what I had gathered from my brief look through the code but I didn't want to just assume there wasn't anything to use.  It's not really a necessity, I just like the idea of it being verifiable.  I am using the highres timestamp so it has microsecond precision and shouldn't be easily predicted given normal variances in network speed and the number of hops to be received, for my purposes it should be as good as I'd get from a PRNG.


I see.  Given the way that it works now there is a good 10-15 second delay anyway, I suppose what this means is just that if I do end up moving the bitcoind closer to the webserver I should just artificially maintain that delay.


Will look into it.  For now I can run the full GUI version without a problem but again if I were to move it out onto one of the webservers I would want to make sure there was some way to get at that information just in case.

Thanks for your responses, enjoy your winnings

Cool game! I won 2 BTC!


Nothing like that exists. The user knows the entire transaction before everyone else does, and nothing is ever added to it by other nodes. The info+timestamp system probably isn't secure, either, since you can guess most of this info. Just use a random number. If someone wants to verify your honesty, they can look at the randomness of the results.


It's possible. Worst case:

- Attacker sends the first transaction only to you.
- You accept the transaction and relay it to your eight peers.
- Attacker doesn't like his results. He creates a double-spending transaction back to himself and sends it to 5,000 peers.
- Attacker is very likely to reach more nodes than you will, and will therefore probably win.

The attack is made much more difficult when the attacker can't connect directly to you (which he can't in your case). A 10-second delay between accepting the transaction and showing the result would nearly eliminate the attacker's chance of beating you. You can also run Bitcoin with -maxconnections=100 to increase the number of peers you'll relay transactions to, which will improve your chances.

See this thread.


I believe the listtransactions patch can do that. You can't do it with stock bitcoind, AFAIK.

I've got a couple of thoughts floating around and I guess this is the place to put them.  Sorry if it makes for a longish post but I'd rather not just show up and immediately start a whole collection of threads.

First a brief introduction, I run an online game and was pointed this direction by a user asking about bitcoins being added as one of the payment/donation methods.  I've been lurking here about a week now and after generating a block yesterday decided to do some experimenting, I tend to find playing with things hands-on is the best way to learn how they work.  So what I did is design and implement a basic money game like those you would see using egold.  You can find the results here http://bitcoindarts.movoda.net/.  It is fully functional, maybe a little slow to process payments due to bitcoind not running on the server (no offense to the coders but I'm not ready to trust that on one of my production servers).  Feel free to play with it if you want, in theory it should only hand back out 96% of the bitcoins going in but there's not a huge reserve if someone starts winning so pay attention to the maximum bid it lists.  And now here's the questions that I've happened across while experimenting.

I would have liked to use something publicly verifiable for the hash used in determining the outcome rather than the payment info plus timestamp hashed that I ended up using, but couldn't find if there is such a thing for each payment.  I see there is a lottery which uses the hash data from the generated blocks to determine the winners, but it would seem if that sort of system was used I would end up wit all the payments from around the same time ending up winning the same.  Is there some random part of the payment information that can be used to generate the result that couldn't be calculated before the payment was sent or am I better off with the way it is and any users would just have to trust that the result hash is truly random?

As far as the payment confirmations go is it relatively safe to do the way that it is working there?  As far as I can tell if someone was trying to double-spend any coins they would have to do it fairly fast.  The server calculates/shows the results as soon as it sees the payment with 0 confirmations, would it be possible to see the results and then spend the coins again to another account if they didn't like the outcome?  The actual winnings aren't sent out until it gets a few confirmations at least so there shouldn't be a problem there, just not sure how quickly someone could void a transaction if they were trying (or if by the time the server displayed it that would be long enough to make sure that would be the transaction that would stick).  Not as big a problem with accepting payments (which would be my final goal) but trying to understand how the network/system works.

And finally is there some way to read the status on outgoing payments back from bitcoind?  I'm logging them in the database as I send commands to it, but I see in the GUI client it lists outgoing payments as well and I don't see a way to get that information from the headless client.

And now the comments, from my perspective there seems to be a lot of potential here and it seems like it shouldn't be a problem from the technical side adding bitcoins as a payment method.  There seems to be enough infrastructure in place that I can cash it out to USD/Paypal (which is what will be needed to actually use donations to pay for hosting in the foreseeable future) and I already have an in-game "cash equivalent" that they could be exchanged for at current exchange rates.  The stories/warnings I've seen here about losing the wallet data are somewhat worrisome, but on the other hand the normal game database data that I keep backed up very regularly is probably worth more than would ever be kept in bitcoins on the server anyway so just backing the wallet up with my normal backups should be sufficient.  From what I've seen discussed (outside of the forums here) the biggest draw may still be the ability to work on mining coins.  I can't say for my use case that I would expect to see people buying bitcoins to use when they could just buy things directly but it does seem there are at least a few people who have mined or gotten bitcoins somehow and I don't really see any downside to accepting them.