|
Not accepting any more. Thank you for participating.
|
|
|
|
I put it on my third line. Please, PM me if you have the time, just to confirm you know. I prefer not to advertise for free.  1HeroCCotNLtJzpEiWGrRkaFSFDBZkF1jG Confirming. |
|
|
|
Lucky #
e98f-6c29-003c
That's not a bet ID. |
|
|
|
Neat user interface. Higher max bets please.
Betting limits have been increased. |
|
|
|
Just putting this out there. I have not checked this service and if in the future it was exposed as a scam or something, This contract is invalid for me. Of course I would make sure not just jump to conclusion.
Seems fair. |
|
|
|
Nice layout, and I'm mostly ok with the API.
But! This is a big "but" for me, by the way. Stop storing the user/password in a cookie, and specially do not store anywhere in plain text (much more specially don't do that in the cookies!). I just did a SELECT * FROM moz_cookies WHERE baseDomain = 'coinroll.it'; on cookies.sqlite from Firefox and I see everything as clear as it can get.
My second issue is the limit of bets. Are you scared of someone suddenly getting lucky on < 1 and stealing all your pot ?
Nevertheless, congrats on making a decent API for it.
I just saw your post, sorry for the delay. This was a design choice. I wanted it to be loginless and stateless. The alternative would be to have a (static) session ID which would pretty much have the same effect: if someone has access to your machine they can access your Coinroll balance. Which I don't think is a problem anyway. If your system is compromised you have bigger problems than your balance on a gambling website. The cookie has the 'httpOnly' and 'secure' flags set, so it can't be read by javascript and it is only transmitted via HTTPS. People don't leave Bitcoins on the website. They also make (and they should) new accounts for every session. As for your second question, the pot is big enough to make that event highly unlikely. The betting limits are adjusted based on that. |
|
|
|
|
Looks like the unicode character I used doesn't render on Windows. I've updated the OP with a new one.
|
|
|
|
I will buy your signature space for 1 month. The ad is as follows: • Forget SatoshiDICE - Place instant off-the-chain bets now at Coinroll.it • Forum threadBBcode: [size=13pt][color=navy][glow=white,2,300][url=https://coinroll.it/?r=5][b]•[/b] Forget SatoshiDICE - Place instant off-the-chain bets now at Coinroll.it[/url] [url=https://bitcointalk.org/index.php?topic=191176.0][b]•[/b] Forum thread[/url][/glow][/color][/size] 50-100: 0.02 BTC 101-200: 0.03 BTC 201-400: 0.05 BTC 400+: 0.08 BTC Terms:- This is for 30 days
- You must make at least 30 posts during that period
- You will be paid upfront
- You must have at least 50 existing posts
- You can have up to 1 additional 3rd party ad
- Styling is up to you
Do not PM me. To participate change your signature and paste your address in this thread. |
|
|
|
8da0-4491-3045
That's your user ID. |
|
|
|
Miners have ALWAYS been free not to include your tx in a block. Miners everyday routinely don't include tx in the next block (thus the unconfirmed list).
Initially the functionality of the bitcoind were so crude miners had little control over what tx were included. That wasn't intended it was simply the result of limited development and higher priorities. Over time more functionality was added which allowed miners to fine tune their transaction selection.
Today miners can and do exclude transactions based on:
a) priority
b) block size
c) tx fees
and starting in 0.8.2
d) output size
0.8.2 simply gives miners the ability to better control the transactions they want to include. If it wasn't in bitcoind miners could write custom patches to do the very single thing. Satoshi always intended for miners to have the control over which tx to include. Nothing has changed, the devs have given miners the tools to make more informed transaction selection. Now miners are "big boys" and if they see a lot of value in including 100 satoshi or even 1 satoshi transactions they can. They simply need to change the configuration file. Given miners already set a half dozen configuration values related to min fees, block size, priority, etc one more config value is hardly a burden for a miner.
If you think bitcoin is better off with 1 satoshi spam ... then convince enough nodes to mine them and you can spam away. The reality is you KNOW miners don't want to include dust spam however prior to 0.8.2 they lacked tools good enough to make optimal tx selection. No miners wants to bloat the chain with uneconomical spam, it makes their future jobs more difficult. All those uneconomical outputs have a high probability of never being spent and thus they bloat the UXTO. The UXTO governs the resources miners (and all full nodes) use to validate tx and blocks.
It seems you are afraid of the free market. Freedom is about choice. You are free to create dust spam, nobody can stop you. Miners are free to chose not to include that dust spam up till now miners lacked good tools to exclude those tx. That isn't "freedom" it is merely a lack of choice due to insufficient development. Starting in 0.8.2 you won't be able to stop miners from exercising their freedom to not include uneconomical transactions.
Quoted, as it is the post with the highest SNR in this thread. UXTO bloat can potentially be a big problem in the future if it is not addressed. The sky is not falling people. |
|
|
|
But it's still probably just an estimate.
My understanding is that it may overshoot or undershoot between blocks (because it doesn't know the exact number, only the average) but the average over all these years should be very close to the real number. |
|
|
|
Can you explain how this is being calculated?
You can get the hash count every time there's a SetBestChain in debug.log. Then you log2 that number. |
|
|
|
|
The Bitcoin network reached a big milestone yesterday: it has performed over 270 (double) hashes since its conception.
Current count is:
1,191,253,457,820,256,820,938 = 270.01297 hashes
making it by far the most powerful distributed network computing system ever to have existed.
|
|
|
|
Some changes: - Deposit addresses are now fixed for each user
- You get a notification if you send a transaction that doesn't meet the instant deposit criteria
- You can now cancel deferred withdrawals
- Withdraw popup will remember the last used address
|
|
|
|
The client side frontend is very nice. May I ask which dev suite / technology you used to implement it?
My trusty text editor. Found this webpage after reading the prize thread. Works well, house edge is really low almost half of other dice games. After 1 confirmation my deposit showed up. Rolls and withdrawals are instant.
Your deposits will show up instantly as long as they have the correct fee and do not depend on other unconfirmed transactions. |
|
|
|
Just a reminder: there's an ongoing 5 BTC giveaway. All you have to do is play the game once. |
|
|
|
Downloads are hanging right now. Tried with direct .torrent links and magnet links.  EDIT: 3 out of 4 torrents have downloaded now; still waiting on the fourth one to start. Maybe running out of disk space? Torrent client was stuck at 100% cpu. I miss the search feature. It was really giving me good results and made life easier.
I'll see what I can do. |
|
|
|
|
Show Posts
