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

[ShroomsKit_Disgrace]

Why should I pay attention to XCP and not to MSC? 

[1715629358]

1715629358

[1715629358]

1715629358

[dpb]

Why should I pay attention to XCP and not to MSC? 

Why not both?

I prefer Counterparty to Mastercoin because it was the first working decentralized exchange on which I was able to create an asset. I also like the proof-of-burn distribution model more than the developers-have-an-unfair-advantage distribution model. I want as many layers of decentralization as possible; I don't want to support projects meant to promote neutrality that give special privileges to groups or individuals.

[zero3112]

So where do mastercoins come from?  How are they made and why can't unlimited be made. I don't understand how you get mastercoins if you can't mine them. For me Mastercoin looks like another ripple with unfair distribution and no mining.

I think I like the philosophy behind Counterparty better than mastercoin. So my personal choice would be Counterparty.

- Now I am just looking to have technical questions answered. What are the differences between the technical protocols of Mastercoin vs. Counterparty.
- What are the confirm times of blocks on both of these coins?
- How many coins will there ever be on both of the coins?
- What algorithm do they use that is comparable to mining?
- What features does one offer that the other can't offer?

[Chang Hum]

So where do mastercoins come from?  How are they made and why can't unlimited be made. I don't understand how you get mastercoins if you can't mine them. For me Mastercoin looks like another ripple with unfair distribution and no mining.

I think I like the philosophy behind Counterparty better than mastercoin. So my personal choice would be Counterparty.

- Now I am just looking to have technical questions answered. What are the differences between the technical protocols of Mastercoin vs. Counterparty.
- What are the confirm times of blocks on both of these coins?
- How many coins will there ever be on both of the coins?
- What algorithm do they use that is comparable to mining?
- What features does one offer that the other can't offer?

The best person to answer these questions is probably Bellebite2014

[ShroomsKit_Disgrace]

GOOD QUESTIONS

The best person to answer these questions is probably Bellebite2014

Every time someone asks you good questions about XCP-MSC differences, advantages and disadvantages you answer by referring the question to a troll... 

[NewLiberty]

So where do mastercoins come from?  How are they made and why can't unlimited be made. I don't understand how you get mastercoins if you can't mine them. For me Mastercoin looks like another ripple with unfair distribution and no mining.

I think I like the philosophy behind Counterparty better than mastercoin. So my personal choice would be Counterparty.

- Now I am just looking to have technical questions answered. What are the differences between the technical protocols of Mastercoin vs. Counterparty.
- What are the confirm times of blocks on both of these coins?
- How many coins will there ever be on both of the coins?
- What algorithm do they use that is comparable to mining?
- What features does one offer that the other can't offer?

Both use the bitcoin block chain so confirm times are the same.
There are no new coins of either.  There are more Mastercoin than Counterparty
Since they are on the bitcoin block chain, they use the same algorithms of bitcoin, they are not separately mined, or merge mined, they use the bitcoin protocol as the fundamental layer.

The feature sets are fairly similar, the implementations have significant differences.  Both of these change rapidly though as they are under heavy development.

[IamNotSure]

Both use the bitcoin block chain so confirm times are the same.
There are no new coins of either.  There are more Mastercoin than Counterparty
Since they are on the bitcoin block chain, they use the same algorithms of bitcoin, they are not separately mined, or merge mined, they use the bitcoin protocol as the fundamental layer.

The feature sets are fairly similar, the implementations have significant differences.  Both of these change rapidly though as they are under heavy development.

Mistake here, there are approx 4.27 times more XCP than MSC

[NewLiberty]

Both use the bitcoin block chain so confirm times are the same.
There are no new coins of either.  There are more Mastercoin than Counterparty
Since they are on the bitcoin block chain, they use the same algorithms of bitcoin, they are not separately mined, or merge mined, they use the bitcoin protocol as the fundamental layer.

The feature sets are fairly similar, the implementations have significant differences.  Both of these change rapidly though as they are under heavy development.

Mistake here, there are approx 4.27 times more XCP than MSC

Thank you, I need my delsexia meds.
There are:
 619478.6 MSC
2648755 XCP

[baddw]

I don't know if this meets all of the requirements stated, but based on a quick skimming of P2SH^2 and your Proof-of-Publication paper, here's a rough idea of an "attack" to store arbitrary data.  This would require a tiny amount of brute-forcing, and it is not dust/fee-efficient, but I think it would work.  I was unable to find the "2.0" discussion.

You missed the part where I said "no-brute-forcing" - I'm talking about something quite different that takes advantage of what P2SH^2 does. However, the rest of your post would work and is actually pretty clever, so sent you a tip all the same.

Hey, thanks man!  I like these games    Unfortunately I am not very well-read on a lot of this stuff, but I've been convinced for a long time that it's impossible to prevent hiding data in Bitcoin transactions, unless somehow every output address is pre-approved, which is of course impossible without completely wrecking Bitcoin.  The P2SH^2 idea seems to be trying to add a bit of "verification" to output addresses, but even requiring 2 hashes doesn't really change anything.  It makes it a bit harder, but as long as output addresses are essentially arbitrary, there's no way to prevent some attack along these lines from working.

And I didn't "miss" the brute-forcing, I just kind of ignored it because the brute-forcing in this scheme would (unless I'm way off somehow) only require a few milliseconds of computation for a single-byte encoding, as you'd only need to come up with hashes starting with A-Z, a-z, 0-9.

[jtimon]

Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain.

You wouldn't have to solve any problem if your chain validated your transactions. You wouldn't need to bloat your chain with open orders like mastercoin and counterparty (if I understand correctly) do.
Colored coins don't put the open orders in the chain, but not all colored aspects of a colored coins transactions are validated.
If your chain validated all you need it to validate, you could even have SPV clients consuming a committed UTXO (something non-hardfork colored coins cannot give you).

I don't know mastercoin and counterparty deeply but I believe they use "accounts" (like ripple.com) instead of inputs/outputs (like bitcoin and freimarkets), which is another design mistake.

Too many efficiency sacrifices only to avoid bootstrapping your own chain like namecoin did when it wanted to support additional features.
If we all bitcoin users want to support these features in the bitcoin chain, there's a better way to do it: a hard fork.
I'm all for this features (asset issuance, p2p trade, ripple-like transitive trades, options, etc) in Bitcoin's main chain myself, but the right way.

[LightedLamp]

Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain.

You wouldn't have to solve any problem if your chain validated your transactions. You wouldn't need to bloat your chain with open orders like mastercoin and counterparty (if I understand correctly) do.
Colored coins don't put the open orders in the chain, but not all colored aspects of a colored coins transactions are validated.
If your chain validated all you need it to validate, you could even have SPV clients consuming a committed UTXO (something non-hardfork colored coins cannot give you).

I don't know mastercoin and counterparty deeply but I believe they use "accounts" (like ripple.com) instead of inputs/outputs (like bitcoin and freimarkets), which is another design mistake.

Too many efficiency sacrifices only to avoid bootstrapping your own chain like namecoin did when it wanted to support additional features.
If we all bitcoin users want to support these features in the bitcoin chain, there's a better way to do it: a hard fork.
I'm all for this features (asset issuance, p2p trade, ripple-like transitive trades, options, etc) in Bitcoin's main chain myself, but the right way.

You've also failed to read deeply into this thread. Reposting service: free, tips - welcome.

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

[BitcoinTangibleTrust]

Product and Service Updates March 31, 2014
Our mission is to digitize all valuable assets into the Counterparty platform and to build a trustless, yet reputable service that delivers unmatched ability to access asset markets, globally.

Purchasing 1/2 Ounze of Gold with Bitcoin Tangible Trust process and Counterparty community member led_cd/Global_trade Repo:

Proof of Purchase Received:
We have received and published Proof of Purchase from Agora for led_cd's gold. You may review the proof of purchase here: http://bitcointangibletrust.com/assets/

With the confirmation of Proof of Purchase, we used Counterparty send command to deliver to led_cd his new digital gold coin.
You may verify the asset detail here: http://blockscan.com/assetinfo.aspx?q=GLDAGOAAAAAAA

Why use BitcoinTangible Trust?
As we continue to work with new customers, here are some of the reasons why customers say they would like to use this service:

• Buyers like their digital gold coins attached to their BTC address
• Buyers want a difficult process to be made easy for purchasing precious metals fast
• Buyers want to be anonymous and there is HUGE anonymous buyer demand
• Buyers don't want to worry about details of precious metals storage, insurance, bonding, audits, KYC/AML etc

Thank you Counterparty Devs and the Counterparty Community.

Special thanks to Peter Todd for the congrats over the weekend.
Bitcoin Tangible Trust Team
Cross Posted to Counterparty Forums: https://forums.counterparty.co/index.php/topic,203.0.html

[GLaDOS]

I don't know if this meets all of the requirements stated, but based on a quick skimming of P2SH^2 and your Proof-of-Publication paper, here's a rough idea of an "attack" to store arbitrary data.  This would require a tiny amount of brute-forcing, and it is not dust/fee-efficient, but I think it would work.  I was unable to find the "2.0" discussion.

You missed the part where I said "no-brute-forcing" - I'm talking about something quite different that takes advantage of what P2SH^2 does. However, the rest of your post would work and is actually pretty clever, so sent you a tip all the same.

Hey, thanks man!  I like these games    Unfortunately I am not very well-read on a lot of this stuff, but I've been convinced for a long time that it's impossible to prevent hiding data in Bitcoin transactions, unless somehow every output address is pre-approved, which is of course impossible without completely wrecking Bitcoin.  The P2SH^2 idea seems to be trying to add a bit of "verification" to output addresses, but even requiring 2 hashes doesn't really change anything.  It makes it a bit harder, but as long as output addresses are essentially arbitrary, there's no way to prevent some attack along these lines from working.

And I didn't "miss" the brute-forcing, I just kind of ignored it because the brute-forcing in this scheme would (unless I'm way off somehow) only require a few milliseconds of computation for a single-byte encoding, as you'd only need to come up with hashes starting with A-Z, a-z, 0-9.

Disclaimer:  I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data.  In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions?  Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values.  ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.

[maaku]

LightedLamp, I don't think that person you are quoting understands what we mean by "side-chain." There would be no storing of hashes via OP_RETURN, and no referencing of external transactions. A side-chain is just another block chain, but one which allows transfer of value back and forth between itself and the bitcoin chain (and other chains too). So you can move coins onto the side-chain, do whatever fancy transactions you want (e.g. distributed markets), and then move back when you are done.

[Peter Todd]

LightedLamp, I don't think that person you are quoting understands what we mean by "side-chain." There would be no storing of hashes via OP_RETURN, and no referencing of external transactions. A side-chain is just another block chain, but one which allows transfer of value back and forth between itself and the bitcoin chain (and other chains too). So you can move coins onto the side-chain, do whatever fancy transactions you want (e.g. distributed markets), and then move back when you are done.

Well if we're not going to call what I was talking about as a side-chain, what term do we want to use for the notion of a chain that consists of hashes embedded in one blockchain, that refer to data that we're not storing on that blockchain? Do you want to reserve the term side-chain for only a specific way of moving value from one to the other? Because from the user's point of view handling that by atomic purchases of shares for coins or whatever doesn't look much different from the SPV proofs model. You also have to ask if a side-chain refers to a specific proof-of-work consensus, or things like proof-of-sacrifice apply as well - and as I argued above, if the "hashes that refer to data stored elsewhere" has any hope of being secure you need actual incentives to publish and thus something like proof-of-sacrifice and a chain-style structure.

[maaku]

Didn't know that quote was from you Peter. I would reserve the phrase "side-chain" for things that actually involve chains other than bitcoin at the very least. Anyway the complaint was that the quote had nothing to do with the concept of a side-chain jtimon was talking about.

[Peter Todd]

Disclaimer:  I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data.  In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Yeah, you're basically limited by how much space you have for that dictionary. For instance a 32-bit brute force dictionary, stored as 32-bit seeds, would be 17GiB.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions?  Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values.  ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.

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?

[baddw]

Disclaimer:  I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data.  In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Yeah, you're basically limited by how much space you have for that dictionary. For instance a 32-bit brute force dictionary, stored as 32-bit seeds, would be 17GiB.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions?  Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values.  ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.

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?

Peter, could you supply a link to any and all P2SH^2 information?  I'm afraid that what I found (a single short thread on the bitcoin devs mailing list) was not terribly complete (or maybe I'm just lacking on background implementation info).

I do appreciate your taking the time to teach.

[Peter Todd]

Peter, could you supply a link to any and all P2SH^2 information?  I'm afraid that what I found (a single short thread on the bitcoin devs mailing list) was not terribly complete (or maybe I'm just lacking on background implementation info).

I do appreciate your taking the time to teach.

That thread is the best resource on what P2SH^2 is; the question isn't so much about implementation, but rather understanding why Bitcoin works and what exactly is the role of mining.

[Patel]

This is where 80 bytes OP_RETURN will take Bitcoin