|
A quick question about Counterwallet.
If someone enter the pass phrase with a wrong word by mistake, can he still login to a newly created account? In this case, if he store a lot of XCP into this account, he may have no chance to login to this account later because he did not really know what's the pass phrase he entered.
EDIT: it is confirmed that user can login into a wrong account by accident, for example if he type 'might' for 'mighty' or vice versa.
Is there any measure has been taken to avoid this issue? For example, has to enter pass phrase twice for a newly created account?
EDIT: it seems there's no way to avoid this mistake yet.
Otherwise, users have to be warned that you have to login into the same account at least twice and check the generated addresses are the same, before you store any value into this account.
|
|
|
|
Deprived, could you please do the following things immediately since now you apparently don't have enough time and interest to manage this fund any more.
1, pay the outstanding MINING dividend.
2, give options to redeem MINING + SELLING pairs.
3, allow shareholders to trade SELLING so that one side get BTC and the other side get MINING SELLING pair.
4, to facilitate 3, please make the holding list public, at least for SELLING.
All my 4 suggestions can be done immediately without waiting for any conditions. Therefore, please don't postpone again with any reasons or just disappear without any explanation.
Deprived always talked about moving to ciphertrade, which should open today!! Let's wait a little bit, maybe we'll be surprised!! As I said already, my proposal does not need any prerequisite. It can be done immediately, and does not matter whether the fund is closed or relisted at last. There's really no any reason to wait for anything now. Moreover, do you think the current situation is caused by lack of exchange? If the fund is always in an exchange, it's price will be miserable now. |
|
|
|
|
Deprived, could you please do the following things immediately since now you apparently don't have enough time and interest to manage this fund any more.
1, pay the outstanding MINING dividend.
2, give options to redeem MINING + SELLING pairs.
3, allow shareholders to trade SELLING so that one side get BTC and the other side get MINING SELLING pair.
4, to facilitate 3, please make the holding list public, at least for SELLING.
All my 4 suggestions can be done immediately without waiting for any conditions. Therefore, please don't postpone again with any reasons or just disappear without any explanation.
|
|
|
|
Can anyone tell me what happened in the last three days here? Any reason for the recent little price drop? What about something like this http://www.nxtcoins.nl/50-2/ for Counterparty? And another, more general question regarding the DEX: Can I atm only trade BTC to XCP on there or more? Let's say n the future there will be more con (LTC for example) can I then, after I bought LTC with BTC on the DEX, withdraw those LTC into my LTC wallet? Not really. You can only trade assets issued in the DEX (BTC is the only exception), not other coins, unless someone issues an asset here to 1:1 map that coin and you trust him/her. |
|
|
|
Sorry if this sounds like a dumb question but I don't understand the implications - what does " it will be enabled on mainnet with block 293000" really mean since bare multi-sig is still the default method used going forward at least in the near future. Is the protocol capable of automatically switching to pubkeyhash if it fails to create a bare multisig transaction and relay it successfully. It means the protocol will parse this kind of encoded transactions from block 293000, but it does not mean the client will encode in this way. Ah that makes sense I don't see this as a threat as you state, even if the protocol is capable of parsing it, the client is not yet sending this transaction. This ensures continuity for XCP in the short term, its a business continuity plan in an adverse situation that has not been triggered. Hopefully saner heads will prevail. In the meantime, XCP has a way forward even if the situation deteriorates from where we stand currently. PP has always been against creating transactions with unspendable outputs. It looks like the devs are looking after worse case scenarios, nothing more than that. If counterwallet were to start sending these messages, I would agree with everything you are saying. But we are not there yet and hopefully will not be. Yes, I agree with you and with this method will never be really used. |
|
|
|
Sorry if this sounds like a dumb question but I don't understand the implications - what does " it will be enabled on mainnet with block 293000" really mean since bare multi-sig is still the default method used going forward at least in the near future. Is the protocol capable of automatically switching to pubkeyhash if it fails to create a bare multisig transaction and relay it successfully. It means the protocol will parse this kind of encoded transactions from block 293000, but it does not mean the client will encode in this way. |
|
|
|
|
Up till now, all the counterparty devs have done are respectable and admirable. I really appreciate the fairness, transparency, non-greedy they have shown us. I think even counterparty fails in the end (which I think unlikely), it is still a great project that have great devs and great community.
Therefore, I am really sad to see the devs try to (or have to) use this method to defend this project. Maybe just me, I don't want to see someone succeeds in a battle by threatening others that they will do something really bad, even I know they have good motive and I am in their side.
As we all know, XCP lives with BTC together. Even I have quite some XCP myself, I don't want to see XCP succeeds by hurting BTC, and finally hurts XCP itself. Moreover, I know that we will not win the battle if we use this method.
If counterparty is really successful and this mothod is used, I believe the core dev of bitcoin has no choice but filtering all counterparty transactions to protect the bitcoin. They have to do this, because if counterparty succeeds, each counterparty transactions will introduce around 3 unspendable BTC transactions and these transactions cannot be removed from the blockchain except explicit filtering.
|
|
|
|
Actually quite sad to see this, and wish it will be never used. I understand why Devs implemented it, but this method introduces a lot of unspendable outputs and can never be pruned from the blockchain. Kinds of like ' if you don't let me to do this, I have no choice but to do the worse thing.' Don't think this method cannot be filtered by bitcoin core dev. This is an open source project, any miner can parse counterparty protocol and filter it as easy as us. BTW, even if we really want to use it, it's slightly better to use PayToPubKey instead. One pub key has 32 bytes, larger than 20 bytes (the size of key hash). |
|
|
|
How do you know it is Robby who begun the counterparty? Is there any proof of you just know? Do you have actual proof the Earth is round? ...or do you just ' know'? What is ' proof'? I am not debating with you. It's a honest question. Btw, there're a lot of beautiful photos of our Mother Earth.  |
|
|
|
Calling Counterparty a "copycat" is calling it as it is. They've copied Mastercoin down to smallest details and Mastercoin's idea of using BTC blockchain.
Counterparty is not anonymous. Everyone knows it is being built by 'Robby' - https://bitcointalk.org/index.php?action=profile;u=102837 You can check precisely from where the whole thing started: https://bitcointalk.org/index.php?topic=265488.msg3822194;topicseen#msg3822194 Robby wanted to join Mastercoin and he started telling everyone how they suck and he is an experienced professional who has done many big projects. Mastercoin didn't get impressed with Robby's 'big swinging dick' attitude - so they told him "No thanks". So Robby went off and did his own thing: CounterParty. Robby built something nice. However, the Mastercoin infrastructure is much more than Robby's fast programming ability. Mastercoin is a community of dedicated hard working guys who COOPERATE together. Robby is a single dominant personality who wants to take over and tell others who don't agree with him - they suck. We'll see which holds up. Robby's work is no doubt nice. But Robby is not a community of cooperating parts. Counterparty will copy Mastercoin and every step - in some places, CP will even look better. But CP will not be able to pass MSC as CP is mere a one man show with loads of coding skill. It is a shame really. Mastercoin could have used contributions from Robby. But his dumb-ass personality got in the way. He isn't the kind of guy who cooperates with others. 'My way or the highway'. So - he took the highway. Bye-bye robby. I had to laugh a bit at this post, especially the “big swinging dick” part. Here's the deal, guys: I got involved with Mastercoin because as an investor, I felt that things were in a bit of a rut and my skills could potentially be useful. I had some ideas that I put out there in a way that the Mastercoin team was free to integrate, or not. It was never intended to be a “my way or the highway” kind of thing, and any references to “my business” or “my experience” was simply to help give the ideas context and to establish a relevance to them, *not* to puff me up personally. Moreover, I offered support and resources as well in several proposals (by for instance, promoting the idea of a “mastercoind” as well as developing part of it and offering to finish it, offering development resources, providing some targeted, experience-based tips to the team, and more). My intention and goal there was not to “steamroll” anyone, nor force anything down people's throats, but more to raise an objection and outline a potentially better way of doing things in some regards, and then let the community voice their support or lack of support for it. The best ideas should emerge and thrive, by consensus. “Dominant personalities” do not do a good job building organizations, products, projects, or anything really which involves more than one person – them. My track record points to collaboration, working well with others, and being able to delegate effectively (which is the only way to grow something beyond yourself). Was it always this way? No, and I had to learn some very good, but hard lessons along the “school of hard knocks” path, and am still learning. Like most people, I have more failures than successes in my life, but unlike many people, I really try to learn from each mistake and improve. In fact, all else being equal, I prefer to stay in the background – it's easier that way, and actions should speak for themselves. However, if I see something that is not going too well, and I have the interest, available time, and may have the skills to potentially help, then yes, I may get involved at that point. The only reason I stated my opinions is because I felt that logical, decisive action was lacking at the time in a few targeted areas, and things were not moving quickly enough. It was clear the “storm” that was coming in this space, and that Mastercoin would not be able to enjoy its first-mover advantage for long. In a few short months, this has come to pass. I am glad to see that Mastercoin is becoming better organized and learning from past mistakes. This is a mark of any good organization. However, the luxury of time is no longer on their side. I am still a Mastercoin investor, and am grateful to the team (especially David, Ron, Taariq at the time, etc) for talking to and getting to know me and the ideas I had around team building and software development. Hopefully it was not a waste of time for them. I noticed that you neither admitted nor denied that you are phantom. |
|
|
|
i am coming!
i suggest xcp team use MXCP for Unit NOW。especially the net Wallet。like Mantissa pricing,this is Scientific research
and then it seem like more Bargaining chip for Issuance of asset
and more people like buy it because it seem so cheap like dogecoin
if 1.3 usd can buy 0.1XCP and 100MXCP ,i think you will choose 100mXCP because 100 look so comfortably then 0.1
Foresight XCP will have a bright future. 2,648,496 is such a small quantity. i think we should use mXCP as default unit from now on. As a possible newbie coin-buyer, judging strictly from the chart action, is this coin dead? Why do you think so? Based on the price or volume? Counterparty is different from the other altcoins. It provides new functions to BTC and it's value needs to evaluated on its function rather than its short term price or volume. The price now is still pure noise. |
|
|
|
Calling Counterparty a "copycat" is calling it as it is. They've copied Mastercoin down to smallest details and Mastercoin's idea of using BTC blockchain.
Counterparty is not anonymous. Everyone knows it is being built by 'Robby' - https://bitcointalk.org/index.php?action=profile;u=102837 You can check precisely from where the whole thing started: https://bitcointalk.org/index.php?topic=265488.msg3822194;topicseen#msg3822194 Robby wanted to join Mastercoin and he started telling everyone how they suck and he is an experienced professional who has done many big projects. Mastercoin didn't get impressed with Robby's 'big swinging dick' attitude - so they told him "No thanks". So Robby went off and did his own thing: CounterParty. Robby built something nice. However, the Mastercoin infrastructure is much more than Robby's fast programming ability. Mastercoin is a community of dedicated hard working guys who COOPERATE together. Robby is a single dominant personality who wants to take over and tell others who don't agree with him - they suck. We'll see which holds up. Robby's work is no doubt nice. But Robby is not a community of cooperating parts. Counterparty will copy Mastercoin and every step - in some places, CP will even look better. But CP will not be able to pass MSC as CP is mere a one man show with loads of coding skill. It is a shame really. Mastercoin could have used contributions from Robby. But his dumb-ass personality got in the way. He isn't the kind of guy who cooperates with others. 'My way or the highway'. So - he took the highway. Bye-bye robby. How do you know it is Robby who begun the counterparty? Is there any proof of you just know? |
|
|
|
Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view. I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin. The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_ProposalsIt is not my job to hold everyone's hand, be your nanny, and fix everybody's software. If you like decentralized development, you should know that. There is a demonstrable engineering flaw. CheckMultiSig() is built for ECDSA public keys. Counterparty is not storing ECDSA public keys there. When you use a system outside its design specifications, there are bound to be negative side effects. From this we may conclude, contra to the hyperventilating on this thread, - I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
- I'm well versed in in-chain data projects -- I wrote some myself
- Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
- This feature may be going away anyway, for other reasons
- Plenty of innovation is going on in the bitcoin space. It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks
To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view. Thanks a lot for the opinion from another Core Dev of Bitcoin. To be fair, Counterparty plans to use OP_RETURN from the beginning, and using CheckMultiSig is just a workaround added just before the official release because nobody knew when the core 9.0 would be out and whether OP_RETURN will be added. Now imagine Counterparty did not add CheckMultiSig and kept waiting for OP_RETURN added in this core and now suddenly find that OP_RETURN has been reduced to 40 bytes at the last minute. If we calm down and it will not be difficult to understand that the devs of Counterparty don't want to use CheckMultiSig at all. They and all the community are looking forward to removing CheckMultiSig and using OP_RETURN for the good of bitcoin and, to be honest, also reducing the trading fees caused by CheckMultiSig. Nobody is arguing that Counterparty has to use checkmultisig. Current situation is that, the functionalities are designed for 80 bytes OP_RETURN. With only 40 bytes OP_RETURN, counterparty are forced to keep using checkmultisig against the benefit of both communities. |
|
|
|
You don't want the bitcoin protocol to change to allow counterparty to operate in a more beneficial way, and then you say that it will change in the future. It will upgrade to allow that support in the future. I never said I didn't want the Bitcoin protocol to change. On the contrary, I support extending it to do what Counterparty wants. But such extensions are slow-moving right now, and take time to implement properly. I also understand Counterparty wants a solution "today". I agree the 80-byte OP_RETURN is a good short-term way to do this. Deploying a whitelist to miners, to accept these Counterparty transactions can be done within a few weeks. But deploying a default relay policy change requires months (releasing a new version of Bitcoin Core, and the slowest part: waiting for all the users to upgrade). Thankfully, there is an immediately available workaround to not having the default relay policy "on your side": Just have Counterparty participants relay their transactions to nodes running the updated relay policy. So, recommended course of action: Immediate-term:1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions. 2. Deploy patch to major mining pools, and open merge request with mainline Bitcoin Core. 3. Begin using OP_RETURN Counterparty immediately; use addnode to get it relayed to miners. Short-term:4. After discussion, patch is merged to Bitcoin Core. 5. Bitcoin Core 0.10 is released with a default relay policy accepting Counterparty transactions, and addnode is no longer needed. Long-term:6. Counterparty developers discuss future plans with Freimarkets developers and others interested in this kind of functionality. 7. Interested developers figure out the best way to do everything, probably including using merged-mining, side-chains, and other things that are impractical today. 8. Interested developers implement new system, and write a BIP documenting it. 9. BIP gets reviewed. 10. Counterparty users upgrade to new version based on BIP. 11. Everyone gets a break. Hopefully that clarifies my position. Luke's suggestion seems reasonable. However, the second step in the immediate plan is quite difficult, if not impossible. How can we persuade the operators of BtcGuild, GHash.IO, and Discus Fish to accept the patch? Moreover, there are around 30% of the hashing power belong to 'Unknown'. Who to contact for these miners? Most likely the Eligius is only one can apply the patch since it is run by Luke himself, but Eligius only have around 14% of the shares. (according to http://blockchain.info/pools) More practical way is 1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions. 2. contact major mining pools and request them to apply this patch, and open merge request with mainline Bitcoin Core. 3. Use OP_RETURN for data <= 40 bytes. Keep using CheckMultiSig for data > 40 bytes, until more than 60% (GHash.IO + BTCGuild + Eligius + Discus Fish) of hashing rate accepts that patch, and then use addnode to get it relayed to miners. Otherwise, just wait until the new core with the counterparty patch is out (Personally I think the latter, although difficult, has higher chance to be successful). I believe the main operators are as reluctant to take the counterparty patch as they will take other patches to filter CheckMultiSig. Therefore, everything will be fine if the official core accepts the counterparty patch before accepting the filtering CheckMultiSig patch. However, I still think try to encode the transactions in a more efficient way is still the best option now. I believe that, most transactions, if not all, can be encoded with 40 bytes. |
|
|
|
|
Personally, I think we can evaluate the possibility to compress our most transactions to 40 bytes now. If it is possible, it's better to do it now cause no real OP- RETURN has been used in main net yet and no need to worry about backward compatibility.
I agree that to force it to fit 40 bytes introduces a lot of unnecessary work, but anyway reducing the block chain size is beneficial to the bitcoin in the long term.
A tx = flag + asset id + amount + price + expire + fee ... I think it's doable to encode them in a space efficient way.
|
|
|
|
|
Tried the wallet.
1: "No counterparty servers are currently available. Please try again later. ERROR: undefined"
2: Second, the webpage cannot be scrolled or zoomed in both Safari and Chrome. This is not friendly to small screens especially for mobile phones.
3: In the page for enter words with screen keyboard, the words entered are not masked. Moreover, sometimes the keyboard does not work at all and has to press the screen keyboards and the response is pretty slow. (Chrome) Screen keyboard is really really painful and I doubt anyone will like to use it.
Thanks for the hard working and wish my comment helps.
|
|
|
|
As far as I know, 80 to 40 does not change much. Previously we divide data into segments of 80 bytes, now 40 bytes. Just the number of outputs doubled. What's the big deal? Only one OP-RETURN is allowed in one transaction?
Only one allowed. Oops. Then we have to keep using multisig for long data. do we know how many percent of current transactions can be squeezed into 40 bytes now? Could we use asset id instead of using the name everywhere? |
|
|
|
|
As far as I know, 80 to 40 does not change much. Previously we divide data into segments of 80 bytes, now 40 bytes. Just the number of outputs doubled. What's the big deal? Only one OP-RETURN is allowed in one transaction?
|
|
|
|
|
Nobody comments on why Tachikoma and his friend went to Etherium just a month after he agreed to work full time for Mastercoin? Nobody cares who is working on the reference implementation of mastercoind now? Why people keeps believing or wishing but never really ask these kind of important questions? Trying to prove mastercoin is better than counterpary, Etherium, or whatever else does not help anything. We, the investors of MSC, should keep asking questions to JR, Ron about the current status and the real reason why the 2/3 of full time developers (they spent so much time in hiring them in the first space) leave.
|
|
|
|
|
I really don't think 5 XCP is a big price to a serious issuance now. the problem is just that it is burnt. However, even there will be 10k assets, 50k XCP is still a small part of 2.6M. Moreover, the fee can be reduced later when XCP appreciate a lot.
Please don't low the fee too much and otherwise there will be a lot of rubbish asset names.
|
|
|
|
|
Show Posts
