Hello everyone,
just wanna share my story here, which I am requesting a refund cheque.
I have ordered a Platinum 1.5TH...
========================================
2014-01-15 13:15:10 Refund
2013-11-26 08:21:15 Payment accepted
2013-11-24 14:39:19 Awaiting bank wire payment
2013-11-24 14:39:19 Pre-Ordered
========================================
Jason 2014-05-08 18:08:36 Hey, how's my refund? Please let me know, thanks.
Jason 2014-04-23 12:51:41 Hello, It's has been a month already, and I just wanna know, how is my refund process now ? Thanks
Kris 2014-03-18 14:09:42 Dear Jason, We are processing your refund. Your refund will be issued in approximately 2-4 weeks. Thank you for your patience.
Jason 2014-02-13 10:32:13 Hello, I just wanna ask how is my refund process now ? Thanks
Jason 2014-02-05 22:41:15 Hello, I just wanna ask how is my refund process now ? Thanks
Kris 2014-01-16 07:58:14 Dear Customer, ok we will start the refund process.
Jason 2014-01-15 23:39:24 My full name: ____ Address: ____ , If you need more information, just let me know, thank you!
Kris 2014-01-15 13:14:55 Dear Customer, Yes we only do refunds in a check form.You will need to message us back with a full name and address as to where we can send the refund to.
Jason 2014-01-15 12:57:51 Here I would like to ask, can I request a refund by now? Thank you.
=======================================
still waiting...
Grain of salt with this one.... Might be real, might be made up. Half the shiite on this whole board is made up. |
|
|
|
|
It's been a while since dividends have been paid out with various incidences... Does anyone have a good measure of what has accrued per share in the interim?
|
|
|
|
what's the deal with this 7 masterkeys ? is this coin going to be centralized?
It doesn't matter. ZeroCoin will be forked many times. I fully expect to see zerocoin-style transactions implemented on multiple new altcoins (with different Proof of Work algorithms), so if you don't like what they do just fork it. |
|
|
|
|
There aren't many 'users' of the data feature yet, so it's good to see some data actually being posted.
|
|
|
|
|
How About N.F.C. (Newest Fail Chain)?
|
|
|
|
Here's my fix for the issue with shared wallets I discovered earlier: https://github.com/mikaelh2/primecoin/commit/a1c3f5854e9970d2f9f13ff75601dc7c87bf83c3Basically this should help people who are running lots of miners using the same shared wallet. My fix is to initialize the extra nonce value using the current value of a nanosecond-precision clock. That should give a unique value on every machine. Boost.Chrono is now required for compiling and I have updated the makefiles to reflect that. Thanks!! Someone please compile x86 and x64 builds. Edit: unable to compile on centos 6.4 x64 : ain.cpp: In function ‘void BitcoinMiner(CWallet*)’: main.cpp:4578: error: ‘boost::chrono’ has not been declared main.cpp:4578: error: expected ‘;’ before ‘time_now’ main.cpp:4579: error: ‘boost::chrono’ has not been declared boost_1_55_0 compiled successfully. You can get it to compile on CentOS but it's a bit more tricky than before. You need to have a newer version of boost installed. Then you need to tell the compiler where you installed the newer boost. By default it goes into /usr/local. Then you need to modify the makefile like this: cp makefile.unix makefile.my
sed -i -e 's/$(OPENSSL_INCLUDE_PATH))/$(OPENSSL_INCLUDE_PATH) \/usr\/local\/include)/' makefile.my
sed -i -e 's/$(OPENSSL_LIB_PATH))/$(OPENSSL_LIB_PATH) \/usr\/local\/lib)/' makefile.my
sed -i -e 's/$(LDHARDENING) $(LDFLAGS)/$(LDHARDENING) -Wl,-rpath,\/usr\/local\/lib $(LDFLAGS)/' makefile.my And then you type 'make -f makefile.my' to compile. Official binaries will be coming soon. I want to see if I can downgrade my glibc version first somehow. If I can get the glibc version down to 2.12, the binaries should work on CentOS. I would like to confirm that the above instructions fix an identical compilation issue on Ubuntu 13.04 |
|
|
|
|
Please add Datacoin market (DTC/BTC)
|
|
|
|
I had a wacky idea for using multisig m-of-n outputs as a vehicle for implementing decentralized datastreams as bet arbiters on the MasterCoin protocol. If interested, check it out in my github fork of the mastercoin spec and tell me if the idea could hold water. |
|
|
|
|
Even though your not open at present, you might want to remove the mention of inputs.io on your website FAQ. <Just saying>
|
|
|
|
|
You need to post in the Marketplace / Lending section
|
|
|
|
Yeah I think it's just like any confiscation due to illegal activities, where they sell the items at auction to the highest bidder. My only question is how they will sell all the BTC? If they use an online exchange that's in effect saying the exchanges are legal and ok.
If they auction them off, then the auctioning agency will need to apply for a Money Transmitter permit or the government will run afoul of itself. |
|
|
|
|
I think the key point being made is: You have no recourse if a user of your coldpi creates an image of the sd card posts a link to the image as the software is open-source and you don't "own" the software. I like the idea about pre-loading it with BTC but then you may need a register as a MSB with MT license to sell within the USA.
|
|
|
|
yes, its very weird, i plan to abandon this sub-forum, so much hate towards doge and no complain against scam coins.
Doge is a pump/dump coin... so in that sense, it is well suited for this sub-forum. |
|
|
|
So I decided to check this new hot protocol over faucet. I entered all data properly and to my surprise got 0.0000546 BTC on my Bitcoin address but 0.00125 MSC to Mastercoin address. Now I'm totally confused about the whole deal here. 1. Why amounts for BTC and MSC differ? 2. When it comes to how much BTC and MSC one receives over faucet, is ratio constant or random? 3. What happens with my 0.0000546 BTC if I spend my 0.00125 MSC or I do it the other way around? In other words, are those 0.0000546 BTC now bound to 0.00125 MSC or not? http://mastercoin-explorer.com/transactions/5c707b42cebe78283eb2d4c61e4dd7d4a241f35690b265e862844b58ef489bbethey are not bound, you can spend all the btc on the address, and the msc will still be on the address The entire mastercoin protocol is bordering on insanity. There is no correlation as to amount of BTC sent and the MSC that is sent. It is completely arbitrary. In short, there is no real security that the MSC that is received is even the MSC that is available to send. What this means is the value of 1 MSC is the same as 100 MSC or 1,000 MSC! So you do the math? If 1 MSC = 100 MSC = 1,000 MSC then clearly the underlying unit is zero. You should read the spec before accusing the developers of insanity—You clearly have a fundamental misunderstanding of what the currency MasterCoin is and how the MasterCoin protocol works. @Mastercoin Developers: There is a real lack of understanding of the MasterCoin protocol versus MasterCoin by MasterCoin-naive. There needs to be a concerted effort to disambiguate the two. |
|
|
|
|
A lot of people are hating on SkyCoin unnecessarily for the coin release mechanism, or rather, the lack thereof, but ultimately that is short-sighted. The project is open source therefore, if you don't like the system, fork it and make it better. Honestly, I would like to see a fair coin-release that followed the exodus addresss concept MasterCoin implemented. Skycoin offers one possible improvement—No devopment skycoin's should be created without a vote by skcoin stakeholders. The developers would have to live off the bitcoin raised in the exodus address or bring their projects to vote for additional skycoins. I strongly suggest such a mechanism is seriously considered and personally would not even consider using a system where the developers hold all / most of the coins (like Ripple) and release them to exchanges or partners
|
|
|
|
Well, I'm not yet an expert on this as I just recently read about it at http://www.coindesk.com/bitgo-safe-aims-secure-bitcoin-wallets-multi-signature-transactions/How about using such a multi-signature method? That way, a "consortium" can decide on the funds and needs a n-out-of-m majority for signing the transaction. Also: Look at how Freicoin is doing on their end, they have the same problem to solve with their key where the fees go to. About concerns of the dev using the coins other than expected: Well, whatever is decided, he has the private key of the address where they go to NOW anyways... Whomever he hands the key to, he might have a copy. Which does not mean I mistrust him, just stating the fact. Could be solved by releasing a new code which sends the fee to another address, moving funds to that new address, and have that new address generated by a to-be-nominated comittee. Not sure if a multi-signature key would require a new address anyway (assuming that globe supports this feature or can be made to support it, not sure of the requirements here). Kind regards Mike Hi Mike, Thanks for your contribution. I think this would be even more impractical then my idea  . The price stabilization mechanism would be run by a script and buy/sell based on predefined rules. The mechanism once their is market-depth may work very fast buying and selling multiple times throughout the day to ease price movements. Asking a group of people 24/7 to approve or disapprove a transaction would therefore be difficult. For the reserve I think there are other methods of making sure that 1 individual alone cannot access the reserves. For example we could set passwords to access the "private key de-crypting password". The passwords could then be switched between members. So 1 member would need another members password to access the "private key de-crypting password". We can go more detail into this lets fist embed the reserve and price stabilization mechanism into Globe. To be honest we have already had to change the code twice after release. You can see the effect it has had on Globe. I would rather not edit the code and release the QTs again because it may just kill Globe.  If I have missed anything or you want to discuss this further feel free to post  This is precisely the problem, you shouldn't have released Globe until you had (1) built in a described and preferably a decentralized mechanism for stabilizing the price, (2) described the process for applying for & releasing developer funds, (3) Fund-raised the BTC and LTC stabilization funds before release. Globe was likely dead at it's half-baked conception. For the stabilization process to work, Globe needs to be exchange traded at release. I suggest you think seriously about re-developing the concept. Perhaps you should integrate Globe with an escrow-backed virtual counterpart issued in colored coins or on the MasterCoin protocol—the latter option would allow for decentralized, rule-based price stabilization see https://github.com/mastercoin-MSC/spec#escrow-backed-user-currencies. |
|
|
|
|
Interesting proposal, almost any bitcoin-like blockchain could potentially host a mastercoin-like protocol layer, but why do they need to be integrated at all?
Cool idea—but might need to outline specific use cases, benefits, and vulnerabilities.
|
|
|
|
Furthermore, each coin is dirt cheap, so using is as a platform for Colored Coins makes more sense.
Your argument is misleading, i.e. one satoshi could be colored. Furthermore, it is unlikely that a competitor in the "advanced feature race" which fails to take advantage of the enormous security and value of the bitocin blockchain will be successful. Might discussion in this thread be centered on MasterCoin rather than advertising/discussing competitors? In that spirit, I have some questions regarding issuance of new currencies and datastreams in the mastercoin protocol. What possibilities are there to automate the stability concept of Escrow-Backed User Currencies? (If unfamiliar, see: https://github.com/mastercoin-MSC/spec) I am wondering what mastercoin protocol features exist or could exist for a decentralized system to both issue and manage a user currency on the mastercoin protocol. In this way users could trust the design of a "user issued" currency on the mastercoin protocol rather than an individual. Specifically, how might a network of users or an instrument such as a separate blockchain possess the capacity to distribute or transact a mastercoin protocol user issued currency? I can think of many ways to create an automated, redundant system which could do this but all of them suffer significant counterparty risk, i.e., they require trust in the creator of the distribution system rather than trust in the distribution system itself. Is there some possibility to decentrally sign mastercoin protocol data streams or transactions? You forget that there is code that treats anything less than around 5,000 satoshi as 'dust'. Therefore there is considerable effect of the price of the coin. I see. You are right about that—Excepting that such discussion belongs somewhere like here: https://bitcointalk.org/index.php?topic=106373.340Is there somewhere to actually discuss mastercoin features with active developers? |
|
|
|
I apologize for breaking up the useless banter with relevant discussion. ActM shareholders, please consider and comment: It seems Chromawallet (colored coin) development is progressing very well. I'm wondering if it would be best to skip listing on crypto-trade.com and avoid the inevitable issues that arise with trading securities on centralized exchanges. I for one, would rather not be exposed to the risk of another exchange operator "having wallet issues" — (I'm looking at you Ukyo) or simply getting bullied by the SEC. Centralized bitcoin security exchanges inevitably fail for technical or legal reasons with few exceptions. Given chromawallet's progress we may be able to use a decentralized solution by the end of January and avoid the rather significant counter-party risk crypto-trade.com represents. Perhaps Killerstorm (chromawallet developer) would provide Ken with some listing support as ActM trading on ChromaWallet might go a long way to increasing ChromaWallet's usage for decentralized stock exchange. |
|
|
|
Furthermore, each coin is dirt cheap, so using is as a platform for Colored Coins makes more sense.
Your argument is misleading, i.e. one satoshi could be colored. Furthermore, it is unlikely that a competitor in the "advanced feature race" which fails to take advantage of the enormous security and value of the bitocin blockchain will be successful. Might discussion in this thread be centered on MasterCoin rather than advertising/discussing competitors? In that spirit, I have some questions regarding issuance of new currencies and datastreams in the mastercoin protocol. What possibilities are there to automate the stability concept of Escrow-Backed User Currencies? (If unfamiliar, see: https://github.com/mastercoin-MSC/spec) I am wondering what mastercoin protocol features exist or could exist for a decentralized system to both issue and manage a user currency on the mastercoin protocol. In this way users could trust the design of a "user issued" currency on the mastercoin protocol rather than an individual. Specifically, how might a network of users or an instrument such as a separate blockchain possess the capacity to distribute or transact a mastercoin protocol user issued currency? I can think of many ways to create an automated, redundant system which could do this but all of them suffer significant counterparty risk, i.e., they require trust in the creator of the distribution system rather than trust in the distribution system itself. Is there some possibility to decentrally sign mastercoin protocol data streams or transactions? |
|
|
|
|
Show Posts
