Author

Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 349. (Read 1276912 times)

full member
Activity: 216
Merit: 100

A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view):

"Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it.

Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...

So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?


Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles?

Peter Todd has already explained why this is not a good idea: https://bitcointalksearch.org/topic/m.5824434
newbie
Activity: 24
Merit: 0
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).

FYI: you could also use uncompressed pubKeys. 0400...0 is not a valid ECDSA point in the first place, thus it might be possible to drop the prefix, too.

https://blockchain.info/tx/2de38a49f0079d0aaa8a0b9cfec71b1af935752b609eee0dc1eae56b2162a7e2

 Grin , dexX7 must have dozens of nefarious tricks up his sleeves already if it ever gets to the cat and mouse game as someone puts it earlier.

What else does it take for the devs to realize that OP_RETURN is the OP_SCRIPT_SUPER_EXTENSION for transactions at the upper layers?
Instead the simple OP_RETURN is still being painted as just storing data when there are countless ways to do that already.


full member
Activity: 210
Merit: 100

A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view):

"Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it.

Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...

So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?


Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles?
legendary
Activity: 1106
Merit: 1026
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).

FYI: you could also use uncompressed pubKeys. 0400...0 is not a valid ECDSA point in the first place, thus it might be possible to drop the prefix, too.

https://blockchain.info/tx/2de38a49f0079d0aaa8a0b9cfec71b1af935752b609eee0dc1eae56b2162a7e2
newbie
Activity: 39
Merit: 0
member
Activity: 70
Merit: 10
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...

If this is too difficult for you, just sell everything, and get back playing with your Barbie dolls... People are incredible, you must be French to complain that much.

haha. calm down man. Never complained. Just asked/suggested.
newbie
Activity: 56
Merit: 0
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...

If this is too difficult for you, just sell everything, and get back playing with your Barbie dolls... People are incredible, you must be French to complain that much.
member
Activity: 70
Merit: 10
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 Smiley

@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).

What I meant was to (medium/long term option) hardcode the need for collateral (xcp as collateral)...  
newbie
Activity: 39
Merit: 0
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).

XBTC is cool, but it still leaves us with Counterparty risk. If there were additional ways to help mitigate that risk, either with XCP backed assets, or say, with OT style voting pools, I think it'd make the Counterparty ecosystem even more attractive.
hero member
Activity: 602
Merit: 500
sr. member
Activity: 390
Merit: 254
Counterparty Developer
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 Smiley

@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).
newbie
Activity: 53
Merit: 0
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
 Cool
newbie
Activity: 53
Merit: 0
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
newbie
Activity: 53
Merit: 0
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
newbie
Activity: 53
Merit: 0
Newbie here.  So is proof-of-burn still how people are buying these?  Or should I buy through Poloniex? Wink

I was a rookie
Hope to get help from others
Someone to help us? Smiley Smiley Smiley Smiley Smiley
sr. member
Activity: 432
Merit: 250
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?
newbie
Activity: 53
Merit: 0
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
Jump to: