Pages:
Author

Topic: [ANN][CHA] Chancecoin, SuperNET core coin for betting in a decentralized casino - page 73. (Read 146141 times)

member
Activity: 85
Merit: 10
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
 
hero member
Activity: 742
Merit: 500
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?
sr. member
Activity: 378
Merit: 250

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)?
legendary
Activity: 2156
Merit: 1131
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.


sr. member
Activity: 322
Merit: 250
Is it still available to burn btc to chance?
hero member
Activity: 900
Merit: 500

If there is no so many bitcoin burning, finally 1M cha?
full member
Activity: 169
Merit: 100
The burn is to be end shortly.
When this coin lunch?
hero member
Activity: 900
Merit: 500
 ???Has there been any progress on that front?
newbie
Activity: 47
Merit: 0

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.
member
Activity: 85
Merit: 10
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!
sr. member
Activity: 287
Merit: 250
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.

legendary
Activity: 2156
Merit: 1131
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)


??
sr. member
Activity: 378
Merit: 250
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.
legendary
Activity: 2156
Merit: 1131
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.
sr. member
Activity: 287
Merit: 250
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?
hero member
Activity: 703
Merit: 500
It seems chancecoin developers are chinese. https://bitcointalksearch.org/user/venetian-272243

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

but not all who speak chinese are from China.
+1
full member
Activity: 155
Merit: 100
It seems chancecoin developers are chinese. https://bitcointalksearch.org/user/venetian-272243

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

but not all who speak chinese are from China.
hero member
Activity: 602
Merit: 500
legendary
Activity: 1148
Merit: 1000
can any body give me a right  bitcoin.conf and chancecoin.conf ?
thanks Smiley

It should work. You can change/adapt some settings if you want.

bitcoin.conf

rpcuser=1
rpcpassword=2
rpcport=8332
rpcallowip=127.0.0.1
port=8333
listen=1
gen=0
server=1
daemon=1
maxconnections=8

chancecoin.conf

[Default]
bitcoind-rpc-connect=127.0.0.1
bitcoind-rpc-port=8332
bitcoind-rpc-user=1
bitcoind-rpc-password=2




much appreciated, thanks! Smiley
i will try it again.
legendary
Activity: 2156
Merit: 1131
can any body give me a right  bitcoin.conf and chancecoin.conf ?
thanks Smiley

It should work. You can change/adapt some settings if you want.

bitcoin.conf

rpcuser=1
rpcpassword=2
rpcport=8332
rpcallowip=127.0.0.1
port=8333
listen=1
gen=0
server=1
daemon=1
maxconnections=8

chancecoin.conf

[Default]
bitcoind-rpc-connect=127.0.0.1
bitcoind-rpc-port=8332
bitcoind-rpc-user=1
bitcoind-rpc-password=2


Pages:
Jump to: