Author

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

newbie
Activity: 24
Merit: 0
...
You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?

I think you just need to have proof that it's been seen/published before Smiley

So P2SH^2 makes it hard to publish data by requiring another hash.
If we can't send data directly via P2SH^2, we could still reveal our data in the actual script later on.
Once the data is seen elsewhere (like in the script to redeem), we can then look at the previously confirmed P2SH^2 txn for the proof.
legendary
Activity: 905
Merit: 1012
Peter, I don't think that's fair or accurate. Anyone observing the chain gets proof of publication of matched orders, and a filtered average over the last N blocks gives you a relatively good idea of the current price in a secure way which you can compare with what you're seeing on the wire. Additionally, such a setup does not rule out the possibility of other proof-of-publication systems being used for distributing the orders. It simply recognizes that consensus over matched trades and consensus over open orders are logically distinct, and data from one need not clog up the other.
full member
Activity: 238
Merit: 100
From my point of view:
(please excuse the table, these forums don't provide much functionality)
PoW BTC ProsPoS CP Pros
  • Large amount of hashing power to ensure security
  • Early mover adoption advantage (fairly widespread)
  • Piggyback on media exposure
  • Legitimacy boost (via bitcoin legitimacy)
  • Can switch between BTC and XCP without exchange
  • Large amount of hashing power unnecessary (more security from less energy)
  • Environmentally friendly (forward thinking)
  • Blazing fast transactions
  • As much OP_return space as we need
  • No large blockchain to turn away early adopters
  • Instead of designing the protocol to work within the scope of bitcoins protocol, we have the freedom to develop without limits
  • IN CONTROL OF OUR OWN DESTINY
PoW BTC ConsPoS CP Cons
  • Slow Transactions
  • Must buy BTC to use XCP (just one more middleman to go through)
  • Paying tx fees to third party (instead of ourselves)
  • Must sync non-CP related transactions (13GB blockchain at start)
  • At mercy of bitcoin developer whims (Protocol could be rendered invalid without notice)
  • NOT IN CONTROL OF OUR OWN DESTINY
  • Can't switch between BTC and XCP as easily (must use an exchange)
  • I honestly can't think of any other downside (security was the only real downside mentioned and that point is moot with a PoS blockchain isn't it?)

+1
Nice, analysis. Something we should keep in mind if and when the time comes for the move off the bitcoin blockchain.
legendary
Activity: 1120
Merit: 1160
Except that the offer doesn't have to be published on-chain until the trade occurs. You could simply publish the bid and the ask at the same time to get single-step (from the chain's perspective) trades, and use some external mechanism such as the p2p network or bitmessage to move orders. This is what Freimarkets does.

Without a proof-of-publication system where you're guaranteed (with high probability) that your offer either gets to a well-defined audience or you find out you're being jammed you're vulnerable to getting ripped: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03892.html If Freimarkets doesn't have that guarantee then it's insecure against sybil attacks, and worse, such attacks are profitable.
legendary
Activity: 905
Merit: 1012
Except that the offer doesn't have to be published on-chain until the trade occurs. You could simply publish the bid and the ask at the same time to get single-step (from the chain's perspective) trades, and use some external mechanism such as the p2p network or bitmessage to move orders. This is what Freimarkets does.
dpb
newbie
Activity: 28
Merit: 0
why couldn't you use bitcoins directly given that you're already on
the same chain?

You can, but a trade involving bitcoin requires an extra transaction to send the funds; trades between XCP and an asset or between an asset and another asset can be completed with only two transactions.

Thank you for the clarification. So the functions it provides is to be the only p2p currency that can be traded in 2 transactions instead of 3 with other assets.
2 transactions is too much, it is possible to do the trade with one transaction if your chain explicitly validates the asset issuance rules.


It's impossible to make a trade in less than 2 steps.

  • Step one: somebody publishes an offer
  • Step two: somebody accepts the offer

A trade with only one step is better known as theft.
newbie
Activity: 44
Merit: 0
Hey I finally have BTC to buy XCP. I couldn't find the buy\sell thread. Buying 1000 xcp for 4 bitcoin. Any amount is fine. any method is fine. PM me.

EDIT: I found the buy thread.
newbie
Activity: 36
Merit: 0
Pathetic trade volume in BTER and poloniex.
legendary
Activity: 1120
Merit: 1160
The opposite of over-engineering is under-engineering.  Creating the least viable product.  The most minimal, simple implementation that can do what you want it to do.  Counterparty is this solution for the distributed exchange/Bitcoin 2.0 idea.  It works, today.  It does so by leveraging the existing Bitcoin network and protocol, which allows the developers to devote their time to getting the important parts right.  How much would the Counterparty codebase increase in size if it required its own blockchain?  I'm betting it would be somewhere in the triple to quadruple range.  Counterparty will continue to work for at least the near future.  If a day comes when it is made not to work by outside forces, Counterparty will change in order to work.

Actually that's incorrect: Counterparty and Mastercoin both have a significantly larger codebase by not requiring their own blockchain. Of course when I say "larger codebase" I mean the code required above and beyond the Satoshi codebase itself. Freimarkets is an example of a system that took the opposite approach of reusing the Satoshi codebase and requiring its own blockchain, and by doing so it got to reuse blockchain-related code from the Satoshi codebase that Counterparty and Mastercoin had to implement themselves. Of course, what they implemented is more simple than reimplementing blockchain code from scratch, but their approach is definitely not the "least-work" way of doing so; Freimarkets is.

But if "what you want it to do" is to be secure against attackers, then the minimum viable product has to be an embedded system as opposed to independent or merge-mined and you're stuck writing embedded-consensus blockchain code.
legendary
Activity: 1120
Merit: 1160
Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.

Counterparty does in fact interoperate with Bitcoin scripting in that you can add conditions to a transaction in the form of Bitcoin scripts - the transaction can only go through if the Bitcoin script evaluates true. I know for a fact that this is used in Mastercoin to allow for atomic Mastercoin<->Bitcoin trades in the decentralized marketplace functionality; I'm sure Counterparty works similarly. Further exploring how to exploit this is on my TODO list, as is adding scripting functionality to Mastercoin itself. (though I'm in no particular rush to do so - my TODO list is rather long!)

Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.

I've said this over and over: Counterparty gains security from this. Client-side validation means you can't be harmed by malicious miners; merge-mining means you can be at nearly zero cost to those miners. We only have to look at Coiledcoin to see why this matters.

As for the inefficiency, yes, currently the global state of the Mastercoin and Counterparty consensus is implemented inefficiently, which is why I'm working on examining how to improve on that with compact proofs of coin validity for Bitcoin. I'm pretty confident that at least linear scaling is possible with simple math using non-interactive proofs, better than linear with "moon-math". There are many ways to apply that research to embedded consensus systems.

In the meantime I'm glad Mastercoin and Counterparty are exploring a huge set of other considerations related to the design of "decentralized finance 2.0" systems.
legendary
Activity: 905
Merit: 1012
There are two problems with that.

First, the system adopted by Counterparty is hugely inefficient. It won't scale. That's why we're making all these complaints about node validation and SPV mode - because these are what lets bitcoin scale even to the level it is currently at. And Counterparty as implemented lacks this capability entirely - and in such a way that it cannot be retrofitted in later.

Second, Counterparty should be working as Bitcoin developers and using existing Bitcoin code and infrastructure. Writing this sort of consensus code is the same difficulty whether you are doing it as a fork or improvement to bitcoin, or doing it as soem sort of embedded/parasitic system. Really, it doesn't make a difference: you still have to deal with the same sorts of issues in either case. The analogy about code encapsulation is cute but doesn't apply: here there are gains to be made from symbiosis. By choosing to make a separate system Counterparty developers are hurting both Bitcoin and themselves.

Quote
In theory, at least.  Obviously the current problems are the result of this NOT happening.  Bitcoin changed a spec at the last minute, and Counterparty had to adapt in a way that the Bitcoin devs didn't like.  Makes me wonder what would have happened if this had simply been kept quiet by the Counterparty devs.  If they had just quietly resorted to using multisig (that is what they're using now, right?  It's hard to keep up) instead of OP_RETURN, without the furor on this forum, would the Bitcoin devs ever have noticed Counterparty?

I participated in those developer discussions, so let's get something clear: I was not, and I don't think any of the other developers were aware of Counterparty's intention to use OP_RETURN + 80 bytes. If so, there would have at least been better communication about the change. OP_RETURN should only ever be utilized in user transactions as a last resort, and even then as a temporary measure until some other infrastructure could be built, and certainly only for financial data relating to transaction processing. Examples would be 256-bit scalars or compressed public keys and a few bits of prefix data for stealth addresses. It was pointed out that under no circumstances would this exceed 40 bytes, so the rather arbitrarily chosen 80 byte limit was twice as big as it needed to be.

There is not and never has been an adversarial relationship between bitcoin developers and Counterparty developers. If we appear antagonistic, it is because we are being critical of the design of Counterparty, which is flawed and needlessly detrimental to Bitcoin.
hero member
Activity: 647
Merit: 510
Counterpartying
In theory, at least.  Obviously the current problems are the result of this NOT happening.  Bitcoin changed a spec at the last minute, and Counterparty had to adapt in a way that the Bitcoin devs didn't like.  Makes me wonder what would have happened if this had simply been kept quiet by the Counterparty devs.  If they had just quietly resorted to using multisig (that is what they're using now, right?  It's hard to keep up) instead of OP_RETURN, without the furor on this forum, would the Bitcoin devs ever have noticed Counterparty?

We were using bare multi-sig while waiting for .9 to come out, so nothing changed. We continue to use the same solution that we were before.

hero member
Activity: 700
Merit: 500
I don't think "built on Bitcoin" is the central idea. "Counterparty protocol" is the central idea.
We can have many choices besides bitcoin.

There are many people out there building Counterparty-like systems, many with their own blockchains.  It's an obvious next step for crypto-currencies.  Obviously it's the central "idea" of Counterparty in some sense.  Maybe I should have said that it was the central "insight" of Counterparty to be built on Bitcoin.

Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.

Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.

Well, we're disagreeing about the meaning of "on bitcoin" here; obviously you're right in one sense, and I'm right in another sense.  Counterparty was designed to work within the known existing constraints of Bitcoin, without requiring any change to Bitcoin itself.  Getting Counterparty transactions to be verified by miners would require tons of work, and it would be fraught with danger of screwing something up in the basics of Bitcoin itself.  However, by doing it this way, if there is something wrong with Counterparty, the larger Bitcoin ecosystem will not be affected at all.  Miners still mine, nodes still nodulate, nobody has to download a new client version or anything. 

There's a sort of partitioning of dangers and responsibilities which I think makes the overall system more robust.  It's kind of like encapsulation in programming: you work on your functions, and make sure that they work; and I'll work on my functions, and make sure that they work; and my functions don't have to know about the inner workings of your functions, and vice-versa.  It results in an efficient division of labor, where the Counterparty devs don't have to get involved with Bitcoin development, and Bitcoin devs don't have to get involved with Counterparty development. 

In theory, at least.  Obviously the current problems are the result of this NOT happening.  Bitcoin changed a spec at the last minute, and Counterparty had to adapt in a way that the Bitcoin devs didn't like.  Makes me wonder what would have happened if this had simply been kept quiet by the Counterparty devs.  If they had just quietly resorted to using multisig (that is what they're using now, right?  It's hard to keep up) instead of OP_RETURN, without the furor on this forum, would the Bitcoin devs ever have noticed Counterparty?
hero member
Activity: 602
Merit: 500
Totally agree. Counterparty's marketcap should be bigger than mastercoin at least. Counterparty is undervalued seriously.  Counterparty should take action in marketing and advertisement after the issue of the counterwallet. Let more people know Counterparty and use it.

Not want to start another meta discussion, but one may also think about implicit value besides available functionality. There are about 4000 BTC available to be spent over time for developement and other funding tasks. (yup, only about 15 % spent since Exodus and already leading to very interesting projects like XCP as side effect)

Funny
legendary
Activity: 905
Merit: 1012
There are plenty of other people working on building distributed-exchange coins from scratch.  Counterparty made the explicit decision not to be one of those guys.  To put it simply, "built on Bitcoin" is THE central idea behind Counterparty.  If you don't agree with that decision, you should be backing the other guys.

Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.

Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.
legendary
Activity: 1106
Merit: 1026
Totally agree. Counterparty's marketcap should be bigger than mastercoin at least. Counterparty is undervalued seriously.  Counterparty should take action in marketing and advertisement after the issue of the counterwallet. Let more people know Counterparty and use it.

Not want to start another meta discussion, but one may also think about implicit value besides available functionality. There are about 4000 BTC available to be spent over time for developement and other funding tasks. (yup, only about 15 % spent since Exodus and already leading to very interesting projects like XCP as side effect)
hero member
Activity: 602
Merit: 500

So it's better for counterparty to just react, instead of act? Are we really doomed to just follow the current trends? Piggybacking from one solution to the next?

What about actually taking a fucking stance? What about making a decision instead of letter other people make decisions for us.
This is the worst business advice ever. Is it a risk? Sure! But those that never take risks have nothing to gain.


Winning the race of utility but not usage?
I would posit that counterparty has less adopters now than when it started as some early adopters have sold out and moved on.

Even Satoshi himself thought PoW was an inherent weakness of the bitcoin protocol.

Counterparty is very active and is currently leading the second generation space with regards to functionality.

Counterparty is not piggybacking from one solution to the next, it is staying on Bitcoin. You are the one suggesting the project moves to another blockchain, then denouncing that very thing in a later post as you say "are we doomed to have to follow trends" while you pitch a PoS solution that is itself a new and upcoming trend in the digital currency space, while Bitcoin has been around forever and is much harder to consider a "trend".

Do you feel Counterparty has taken no risks? The project has been rife with risks from day one, and those risks are gradually being mitigated and eliminated.

What decentralized exchange is winning the race of "usage"? What decentralized financial market is winning the race of usage? Nobody. Let's check back on that in a few months or so.

So, according to you, early adopters sold some or all of their positions in XCP, and that somehow decreased the number of total XCP holders. How are you able to infer that everyone who has bought XCP over the past few months already held XCP?

I never said Counterparty wasn't leading in terms of functionality.
Nor did I say that Counterparty has taken no risks. But huddling behind bitcoin for protection is obviously an aversion to risk when we know that we have more to gain by leaving then by staying.

What you suggested in your previous post was that at a later time if it becomes necessary CP will move to another or its own blockchain (this would be reacting and piggybacking from one solution to the next).
What I suggested was a proactive decision to move not from one solution to the next, and the next, and the next (which is what will invariably happen should we continue down this road), but to move to a final solution.
Our own blockchain would be the final solution. You admitted it yourself. Why don't we just jump ahead a few years then and save ourselves some wasted time? We are wasting time trying to play nice with bitcoin when we could be growing.

According to you "PoS" is a trend and bitcoin has been around "forever". You know they thought email was just a trend? They said it was pointless and stupid and we would never have a need for it. But some people, they saw it for what it was. It wasn't a trend, it was a solution.

You calling PoS a trend shows where your mindset is.
To anyone outside our community bitcoin itself is a trend, or a scheme, or a fraud. You are equating what you and I know to what the world thinks it knows.

My comment regarding counterparty having less adopters was and is evident by the list of trading over the past two months on the exchanges. Any new adopters would have had to buy XCP from poloniex. We can see there has been very little trading on poloniex. So very little XCP was bought. I would also assume the majority of XCP bought on poloniex was from XCP holders. Obviously that is just a theory and is inconsequential anyway.


Look, you have no control over Counterparty.  Some pretty smart dudes have control over Counterparty.  If you want control over something, fork Counterparty yourself, or pay someone to do it for you.  Everyone's a critic, but few are artists.

There's a concept called over-engineering.  It is especially problematic in fast-moving industries such as cryptocurrencies.  Everything is moving so fast, you're saying "let's look 5 years on the horizon!" when nobody really knows what lies 5 years on the horizon.  Any plan that we made to hit a target 5 years from now, would need to be changed several times before we got there.  It's a moving target.

Proof-of-Stake is currently flawed.  There is no good implementation of pure Proof-of-Stake.  Maybe the entire idea will be discredited in 6 months, and the new concept will be called Proof-of-Something-Else.  Creating a Proof-of-Stake coin out of thin air and moving Counterparty to it would be a bad move.

The opposite of over-engineering is under-engineering.  Creating the least viable product.  The most minimal, simple implementation that can do what you want it to do.  Counterparty is this solution for the distributed exchange/Bitcoin 2.0 idea.  It works, today.  It does so by leveraging the existing Bitcoin network and protocol, which allows the developers to devote their time to getting the important parts right.  How much would the Counterparty codebase increase in size if it required its own blockchain?  I'm betting it would be somewhere in the triple to quadruple range.  Counterparty will continue to work for at least the near future.  If a day comes when it is made not to work by outside forces, Counterparty will change in order to work.

There are plenty of other people working on building distributed-exchange coins from scratch.  Counterparty made the explicit decision not to be one of those guys.  To put it simply, "built on Bitcoin" is THE central idea behind Counterparty.  If you don't agree with that decision, you should be backing the other guys.

I don't think "built on Bitcoin" is the central idea. "Counterparty protocol" is the central idea.
We can have many choices besides bitcoin.
hero member
Activity: 700
Merit: 500

So it's better for counterparty to just react, instead of act? Are we really doomed to just follow the current trends? Piggybacking from one solution to the next?

What about actually taking a fucking stance? What about making a decision instead of letter other people make decisions for us.
This is the worst business advice ever. Is it a risk? Sure! But those that never take risks have nothing to gain.


Winning the race of utility but not usage?
I would posit that counterparty has less adopters now than when it started as some early adopters have sold out and moved on.

Even Satoshi himself thought PoW was an inherent weakness of the bitcoin protocol.

Counterparty is very active and is currently leading the second generation space with regards to functionality.

Counterparty is not piggybacking from one solution to the next, it is staying on Bitcoin. You are the one suggesting the project moves to another blockchain, then denouncing that very thing in a later post as you say "are we doomed to have to follow trends" while you pitch a PoS solution that is itself a new and upcoming trend in the digital currency space, while Bitcoin has been around forever and is much harder to consider a "trend".

Do you feel Counterparty has taken no risks? The project has been rife with risks from day one, and those risks are gradually being mitigated and eliminated.

What decentralized exchange is winning the race of "usage"? What decentralized financial market is winning the race of usage? Nobody. Let's check back on that in a few months or so.

So, according to you, early adopters sold some or all of their positions in XCP, and that somehow decreased the number of total XCP holders. How are you able to infer that everyone who has bought XCP over the past few months already held XCP?

I never said Counterparty wasn't leading in terms of functionality.
Nor did I say that Counterparty has taken no risks. But huddling behind bitcoin for protection is obviously an aversion to risk when we know that we have more to gain by leaving then by staying.

What you suggested in your previous post was that at a later time if it becomes necessary CP will move to another or its own blockchain (this would be reacting and piggybacking from one solution to the next).
What I suggested was a proactive decision to move not from one solution to the next, and the next, and the next (which is what will invariably happen should we continue down this road), but to move to a final solution.
Our own blockchain would be the final solution. You admitted it yourself. Why don't we just jump ahead a few years then and save ourselves some wasted time? We are wasting time trying to play nice with bitcoin when we could be growing.

According to you "PoS" is a trend and bitcoin has been around "forever". You know they thought email was just a trend? They said it was pointless and stupid and we would never have a need for it. But some people, they saw it for what it was. It wasn't a trend, it was a solution.

You calling PoS a trend shows where your mindset is.
To anyone outside our community bitcoin itself is a trend, or a scheme, or a fraud. You are equating what you and I know to what the world thinks it knows.

My comment regarding counterparty having less adopters was and is evident by the list of trading over the past two months on the exchanges. Any new adopters would have had to buy XCP from poloniex. We can see there has been very little trading on poloniex. So very little XCP was bought. I would also assume the majority of XCP bought on poloniex was from XCP holders. Obviously that is just a theory and is inconsequential anyway.


Look, you have no control over Counterparty.  Some pretty smart dudes have control over Counterparty.  If you want control over something, fork Counterparty yourself, or pay someone to do it for you.  Everyone's a critic, but few are artists.

There's a concept called over-engineering.  It is especially problematic in fast-moving industries such as cryptocurrencies.  Everything is moving so fast, you're saying "let's look 5 years on the horizon!" when nobody really knows what lies 5 years on the horizon.  Any plan that we made to hit a target 5 years from now, would need to be changed several times before we got there.  It's a moving target.

Proof-of-Stake is currently flawed.  There is no good implementation of pure Proof-of-Stake.  Maybe the entire idea will be discredited in 6 months, and the new concept will be called Proof-of-Something-Else.  Creating a Proof-of-Stake coin out of thin air and moving Counterparty to it would be a bad move.

The opposite of over-engineering is under-engineering.  Creating the least viable product.  The most minimal, simple implementation that can do what you want it to do.  Counterparty is this solution for the distributed exchange/Bitcoin 2.0 idea.  It works, today.  It does so by leveraging the existing Bitcoin network and protocol, which allows the developers to devote their time to getting the important parts right.  How much would the Counterparty codebase increase in size if it required its own blockchain?  I'm betting it would be somewhere in the triple to quadruple range.  Counterparty will continue to work for at least the near future.  If a day comes when it is made not to work by outside forces, Counterparty will change in order to work.

There are plenty of other people working on building distributed-exchange coins from scratch.  Counterparty made the explicit decision not to be one of those guys.  To put it simply, "built on Bitcoin" is THE central idea behind Counterparty.  If you don't agree with that decision, you should be backing the other guys.
legendary
Activity: 1078
Merit: 1002
Bitcoin is new, makes sense to hodl.
An off topic question here and excuse me if its ridiculous,

How does one transfer xcp from a central exchange to an offline wallet?



just send it to a btc address that you have control of the private key, XCP address = BTC address

Quote
XCP is great, but I think before any major innovations come, we need to see what is going on with OP_RETURN.

Once there is clear consensus, everyone will know where XCP is headed.
[/quoted]

if we are banned from every corner, I bet PP should be able to find a way to compress XCP into 32 bytes OP_RETURN in the worst case
legendary
Activity: 1321
Merit: 1007
XCP is great, but I think before any major innovations come, we need to see what is going on with OP_RETURN.

Once there is clear consensus, everyone will know where XCP is headed.
Jump to: