We're back with our regular community updates! http://counterparty.io/news/counterparty-community-update-july-24/

For cryptocurrency sports bettors who want an alternative to centralized betting solutions, BetXCP is a peer-to-peer betting platform that eliminates the need for sportsbooks. Unlike sportsbooks, BetXCP is never in possession of customer funds.

So what happens when the bonds are traded around to random people on the DEX?  The distributions will be withheld until the bonds are held by someone with KYC?

Lending Bits bits looks like a great project, but in the USA wouldn't it violate SEC laws? US companies are not allowed to issue bonds unless they register with the SEC, not to mention they are not allowed to advertise/promote that they are raising financing unless they register with the SEC (this is the "general solicitation" rule).

This is an article about what seems to be fraudulent trading during the MT gOX days that may have been the real cause for BTC to go over $1000 at the time.

http://www.cryptocoinsnews.com/news/report-mtgox-fraud-led-to-1200-bitcoin-price/2014/05/25

It ends with an important paragraph that should be made part of our marketing message.

Can We Trust Centralized Exchanges?

This is not the first time that claims of fake trading data have been thrown at a Bitcoin exchange, but this possible fraud by MtGox would definitely have had an extremely large impact on the bitcoin price over the course of 2013. The impact could have been large enough to be the very basis for the boom, bust, consolidation, and repeat cycle that so many bitcoiners have come to know and understand over the years. BTC China CEO Bobby Lee has taken shots at other Chinese Bitcoin exchanges for possibly faking trading data, which points to the need for honest, transparent exchanges more than ever. After all, how is anyone supposed to know the real price of bitcoin if the data being used to create that price is completely fabricated?

Maybe its possible make some "default" post where is explain all what need about counterparty and countersport. And then xcp holders who like can translate it to own language and go write to local betting forums and tell about this new system.?

Yay!
I'm looking forward to my invitation to the Counter(block)party!

A new security has been announced. currently in IPO stage via CounterParty: DUNNECAP

In case you've missed some of the recent XCP listings over the past few days

DUNNECAP // Blockscan ticker

ROCKMINER // Blockscan ticker

ADEALLY // Blockscan ticker

[...]

b) Tiered pricing based upon the long description cannot be performed as the protocol is agnostic to the description.

Cross post from my reply at the official forums https://forums.counterparty.co/index.php/topic,150.msg1387.html#msg1387 regarding a hierarchy for utility and for controlling asset issuance costs:

When I suggested the hierarchy, I didn't give any thought about implementation. It seems people like the idea and I think there is a utility to this idea so here's an implementation idea which is pretty simple but enables pretty much what people are talking about.

Indeed by itself it would be too much of a code change. The asset names are coded as they are in many different tables and having long asset names would cause problems with the limited space we are working with a Bitcoin transaction.

So here is what I suggest to be a simple solution which is backwards compatible and forwards compatible with more adaptations to the price for issuing assets:

There are only two levels of assets distinguished at the protocol level. More than the second level is merely a client side visualization.

1) Add an additional column to the 'issuances' table called 'assetLongName'
2) Add an optional parameter to issuance --asset-long-name
3) A 'top level' is an asset which must have the asset name = asset long name (this can default if no asset-long-name is entered)
4) A 'top level' asset must conform to existing naming conventions
5) An 'lower level' asset is an asset which is only readily distinguishable by the asset-long-name. The asset name (ie the value being used now and passed around in the messages in transactions) cannot be user specified. The asset short name is generated at #6
6) When issuing a 'lower level' asset, the issuer cannot specify the asset name. The short asset name is generated from a hash of the asset-long-name (something like this http://stackoverflow.com/questions/548158/fixed-length-numeric-hash-code-from-variable-length-string-in-c-sharp)
7) When issuing a 'lower level' asset, in the asset-long-name a 'top level' asset name must already exist before the first period '.' in the string (left to right) .

Notes:
* Top level assets are premium priced - for example 5 XCP
* Lower level assets are priced enough to stop spamming of the network - for example 0.1 XCP
* Pricing can be replaced with proof of stake or whatever later
* By default clients can filter top level assets by only getting assets where the short name = long name
* In the long name for lower level assets, after the first period '.' most characters plus a few special characters like GLaDOS mentioned goes. It is up to the clients to fold up the names in a tree structure and organise it nicely. Clients can use lazy loading of tree structures to reduce overhead.
* All internal counterpartyd code continues to stay referencing the existing short name so it will limit recode
* It would then require some rework to allow commands such as 'order' 'send' to be able to reference the asset long name. However, this is not a #1 priority as the short asset name could be used in the interim.
* There is a limited space available for unique (short) asset names  so there will be some collisions with the hashing of the long name. If the hash is already taken, too bad you will need to vary the long name a little bit. That's the consequence of buying a lower level asset name
* Including a unique index on the asset-long-name column of the issuances table should be sufficient to maintain performance on this table

EDIT:
Some examples to show what I'm talking about.



Client visualization
     
Client visualization alternative - reflects the reality that there is only 2 levels