When you look for a platform that can weathered the storm best, would you put your most valuable assets on an inflatable raft tied to the Bitcoin boat?

I think most businesses would rather stay on BitcoinXCounterparty.

We'd have to wait for an actual P2SH^2 implementation.
But from the P2SH^2 discussion, it looks like the data would be relayed/published along with the P2SH^2 even though it will not be not stored.

Just like P2SH, we'd be pushing transactional data from one end to the other only to add even more bloat in the end.  One of the reasons given to deter OP_RETURN was that blockchain bloat would further reduce the economic incentive for full nodes.  It's a bit absurd since there's very little economic incentives for full nodes now.  The fees only go to the miners.

As the blockchain grow and grow, the only incentives for full nodes may actually come from projects on top of Bitcoin such as the current MsC/XCP crowds.

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

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.

and not only that, but for now this faucet is sending out more BTC than some BTC faucets.

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.

Not only that, wouldn't you need a feed to lock the drawings into the protocol or the timings can easily be skewed depending on parsing times?

If that's the case, it can just be Counterparty with a feed for the drawings and a small % going to the feed operator for the incentive.

If I am not mistaken, most of the simple operations should take less than 40 bytes already for both MSC and XCP.

It just makes it unnecessarily complicated for feeds, asset issuances, etc..when a few more bytes could keep things simple.

e.g. for some operations like asset issuance we could make two or more OP_RETURN40 operations.  But it's even more bloat.

  , 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.

Going through all the recent posts, it feels as if everyone is almost on the same page even though some external media would have us believe of endless debates over irreconcilable differences between the devs.  It's natural that we feel uneasy about OP_RETURN and its possible consequences if one of our highest priority is to protect the blockchain from spam.  If anything, it makes me appreciate the core devs a little more for handling these challenges.

Now think back a few years...the Bitcoin design paper may not even be completed -- let alone a working client -- had Satoshi insisted on including other features such as markets, assets, contracts, and all the possible financial transactions.

Instead Satoshi opted for a simple version of electronic cash and a simple script as a way to add more features in the future.  Today, script gives us a simple OP_RETURN that could bring all those features and more.  And yet we look for a more complicated solution.

Instead, think of jgarzik's updated OP_RETURN as the simple extension to allow features that would be too limited via script.  There is no need to enable dangerous OPs for transactions that can run at the upper layer.  Yes, allowing arbitrary data seems dangerous because there will be people who will try to stuff junks into the txns.  On the other hand, it opens up a world of possibilities for non-core developers to create unimaginable transactions. Trying to deter OP_RETURN is like trying to hold back the first message boards because of spams.

If it's possible to have an OP_RETURN with variable payloads and appropriate fees in place as advocated by Peter Todd and PhantomPhreak, Bitcoin and its upper layers would soon leave most of the new competitors in the dust.  The significant of a simple OP_RETURN can multiply many times beyond current implementations such as XCP and MSC.  Yes, we could be building secondary chains, efficiently merged solutions, or even DHTs of DHTs.  One day.  For today, Bitcoin just needs a simple OP_RETURN.



One would expect satoshi to be monitoring the XCP/MSC threads closely and may even provide feedbacks as a detached observer.  topynate provided some very insightful posts (in an almost academic-like style), showed us the futility of trying to classify OP_RETURN as carrying non-finanical data, and even quoted satoshi to remind us of the comparable "unstructured simplicity" in an OP_RETURN.  That embodies the ideals of satoshi for many.  Of course, satoshi would need a stealth address since he could not move those unsteathed coins without being noticed now

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

Long asset names should not be changeable just like short names.   The long names are enforced at the time of issuance to be valid only if the issuer also owns the top level asset. 

Afterward everything should go through the protocol using only the short names.

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.

I tried an actual example based from this suggestion on the official forum.  

Here's how it could work if we really do have 256^8 = 18446744073709551616 names according to PhantomPhreak.

1. User issues asset CAKE.
   This steps works normally by creating the top level asset CAKE.

2. User issues asset CAKE.CHOCOLATE
   a. Since this is not a top level asset (it has the dot), the client software will hash CAKE.CHOCOLATE and fold it into range using hash256(CAKE.CHOCOLATE) %  18446744073709551616 = 14342628182955096483.  Now it will encode the ASSET_ID of 14342628182955096483 into base26 to get a valid asset name of FUHSJLMRZXYYVR.
  
   b. Client checks that I own CAKE.  If so, it sets the protocol to issue FUHSJLMRZXYYVR setting the long name to CAKE.CHOCOLATE

3. User issues asset CAKE.STRAWBERRY
   a. Again, the client will hash CAKE.STRAWBERRY using hash256('CAKE.STRAWBERRY') %  18446744073709551616 = 12954728149517977030 resulting in this asset name: FFTOTODXVAJETA

   b. Client checks that the user owns CAKE before issuing FFTOTODXVAJETA with the long name of CAKE.STRAWBERRY

4. User issues asset CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP
   a. Client hashes hash256('CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP') %  18446744073709551616 = 14967343411115770189 or GAVXSUXGXBLXSV

   b. Client checks that user owns CAKE.  Unfortunately, a squatter knew that the user would be issuing this delicious cake and squatted the asset name GAVXSUXGXBLXSV. It just means that the CAKE owner has change the long asset name a bit to avoid this collision.  Because the squatter does not own CAKE, the long asset name for GAVXSUXGXBLXSV could not be CAKE.DOUBLEFUDGECREAMYVANILLAWITHCHOCOLATECHIP.

5. When we buy/sell CAKE.CHOCOLATE and CAKE.STRAWBERRY, we will actually be exchanging FUHSJLMRZXYYVR and FFTOTODXVAJETA through the Counterparty protocol.  Our clients/blockscan will show the long asset names.

As far as I can tell, this suggested implementation should work and be compatible with the existing protocol.  
This is actually another great suggestion the more I think about it now.

It reminds me of the 8.3 short/long filename.  It should be okay to allow lowercase characters, numbers, and symbols for the long asset name since it will be hashed and encoded into base 26 anyway.

An simple idea that seems to have been ignored on the official forums...

Wouldn't it be easier to just allow dots in the asset names (hint:  Global_trade_repo's hierarchy idea)?

That way BTT.UNIQUESILVER and BTT.RARECOIN would not collide with someone else's UNIQUESILVER and RARECOIN?
As suggested by Global_trade_repo, the asset names with dots in them could cost less to issue.

Not only that, but the buyers could be more confident that the assets were issued from BTT without rechecking/verifying the description/catalog.  An impostor could issue a VERYRARECOIN with a description poiting to BTT's catalog for example.  But the impostor cannot fake a BTT.VERYRARECOIN asset if it's required to own the BTT asset first.

We should also allow other characters such as #, $, %, and digits after the dot in the asset names.  So BTT can issue BTT.SILVER$100  or BTT.GOLD#1906 for example.


Otherwise, assuming a business can issue 100000+ assets, how does it go about organizing/tracking assets efficiently?  It much easier to match BTT.GOLD#1906 or BTT.RAREGOLD#18394 from a catalog than to search for BTT.GOLDXFR and BTT.RAREGOLDSXR to identify the asset.


If Counterparty is a protocol like TCP/IP, then we will need a flexible asset naming scheme that works almost like the domain naming system.

Thanks for creating this. 

I will send out some CAKE.  Everyone who received XCP from this faucet should be getting a little more XCP soon.

Are you suggesting that assets for games will be the most popular in Counterparty?

On the other hand, a crowfunding system on top of Counterparty could replace kickstarter completely or reduce the fees to almost nothing.  Not only that, but there would be no centralized entity to make arbitrary decisions to pull project listings.

Short Version Snapshot
Every feature in the Counterparty protocol has been implemented/working for awhile now...if you run it with the command line. 
The BoottleXCP GUI is one alternative to avoid the command line.
The web wallet is still being tested. 
More details can be found from this post: https://bitcointalk.org/index.php?topic=395761.0

If anyone wants to give it a try and get some FREE XCP, please post your address in the following thread:
https://forums.counterparty.co/index.php/topic,118.0.html

Or just PM me there on the official Counterparty forum.

Here's what will happen:
 1. I will send you 100 CAKE.
 2. Once 10000 CAKE have been given away, I will issue an XCP dividend to all the CAKE shareholders.

Long Version
I also plan to try a CAKE dividend with Mastercoin someday.

I tried a few things, but could not reproduce that error message.
Did you wait until Counterparty finish parsing up to the latest blocks?

Here's what always works for me so far.
1. Restart system
2. Start bitcoin-qt and wait until it syncs to the latest block
3. Start Counterparty and wait until it catches up to the latest block
4. Try to run the send command

This would work much better once we have the web wallet.

Once XCP is more accessible to the mass, many IPOs and crowdfunding projects can easily be done without the high fees.

That theme looks amazing! 

Also remember, you can get free XCP dividends by requesting some CAKE on the official Counterparty forum.