[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[deliciousowl]

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.

This may be possible in the future, who knows...

[l4p7]

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? 

You have at least one working eye, an internet connection, and you can hopefully click on the pages on top. People are so lazy nowadays, incredible.

It's just difficult to monitor NXT, Counterparty and all the other projects closely at the same time...

[l4p7]

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? 

You have at least one working eye, an internet connection, and you can hopefully click on the pages on top. People are so lazy nowadays, incredible.

What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp. 

[wizzardTim]

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? 

The talk with BTC devs to eliminate XCPs way of work + the upcoming change in MAXCoin made many people sell XCP for MAX for some time.

But that's just my point of view.

[km4700ruda]

Can we also create an unofficial wiki, that any one of us can edit. That way we would be able to add how to's and other instructions without waiting for the developers.
This will really help in easing newbies into the product.

Your proposal is really very idea
And very good
At least I feel very good

[km4700ruda]

i want my xcps back
 busoni,Should not be because of your mistake, let us bear all the losses

Good luck to you
I really don't want to see that happen
 

[xnova]

Great news! Pay-to-PubKeyHash Functionality Added
https://www.counterparty.co/pay-to-pubkeyhash-functionality-added/

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.

The intent of introducing pay to pubkeyhash encoding is, as stated above, for a worst-case scenario. We will never use this kind of encoding by default, and it will only be as a last resort if we have no other viable alternatives. I suspect that if things ever did get to that point with Bitcoin, we would also strongly be considering a different block chain as well. We are hopeful this situation would never have to happen, but this provides an assurance to investors and people that use the Counterparty network to build and transfer value that it won't just 'disappear' overnight.

[xnova]

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? 

You have at least one working eye, an internet connection, and you can hopefully click on the pages on top. People are so lazy nowadays, incredible.

What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp. 

The Counterparty distributed exchange doesn't work with blockchain-based currencies other than the one it is built on (Bitcoin). The reason for this is that it would necessitate enhancing all of the software to download and integrate with the additional blockchain and daemon (e.g. litecoin and litecoind). Moreover, the security of the Counterparty network as a whole would be only as strong as the weakest chain, if XCP were free to "float" across chains in some way. The implementation complexity would also rise greatly, and it would significantly enhance the complexity of the Counterwallet UI. At this point at least, the tradeoffs here seem not worth the benefits (however this may change in the future). Our first concerns with Counterparty are security and simplicity of implementation, and the latter highly influences the rate of development that we have been able to deliver at thus far.

On the DEx you can trade Counterparty user-defined assets. This is an emerging area, and I can tell you, that by the end of the year, this will be exponentially more useful than it seems now.

[freedomfighter]

Great news! Pay-to-PubKeyHash Functionality Added
https://www.counterparty.co/pay-to-pubkeyhash-functionality-added/

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.

The intent of introducing pay to pubkeyhash encoding is, as stated above, for a worst-case scenario. We will never use this kind of encoding by default, and it will only be as a last resort if we have no other viable alternatives. I suspect that if things ever did get to that point with Bitcoin, we would also strongly be considering a different block chain as well. We are hopeful this situation would never have to happen, but this provides an assurance to investors and people that use the Counterparty network to build and transfer value that it won't just 'disappear' overnight.

Thanks for the explanation.

I wonder though what was the logic in declaring this publicly. Since it is a last resort of sort.

I (want to) assume that there is some line of communications between you guys and the BTC devs. I am sure not all liked the language and attitude of Luke jr. etc. PP was going to PM Mike Hearn etc.

So it seems that this announcement might be counterproductive no?

[PhantomPhreak]

Great news! Pay-to-PubKeyHash Functionality Added
https://www.counterparty.co/pay-to-pubkeyhash-functionality-added/

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.

The intent of introducing pay to pubkeyhash encoding is, as stated above, for a worst-case scenario. We will never use this kind of encoding by default, and it will only be as a last resort if we have no other viable alternatives. I suspect that if things ever did get to that point with Bitcoin, we would also strongly be considering a different block chain as well. We are hopeful this situation would never have to happen, but this provides an assurance to investors and people that use the Counterparty network to build and transfer value that it won't just 'disappear' overnight.

Thanks for the explanation.

I wonder though what was the logic in declaring this publicly. Since it is a last resort of sort.

I (want to) assume that there is some line of communications between you guys and the BTC devs. I am sure not all liked the language and attitude of Luke jr. etc. PP was going to PM Mike Hearn etc.

So it seems that this announcement might be counterproductive no?

Creating unspendable outputs is hardly the worst thing in the world. It happens every time someone loses a private key. Even if Counterparty created a thousand of them for every one of its transactions, it would still be adding enormous value to Bitcoin. All concerns about storing data in the blockchain are ideological, not practical; encoding in spendable (or better yet provably prunable) outputs is merely ideal, and there are a lot of things about Bitcoin's design, for instance, that are very, very far from that standard.

[CryptoFinanceUK]

What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp. 

Funnily enough, I just posted a similar idea in the main Counterparty forums.

[l4p7]

What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp.  

Funnily enough, I just posted a similar idea in the main Counterparty forums.

+1

@xnova, thanks for your post above. Any comment form developers on the collateral idea? Ad- and disadvantages? Posibility of implementation?  

[jioy]

too low!!!

[koinjoin75]

I think that the ability of getting XCP with proof-of-burn should be postponed to the time when there will be a stable client. It will help the distribution of the coin. If not there will be another distributed exchange with large-holders(who risked their money into a thing that didn't worked at the time) which will be very unhealthy for the counterparty system.

I think your suggestion is very good very correct
The proposal should get their research
Hoping to solve

[deliciousowl]

I think that the ability of getting XCP with proof-of-burn should be postponed to the time when there will be a stable client. It will help the distribution of the coin. If not there will be another distributed exchange with large-holders(who risked their money into a thing that didn't worked at the time) which will be very unhealthy for the counterparty system.

I think your suggestion is very good very correct
The proposal should get their research
Hoping to solve

This doesn't make sense. The proof of burn is over. It has been since January.

What are you even talking about?

[koinjoin75]

Newbie here.  So is proof-of-burn still how people are buying these?  Or should I buy through Poloniex?

I was a rookie
Hope to get help from others
Someone to help us?

[koinjoin75]

Asset fees should not be burned because then we are diminishing the total supply. Since there is no mining, or additionally BTC burning going on, why don't we change the protocol to distribute asset fees among all holders of XCP?

1) Distributing the XCP is very difficult technically, because of rounding issues.
2) The two possibilities are economically equivalent, and the total number of XCP doesn't matter so much, because of the divisibility.

You don't think a higher escrow amount would have worked better than a 5 xcp asset fee? We have hundreds of Asset names already parked - imagine what it will be like when the user base is 50x ?

The vast majority of those assets were created before the fee was put in place.

I agree with you
I believe many people have this idea

[koinjoin75]

Does anyone know the legality of the devs getting rid of something within the protocol which is non consentual to other users of bitcoin, it can;t be legal

there must be regulations in place

Not kidding, I honestly did laugh while reading this.

XCP people threatening lawsuits over their choice of poor design implementation that leaves them vulnerable to any whim the BTC devs might have for changing protocol.

Counterparty might provide benefits, so it would probably be good if it succeeds, but this is not a viable argument route haha.

See this article
I also can't help laughing

[koinjoin75]

How much of this proposal, and of other similar proposals, can be handled by the asset description field? (Not much space is needed to store a URL.).I love namespaces, etc., but I want to keep the protocol-level as simple and as stupid as possible. We could do this sort of thing is Counterwallet and BootleXCP themselves, for example.

Extremely good point and porqupine has also communicated the same to me.

We would only need a naming convention on how to format the asset description field. The rest can be up to the client side to parse it.

As long as there was some defacto which was perhaps outlined by the Counterparty team but not necessarily enforced, then everyone would be a happy camper.

Eg Lets just use the tilde as a delimiting character in the description. Field 1 = namespace, field 2 = description, field 3 = url

It needs to be a new long asset name field that is enforced by the protocol for long names.  A description will not work because users can put anything in there.

My understanding (a dev can correct me) is that the description field can be modified for an asset.

So lets just say we all agree on a defacto standard for the description field. There are 3 fields delimited by a tilde.

Each of the clients can just invalidate and fail to show any asset in their list where 3 tildes aren't found. The asset owner would have motivation to get it right.

I think you understand very well
That's perfectly correct
I said I agree with you
 

[xnova]

What about requiring the issuer to put collateral (xcp) into the system. For example: I issue LTC within Counterparty and have to put up xcp worth the amount of LTC that is bought from me. This would make the system more safe/reliable and boost the demand for xcp.  

Funnily enough, I just posted a similar idea in the main Counterparty forums.

+1

@xnova, thanks for your post above. Any comment form developers on the collateral idea? Ad- and disadvantages? Posibility of implementation?  

I like this idea a lot. It's almost like a margin call, where the issuer needs to keep putting up collateral as the value changes. Maybe the details about max funding amount, duration, etc. could be specified in new asset fields? If the issuer didn’t want to be long XCP vs. the other asset they could also raise money on the DEX, buy LTC (or whatever) with the XCP they raise and keep that as side collateral so that they are never better or worse off as the asset changes in value.

There is nothing to stop people from issuing LTC (or whatever) trading derivatives, similar to how XBTC has been created on Counterparty as essentially a proxy for BTC. We encourage folks in the community to come up with and enact these kinds of use-cases (in a thoughtful, responsible manner, not unlike how XBTC was created and is operated).