[ANN][CHA] Chancecoin, SuperNET core coin for betting in a decentralized casino

[nonlinearboy]

It seems chancecoin developers are chinese. https://bitcointalk.org/index.php?action=profile;u=272243;sa=showPosts

i assume you mean that one of them is from China.

but not all who speak chinese are from China.

+1

[Kyune]

1. This does rely on reasonable time synchronization. If people are worried about timestamp cheating, we can always increase the verification time, but there's a tradeoff there. If a block is orphaned and a transaction moves into another block, the bet will be resolved based on the new block.

2. The %2 was a bug. I just released version 1.3 to fix that, and the Windows client will be updated shortly. I also updated the technical specification to reflect what actually happens in the code. (number i) was a typo, and I had forgotten to mention the factor of 100 is simply to put the standard random uniform variable into percentage terms (since Chancecoin saves the chance of winning as a percentage as well).

3. I can write up the formal proof once the bitcoinj wallet gets off the ground. I apologize for taking a while to answer questions recently. Venetian and I have been pounding the code treadmill pretty hard with this new wallet software.

Thanks a lot. Makes sense.

On the time sync point: where is the current verification time defined, or at the moment is it zero? Do the bitcoin spec / software / major minors define anywhere a maximum time skew that would be allowed before a block is rejected? (I've not checked the bitcoin blockchain, but in alt coins I've certainly seen blocks appear out of timestamp order, especially during the instamine phase, presumably due to lack of time sync in the miner). Is there a guaranteed delay in announcing the lottery numbers? Would it be possible for a rogue miner to do something like:

 - Normal case: mine without an Chancecoin transaction, and with the correct timestamp
 - As soon as a lottery result is made available, and for the next 10 seconds, mine with a winning Chancecoin transaction (might need a few attempts to get a suitable transaction ID), and with the timestamp out by 10 seconds
 - After 10 seconds, go back to the normal case (no Chancecoin transaction; correct timestamp)

If that is a possibility, could you also include the block ID into the mix (like transaction ID is now) to prevent this behaviour, and would that help?

I did not see a response from the devs to the above.  It does seem within the realm of possibility that timestamp mismatches and reliance on an external data source could be exploited by sophisticated actors to tilt the odds in their favor, particularly by harnessing mining power.  Is Chancecoin provably fair...for the house?

[superresistant]

1. This does rely on reasonable time synchronization. If people are worried about timestamp cheating, we can always increase the verification time, but there's a tradeoff there. If a block is orphaned and a transaction moves into another block, the bet will be resolved based on the new block.
2. The %2 was a bug. I just released version 1.3 to fix that, and the Windows client will be updated shortly. I also updated the technical specification to reflect what actually happens in the code. (number i) was a typo, and I had forgotten to mention the factor of 100 is simply to put the standard random uniform variable into percentage terms (since Chancecoin saves the chance of winning as a percentage as well).
3. I can write up the formal proof once the bitcoinj wallet gets off the ground. I apologize for taking a while to answer questions recently. Venetian and I have been pounding the code treadmill pretty hard with this new wallet software.

Thanks a lot. Makes sense.
On the time sync point: where is the current verification time defined, or at the moment is it zero? Do the bitcoin spec / software / major minors define anywhere a maximum time skew that would be allowed before a block is rejected? (I've not checked the bitcoin blockchain, but in alt coins I've certainly seen blocks appear out of timestamp order, especially during the instamine phase, presumably due to lack of time sync in the miner). Is there a guaranteed delay in announcing the lottery numbers? Would it be possible for a rogue miner to do something like:
 - Normal case: mine without an Chancecoin transaction, and with the correct timestamp
 - As soon as a lottery result is made available, and for the next 10 seconds, mine with a winning Chancecoin transaction (might need a few attempts to get a suitable transaction ID), and with the timestamp out by 10 seconds
 - After 10 seconds, go back to the normal case (no Chancecoin transaction; correct timestamp)
If that is a possibility, could you also include the block ID into the mix (like transaction ID is now) to prevent this behaviour, and would that help?

I did not see a response from the devs to the above.  It does seem within the realm of possibility that timestamp mismatches and reliance on an external data source could be exploited by sophisticated actors to tilt the odds in their favor, particularly by harnessing mining power.  Is Chancecoin provably fair...for the house?

But to exploit this if I understand correctly, you must attack the whole Bitcoin network which is not worth it at all.
So it is just impossible.

[notsoshifty]

I did not see a response from the devs to the above.  It does seem within the realm of possibility that timestamp mismatches and reliance on an external data source could be exploited by sophisticated actors to tilt the odds in their favor, particularly by harnessing mining power.  Is Chancecoin provably fair...for the house?

But to exploit this if I understand correctly, you must attack the whole Bitcoin network which is not worth it at all.
So it is just impossible.

I don't see why any of the major bitcoin mining pools couldn't do it.

[superresistant]

I don't see why any of the major bitcoin mining pools couldn't do it.

Define and explain this :
mine with a winning Chancecoin transaction and with the timestamp out by 10 seconds
After 10 seconds, go back to the normal case (no Chancecoin transaction; correct timestamp)

??

[Kyune]

I did not see a response from the devs to the above.  It does seem within the realm of possibility that timestamp mismatches and reliance on an external data source could be exploited by sophisticated actors to tilt the odds in their favor, particularly by harnessing mining power.  Is Chancecoin provably fair...for the house?

But to exploit this if I understand correctly, you must attack the whole Bitcoin network which is not worth it at all.
So it is just impossible.

I don't see why any of the major bitcoin mining pools couldn't do it.

Agreed.  Particularly in light of phm's comment about the flexibility in timestamps:

Not sure if you know this, but timestamps in blockchain are prone to limited manipulation, rules of validating them are quite fuzzy. "A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours". So in fact nothing prevents miner from sending the block with timestamp few minutes in the past or in the future, timestamps in consecutive blocks don't have to always increase. How will you enforce such rule if you don't really know the real time when given block was mined?

Suppose quick draw lottery result N comes out at noon, and result N+1 comes out at 12:04:00.   If, per notsoshifty's and phm's suggestion I can manage (as a major pool) to mine a block at 12:00:05 that includes a Chancecoin bet that I know will win if evaluated against result N, but include in that block a timestamp that is a bit before noon (maybe even well before noon, given phm's comments), how can the Chancecoin protocol absolutely ensure that my bet is evaluated against result N+1 or later?

I would only have have to sneak these "sure bets" into the blockchain once in a while to slowly drain the Chancecoin house dry.

[Ziggy]

Updated:

 The input must come from a single Bitcoin address. There can be multiple output addresses in any order, as long as one of them is the burn address (1ChancecoinXXXXXXXXXXXXXXXXXZELUFD).

Hi.magician
I missed this Update,so I want to know are these two burning successful or not?
txid:a3d8e083b7de0bc32b0dfc6e4ba2ebe4642387046cde4fa455179f4398450d9e
and
txid:0078fdbb3c12f96e68e9511cf670a8f67403e68f0ca99d450d9cb096b142ad56

thank you!

[Janitor]

Suppose quick draw lottery result N comes out at noon, and result N+1 comes out at 12:04:00.   If, per notsoshifty's and phm's suggestion I can manage (as a major pool) to mine a block at 12:00:05 that includes a Chancecoin bet that I know will win if evaluated against result N, but include in that block a timestamp that is a bit before noon (maybe even well before noon, given phm's comments), how can the Chancecoin protocol absolutely ensure that my bet is evaluated against result N+1 or later?

So you're a large pool that is actually two large pools (each with a different system time)?
How does that work?

And as magician said time tolerance can be decreased.
There's no reason to tolerate significant skew, IMO.
However, resolution in the next block is a small price ot pay just to be on the safe side.

[nightwishx]

 ???Has there been any progress on that front?

[lhuibin]

The burn is to be end shortly.
When this coin lunch?

[nightwishx]

If there is no so many bitcoin burning, finally 1M cha?

[ownerbest]

Is it still available to burn btc to chance?

[superresistant]

Is it still available to burn btc to chance?

(298340-297967)*8.7*(1/(24*60))=2.25 days.

2 days and 6 hours left.

[notsoshifty]

Suppose quick draw lottery result N comes out at noon, and result N+1 comes out at 12:04:00.   If, per notsoshifty's and phm's suggestion I can manage (as a major pool) to mine a block at 12:00:05 that includes a Chancecoin bet that I know will win if evaluated against result N, but include in that block a timestamp that is a bit before noon (maybe even well before noon, given phm's comments), how can the Chancecoin protocol absolutely ensure that my bet is evaluated against result N+1 or later?

So you're a large pool that is actually two large pools (each with a different system time)?
How does that work?

And as magician said time tolerance can be decreased.
There's no reason to tolerate significant skew, IMO.
However, resolution in the next block is a small price ot pay just to be on the safe side.

I think Kyune has described it perfectly. Much better than I did anyway.

No need for two large pools (or one large pool splitting itself into two). One large pool could do it by itself. Of course, unless it was willing to put into its blocks a timestamp that is out by four minutes (unlikely), it wouldn't be able to do it for every block it mined; but nor would it need to.

My original suggestion was to include the block hash into the mix (as the transaction hash is now). Would that work? Does it introduce other problems (e.g. a winning bet might become a losing bet if its original block gets orphaned)?

[nakaone]

is it possible to have a decentralized exchange with xcp? - seems from a non-technical perspective be inuitive

I finally got why you need your own system, when implemented properly this can be a good idea. anyway isn't it more or less an extension of the xcp system?

[Ziggy]

I still have the same problem: wallet starts without error, btc-qt is running an up to date, but when I click on "open wallet" or "casino" nothing happens.

any suggestions?

have the same question.How to burn from CHA wallet?

I am using windows xp ,bitcoin-qt 0.9.1,chancecoin wallet 1.5
after doing this the problem solved:

check the setting of bitcoin.conf(C:\Users\(your user name)\AppData\Roaming\Bitcoin)
and chancecoin.conf(C:\Users\XXX(your user name)\AppData\Roaming\Chancecoin\chancecoin)
the "rpcuser"and"rpcpassword"of both .conf should be the same.
in my case
bitcoin.conf:
rpcuser=rpc
rpcpassword=rpcpw1234
server=1
daemon=1
txindex=1

chancecoin.conf
[Default]
bitcoind-rpc-connect=127.0.0.1
bitcoind-rpc-port=8332
bitcoind-rpc-user=rpc
bitcoind-rpc-password=rpcpw1234

hope this can help you
 

[Ziggy]

Also, do you know what the issue could be?
I work within a VM on a tinyXP Windows. The blockchain is uptodate and it is txindex=1 with a rescan.
When i delete the DB of chancecoin it starts downloading up to the block XXXXXX and always stops at exactely this block.

What trouble shooting can i do?

Which block does it stop on? I'll look into it.

292091

I deleted the DB 3 times, always scans to this block, then stops.

We tried to reproduce the problem you had and made a few changes to hopefully address the problem. You should download the updated windows binary and it should move past that block smoothly.

I am using xp/chancecoin wallet-1.5
I deleted the DB 2 times
but the synchronizing always stuck at block 295629
is this a new problem? 

[lhbx1x]

When will this coin lunch？

[SpongebobCoinpants]

I still have the same problem: wallet starts without error, btc-qt is running an up to date, but when I click on "open wallet" or "casino" nothing happens.

any suggestions?

have the same question.How to burn from CHA wallet?

I am using windows xp ,bitcoin-qt 0.9.1,chancecoin wallet 1.5
after doing this the problem solved:

check the setting of bitcoin.conf(C:\Users\(your user name)\AppData\Roaming\Bitcoin)
and chancecoin.conf(C:\Users\XXX(your user name)\AppData\Roaming\Chancecoin\chancecoin)
the "rpcuser"and"rpcpassword"of both .conf should be the same.
in my case
bitcoin.conf:
rpcuser=rpc
rpcpassword=rpcpw1234
server=1
daemon=1
txindex=1

chancecoin.conf
[Default]
bitcoind-rpc-connect=127.0.0.1
bitcoind-rpc-port=8332
bitcoind-rpc-user=rpc
bitcoind-rpc-password=rpcpw1234

hope this can help you
  

Got wallet to work.

How do I import chancecoin from a blockchain.info wallet and send it to a new address?

If someone gives me good instructions on how to do this, and also an address, I can send them $50 worth of chancecoin.

[techflag]

i send 0.1BTC,wait cha