BKK, how much is this following news going to screw you? following Bitcoin activities are illegal in Thailand: - Buying Bitcoins
- Selling Bitcoins
- Buying any goods or services in exchange for Bitcoins
- Selling any goods or services for Bitcoins
- Sending Bitcoins to anyone located outside of Thailand
- Receiving Bitcoins from anyone located outside of Thailand
Source: https://bitcoin.co.th/trading-suspended-due-to-bank-of-thailand-advisement/?bettertitleObviously anyone in Thailand will have to trade their BTC quietly as the law is unlikely to be enforceable unless you advertise what you are doing. Keep your BTC wallet offshore so no transactions passing though Thai jurisdiction, though technically the blockchain is everywhere. Litecoin would be an alternative. However in this case it's simply poor reporting, as The Bank of Thailand has no legal power see: https://bitcointalk.org/index.php?topic=264389.0 |
|
|
|
Baritus mentioned in the DGC fundraiser thread that he plans to integrate a payment processor into the DGC/ARG bank/exchange. In regard to the dgc block reward reduction issue: I initially supported a reduction of the DGC block reward. In an ideal world, I still wish that DGC had a slightly smaller block reward---say 15 DGC. However, in light of the points raised by disclaimer, cosmo, et. all, my view on the issue has changed. I think one of the strongest points that DGC has going for it was the fairness of its launch and the lack of benefits to be had by ultra-early-adopters. Indeed, this is one of the major reasons that I initially choose to support digitalcoin (of course, far from the only reason  ) To change the block reward would largely undo this, at least perceptually. Digitalcoin set the standard for fair coin launches, and I feel that the negatives of changing the block reward far outweigh the benefits. You realize that DGC halves it's block reward every 4730400 blocks anyway, so to bring it forward is no big deal. But it's only tackling the symptoms not the problem. |
|
|
|
I'm just gauging community opinion with the poll, you can be assured no decisions are ever made in this community without input from all members. I definitely see both sides of the argument and I am currently siding with keeping it as is or a slight decrease (10-20%).
Nevertheless, polls are one of the few ways of gathering information so don't be surprised to see them coming up. It doesn't mean anything but an opinion gauge.
Good discussion, if anyone has anything else to add, please do.
The coin creation rate should be relative to the coin requirement rate, supply vs demand. To maintain a desired balance you need to alter one or the other, I vote for increasing demand. If you want a coin that has low supply, focus on ARG. The main shortfall I see with DGC demand, is a merchant gateway where people can add Bitpay style DGC payments as an option to their shopping carts. eg. Prestashop, Magnet, WHMCS etc. I believe that should be the main focus of development, solve that and the over supply problem will vanish. |
|
|
|
|
My advice is avoid any large scale mining purchases that have the slightest sniff of a centralized mining farm. It's bad for the BTC network. Just look at what ASICminer have done to spoil mining for all. Keep that hash rate spread around as much as possible.
The going rate on new ASIC releases should be less than $20 per GH/s or it wont be a happy ROI.
|
|
|
|
honestly, i can't take this poll seriously. I mean you got Kujmandos and his 27 sockpuppets voting for CloudCoin. i think he's the only one who mines it.
As always with these kind of polls, most people don't vote, it's mainly coin groupies. |
|
|
|
bump. ive bought $100 worth off them too.
Same, not a problem. |
|
|
|
Another payout is currently in progress, try again in a minute. Since yesterdays database maintenance I cant withdraw any coin. Got the message above a million times! Same, neither auto-payouts or cash out are working. |
|
|
|
|
Has to be the longest list of poll options I have seen!
|
|
|
|
If Mt Gox folded, BTC would take a fast dive, but crypto in general would ultimately recover. People would not put their faith in just one big exchange. We don't need a "too big to fail" in crypto, leave that for fiat.
unless one of the many up and coming US exchanges popped up into the marketplace first. I remember kraken saying they were going to open up their doors this month. perhaps next month who knows The value of Gox is not just in being an exchange, it's the price discovery for BTC, so many merchants and other things are linked into the Gox price. Another exchange would take a while to fill that void. |
|
|
|
|
If Mt Gox folded, BTC would take a fast dive, but crypto in general would ultimately recover. People would not put their faith in just one big exchange. We don't need a "too big to fail" in crypto, leave that for fiat.
|
|
|
|
I have withdrawn BTC to my wallet many times from Gox over the past few months. I have never been verified, I don't withdraw fiat, I just use Gox to make more BTC when the BTC/USD is volatile there.
how many at a time ?a few or a few dozen? (wonder if there is a limit change in policy) or aml flags or just fud on this thread by others...or trying to hold a Ponzi together 5 BTC withdrawals since the start of May, never a problem, sometimes slow. Never bothered to get verified. |
|
|
|
It should be blatantly clear to all that MTGOX doesn't have the cash flow to operate in too large a capacity as an exchange. Sure they can handle small withdrawals to keep the illusion up but choke on anything large. I highly suspect they are operating on Fractional BTC reserves also and if people started making huge BTC withdrawals, we would start to see similar actions there.
~BCX~
It's probably more complicated than that, if they wanted to increase their reserves, they would just increase the fees until it balanced. |
|
|
|
The default assumptions on that calculator need to be questioned. It's like one of those Al Gore climate fear charts. It basically says by the end of the year no ASICs out there will be returning a profit. If that is the case then people will simply switch them off and the difficulty will stop rising. They won't switch them all off at once, the Avalon and ASICminer chip based ones will be the first, as they are the least power efficient. I question their difficulty projections. What it does tell me is the days of $50/GH/s are over, to remain competitive ASIC manufactures are going to be looking at offering product below $20/GH/s or they are going to fade away. |
|
|
|
|
You could try converting your Gox funds back to BTC, make sure it's a quiet time, so the price is not going to flap around much. Then move the BTC out to somewhere like coinjar.in in Melbourne, and convert it to AUD there.
|
|
|
|
|
I makes me laugh that the pressure on companies to get ASICs out the door fast, to get in before the diff rate rapidly increases, is exactly what is causing the rapid diff rate increases in the first place. A typical unsustainable approach. If we took out time and showed a little patience we would all be better off.
|
|
|
|
What I proposed a an error handler for a sudden increase in hash rate in the DGC thread was: My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.
Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block. Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats) For ARG you would probably make it a 25 sec minimum gap between blocks.
You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec. So you would multiply the times by 3 to suit CAP since DGC is 20sec block target and CAP is 60sec. This would not be easy to implement since you can't guarantee that all nodes are going to be within 15/25/whatever seconds of each other. If, for the faster coins, it requires the timestamps to become more accurate, that could be a useful modification too. There are no shortage of accurate Internet time sources the client could calibrate to. |
|
|
|
The coins don't have appropriate error handling for sudden changes in hash rate. That needs to be added to every coin. The original BTC code lacked this, and everything else has evolved from that. There needs to be minimum time between blocks, at the moment there is not, and the network will happily accept blocks at any old rate, even injected by an attacker. This is what I suggested in the DGC thread the other day if you could comment: My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.
Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block. Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats) For ARG you would probably make it a 25 sec minimum gap between blocks.
You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec. The idea would be to make the client software delay blocks for network submission until the minimum next timestamp had elapsed. Someone with a hacked client would have their too rapid block injection rejected by the rest of the network. |
|
|
|
What I proposed a an error handler for a sudden increase in hash rate in the DGC thread was: My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.
Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block. Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats) For ARG you would probably make it a 25 sec minimum gap between blocks.
You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec. So you would multiply the times by 3 to suit CAP since DGC is 20sec block target and CAP is 60sec. |
|
|
|
Maybe you should read through my posting history before throwing wild unfounded accusations...
Maybe you should look at my profile and realize I have been part of this forum long before your appearance... So I know what I talking about when I say that you and KnC are acting a la BFL. I watched the whole BFL ordeal unfold from the begin. KnC is just another business promising the same thing which was promissed by BFL, month after month: "Hey guys and gals, we do not have a prototype or even the final design of an ASIC mining device, but we are certainly going to deliver on July August September October November December January February March April May June July." That is, indeed, hilarious! So I other words you have no evidence to support your claims about KNCminer, I thought as much. |
|
|
|
|
Show Posts
