Search content
Sort by
Showing 19 of 19 results by xianglan
Re: [ANN][C2.1] Coin2 | Pow/PoS | ChainOfConflict[FPS] The Future of Gaming is Now
Bittzy I think its you with joels account. Can you explain the page 1 document and how they dont match up. Sorry but im not following it. Turned my brain off for the night, mondays ya know.
i also have a question: Since I moved my coins to my mac os wallet, the blockchain shows only half of the coins in my wallet. The wallet itself shows the correct account, test-transactions I made to mintpal went through without problems. Maybe my wallet isn't the only one with this problem. This could explain the difference.
Also, should I be worried? I don't want to send it all back to mintpal just to check if it's "real". I got it from mintpal after the swap and am staking since.
Of course. I sent you a pm, thx for your help.
Great, UdjinM6 solved my problem, it was because of multiple wallet adresses (as someone guessed before) and is no but or anything shady. Thx for your help!
Thank you for your response! I'm glad to help you
In case someone else have issues like that here is a short overview:
Sometimes when you make a transaction your balance splits and second (third, etc) part of your coins moves to so called "change address". Don't worry, that's nothing special of C2, it's how bitcoin works. You can read more on change addresses there https://en.bitcoin.it/wiki/Change
Confusing part is that those change addresses are not shown in wallet GUI (and that's a standard behavior too) but you can list all addresses your wallet uses by firing command "listaddressgroupings" in Help > Debug window > Console
What's going on now?
Re: [ANN][CHA] Chancecoin protocol, client, and coin for decentralized dice betting
I have burnt a few bitcoins from a blockchain.info address. How do I verify that CHA got credited to my address as expected?
I also want to know .It will take 10G place to run currently wallet because it need install the btc-qt, the btc-qt will take 10G place.
Re: [ANN][CHA] Chancecoin protocol, client, and coin for decentralized dice betting
I am happy to announce that we are hard at work on an improved wallet software that harnesses bitcoinj. This will have several advantages and solve a lot of issues we've been hearing about in regards to installing and using the current wallet software. I'll get into these details later, but I just wanted to give a quick update.
It looks like the burn period has been going well so far. I'd like to thank the whole community for its continued support. Special thanks goes to those who have gone out of their way to answer questions in the forum and promote Chancecoin at other venues. We're very excited to see this project come to full fruition.
GOOD JOB.It looks like the burn period has been going well so far. I'd like to thank the whole community for its continued support. Special thanks goes to those who have gone out of their way to answer questions in the forum and promote Chancecoin at other venues. We're very excited to see this project come to full fruition.
I like the project, I will burn more btc and let more people know this coin.
Re: [ANN][CHA] Chancecoin protocol, client, and coin for decentralized dice betting
can i send btc from multibit wallet?
after i send btc, when and how i can get the chance coin?
thank you very much!
after i send btc, when and how i can get the chance coin?
thank you very much!
You can indeed burn BTC into CHA using Multibit. BUT you must be careful that you are sending BTC from a single address (otherwise Chancecoin won't know which address to send CHA to). The best thing to do is send BTC to the burn address using a wallet that only has a single address. To check that you only have a single address, click on "Request" and verify that under "Your receiving addresses," you only have one address listed. If you have more than one, you should create a new wallet (File -> New Wallet), send some BTC to the new wallet, and then send BTC from the new wallet to 1ChancecoinXXXXXXXXXXXXXXXXXZELUFD. Hope that helps. Alternatively, you can always send BTC to a Blockchain.info wallet and follow the instructions I just posted for burning from Blockchain.info.
After you send BTC, you can see your Chancecoin using the Chancecoin wallet software. You can either install this from source, or run a pre-compiled binary. We currently have a pre-compiled binary available for OS X Mavericks, and we will have a Windows binary out soon. The wallet software has a function you can use to check the balance associated with your address.
It said that Please make sure you have bitcoind or Bitcoin-QT running and that your config file is set correctly at C......
I have not install the bitcoind, I install the multibit. Does it mean that I can't use the chancecoin wallet software because I don't install the bitcoin-qt?
Re: [ANN] eMunie (EMU) - NOT a BitCoin fork/clone - call for beta testers
I'll sign up for the beta test - nice to see some originality for once.
I do, however, see a few issues with the proposal. Some (hopefully all) are probably addressed.
1. Transactions. If the network grows to any decent size then there will frequently be multiple transactions created at the same time. This poses a massive problem as:
a) If transactions don't have to be ordered in the ledger then it allows the back-insertion of double-spends (i.e. spend something legitimately then, using 2 of your own hatching nodes, spend it again later but with an earlier time-stamp).
b) If transactions have to be ordered - i.e. once one is accepted any others must be after it - then that is surely going to lead to lots of orphaned transactions and ones which have to be reprocessed to get back in sequence. That would then allow anyone to grind the network to a halt by broadcasting a fairly modest quantity of transactions.
2. Voting to create new EMUs. This talks about voting on a random node. How is this randomness enforced? Clearly it can't be implemented by use of a RND function in the client - or people could change the code, create lots of semi-clients (i.e. lightweight ones with nothing much other than voting mechanism) and vote yes to a seed node they run themselves.
I do, however, see a few issues with the proposal. Some (hopefully all) are probably addressed.
1. Transactions. If the network grows to any decent size then there will frequently be multiple transactions created at the same time. This poses a massive problem as:
a) If transactions don't have to be ordered in the ledger then it allows the back-insertion of double-spends (i.e. spend something legitimately then, using 2 of your own hatching nodes, spend it again later but with an earlier time-stamp).
b) If transactions have to be ordered - i.e. once one is accepted any others must be after it - then that is surely going to lead to lots of orphaned transactions and ones which have to be reprocessed to get back in sequence. That would then allow anyone to grind the network to a halt by broadcasting a fairly modest quantity of transactions.
2. Voting to create new EMUs. This talks about voting on a random node. How is this randomness enforced? Clearly it can't be implemented by use of a RND function in the client - or people could change the code, create lots of semi-clients (i.e. lightweight ones with nothing much other than voting mechanism) and vote yes to a seed node they run themselves.
Re: [NEM] NEM -New Economy Movement - No Envy Movement - Updates+Discussion thread
My plan is to use taint analysis to link closely related accounts together. And we will limit the holding of these closely related accounts to 5 stakes, anything above that would be refunded.
We can't really say for sure all these related accounts is just one person. It is possible that a group of friends is buying via one big account holder and but one account still represent one person. It is a good thing if someone can draw a close friend or two of him into crypto because of this opportunity and then they can can help to promote NEM in differently ways locally. But I would like to restrict these groups to a maximum of 5 stakes.
I asked Kooream to compile population statistics so that we can see have a glimpse of how many unique accounts/ individuals we could have. I expect group 1, accounts created before the fundraising, consists mainly of unique accounts and as well as accounts in group 2, accounts created during the fundraising but engaged in more activities. Counting both groups, we already have roughly 1500 stakeholders, so that's a good thing.
It is expected that stakeholders can buy 1 more share for loved one/ family member as well so a certain percentage of group 3 account falls into this category. A certain portion accounts in group 3 are also unique accounts but they are not yet active so they should be able to keep their shares. The remaining are likely sockpuppet accounts and we will try to refund them using the taint analysis.
I have finished the unified list and will post them momentarily. Let's wait 1-2 days before we start the public auditing. There will be guidelines and bounties announced for the efforts. Generally the public auditing includes: public checking for errors, discrepancies in the stakeholder list; public checking for big multi-accouter using taint analysis.
UP
You guys did very good job.I like those ideas.We can't really say for sure all these related accounts is just one person. It is possible that a group of friends is buying via one big account holder and but one account still represent one person. It is a good thing if someone can draw a close friend or two of him into crypto because of this opportunity and then they can can help to promote NEM in differently ways locally. But I would like to restrict these groups to a maximum of 5 stakes.
I asked Kooream to compile population statistics so that we can see have a glimpse of how many unique accounts/ individuals we could have. I expect group 1, accounts created before the fundraising, consists mainly of unique accounts and as well as accounts in group 2, accounts created during the fundraising but engaged in more activities. Counting both groups, we already have roughly 1500 stakeholders, so that's a good thing.
It is expected that stakeholders can buy 1 more share for loved one/ family member as well so a certain percentage of group 3 account falls into this category. A certain portion accounts in group 3 are also unique accounts but they are not yet active so they should be able to keep their shares. The remaining are likely sockpuppet accounts and we will try to refund them using the taint analysis.
I have finished the unified list and will post them momentarily. Let's wait 1-2 days before we start the public auditing. There will be guidelines and bounties announced for the efforts. Generally the public auditing includes: public checking for errors, discrepancies in the stakeholder list; public checking for big multi-accouter using taint analysis.
UP
GOOD.
wish better.
Re: NXTL: Next Coin Lite 3 - NEXT UPGRADED - Fair Distribution - Topic 3
Skillroad, I guess you are Chinese. right?
Yes.